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

May 30, 2012, 7:43 PM

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

On Mon, May 28, 2012 at 12:10 PM, <noreply [at] mythtv> wrote:
> #10765: HD-PVR: Rework SignalMonitor to avoid reading from device
> ------------------------------+------------------------
>  Reporter:  jpoet             |          Owner:  jpoet
>     Type:  Patch - Bug Fix   |         Status:  closed
>  Priority:  minor             |      Milestone:  0.25.1
> Component:  MythTV - General  |        Version:  0.25
>  Severity:  medium            |     Resolution:  fixed
>  Keywords:  HDPVR LiveTV      |  Ticket locked:  0
> ------------------------------+------------------------
> Changes (by wagnerrp):
>
>  * version:  Unspecified => 0.25
>
>
> --
> Ticket URL: <http://code.mythtv.org/trac/ticket/10765#comment:5>
> MythTV <http://code.mythtv.org/trac>
> MythTV Media Center

since this was applied I've noticed this in my backend log:
(StartEncoding) MPEGRec(/dev/hdpvr2): StartEncoding
May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
started
May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
middle
May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
error state
May 30 19:36:31 MythCenter mythbackend[17345]: E RecThread
mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
detected
May 30 19:36:31 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
RestartEncoding
May 30 19:36:31 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1332 (StopEncoding) MPEGRec(/dev/hdpvr2):
StopEncoding
May 30 19:36:32 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1348 (StopEncoding) MPEGRec(/dev/hdpvr2): Encoding
stopped
May 30 19:36:32 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1410 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Checking Resolution
May 30 19:36:32 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1419 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Got Resolution 1920x1080
May 30 19:36:32 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1280 (StartEncoding) MPEGRec(/dev/hdpvr2):
StartEncoding
May 30 19:36:32 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
started
May 30 19:36:32 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
May 30 19:36:32 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
middle
May 30 19:36:32 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
May 30 19:36:35 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
May 30 19:36:35 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
error state
May 30 19:36:35 MythCenter mythbackend[17345]: E RecThread
mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
detected
May 30 19:36:35 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
RestartEncoding
May 30 19:36:35 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1332 (StopEncoding) MPEGRec(/dev/hdpvr2):
StopEncoding
May 30 19:36:36 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1348 (StopEncoding) MPEGRec(/dev/hdpvr2): Encoding
stopped
May 30 19:36:36 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1410 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Checking Resolution
May 30 19:36:36 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1419 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Got Resolution 1920x1080
May 30 19:36:36 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1280 (StartEncoding) MPEGRec(/dev/hdpvr2):
StartEncoding
May 30 19:36:36 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
started
May 30 19:36:36 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
May 30 19:36:36 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
middle
May 30 19:36:36 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
May 30 19:36:39 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
May 30 19:36:39 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
error state
May 30 19:36:39 MythCenter mythbackend[17345]: E RecThread
mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
detected
May 30 19:36:39 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
RestartEncoding
May 30 19:36:39 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1332 (StopEncoding) MPEGRec(/dev/hdpvr2):
StopEncoding
May 30 19:36:40 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1348 (StopEncoding) MPEGRec(/dev/hdpvr2): Encoding
stopped
May 30 19:36:40 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1410 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Checking Resolution
May 30 19:36:40 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1419 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Got Resolution 1920x1080
May 30 19:36:40 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1280 (StartEncoding) MPEGRec(/dev/hdpvr2):
StartEncoding
May 30 19:36:40 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
started
May 30 19:36:40 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
May 30 19:36:40 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
middle
May 30 19:36:40 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
May 30 19:36:43 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
May 30 19:36:43 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
error state
May 30 19:36:43 MythCenter mythbackend[17345]: E RecThread
mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
detected
May 30 19:36:43 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
RestartEncoding
May 30 19:36:43 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1332 (StopEncoding) MPEGRec(/dev/hdpvr2):
StopEncoding
May 30 19:36:44 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1348 (StopEncoding) MPEGRec(/dev/hdpvr2): Encoding
stopped
May 30 19:36:44 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1410 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Checking Resolution
May 30 19:36:44 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1419 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Got Resolution 1920x1080
May 30 19:36:44 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1280 (StartEncoding) MPEGRec(/dev/hdpvr2):
StartEncoding
May 30 19:36:44 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
started
May 30 19:36:44 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
May 30 19:36:44 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
middle
May 30 19:36:44 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
May 30 19:36:47 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
May 30 19:36:47 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
error state
May 30 19:36:47 MythCenter mythbackend[17345]: E RecThread
mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
detected
May 30 19:36:47 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
RestartEncoding
May 30 19:36:47 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1332 (StopEncoding) MPEGRec(/dev/hdpvr2):
StopEncoding
May 30 19:36:48 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1348 (StopEncoding) MPEGRec(/dev/hdpvr2): Encoding
stopped
May 30 19:36:48 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1410 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Checking Resolution
May 30 19:36:48 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1419 (HandleResolutionChanges) MPEGRec(/dev/hdpvr2):
Got Resolution 1920x1080
May 30 19:36:48 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1280 (StartEncoding) MPEGRec(/dev/hdpvr2):
StartEncoding
May 30 19:36:48 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
started
May 30 19:36:48 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
May 30 19:36:48 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
middle
May 30 19:36:48 MythCenter mythbackend[17345]: I RecThread
DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
May 30 19:36:50 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
May 30 19:36:50 MythCenter mythbackend[17345]: E DeviceReadBuffer
DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
error state
May 30 19:36:50 MythCenter mythbackend[17345]: E RecThread
mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
detected
May 30 19:36:50 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
RestartEncoding
May 30 19:36:50 MythCenter mythbackend[17345]: I RecThread
mpegrecorder.cpp:1332 (StopEncoding) MPEGRec(/dev/hdpvr2):
StopEncoding


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

