[mythtv-users] firewire fragility

Tue Jun 14 12:48:38 UTC 2011

This could be completely wrong, but you might want to check whether your
firewire card is in a slot sharing IRQ's with your hard drive controller.  If
it is sharing, you might try moving it to a different slot, as this could
potentially be what your problem is.

Just a thought.

At Mon, 13 Jun 2011 18:21:03 -0400 (EDT), you wrote
>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
>
>_______________________________________________
>mythtv-users mailing list
>mythtv-users at mythtv.org
>http://www.mythtv.org/mailman/listinfo/mythtv-users

----