[mythtv] [mythtv-commits] Ticket #10765: HD-PVR: Rework SignalMonitor to avoid reading from device

[Steven Adeff]

On Fri, Jun 15, 2012 at 4:05 PM, John P Poet <jppoet at gmail.com> wrote:
> On Fri, Jun 15, 2012 at 1:15 PM, Steven Adeff <adeffs.mythtv at gmail.com>
> wrote:
>> On Thu, May 31, 2012 at 2:14 PM, Michael T. Dean
>> <mtdean at thirdcontact.com> wrote:
>> > On 05/31/2012 02:04 PM, Dan Wilga wrote:
>> >>
>> >> On 5/31/12 10:59 AM, John P Poet wrote:
>> >>>
>> >>> I proposed integrating the HD-PVR killer into the myth code, and the
>> >>> idea
>> >>> was rejected -- too specialized.
>> >>
>> >> I'm with Tom on this. I think it would be a good idea for the BE to see
>> >> if
>> >> the recording is zero bytes long (or perhaps sticking at the current
>> >> size
>> >> for too long) and trigger a system event. It seems to me that this
>> >> would
>> >> detect the HDPVR needing a reboot condition, as well as a host of DVB
>> >> issues
>> >> that seem to result in zero-length recordings.
>> >>
>> >> Using an event, one could write a script to use X10 to power cycle the
>> >> HDPVR, reload kernel modules, or just send a warning email. And if this
>> >> was
>> >> accompanied by an automatic reschedule of the failed recording, that
>> >> would
>> >> be the icing on the cake (mmmm... caaake).
>> >>
>> >> I know people have done versions of this using external scripts, but I
>> >> think having it built-into the BE would be more robust.
>> >
>> >
>> > The HDPVR Killer scripts already use events.  See the README at the
>> > bottom
>> > of:
>> >
>> > https://github.com/Beirdo/hdpvr-killer/tree/master/src
>> >
>> > (see, also, http://www.hdpvrkillerdevice.com/ and the rest of the repo).
>> >  The only difference between its approach and the one you mentioned is
>> > that
>> > the backend would unilaterally decide--meaning the backend defines the
>> > one
>> > and only meaning for--when a recording is considered failed, rather than
>> > allowing users to define what they consider a failed recording.  The
>> > script
>> > could easily force delete the failed recording, which (if done properly,
>> > using the protocol, versus directly) would trigger a reschedule.
>> >
>> > IMHO, how a user wants to deal with a temporary failure of the hardware
>> > is
>> > likely to vary significantly.  So, it seems that a script that allows
>> > user-customization is a good approach.
>> >
>> > Mike
>>
>> with this change, do we still need to be concerned with the delay in
>> our channel change script for the cable box channel change time?
>
>
>
> In my experience, changing channels on my Directv STBs results in the video
> output signal "glitching".  While it is "glitching", the hdpvr driver will
> report various video "resolutions".  The new HD-PVR SignalMonitor tries to
> wait for those "glitches" to settled down, and then it assume it is safe to
> start recording.
>
> The new HD-PVR SignalMonitor waits for the hdpvr driver to report a
> consistent video resolution and a consistent audio 'mode' for 2 seconds.  If
> it sees the video resolution, or the audio 'mode' (ac3) change, it resets
> the timer and continues to wait.
>
> So, it still depends on your STB.  How quickly does it change channels, and
> lock onto the 'new' video resolution of that channel?  How does it behave
> during the channel change processes?  It is possible that some STBs may
> behave completely different from my Directv STBs, and this new method may
> not work at all...
>
> With my Directv STBs, 2 seconds seems to be enough, but I have left a 1
> second sleep at the bottom of the channel change script, just out of
> paranoia.  Since I don't use LiveTV (except for testing), I can afford a
> longer delay before the recording starts.
>
> While testing this, having the HD-PVR Signal Monitor require a consistent
> video resolution for 1 second actually worked most (80%) of the time, but 2
> seconds brought the success rate closer to 100% -- especially when bouncing
> between 480i, 720p and 1080i channels.

hrmmm. right now the script I use waits 4.5 seconds, but sometimes
Myth can take up to 30seconds, or more if I change the timeout, to
lock.

I don't think it took this long before though. perhaps this is what is
causing so many issues for me since this patch.

-- 
Steve
http://www.mythtv.org/wiki/User:Steveadeff
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette - http://www.mythtv.org/wiki/Mailing_List_etiquette