May 30, 2012, 8:02 PM

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

On Wed, May 30, 2012 at 8:43 PM, Steven Adeff <adeffs.mythtv [at] gmail>wrote:

> On Mon, May 28, 2012 at 12:10 PM, <noreply [at] mythtv> wrote:
> > #10765: HD-PVR: Rework SignalMonitor to avoid reading from device
> > ------------------------------+------------------------
> > Reporter: jpoet | Owner: jpoet
> > Type: Patch - Bug Fix | Status: closed
> > Priority: minor | Milestone: 0.25.1
> > Component: MythTV - General | Version: 0.25
> > Severity: medium | Resolution: fixed
> > Keywords: HDPVR LiveTV | Ticket locked: 0
> > ------------------------------+------------------------
> > Changes (by wagnerrp):
> >
> > * version: Unspecified => 0.25
> >
> >
> > --
> > Ticket URL: <http://code.mythtv.org/trac/ticket/10765#comment:5>
> > MythTV <http://code.mythtv.org/trac>
> > MythTV Media Center
>
> since this was applied I've noticed this in my backend log:
> (StartEncoding) MPEGRec(/dev/hdpvr2): StartEncoding
> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
> started
> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
> middle
> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
> DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
> DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
> error state
> May 30 19:36:31 MythCenter mythbackend[17345]: E RecThread
> mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
> detected
> May 30 19:36:31 MythCenter mythbackend[17345]: I RecThread
> mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
> RestartEncoding
>
<snip>


Have you tried yanking the HD-PVR's power cord for a minute? About once
every couple of months, my HD-PVR will get in a state like that. Turning
it off/on does not fix it -- I actually have to yank the power for a while.

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

May 31, 2012, 6:19 AM

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

