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

Steven Adeff adeffs.mythtv at gmail.com
Thu Jun 21 13:54:21 UTC 2012


On Mon, Jun 18, 2012 at 12:49 PM, John P Poet <jppoet at gmail.com> wrote:
> On Fri, Jun 15, 2012 at 8:56 PM, Steven Adeff <adeffs.mythtv at gmail.com>
> wrote:
>> 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.
>>
>
> If you watch your STB change channels on your TV, how does it behave?  How
> long does it take to produce stable video & audio after typing in the new
> channel number?
>
> The only scenario I can think of that might cause a problem, involves the
> STB sending out a (constant resolution) blank picture for more than 2
> seconds *before* finally locking on the new channel.   Or maybe, it shows a
> "snapshot" of the last video frame for more than 2 seconds before finally
> displaying the new channel.
>

not long. right now I have the channel change script pause for 4.5
seconds before releasing back to Myth, previously this was more than
enough time for the STB to lock and output the new channel even on the
random slow channel changes. I would think this wait would negate any
issues Myth has in locking in.

It's gotten quite bad, recordings are at best 50/50 as to whether they
will actually work or not.

I need to figure out which change this went in to affect and manually
compile the change just before it, Myth has basically become useless
on this setup.


-- 
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


More information about the mythtv-dev mailing list