jppoet at gmail
Jul 21, 2012, 8:15 PM
Post #2 of 3
(339 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?
|