On Wed, May 30, 2012 at 11:02 PM, John P Poet <jppoet [at] gmail> wrote:
> On Wed, May 30, 2012 at 8:43 PM, Steven Adeff <adeffs.mythtv [at] gmail>
> wrote:
>> On Mon, May 28, 2012 at 12:10 PM,  <noreply [at] mythtv> wrote:
>> > #10765: HD-PVR: Rework SignalMonitor to avoid reading from device
>> > ------------------------------+------------------------
>> >  Reporter:  jpoet             |          Owner:  jpoet
>> >     Type:  Patch - Bug Fix   |         Status:  closed
>> >  Priority:  minor             |      Milestone:  0.25.1
>> > Component:  MythTV - General  |        Version:  0.25
>> >  Severity:  medium            |     Resolution:  fixed
>> >  Keywords:  HDPVR LiveTV      |  Ticket locked:  0
>> > ------------------------------+------------------------
>> > Changes (by wagnerrp):
>> >
>> >  * version:  Unspecified => 0.25
>> >
>> >
>> > --
>> > Ticket URL: <http://code.mythtv.org/trac/ticket/10765#comment:5>
>> > MythTV <http://code.mythtv.org/trac>
>> > MythTV Media Center
>>
>> since this was applied I've noticed this in my backend log:
>>  (StartEncoding) MPEGRec(/dev/hdpvr2): StartEncoding
>> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>> mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
>> started
>> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>> DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
>> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>> DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
>> middle
>> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>> DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
>> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
>> DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
>> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
>> DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
>> error state
>> May 30 19:36:31 MythCenter mythbackend[17345]: E RecThread
>> mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
>> detected
>> May 30 19:36:31 MythCenter mythbackend[17345]: I RecThread
>> mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
>> RestartEncoding
>
> <snip>
>
>
> Have you tried yanking the HD-PVR's power cord for a minute?  About once
> every couple of months, my HD-PVR will get in a state like that.  Turning it
> off/on does not fix it -- I actually have to yank the power for a while.

yea, that gets done about once a week, if not more often. I'll try it
for a longer period of time and see if that does anything.

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

May 31, 2012, 7:05 AM

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

On Thu, May 31, 2012 at 7:19 AM, Steven Adeff <adeffs.mythtv [at] gmail>wrote:

> On Wed, May 30, 2012 at 11:02 PM, John P Poet <jppoet [at] gmail> wrote:
> > On Wed, May 30, 2012 at 8:43 PM, Steven Adeff <adeffs.mythtv [at] gmail>
> > wrote:
> >> On Mon, May 28, 2012 at 12:10 PM, <noreply [at] mythtv> wrote:
> >> > #10765: HD-PVR: Rework SignalMonitor to avoid reading from device
> >> > ------------------------------+------------------------
> >> > Reporter: jpoet | Owner: jpoet
> >> > Type: Patch - Bug Fix | Status: closed
> >> > Priority: minor | Milestone: 0.25.1
> >> > Component: MythTV - General | Version: 0.25
> >> > Severity: medium | Resolution: fixed
> >> > Keywords: HDPVR LiveTV | Ticket locked: 0
> >> > ------------------------------+------------------------
> >> > Changes (by wagnerrp):
> >> >
> >> > * version: Unspecified => 0.25
> >> >
> >> >
> >> > --
> >> > Ticket URL: <http://code.mythtv.org/trac/ticket/10765#comment:5>
> >> > MythTV <http://code.mythtv.org/trac>
> >> > MythTV Media Center
> >>
> >> since this was applied I've noticed this in my backend log:
> >> (StartEncoding) MPEGRec(/dev/hdpvr2): StartEncoding
> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> >> mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
> >> started
> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> >> DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> >> DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
> >> middle
> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> >> DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
> >> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
> >> DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
> >> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
> >> DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
> >> error state
> >> May 30 19:36:31 MythCenter mythbackend[17345]: E RecThread
> >> mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
> >> detected
> >> May 30 19:36:31 MythCenter mythbackend[17345]: I RecThread
> >> mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
> >> RestartEncoding
> >
> > <snip>
> >
> >
> > Have you tried yanking the HD-PVR's power cord for a minute? About once
> > every couple of months, my HD-PVR will get in a state like that.
> Turning it
> > off/on does not fix it -- I actually have to yank the power for a while.
>
> yea, that gets done about once a week, if not more often. I'll try it
> for a longer period of time and see if that does anything.
>


That can also be caused by a loose cable. If nothing else works, I can send
you a patch to revert that change, but I really expect this problem to be
coincidence instead of cause and effect.

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

May 31, 2012, 7:16 AM

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

