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

Sun Jul 22 01:50:23 UTC 2012

On Tue, Jun 26, 2012 at 8:29 PM, John P Poet <jppoet at gmail.com> wrote:
> On Tue, Jun 26, 2012 at 8:35 AM, Steven Adeff <adeffs.mythtv at gmail.com>
> wrote:
>> 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.
>
>
>
> I suppose it might be a driver issue.  In a way, I hope it is, since I don't
> know what could be special about your STB that would cause this problem.
>
> John

John,

with this work, does MythTV still wait for the channel change script
to return before starting to collect data from the HDPVR?

here's why I ask...

I just updated the system to Ubuntu 12.04 and am playing with getting
it to record. Part of this is the v4l2 command to fix the color issue
with the newer hdpvr firmware.

when it DOES work for live tv I notice that initially the color is
incorrect then it becomes correct, as though MythTV is not waiting for
the channel change scrip to collect data from the hdpvr and then when
the script does send the v4l2 command it becomes fixed.

if this is the case, this is probably why this patch is not working as
it should wait for the channel change script to exit before trying to
get data from the hdpvr.

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