[mythtv-users] Automation query

[Michael T. Dean]

On 02/12/2011 08:06 PM, Thomas Mashos wrote:
> On Sat, Feb 12, 2011 at 4:16 PM, Michael T. Dean 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.
> Just for reference, I'm on 0.24 and have the HDPVR issue we are discussing.

In case there was any confusion (and I'm worried by some of the replies 
and other threads on the list that there may have been), I was /not/ 
saying that people who are using HD-PVRs should upgrade to 0.24-fixes 
and their Live TV or recording problems will magically disappear.  And I 
/definitely/ was not saying that 0.24-fixes has solved any HD-PVR (or 
capture device/driver) problems.

I was simply responding to Yeechang's question of why people using 
external channel change scripts who upgrade to 0.24 need to verify the 
timeout and whether it will cause 10s channel changes.

In summary, I explained that the timeout will not affect Live TV 
tuning/channel changing speed.  However, I mentioned that there are 
unrelated changes that beneficially affect playback startup speed in 
0.24-fixes and above.

But it's still up to the user to decide whether--and when--to upgrade to 
0.24-fixes.

Mike