On Thu, May 31, 2012 at 10:05 AM, John P Poet <jppoet [at] gmail> wrote:
> On Thu, May 31, 2012 at 7:19 AM, Steven Adeff <adeffs.mythtv [at] gmail>
> wrote:
>> On Wed, May 30, 2012 at 11:02 PM, John P Poet <jppoet [at] gmail> wrote:
>> > On Wed, May 30, 2012 at 8:43 PM, Steven Adeff <adeffs.mythtv [at] gmail>
>> > wrote:
>> >> On Mon, May 28, 2012 at 12:10 PM,  <noreply [at] mythtv> wrote:
>> >> > #10765: HD-PVR: Rework SignalMonitor to avoid reading from device
>> >> > ------------------------------+------------------------
>> >> >  Reporter:  jpoet             |          Owner:  jpoet
>> >> >     Type:  Patch - Bug Fix   |         Status:  closed
>> >> >  Priority:  minor             |      Milestone:  0.25.1
>> >> > Component:  MythTV - General  |        Version:  0.25
>> >> >  Severity:  medium            |     Resolution:  fixed
>> >> >  Keywords:  HDPVR LiveTV      |  Ticket locked:  0
>> >> > ------------------------------+------------------------
>> >> > Changes (by wagnerrp):
>> >> >
>> >> >  * version:  Unspecified => 0.25
>> >> >
>> >> >
>> >> > --
>> >> > Ticket URL: <http://code.mythtv.org/trac/ticket/10765#comment:5>
>> >> > MythTV <http://code.mythtv.org/trac>
>> >> > MythTV Media Center
>> >>
>> >> since this was applied I've noticed this in my backend log:
>> >>  (StartEncoding) MPEGRec(/dev/hdpvr2): StartEncoding
>> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>> >> mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
>> >> started
>> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>> >> DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
>> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>> >> DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
>> >> middle
>> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>> >> DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
>> >> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
>> >> DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
>> >> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
>> >> DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
>> >> error state
>> >> May 30 19:36:31 MythCenter mythbackend[17345]: E RecThread
>> >> mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
>> >> detected
>> >> May 30 19:36:31 MythCenter mythbackend[17345]: I RecThread
>> >> mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
>> >> RestartEncoding
>> >
>> > <snip>
>> >
>> >
>> > Have you tried yanking the HD-PVR's power cord for a minute?  About once
>> > every couple of months, my HD-PVR will get in a state like that.
>> > Turning it
>> > off/on does not fix it -- I actually have to yank the power for a while.
>>
>> yea, that gets done about once a week, if not more often. I'll try it
>> for a longer period of time and see if that does anything.
>
>
>
> That can also be caused by a loose cable. If nothing else works, I can send
> you a patch to revert that change, but I really expect this problem to be
> coincidence instead of cause and effect.
>
> John
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?

I agree, and it's not like there weren't issues before. I just wasn't
sure if I was hitting a side effect of the new code or not, or if this
is intended behavior.

that said, if Myth "knows" it's not receiving proper info from an
HDPVR in this manner, could it be used to trigger the HDPVR
"powercycle" device to initiate a power cycle?

thanks!

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

May 31, 2012, 7:59 AM

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

On Thu, May 31, 2012 at 8:16 AM, Steven Adeff <adeffs.mythtv [at] gmail>wrote:

