[mythtv] change in cablebox behavior / firewire lockup

Martin Purschke mlp00 at optonline.net
Fri Sep 11 16:31:44 UTC 2009


Replying to my own post...

The solution to the firewire lockup problem I had in mind is indeed
effective. I kludged up my existing  0.21 version with a hard-coded 15s
delay, and the recordings now work 100%.

The next step would be to add this in a more configurable and standard
way. I'll be away from home and my mythtv box for two weeks and will try
produce a patch when I'm back.

	Martin	

Martin Purschke wrote:
> I could need some advice to overcome an annoying problem that cropped up
> recently.
> 
> Cablevision on Long Island switched a number of channels to
> "switched-video", meaning that the (SA4250HD) cablebox talks to some
> upstream server to request that particular video stream, rather than
> just picking from streams that arrive all the time. That results in a
> long channel change delay, 10-15s or so. The backend process gets a lock
> on the firewire early on from the channel that the box had been tuned to
> before and starts recording, but then loses the lock after the channel
> change actually takes effect. The end result is a recording of a few
> seconds, a few hundred KB; the recording stops after that.
> 
> What's worse, the backend process seems to lock up when that happens.
> While it's still there, I have to kill and restart it.
> 
> My current workaround is that I preset the box to the next-requested
> channel, but that obviously works only when I'm around to do that.
> 
> I have been looking for a way to delay the onset of the actual
> recording, that is, issue the change-channel command, then wait an
> adjustable delay until all is settled. Or, probably better, have the
> recording start on time but issue the channel change command some 10-15s
> before that.
> 
> Maybe someone knows how to accomplish that, or has any other suggestion,
> else I'm ready to chip in some coding work (I was thinking one could add
> a field with that per-channel delay to the channels table in the DB to
> tune that. That could also be used to cut out the typical few seconds of
> previous-channel footage at the start of a recording even in the absence
> of an actual problem). I'm a programmer in my professional life but
> would probably need some time to get up to speed with the procedures to
> submit patches etc.
> 
> Here's the version info -
> 
>> MythTV Version   : 19961
>> MythTV Branch    : branches/release-0-21-fixes
>> Library API      : 0.21.20080304-1
>> Network Protocol : 40
>> Options compiled in:
>>  linux profile using_oss using_alsa using_backend using_dbox2 using_dvb using_firewire using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc using_opengl_vsync using_v4l using_x11 using_xrandr using_xv using_glx_proc_addr_arb using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3 using_live
> 
> and below is a piece of the log when the recording failed.
> 
> Thanks for any advice/hints/suggestions.
> 
> 	Martin
> 
> 
>> 2009-09-05 16:45:06.543 FireDev(001CEA9098680000): Requesting STB Power State
>> 2009-09-05 16:45:06.551 FireDev(001CEA9098680000): STB Power State: On
>> 2009-09-05 16:45:06.554 SM(001cea9098680000)::AddFlags: Seen(STB,) Match(STB,) Wait()
>> 2009-09-05 16:45:06.555 FireChan(001cea9098680000): Retune()
>> 2009-09-05 16:45:06.558 FireDev(001CEA9098680000): Requesting STB Power State
>> 2009-09-05 16:45:06.566 FireDev(001CEA9098680000): STB Power State: On
>> 2009-09-05 16:45:06.568 SetChannelByNumber(833)
>> 2009-09-05 16:45:06.572 FireDev(001CEA9098680000): Requesting STB Power State
>> 2009-09-05 16:45:06.579 FireDev(001CEA9098680000): STB Power State: On
>> 2009-09-05 16:45:06.580 SetChannel(model SA4200HD, alt 0, chan 833)
>> 2009-09-05 16:45:06.584 SetChannel() -- locked
>> 2009-09-05 16:45:06.602 SetLastChannel(833): cleared: no
>> 2009-09-05 16:45:06.653 FireSM(001cea9098680000): UpdateValues() -- Waiting for table monitor to start
>> 2009-09-05 16:45:06.653 FireSM(001cea9098680000): RunTableMonitor(): -- begin
>> 2009-09-05 16:45:06.654 FireSM(001cea9098680000): UpdateValues() -- Table monitor started
>> 2009-09-05 16:45:06.661 LFireDev(001CEA9098680000): Starting Port Handler Thread
>> 2009-09-05 16:45:06.677 LFireDev(001CEA9098680000): Starting Port Handler Thread -- locked
>> 2009-09-05 16:45:06.687 LFireDev(001CEA9098680000): OpenPort()
>> 2009-09-05 16:45:06.693 LFireDev(001CEA9098680000): OpenPort() -- got lock
>> 2009-09-05 16:45:06.701 FireDev(001CEA9098680000): AddListener() 1
>> 2009-09-05 16:45:06.716 LFireDev(001CEA9098680000): Opening P2P connection
>> libiec61883 warning: Established connection on channel 0.
>> You may need to manually set the channel on the receiving node.
>> 2009-09-05 16:45:06.889 LFireDev(001CEA9098680000): OpenAVStream
>> 2009-09-05 16:45:06.890 LFireDev(001CEA9098680000): Opening A/V stream object
>> 2009-09-05 16:45:06.900 LFireDev(001CEA9098680000): Buffered packets 2000 (8000 KB)
>> 2009-09-05 16:45:06.905 LFireDev(001CEA9098680000): Starting A/V streaming -- really
>> 2009-09-05 16:45:06.925 LFireDev(001CEA9098680000): Starting A/V streaming -- done
>> 2009-09-05 16:45:06.926 LFireDev(001CEA9098680000), Warning: No Input in 50 msec...
>> 2009-09-05 16:45:06.984 LFireDev(001CEA9098680000), Warning: No Input in 100 msec...
> ..and so on
> 
> 
> 
> 
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 



More information about the mythtv-dev mailing list