[mythtv-users] Automation query

Thomas Mashos tgm4883 at gmail.com
Sun Feb 13 01:06:48 UTC 2011


On Sat, Feb 12, 2011 at 4:16 PM, Michael T. Dean <mtdean at thirdcontact.com>wrote:

> On 02/12/2011 06:17 PM, Yeechang Lee wrote:
> > If 0.24 has functionality that prevents the issue from occurring I am
> > glad to hear it as I am still on 0.23. What does setting the timeout
> > to 10 seconds do? Is it a delay between channel changing and
> > attempting to lock on the signal? If so I imagine it would make using
> > live TV painful.
>
> For the first time, ever, MythTV 0.24+ monitors external channel change
> progress so that it can determine when to begin recording, even for
> long-running channel-change scripts.  With earlier versions of MythTV,
> if you had a channel change script that could run for more than a second
> or 2, you'd have to background the script--so mythbackend starts
> recording immediately, even before channel change was complete--and hope
> that everything worked out.
>
> The HD-PVR, though, is very temperamental and if you began recording
> before it had gotten a "lock," it would cause problems.  Therefore, John
> Poet wrote code to monitor the channel change script and start recording
> once it completes.
>
> If you set the timeout to 10s and your external channel change script
> takes 0.00005 seconds to complete, mythbackend will start recording
> after 0.00005s (well, plus a few ms or whatever it takes since nothing
> is instantaneous :).  If your channel change script takes 9s, though--as
> can happen for an HD-PVR to become ready to record under some
> circumstances--mythbackend will wait until the device is ready before
> beginning to record.  In other words, nothing changes as far as the
> performance of the HD-PVR or channel changes with the HD-PVR, but rather
> than have a built-in "wait a few seconds just in case", we can start
> recording as soon as the device/drivers are ready (which will, in
> general, likely be around the same wait time as with the previous
> hard-coded wait, but could be shorter or longer in some circumstances).
>
> The reason I mentioned the timeout is because since that timeout value
> was never used before for capture using inputs that required external
> channel change scripts, users who upgrade their databases from previous
> versions may have invalid/incorrect values for the timeout for their
> devices/channel change scripts.  Therefore, anyone who uses an external
> channel change script and upgrades to 0.24 should verify the values are
> sensible.
>
> That said, if you upgrade to 0.24-fixes from this Thursday or later, you
> will almost definitely see /much/ faster and more reliable Live TV and
> playback startup, and possibly faster channel changes in Live TV, thanks
> to some great work done by Mark Kendall and Taylor Ralph.  I highly
> recommend the upgrade--especially for Live TV users.
>
> Note, though, you need a /very/ new 0.24-fixes.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/mailman/listinfo/mythtv-users
>


Just for reference, I'm on 0.24 and have the HDPVR issue we are discussing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20110212/39b4e3e6/attachment.html 


More information about the mythtv-users mailing list