[mythtv] [mythtv-commits] Ticket #10765: HD-PVR: Rework SignalMonitor to avoid reading from device
adeffs.mythtv at gmail.com
Sat Jun 16 02:56:48 UTC 2012
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>
>> 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
I don't think it took this long before though. perhaps this is what is
causing so many issues for me since this patch.
Before you ask, read the FAQ!
then search the Wiki, and this list,
Mailinglist etiquette - http://www.mythtv.org/wiki/Mailing_List_etiquette
More information about the mythtv-dev