[mythtv-users] Upgrade from 0.26 to 0.27 broke firewire

[DaveD]

On 06/25/2014 08:24 PM, Jean-Yves Avenard wrote:
> On 26 June 2014 13:01, DaveD <mythtv at guiplot.com> wrote:
>> I have a master BE/FE system that's never missed a show in several years
>> until I upgraded my system.  I went from Fedora 17 to Fedora 20, which
>> upgraded Myth from 0.26 to 0.27.  The firewire of F17 was already the newer
>> "juju"  drivers, reference at http://www.mythtv.org/wiki/FireWire, but it's
>> hard to say what else might have "upgraded".
>>
>> It works for quite some time before crapping out (log starts filling with
>> "LinuxController recorders/linuxfirewiredevice.cpp:646 (run) -
>> LFireDev(0023A3FFFE4EDD2A): No Input in 50 msec..."
>> then 100 msec, then 150 msec, etc, until "ResetBus" then it starts over at
>> 50 msec).  Today it recorded a one-hour show, then a half-hour show, then
>> crapped out 10 minutes into the second half-hour show.  This is typical.
>> Some times it craps out early in the first show.  Once it even got all three
>> one day, then crapped out the next day.  Once it craps out, I have to
>> restart the backend.  Whatever that does, it makes it work again for a
>> while. I've watched hours of "Live" TV over the firewire and it never
>> crapped.  Only on scheduled shows, usually near the beginning of a show.
>>
>> Why can't Myth "reset" the connection the way restarting the backend does?
>> (that's a bit rhetorical, since it shouldn't need to if it worked like 0.26
>> did, but still...)
>>
> there's been ZERO change on anything related to firewire between 0.27 and 0.27
Maybe there SHOULD have been...?
>> I'm looking for advice (other than "get a cable card").  Something has
>> changed, and not for the better.
> if something has changed, it's not in myth.
>
> I'm not saying there's no problem in myth, all your upgrade may have
> revealed a corner case that cause myth to now fail.
>
> But if it fails with 0.27, it would also fail with 0.26
So, here's what I've tried, and found, so far:  I have a slave backend 
with its own cable box (Pace on the slave, Motorola on the master, which 
is where the problem is).  The slave runs the same versions of OS and 
Myth as the master and has had no issues after the upgrade.  It is 
available for some of the shows that require a cable box and I used it 
where I could.  For the other shows that are on during a time when the 
slave is unavailable, I have been using test-mpeg2, scheduled with cron 
(mplayer for playback, which is very poor WAF rating) and not a single 
recording failed.

Then, today, for a test, I scheduled a 2.5-hour movie and, sure enough, 
about 30 min in it stopped recording and started spamming the backend 
log every 50 mS with "No Input in XXX msec..."  A week's worth of shows 
(about 15 hours of recordings) and not a single problem using 
test-mpeg2.  30 minutes with myth and it fails.  I stopped the backend 
and finished recording the rest of the movie with test-mpeg2.  I don't 
know if I had to stop the backend, but I wanted it to stop filling the 
hard drive with log messages.  I did nothing except run test-mpeg2 (no 
reset of the cable box or anything) and it just works.

Conclusion:  mythbackend is at fault as recordings with cron and 
test-mpeg2 work flawlessly (as long as I remember to pre-set the 
channel).  Any advice on what to try next to find the cause?

Dave D.