Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

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

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


adeffs.mythtv at gmail

Jul 21, 2012, 6:50 PM

Post #1 of 3 (529 views)
Permalink
Re: [mythtv-commits] Ticket #10765: HD-PVR: Rework SignalMonitor to avoid reading from device

On Tue, Jun 26, 2012 at 8:29 PM, John P Poet <jppoet [at] gmail> wrote:
> On Tue, Jun 26, 2012 at 8:35 AM, Steven Adeff <adeffs.mythtv [at] gmail>
> wrote:
>> On Thu, Jun 21, 2012 at 9:54 AM, Steven Adeff <adeffs.mythtv [at] gmail>
>> wrote:
>> > On Mon, Jun 18, 2012 at 12:49 PM, John P Poet <jppoet [at] gmail> wrote:
>> >> On Fri, Jun 15, 2012 at 8:56 PM, Steven Adeff <adeffs.mythtv [at] gmail>
>> >> wrote:
>> >>> On Fri, Jun 15, 2012 at 4:05 PM, John P Poet <jppoet [at] gmail> wrote:
>> >>> > On Fri, Jun 15, 2012 at 1:15 PM, Steven Adeff
>> >>> > <adeffs.mythtv [at] gmail>
>> >>> > wrote:
>> >>> >> On Thu, May 31, 2012 at 2:14 PM, Michael T. Dean
>> >>> >> <mtdean [at] thirdcontact> 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
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


jppoet at gmail

Jul 21, 2012, 8:15 PM

Post #2 of 3 (517 views)
Permalink
Re: [mythtv-commits] Ticket #10765: HD-PVR: Rework SignalMonitor to avoid reading from device [In reply to]

On Sat, Jul 21, 2012 at 7:50 PM, Steven Adeff <adeffs.mythtv [at] gmail>wrote:

> On Tue, Jun 26, 2012 at 8:29 PM, John P Poet <jppoet [at] gmail> wrote:
> > On Tue, Jun 26, 2012 at 8:35 AM, Steven Adeff <adeffs.mythtv [at] gmail>
> > wrote:
> >> On Thu, Jun 21, 2012 at 9:54 AM, Steven Adeff <adeffs.mythtv [at] gmail>
> >> wrote:
> >> > On Mon, Jun 18, 2012 at 12:49 PM, John P Poet <jppoet [at] gmail>
> wrote:
> >> >> On Fri, Jun 15, 2012 at 8:56 PM, Steven Adeff <
> adeffs.mythtv [at] gmail>
> >> >> wrote:
> >> >>> On Fri, Jun 15, 2012 at 4:05 PM, John P Poet <jppoet [at] gmail>
> wrote:
> >> >>> > On Fri, Jun 15, 2012 at 1:15 PM, Steven Adeff
> >> >>> > <adeffs.mythtv [at] gmail>
> >> >>> > wrote:
> >> >>> >> On Thu, May 31, 2012 at 2:14 PM, Michael T. Dean
> >> >>> >> <mtdean [at] thirdcontact> 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.
>
>
The invocation of the external channel change script was not modified. I
didn't look at the code to make sure someone else had not modified it, but
I just did test it by adding a 10 second sleep to the bottom of my shell
script -- with the 10 second sleep, the tuning status OSD did not update
until 10 seconds had passed, then it started showing a non-zero signal
percentage.

You could make the same test -- add a 10 second sleep, and make sure the
OSD status shows "Signal 0%" for ~10 seconds.

John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


adeffs.mythtv at gmail

Jul 21, 2012, 8:59 PM

Post #3 of 3 (512 views)
Permalink
Re: [mythtv-commits] Ticket #10765: HD-PVR: Rework SignalMonitor to avoid reading from device [In reply to]

On Sat, Jul 21, 2012 at 11:15 PM, John P Poet <jppoet [at] gmail> wrote:
> On Sat, Jul 21, 2012 at 7:50 PM, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
>> 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.
>>
>
> The invocation of the external channel change script was not modified. I
> didn't look at the code to make sure someone else had not modified it, but I
> just did test it by adding a 10 second sleep to the bottom of my shell
> script -- with the 10 second sleep, the tuning status OSD did not update
> until 10 seconds had passed, then it started showing a non-zero signal
> percentage.
>
> You could make the same test -- add a 10 second sleep, and make sure the OSD
> status shows "Signal 0%" for ~10 seconds.
>

so since I sent that email we've been playing around more. oddly we
have yet to have a mis-tune, which is nice.

I previously had a sleep command in my script, but it did not seem to
do anything so I removed it, and nothing seemed to change.

I'm trying to figure out how the v4l2-ctl command to fix the
saturation issue plays into the channel change script. The reason is,
if I put it in the channel change script it does not affect the
initial entry into LiveTV but does after a channel change.

so I tried as you said and put a 15 second sleep, and yes, it does
delay the tuning!
so there is the delay, but no matter how long I set it for the colors
always come up bad when first going to livetv, but, oddly, when
changing channels the colors are fine.

so then I created a second script, just to change the pvr settings,
that the channel change script runs in the background (using &) with a
4 second sleep in that script. this causes the initial entry into
livetv to fix shortly after video starts to play, but also for channel
changes to start wrong and then fix shortly after!
if however in this second script I run the channel change command and
then sleep and then run the command again, it fixes the initial livetv
entry AND on channel changes there is no perceptible lag in the fix
(ie it comes up correct).

so that seems to have solved it, though I'm baffled as to whether I'm
the only one with this "delay" issue, or I just missed this in the
wiki entry and mailing lists and had to re-invent the wheel so to
speak?

--
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
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.