jppoet at gmail
Jun 26, 2012, 5:29 PM
Post #17 of 25
(761 views)
Permalink
|
|
Re: [mythtv-commits] Ticket #10765: HD-PVR: Rework SignalMonitor to avoid reading from device
[In reply to]
|
|
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
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
