[mythtv-users] firewire fragility

[Noah Meyerhans]

Hi all. I recently switched to firewire after previously using WinTV
cards.  My firewire card is a Via VT6306/7/8 [Fire II(M)] (as reported
by lspci) and my cable box is a Comcast DCX-3200.  I'm using a build of
mythtv based on the fixes/0.24 branch from github.  In general, this
setup works great.  I get access to all the SD and HD channels I've
tried, and channel changing works well.  However, HD recording seems
really sensitive to other IO activity on the system.

If the system is doing nothing but recording, it can record HD all day
with no problems at all.  However, if I connect to the backend with
either mythweb or mythfrontend, or if commercial flagging is running
while a recording is in progress, there's a very high likelihood that
mythtv will somehow loose its ability to read the firewire stream.  It
won't actually stop recording, but it won't ever write new data to the
output file.  When this happens, mythbackend logs output similar to:

2011-06-13 00:48:05.844 MainServer::ANN Monitor
2011-06-13 00:48:05.844 adding: yyz as a client (events: 0)
2011-06-13 00:48:05.845 MainServer::ANN Monitor
2011-06-13 00:48:05.845 adding: yyz as a client (events: 1)
2011-06-13 00:48:05.868 LFireDev(0025F1FFFE4287C8), Warning: No Input in 200 msec...
2011-06-13 00:48:05.918 LFireDev(0025F1FFFE4287C8), Warning: No Input in 250 msec...
2011-06-13 00:48:05.965 AFD: Opened codec 0xf110f330, id(MPEG2VIDEO) type(Video)
2011-06-13 00:48:05.965 AFD: codec AC3 has 6 channels
2011-06-13 00:48:05.966 AFD: Opened codec 0xf110fe30, id(AC3) type(Audio)
2011-06-13 00:48:05.969 LFireDev(0025F1FFFE4287C8), Warning: No Input in 300 msec...
2011-06-13 00:48:06.019 LFireDev(0025F1FFFE4287C8), Warning: No Input in 350 msec...
2011-06-13 00:48:06.070 LFireDev(0025F1FFFE4287C8), Warning: No Input in 400 msec...
2011-06-13 00:48:06.120 LFireDev(0025F1FFFE4287C8), Warning: No Input in 450 msec...
2011-06-13 00:48:06.171 LFireDev(0025F1FFFE4287C8), Warning: No Input in 500 msec...
2011-06-13 00:48:06.221 LFireDev(0025F1FFFE4287C8), Warning: No Input in 550 msec...
2011-06-13 00:48:06.272 LFireDev(0025F1FFFE4287C8), Warning: No Input in 600 msec...
2011-06-13 00:48:06.322 LFireDev(0025F1FFFE4287C8), Warning: No Input in 650 msec...
2011-06-13 00:48:06.373 LFireDev(0025F1FFFE4287C8), Warning: No Input in 700 msec...
2011-06-13 00:48:06.423 LFireDev(0025F1FFFE4287C8), Warning: No Input in 750 msec...
2011-06-13 00:48:06.474 LFireDev(0025F1FFFE4287C8), Warning: No Input in 800 msec...
2011-06-13 00:48:06.524 LFireDev(0025F1FFFE4287C8), Warning: No Input in 850 msec...
2011-06-13 00:48:06.579 LFireDev(0025F1FFFE4287C8), Warning: No Input in 900 msec...
2011-06-13 00:48:06.629 LFireDev(0025F1FFFE4287C8), Warning: No Input in 950 msec...
2011-06-13 00:48:06.680 LFireDev(0025F1FFFE4287C8), Warning: No Input in 1000 msec...
2011-06-13 00:48:06.730 LFireDev(0025F1FFFE4287C8), Warning: No Input in 1050 msec...
2011-06-13 00:48:06.730 LFireDev(0025F1FFFE4287C8): ResetBus() -- begin
2011-06-13 00:48:06.731 LFireDev(0025F1FFFE4287C8), Warning: Bus Reset disabled
                        eno: Success (0)
2011-06-13 00:48:06.731 LFireDev(0025F1FFFE4287C8): ResetBus() -- end

It will continue to spew several of those messages per second for the
duration of the recording schedule, or until I cancel the recording.
If, after cancelling the recording, I re-schedule recording of the same
program, things are OK (unless, of course, something else generates IO
load).  Things were worse before I disabled the firewire bus reset using
mythtv-setup.  When reset was enabled, it'd keep resetting the bus, but
would still never actually be able to recover from the problem.

The problem doesn't appear to be within the kernel or the firewire
driver, as the kernel doesn't log anything when this happens and
subsequent recording attempts do work.  If I had to guess, I'd say that
it looks like mythtv is losing some kind of synchronization with the
firewire stream, maybe due to dropped data, and is never able to find
its place again.  Maybe it's looking for a particular marker or other
bit of data that has either already passed or been dropped due to IO
load.  If this is the case, maybe re-opening the firewire connection
would be enough to work around the problem.

For the moment, I've worked around the problem by scheduling my viewing
sessions to not conflict with any recordings that I might care about,
and allowing commflag jobs to only run early in the morning, when few
recordings happen.  This isn't an ideal situation, and I'd love to solve
the problem permanently.  Has anybody seen (and better yet, solved)
similar behavior?

I'm happy to provide more details if they'd be helpful.

Thanks.
noah

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.mythtv.org/pipermail/mythtv-users/attachments/20110613/ff9db956/attachment.bin