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

[Steven Adeff]

On Thu, Jun 21, 2012 at 9:54 AM, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
> 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.
>

well I compiled source from just before this commit. things are back
to where they were, which is not great, but much better than after
this commit.

I think the next option is to upgrade the kernel from 2.6 to 3.0 and
see if that and being able to run the newer HDPVR firmware makes a
difference.

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