> On Thu, May 31, 2012 at 10:05 AM, John P Poet <jppoet [at] gmail> wrote:
> > On Thu, May 31, 2012 at 7:19 AM, Steven Adeff <adeffs.mythtv [at] gmail>
> > wrote:
> >> On Wed, May 30, 2012 at 11:02 PM, John P Poet <jppoet [at] gmail> wrote:
> >> > On Wed, May 30, 2012 at 8:43 PM, Steven Adeff <
> adeffs.mythtv [at] gmail>
> >> > wrote:
> >> >> On Mon, May 28, 2012 at 12:10 PM, <noreply [at] mythtv> wrote:
> >> >> > #10765: HD-PVR: Rework SignalMonitor to avoid reading from device
> >> >> > ------------------------------+------------------------
> >> >> > Reporter: jpoet | Owner: jpoet
> >> >> > Type: Patch - Bug Fix | Status: closed
> >> >> > Priority: minor | Milestone: 0.25.1
> >> >> > Component: MythTV - General | Version: 0.25
> >> >> > Severity: medium | Resolution: fixed
> >> >> > Keywords: HDPVR LiveTV | Ticket locked: 0
> >> >> > ------------------------------+------------------------
> >> >> > Changes (by wagnerrp):
> >> >> >
> >> >> > * version: Unspecified => 0.25
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Ticket URL: <http://code.mythtv.org/trac/ticket/10765#comment:5>
> >> >> > MythTV <http://code.mythtv.org/trac>
> >> >> > MythTV Media Center
> >> >>
> >> >> since this was applied I've noticed this in my backend log:
> >> >> (StartEncoding) MPEGRec(/dev/hdpvr2): StartEncoding
> >> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> >> >> mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
> >> >> started
> >> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> >> >> DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() --
> begin
> >> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> >> >> DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
> >> >> middle
> >> >> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
> >> >> DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
> >> >> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
> >> >> DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
> >> >> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
> >> >> DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
> >> >> error state
> >> >> May 30 19:36:31 MythCenter mythbackend[17345]: E RecThread
> >> >> mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
> >> >> detected
> >> >> May 30 19:36:31 MythCenter mythbackend[17345]: I RecThread
> >> >> mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
> >> >> RestartEncoding
> >> >
> >> > <snip>
> >> >
> >> >
> >> > Have you tried yanking the HD-PVR's power cord for a minute? About
> once
> >> > every couple of months, my HD-PVR will get in a state like that.
> >> > Turning it
> >> > off/on does not fix it -- I actually have to yank the power for a
> while.
> >>
> >> yea, that gets done about once a week, if not more often. I'll try it
> >> for a longer period of time and see if that does anything.
> >
> >
> >
> > That can also be caused by a loose cable. If nothing else works, I can
> send
> > you a patch to revert that change, but I really expect this problem to be
> > coincidence instead of cause and effect.
> >
> > John
> > --
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
>
> I agree, and it's not like there weren't issues before. I just wasn't
> sure if I was hitting a side effect of the new code or not, or if this
> is intended behavior.
>
> that said, if Myth "knows" it's not receiving proper info from an
> HDPVR in this manner, could it be used to trigger the HDPVR
> "powercycle" device to initiate a power cycle?
>


I proposed integrating the HD-PVR killer into the myth code, and the idea
was rejected -- too specialized.

It has been a while since I looked at the "recovery" path when there are
HD-PVR problems. We probably should be "backing off" a bit, when the
StartEncoding is repeatedly failing.


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


tom at redpepperracing

May 31, 2012, 8:26 AM

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

On Thu, May 31, 2012 at 10:59 AM, John P Poet <jppoet [at] gmail> wrote:
>
>
> I proposed integrating the HD-PVR killer into the myth code, and the idea
> was rejected -- too specialized.
>
> It has been a while since I looked at the "recovery" path when there are
> HD-PVR problems.  We probably should be "backing off" a bit, when the
> StartEncoding is repeatedly failing.
>

Would it be possible to have a System Event that would trigger on such
a failure, then the user would be responsible for creating the script
that does the killing?

Tom
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


mythtv-dev2 at dwilga-linux1

May 31, 2012, 11:04 AM

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

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.

--
Dan Wilga "Ook."

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

May 31, 2012, 11:14 AM

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

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


adeffs.mythtv at gmail

Jun 1, 2012, 6:20 AM

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

