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

John P Poet jppoet at gmail.com
Fri Jun 15 20:05:37 UTC 2012


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.


John
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20120615/bb18b678/attachment.html>


More information about the mythtv-dev mailing list