You might want to add Resolved to the end of the subject line of the first post.

Is the underlying issue *really* resolved?

I've never had any issues with DMA modes and my hdparm results are very fast. I didn't find that increasing buffer sizes affected it greatly.

I found that ivtv 0.10 has helped a bit - but I occasionally still get dropping data messages. I changed to 0.10.1 this morning - we'll see if that helps things, since there was a change in the changelog that mentioned this issue.

I also read that the real problem was in MythTV - but I haven't tried to do an SVN build. That might be the *real* fix.

When I was having the worst issues - I had two PVR-150's capturing at 720x480 and a third in a slave backend. I moved the second PVR-150 in the master backend to another slave - the issue persisted.

I think I actually made things worse by storing all recorded data on the master - there were issues with XBMCMythTV that kept me from storing data locally on the slaves - but I resolved that by modifying the Python code.

Now that I have the newer ivtv drivers and data being stored on the local machines, things are not too bad - but I still get the occasional dropping data messages. Before this upgrade, I *never* had dropped data.

I'll have to see how the system works going forward...

Edit: This is the MythTV issue that I was following recently:

http://svn.mythtv.org/trac/ticket/1660

I don't know if the underlaying issue is completely resolved (i'd guess it's not, I do still get IOBOUND errors in my kern.log if there is lots going on at the same time).

It is however resolved to the point where I can record shows without having multiple errors on every single show I record... which is what I was seeing previously.

An update to 0.10.x is something I do have in the back of my mind if things start to act up again, especially if others state that they are seeing a positive change from it.

My concern with moving to the new IVTV driver is that I can't specify my buffer size. If 0.10.x performs better than 0.8.2 with the default 4mb buffers, but worse with the 4mb compared to my current 0.8.2 64mb buffers then I really haven't improved my situation, even though the new drivers may technically be performing better. Know what I mean?


I have a system that seems to be working for me (at the moment) and this entire ball of wax is a work in progress, all aspects of this seem to be getting regular tweaks and fixes, so as long as I can make this work until the next release I'm a happy camper.

Thanks for pointing out that the underlying issues may (likely are) still be present though.

_________________
Currently Running:
Too lazy to update this with my current hardware, I'll redo it during my next install =)

I was also concerned by the comment regarding not being able to set the buffer sizes in 0.10.x, but in my case it seems to have helped things a bit.

It is quite easy to reinstall 0.8.2 by doing a "make install" in the directory of the desired version (after a make obviously).

I may try doing an SVN build on MythTV - but I'd like to see how the current config runs for a bit. Right now it is *much* better than it was a few weeks ago...

I was still having skips and many "dropping data" messages in the logs - so I bit the bullet and did an upgrade to the SVN trunk.

This seems to have completely fixed my skipping problems.

How badly did it muck up your mythweb interface?

_________________
Currently Running:
Too lazy to update this with my current hardware, I'll redo it during my next install =)

I noticed a few things were messed up - but it wasn't too bad.

I've had so many issues with MythWeb, rendering blank pages, unable to allocate memory, etc... that I really don't use it too much other than to check status.

I have had a few more "dropping data" messages, though. There are definitely less "skips" than before...