On Thu, May 31, 2012 at 9:19 AM, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> On Wed, May 30, 2012 at 11:02 PM, John P Poet <jppoet [at] gmail> wrote:
>> On Wed, May 30, 2012 at 8:43 PM, Steven Adeff <adeffs.mythtv [at] gmail>
>> wrote:
>>> On Mon, May 28, 2012 at 12:10 PM,  <noreply [at] mythtv> wrote:
>>> > #10765: HD-PVR: Rework SignalMonitor to avoid reading from device
>>> > ------------------------------+------------------------
>>> >  Reporter:  jpoet             |          Owner:  jpoet
>>> >     Type:  Patch - Bug Fix   |         Status:  closed
>>> >  Priority:  minor             |      Milestone:  0.25.1
>>> > Component:  MythTV - General  |        Version:  0.25
>>> >  Severity:  medium            |     Resolution:  fixed
>>> >  Keywords:  HDPVR LiveTV      |  Ticket locked:  0
>>> > ------------------------------+------------------------
>>> > Changes (by wagnerrp):
>>> >
>>> >  * version:  Unspecified => 0.25
>>> >
>>> >
>>> > --
>>> > Ticket URL: <http://code.mythtv.org/trac/ticket/10765#comment:5>
>>> > MythTV <http://code.mythtv.org/trac>
>>> > MythTV Media Center
>>>
>>> since this was applied I've noticed this in my backend log:
>>>  (StartEncoding) MPEGRec(/dev/hdpvr2): StartEncoding
>>> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>>> mpegrecorder.cpp:1304 (StartEncoding) MPEGRec(/dev/hdpvr2): Encoding
>>> started
>>> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>>> DeviceReadBuffer.cpp:128 (Start) DevRdB(/dev/hdpvr2): Start() -- begin
>>> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>>> DeviceReadBuffer.cpp:146 (Start) DevRdB(/dev/hdpvr2): Start() --
>>> middle
>>> May 30 19:36:28 MythCenter mythbackend[17345]: I RecThread
>>> DeviceReadBuffer.cpp:151 (Start) DevRdB(/dev/hdpvr2): Start() -- end
>>> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
>>> DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/hdpvr2): Poll giving up 2
>>> May 30 19:36:31 MythCenter mythbackend[17345]: E DeviceReadBuffer
>>> DeviceReadBuffer.cpp:351 (run) DevRdB(/dev/hdpvr2): fill_ringbuffer:
>>> error state
>>> May 30 19:36:31 MythCenter mythbackend[17345]: E RecThread
>>> mpegrecorder.cpp:1010 (run) MPEGRec(/dev/hdpvr2): Device error
>>> detected
>>> May 30 19:36:31 MythCenter mythbackend[17345]: I RecThread
>>> mpegrecorder.cpp:1247 (RestartEncoding) MPEGRec(/dev/hdpvr2):
>>> RestartEncoding
>>
>> <snip>
>>
>>
>> Have you tried yanking the HD-PVR's power cord for a minute?  About once
>> every couple of months, my HD-PVR will get in a state like that.  Turning it
>> off/on does not fix it -- I actually have to yank the power for a while.
>
> yea, that gets done about once a week, if not more often. I'll try it
> for a longer period of time and see if that does anything.

turns out my ol' man accidentally plugged the toslink into the output
instead of the input on one of the HDPVR when he replaced a broken
toslink cable a few days ago!

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


adeffs.mythtv at gmail

Jun 15, 2012, 12:15 PM

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

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?


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

Jun 15, 2012, 1:05 PM

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

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.


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

Jun 15, 2012, 7:56 PM

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

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.

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

Jun 18, 2012, 9:49 AM

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

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.


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

Jun 21, 2012, 6:54 AM

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

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.


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


adeffs.mythtv at gmail

Jun 26, 2012, 7:35 AM

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

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.

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

Jun 26, 2012, 5:29 PM

Post #17 of 25 (2074 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?


lsorense at csclub

Jun 27, 2012, 5:56 AM

Post #18 of 25 (2075 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 06:29:33PM -0600, John P Poet wrote:
> 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.

I run with 3.2 kernel and what I believe is the latest firmware. I fairly
often have screwed up recordings. I have a scientific atlanta 4250 STB,
which easily takes 3 or 4 seconds to change channels, and this certainly
seems to be way longer than mythtv has the patience for.

It seems to work OK as long as the channel I go to has the same
resolution as the previous one the STB was on, but if the resolution
changes it seems to make the recording fail, although I can't say with
100% certainty that is the case.

Watching live TV from the hd-pvr is pretty much imposible though.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


adeffs.mythtv at gmail

Jun 27, 2012, 12:58 PM

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

On Wed, Jun 27, 2012 at 8:56 AM, Lennart Sorensen
<lsorense [at] csclub> wrote:
> On Tue, Jun 26, 2012 at 06:29:33PM -0600, John P Poet wrote:
>> 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.
>
> I run with 3.2 kernel and what I believe is the latest firmware.  I fairly
> often have screwed up recordings.  I have a scientific atlanta 4250 STB,
> which easily takes 3 or 4 seconds to change channels, and this certainly
> seems to be way longer than mythtv has the patience for.
>
> It seems to work OK as long as the channel I go to has the same
> resolution as the previous one the STB was on, but if the resolution
> changes it seems to make the recording fail, although I can't say with
> 100% certainty that is the case.
>
> Watching live TV from the hd-pvr is pretty much imposible though.

well that is not promising at all...


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


lsorense at csclub

Jun 27, 2012, 1:02 PM

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

On Wed, Jun 27, 2012 at 03:58:48PM -0400, Steven Adeff wrote:
> well that is not promising at all...

It's slightly annoying. I don't really do much livetv watching anyhow,
so for the most part it isn't too bad, although having to reschedule
the failed recordings (once I notice them) is annoying.

I wasn't bothering to get anything done about it since I was under the
impression that it was considered to be the fault of the cable box and
not mythtv. Not that the cable box is ever going to get changed, so
the only thing that could possibly improve the situation would be mythtv.

Maybe there is a setting for a tuning timeout I could change.
New features do get added occationally after all.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


adeffs.mythtv at gmail

Jun 27, 2012, 1:23 PM

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

On Wed, Jun 27, 2012 at 4:02 PM, Lennart Sorensen
<lsorense [at] csclub> wrote:
> On Wed, Jun 27, 2012 at 03:58:48PM -0400, Steven Adeff wrote:
>> well that is not promising at all...
>
> It's slightly annoying.  I don't really do much livetv watching anyhow,
> so for the most part it isn't too bad, although having to reschedule
> the failed recordings (once I notice them) is annoying.
>
> I wasn't bothering to get anything done about it since I was under the
> impression that it was considered to be the fault of the cable box and
> not mythtv.  Not that the cable box is ever going to get changed, so
> the only thing that could possibly improve the situation would be mythtv.
>
> Maybe there is a setting for a tuning timeout I could change.
> New features do get added occationally after all.

I have a "sleep" command in my channel change script, since Myth will
not request data from the tuner until the script finishes this made
things work prior to the HDPVR change. the biggest issue was having to
reboot the HDPVR. usually recordings worked perfectly, and most of the
time LiveTV worked perfectly.

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


lsorense at csclub

Jun 28, 2012, 6:41 AM

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

On Wed, Jun 27, 2012 at 04:23:41PM -0400, Steven Adeff wrote:
> I have a "sleep" command in my channel change script, since Myth will
> not request data from the tuner until the script finishes this made
> things work prior to the HDPVR change. the biggest issue was having to
> reboot the HDPVR. usually recordings worked perfectly, and most of the
> time LiveTV worked perfectly.

When I tried that, I got a timeout error from mythtv about channel
changing taking too long.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Jun 28, 2012, 12:18 PM

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

On 06/27/2012 04:02 PM, Lennart Sorensen wrote:
> On Wed, Jun 27, 2012 at 03:58:48PM -0400, Steven Adeff wrote:
>> well that is not promising at all...
> It's slightly annoying. I don't really do much livetv watching anyhow,
> so for the most part it isn't too bad, although having to reschedule
> the failed recordings (once I notice them) is annoying.
>
> I wasn't bothering to get anything done about it since I was under the
> impression that it was considered to be the fault of the cable box and
> not mythtv. Not that the cable box is ever going to get changed, so
> the only thing that could possibly improve the situation would be mythtv.
>
> Maybe there is a setting for a tuning timeout I could change.
> New features do get added occationally after all.

Yes, there is, and yes, you should. You may need to make it
significantly larger. It's in mythtv-setup.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


adeffs.mythtv at gmail

Jun 28, 2012, 12:49 PM

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

On Thu, Jun 28, 2012 at 9:41 AM, Lennart Sorensen
<lsorense [at] csclub> wrote:
> On Wed, Jun 27, 2012 at 04:23:41PM -0400, Steven Adeff wrote:
>> I have a "sleep" command in my channel change script, since Myth will
>> not request data from the tuner until the script finishes this made
>> things work prior to the HDPVR change. the biggest issue was having to
>> reboot the HDPVR. usually recordings worked perfectly, and most of the
>> time LiveTV worked perfectly.
>
> When I tried that, I got a timeout error from mythtv about channel
> changing taking too long.

there's a setting for how long to wait in the tuner setup in
mythtv-setup, you need to make that longer too.

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


lsorense at csclub

Jun 29, 2012, 6:50 AM

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

On Thu, Jun 28, 2012 at 03:18:29PM -0400, Michael T. Dean wrote:
> Yes, there is, and yes, you should. You may need to make it
> significantly larger. It's in mythtv-setup.

I will try that on the weekend and see how that goes.

--
Len Sorensen
_______________________________________________
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.