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

Mailing List Archive: MythTV: Users

Failed HD-PVR recordings

 

 

First page Previous page 1 2 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded


bderman at gmail

Jul 2, 2009, 7:23 PM

Post #1 of 43 (3778 views)
Permalink
Failed HD-PVR recordings

Hello!

I'm having a problem with random recordings failing with my 2 HD-PVR
boxes.

HD-PVR: They are connected to my Astound cable set-top boxes via
Component+S/PDIF. They are running latest firmware from Hauppauge -
dmesg reports firmware version 0x12. Not sure which driver version I'm
using but I compiled it about 2 weeks ago.

Random: Same show will record on either box just fine, sometimes it
will fail. After a fail, I sometimes get a good recording, sometimes
another failure. Sometimes the first show after a restart will fail,
sometimes it will be ok. It doesn't appear to have anything to do with
specific channels or anything like that.

I'm changing channels via firewire.

$ mythbackend --version
Please include all output in bug reports.
MythTV Version : 20728
MythTV Branch : trunk
Library API : 0.22.20090424-2
Network Protocol : 45
QT Version : 4.4.0
Options compiled in:
linux release using_oss using_alsa using_arts using_backend using_dvb
using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv
using_ivtv using_joystick_menu using_lirc using_mheg
using_opengl_video using_opengl_vsync using_qtwebkit using_v4l
using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw
using_bindings_perl using_bindings_python using_opengl using_vdpau
using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

Here's what I find in my backend log:

2009-07-02 18:38:15.350 TVRec(1): ASK_RECORDING 1 0 0 0
2009-07-02 18:38:15.564 TVRec(1): Changing from None to Watching
RecordingOnly
2009-07-02 18:38:15.573 TVRec(1): HW Tuner: 1->1
2009-07-02 18:38:16.479 ret_pid(11381) child(11381) status(0x0)
2009-07-02 18:38:16.481 External Tuning program exited with no error
2009-07-02 18:38:16.772 AutoExpire: CalcParams(): Max required Free
Space: 7.0 GB w/freq: 15 min
2009-07-02 18:38:16.780 Started recording: The Rachel Maddow Show:
channel 1037 on cardid 1, sourceid 1
2009-07-02 18:38:16.790 scheduler: Started recording: The Rachel
Maddow Show: channel 1037 on cardid 1, sourceid 1
2009-07-02 18:38:24.351 MainServer::ANN Monitor
2009-07-02 18:38:24.354 adding: myth-mini as a client (events: 0)
2009-07-02 18:38:24.599 mythbackend version: trunk [20728] www.mythtv.org
2009-07-02 18:38:24.602 Using runtime prefix = /usr
2009-07-02 18:38:24.603 Using localhost value of livingroom
2009-07-02 18:38:24.618 New DB connection, total: 1
2009-07-02 18:38:24.629 Connected to database 'mythconverg' at host:
localhost
2009-07-02 18:38:24.643 Closing DB connection named 'DBManager0'
2009-07-02 18:38:24.645 Connected to database 'mythconverg' at host:
localhost
2009-07-02 18:38:24.654 Current Schema Version: 1235
2009-07-02 18:38:25.880 MPEGRec(/dev/video0) Error: Device error
detected
2009-07-02 18:38:25.884 DevRdB(/dev/video0): Stop(): Not running.
2009-07-02 18:38:36.261 MPEGRec(/dev/video0) Error: Device error
detected
2009-07-02 18:38:36.262 DevRdB(/dev/video0): Stop(): Not running.
2009-07-02 18:38:46.641 MPEGRec(/dev/video0) Error: Device error
detected
2009-07-02 18:38:46.642 DevRdB(/dev/video0): Stop(): Not running.
2009-07-02 18:38:57.028 MPEGRec(/dev/video0) Error: Device error
detected
2009-07-02 18:38:57.029 DevRdB(/dev/video0): Stop(): Not running.
2009-07-02 18:39:07.404 MPEGRec(/dev/video0) Error: Device error
detected
2009-07-02 18:39:07.409 DevRdB(/dev/video0): Stop(): Not running.

I get a bunch of these in /var/log/messages:

Jul 2 18:16:47 mythtv kernel: [348910.645710] Pid: 14286, comm:
mythbackend Tainted: P (2.6.24-19-generic #1)
Jul 2 18:16:47 mythtv kernel: [348910.645714] EIP: 0060:
[sunrpc:_spin_lock+0x5/0x10] EFLAGS: 00000246 CPU: 0
Jul 2 18:16:47 mythtv kernel: [348910.645717] EIP is at _spin_lock
+0x5/0x10
Jul 2 18:16:47 mythtv kernel: [348910.645718] EAX: e4a1ea68 EBX:
e4a1ea64 ECX: f8a3d220 EDX: f3fd0000
Jul 2 18:16:47 mythtv kernel: [348910.645721] ESI: e4a1ea68 EDI:
e49a7140 EBP: df9aac68 ESP: f3fd1dd0
Jul 2 18:16:47 mythtv kernel: [348910.645723] DS: 007b ES: 007b FS:
00d8 GS: 0000 SS: 0068
Jul 2 18:16:47 mythtv kernel: [348910.645724] CR0: 8005003b CR2:
b27fdd5c CR3: 1f8c7000 CR4: 00000690
Jul 2 18:16:47 mythtv kernel: [348910.645726] DR0: 00000000 DR1:
00000000 DR2: 00000000 DR3: 00000000
Jul 2 18:16:47 mythtv kernel: [348910.645729] DR6: ffff0ff0 DR7:
00000400
Jul 2 18:16:47 mythtv kernel: [348910.645731] [__mutex_lock_slowpath
+0x1a/0xa0] __mutex_lock_slowpath+0x1a/0xa0
Jul 2 18:16:47 mythtv kernel: [348910.645740] [d_kill+0x3d/0x60]
d_kill+0x3d/0x60
Jul 2 18:16:47 mythtv kernel: [348910.645767] [nfs:mutex_lock
+0x14/0x290] mutex_lock+0x14/0x20
Jul 2 18:16:47 mythtv kernel: [348910.645777] [<f9361da2>]
hdpvr_release+0x22/0x60 [hdpvr]
Jul 2 18:16:47 mythtv kernel: [348910.645797] [<f8a3d242>]
v4l2_release+0x22/0x40 [videodev]
Jul 2 18:16:47 mythtv kernel: [348910.645814] [__fput+0xa7/0x190]
__fput+0xa7/0x190
Jul 2 18:16:47 mythtv kernel: [348910.645859] [filp_close+0x49/0x80]
filp_close+0x49/0x80
Jul 2 18:16:47 mythtv kernel: [348910.645882] [put_files_struct
+0x92/0xb0] put_files_struct+0x92/0xb0
Jul 2 18:16:47 mythtv kernel: [348910.645909] [do_exit+0x180/0x860]
do_exit+0x180/0x860
Jul 2 18:16:47 mythtv kernel: [348910.645945]
[sunrpc:recalc_sigpending+0xb/0x40] recalc_sigpending+0xb/0x40
Jul 2 18:16:47 mythtv kernel: [348910.645948] [dequeue_signal+0x6b/
0x150] dequeue_signal+0x6b/0x150
Jul 2 18:16:47 mythtv kernel: [348910.645975] [do_group_exit
+0x26/0x80] do_group_exit+0x26/0x80
Jul 2 18:16:47 mythtv kernel: [348910.645993] [get_signal_to_deliver
+0x2b7/0x4a0] get_signal_to_deliver+0x2b7/0x4a0
Jul 2 18:16:47 mythtv kernel: [348910.646048] [do_notify_resume
+0x93/0x750] do_notify_resume+0x93/0x750
Jul 2 18:16:47 mythtv kernel: [348910.646061] [<f8873a50>]
scsi_next_command+0x30/0x50 [scsi_mod]
Jul 2 18:16:47 mythtv kernel: [348910.646099] [<f8873bdb>]
scsi_end_request+0xab/0xe0 [scsi_mod]
Jul 2 18:16:47 mythtv kernel: [348910.646174] [snd_pcm:getnstimeofday
+0x34/0x9830] getnstimeofday+0x34/0xe0
Jul 2 18:16:47 mythtv kernel: [348910.646203] [snd_pcm:ktime_get_ts
+0x1e/0x4f0] ktime_get_ts+0x1e/0x60
Jul 2 18:16:47 mythtv kernel: [348910.646222] [ktime_get+0x18/0x40]
ktime_get+0x18/0x40
Jul 2 18:16:47 mythtv kernel: [348910.646248] [sys_futex+0x97/0x120]
sys_futex+0x97/0x120
Jul 2 18:16:47 mythtv kernel: [348910.646280] [snd_pcm:getnstimeofday
+0x34/0x9830] getnstimeofday+0x34/0xe0
Jul 2 18:16:47 mythtv kernel: [348910.646330] [work_notifysig
+0x13/0x25] work_notifysig+0x13/0x25
Jul 2 18:16:47 mythtv kernel: [348910.646418] =======================



Any ideas? More info needed?

Thanks,

Brad


chmeredith at gmail

Jul 2, 2009, 8:11 PM

Post #2 of 43 (3685 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Thu, Jul 2, 2009 at 9:23 PM, Brad DerManouelian <bderman [at] gmail>wrote:

> Hello!
>
> I'm having a problem with random recordings failing with my 2 HD-PVR boxes.
>
> HD-PVR: They are connected to my Astound cable set-top boxes via
> Component+S/PDIF. They are running latest firmware from Hauppauge - dmesg
> reports firmware version 0x12. Not sure which driver version I'm using but I
> compiled it about 2 weeks ago.
>
> Random: Same show will record on either box just fine, sometimes it will
> fail. After a fail, I sometimes get a good recording, sometimes another
> failure. Sometimes the first show after a restart will fail, sometimes it
> will be ok. It doesn't appear to have anything to do with specific channels
> or anything like that.
>
> I'm changing channels via firewire.
>
> $ mythbackend --version
> Please include all output in bug reports.
> MythTV Version : 20728
> MythTV Branch : trunk
> Library API : 0.22.20090424-2
> Network Protocol : 45
> QT Version : 4.4.0
> Options compiled in:
> linux release using_oss using_alsa using_arts using_backend using_dvb
> using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv
> using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video
> using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv
> using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl
> using_bindings_python using_opengl using_vdpau using_ffmpeg_threads
> using_libavc_5_3 using_live using_mheg
>
> Here's what I find in my backend log:
>
> 2009-07-02 18:38:15.350 TVRec(1): ASK_RECORDING 1 0 0 0
> 2009-07-02 18:38:15.564 TVRec(1): Changing from None to Watching
> RecordingOnly
> 2009-07-02 18:38:15.573 TVRec(1): HW Tuner: 1->1
> 2009-07-02 18:38:16.479 ret_pid(11381) child(11381) status(0x0)
> 2009-07-02 18:38:16.481 External Tuning program exited with no error
> 2009-07-02 18:38:16.772 AutoExpire: CalcParams(): Max required Free Space:
> 7.0 GB w/freq: 15 min
> 2009-07-02 18:38:16.780 Started recording: The Rachel Maddow Show: channel
> 1037 on cardid 1, sourceid 1
> 2009-07-02 18:38:16.790 scheduler: Started recording: The Rachel Maddow
> Show: channel 1037 on cardid 1, sourceid 1
> 2009-07-02 18:38:24.351 MainServer::ANN Monitor
> 2009-07-02 18:38:24.354 adding: myth-mini as a client (events: 0)
> 2009-07-02 18:38:24.599 mythbackend version: trunk [20728] www.mythtv.org
> 2009-07-02 18:38:24.602 Using runtime prefix = /usr
> 2009-07-02 18:38:24.603 Using localhost value of livingroom
> 2009-07-02 18:38:24.618 New DB connection, total: 1
> 2009-07-02 18:38:24.629 Connected to database 'mythconverg' at host:
> localhost
> 2009-07-02 18:38:24.643 Closing DB connection named 'DBManager0'
> 2009-07-02 18:38:24.645 Connected to database 'mythconverg' at host:
> localhost
> 2009-07-02 18:38:24.654 Current Schema Version: 1235
> 2009-07-02 18:38:25.880 MPEGRec(/dev/video0) Error: Device error detected
> 2009-07-02 18:38:25.884 DevRdB(/dev/video0): Stop(): Not running.
> 2009-07-02 18:38:36.261 MPEGRec(/dev/video0) Error: Device error detected
> 2009-07-02 18:38:36.262 DevRdB(/dev/video0): Stop(): Not running.
> 2009-07-02 18:38:46.641 MPEGRec(/dev/video0) Error: Device error detected
> 2009-07-02 18:38:46.642 DevRdB(/dev/video0): Stop(): Not running.
> 2009-07-02 18:38:57.028 MPEGRec(/dev/video0) Error: Device error detected
> 2009-07-02 18:38:57.029 DevRdB(/dev/video0): Stop(): Not running.
> 2009-07-02 18:39:07.404 MPEGRec(/dev/video0) Error: Device error detected
> 2009-07-02 18:39:07.409 DevRdB(/dev/video0): Stop(): Not running.
>
> I get a bunch of these in /var/log/messages:
>
> Jul 2 18:16:47 mythtv kernel: [348910.645710] Pid: 14286, comm:
> mythbackend Tainted: P (2.6.24-19-generic #1)
> Jul 2 18:16:47 mythtv kernel: [348910.645714] EIP:
> 0060:[sunrpc:_spin_lock+0x5/0x10] EFLAGS: 00000246 CPU: 0
> Jul 2 18:16:47 mythtv kernel: [348910.645717] EIP is at
> _spin_lock+0x5/0x10
> Jul 2 18:16:47 mythtv kernel: [348910.645718] EAX: e4a1ea68 EBX: e4a1ea64
> ECX: f8a3d220 EDX: f3fd0000
> Jul 2 18:16:47 mythtv kernel: [348910.645721] ESI: e4a1ea68 EDI: e49a7140
> EBP: df9aac68 ESP: f3fd1dd0
> Jul 2 18:16:47 mythtv kernel: [348910.645723] DS: 007b ES: 007b FS: 00d8
> GS: 0000 SS: 0068
> Jul 2 18:16:47 mythtv kernel: [348910.645724] CR0: 8005003b CR2: b27fdd5c
> CR3: 1f8c7000 CR4: 00000690
> Jul 2 18:16:47 mythtv kernel: [348910.645726] DR0: 00000000 DR1: 00000000
> DR2: 00000000 DR3: 00000000
> Jul 2 18:16:47 mythtv kernel: [348910.645729] DR6: ffff0ff0 DR7: 00000400
> Jul 2 18:16:47 mythtv kernel: [348910.645731]
> [__mutex_lock_slowpath+0x1a/0xa0] __mutex_lock_slowpath+0x1a/0xa0
> Jul 2 18:16:47 mythtv kernel: [348910.645740] [d_kill+0x3d/0x60]
> d_kill+0x3d/0x60
> Jul 2 18:16:47 mythtv kernel: [348910.645767] [nfs:mutex_lock+0x14/0x290]
> mutex_lock+0x14/0x20
> Jul 2 18:16:47 mythtv kernel: [348910.645777] [<f9361da2>]
> hdpvr_release+0x22/0x60 [hdpvr]
> Jul 2 18:16:47 mythtv kernel: [348910.645797] [<f8a3d242>]
> v4l2_release+0x22/0x40 [videodev]
> Jul 2 18:16:47 mythtv kernel: [348910.645814] [__fput+0xa7/0x190]
> __fput+0xa7/0x190
> Jul 2 18:16:47 mythtv kernel: [348910.645859] [filp_close+0x49/0x80]
> filp_close+0x49/0x80
> Jul 2 18:16:47 mythtv kernel: [348910.645882]
> [put_files_struct+0x92/0xb0] put_files_struct+0x92/0xb0
> Jul 2 18:16:47 mythtv kernel: [348910.645909] [do_exit+0x180/0x860]
> do_exit+0x180/0x860
> Jul 2 18:16:47 mythtv kernel: [348910.645945]
> [sunrpc:recalc_sigpending+0xb/0x40] recalc_sigpending+0xb/0x40
> Jul 2 18:16:47 mythtv kernel: [348910.645948] [dequeue_signal+0x6b/0x150]
> dequeue_signal+0x6b/0x150
> Jul 2 18:16:47 mythtv kernel: [348910.645975] [do_group_exit+0x26/0x80]
> do_group_exit+0x26/0x80
> Jul 2 18:16:47 mythtv kernel: [348910.645993]
> [get_signal_to_deliver+0x2b7/0x4a0] get_signal_to_deliver+0x2b7/0x4a0
> Jul 2 18:16:47 mythtv kernel: [348910.646048]
> [do_notify_resume+0x93/0x750] do_notify_resume+0x93/0x750
> Jul 2 18:16:47 mythtv kernel: [348910.646061] [<f8873a50>]
> scsi_next_command+0x30/0x50 [scsi_mod]
> Jul 2 18:16:47 mythtv kernel: [348910.646099] [<f8873bdb>]
> scsi_end_request+0xab/0xe0 [scsi_mod]
> Jul 2 18:16:47 mythtv kernel: [348910.646174]
> [snd_pcm:getnstimeofday+0x34/0x9830] getnstimeofday+0x34/0xe0
> Jul 2 18:16:47 mythtv kernel: [348910.646203]
> [snd_pcm:ktime_get_ts+0x1e/0x4f0] ktime_get_ts+0x1e/0x60
> Jul 2 18:16:47 mythtv kernel: [348910.646222] [ktime_get+0x18/0x40]
> ktime_get+0x18/0x40
> Jul 2 18:16:47 mythtv kernel: [348910.646248] [sys_futex+0x97/0x120]
> sys_futex+0x97/0x120
> Jul 2 18:16:47 mythtv kernel: [348910.646280]
> [snd_pcm:getnstimeofday+0x34/0x9830] getnstimeofday+0x34/0xe0
> Jul 2 18:16:47 mythtv kernel: [348910.646330] [work_notifysig+0x13/0x25]
> work_notifysig+0x13/0x25
> Jul 2 18:16:47 mythtv kernel: [348910.646418] =======================
>
>

Do you have your STB set up to force 720p or 1080i all the time? The hdpvr
still doesn't like resolution changes and that can cause the driver to crash
sometimes.


bderman at gmail

Jul 2, 2009, 8:27 PM

Post #3 of 43 (3682 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Jul 2, 2009, at 8:11 PM, Christopher Meredith wrote:

> Do you have your STB set up to force 720p or 1080i all the time? The
> hdpvr still doesn't like resolution changes and that can cause the
> driver to crash sometimes.

I thought this might be the problem, but I thought work was done to
prevent crashes during resolution changes. Anyway, I can't set my
STB's to output a particular resolution. I can set the max resolution,
but it will output whatever it is sent (including changing resolutions
mid-stream for commercials).

If anyone knows a secret way to force a resolution out of a DHC-6416,
it would be a place to start.

This being said, I still don't think it's actually the cause of the
problem since I can reboot everything and start with a bad recording
without any resolution change.

Thanks,

Brad

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


harley at thepetersclan

Jul 3, 2009, 8:45 AM

Post #4 of 43 (3658 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Thu, 2 Jul 2009 20:27:52 -0700
Brad DerManouelian <bderman [at] gmail> wrote:

> On Jul 2, 2009, at 8:11 PM, Christopher Meredith wrote:
>
> > Do you have your STB set up to force 720p or 1080i all the time?
> > The hdpvr still doesn't like resolution changes and that can cause
> > the driver to crash sometimes.
>
> I thought this might be the problem, but I thought work was done to
> prevent crashes during resolution changes. Anyway, I can't set my
> STB's to output a particular resolution. I can set the max
> resolution, but it will output whatever it is sent (including
> changing resolutions mid-stream for commercials).
>
> If anyone knows a secret way to force a resolution out of a
> DHC-6416, it would be a place to start.
>
> This being said, I still don't think it's actually the cause of the
> problem since I can reboot everything and start with a bad recording
> without any resolution change.
>
> Thanks,
>
> Brad
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Do you mean DCH-6416 ?
If so :

Turn your tv on.
Turn the cable box off.
Press the menu button on the front of the cable box.
Look for the option HDMI/YPbPr set it to 720P using the arrow and
select buttons.
Set the option 4:3 OVERRIDE to off using the arrow and select buttons.
Press the menu button again and turn on the cable box and your done.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


bderman at gmail

Jul 3, 2009, 12:57 PM

Post #5 of 43 (3659 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Jul 3, 2009, at 8:45 AM, Harley Peters wrote:

> Set the option 4:3 OVERRIDE to off using the arrow and select buttons.

Ahh.. that's the part I was missing. When I can drag my 42" display
into the garage again, I'll give that a go.

Thanks!

-Brad

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


richardwoelk at yahoo

Jul 4, 2009, 1:11 PM

Post #6 of 43 (3600 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

Brad DerManouelian wrote:
> On Jul 2, 2009, at 8:11 PM, Christopher Meredith wrote:
>
>> Do you have your STB set up to force 720p or 1080i all the time? The
>> hdpvr still doesn't like resolution changes and that can cause the
>> driver to crash sometimes.
>
> I thought this might be the problem, but I thought work was done to
> prevent crashes during resolution changes. Anyway, I can't set my
> STB's to output a particular resolution. I can set the max resolution,
> but it will output whatever it is sent (including changing resolutions
> mid-stream for commercials).
>
> If anyone knows a secret way to force a resolution out of a DHC-6416,
> it would be a place to start.
>
> This being said, I still don't think it's actually the cause of the
> problem since I can reboot everything and start with a bad recording
> without any resolution change.
>
> Thanks,
>
> Brad
>
I have two HD-PVRs running of satellite set top boxes. I have found that
even bad signal will cause the driver and mythbackend to crash. Changing
channels even to the same resolution is enough glitch in the video sync
to cause problems. I have noticed mythtv seems to reset the HDPVR
instead of recording 0 byte files, but when the rain fade hits hard, a 1
hour show can turn into 36 minutes.
I havn't upgraded in a while, I am running 20668 on Fedora 11. It seems
to be pretty stable, although I have to watch that my logs don't fill up
with h264 errors.

I just put a 3 second sleep at the end of my channel change script so
that the video stabilizes before the HDPVR starts recording, I can now
change channels in livetv (even though I don't use it that often)
I am running the first beta firmware that gave 5.1 AC3, dmesg reports 0xf.

- Richard



_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


bderman at gmail

Jul 4, 2009, 6:04 PM

Post #7 of 43 (3604 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Jul 3, 2009, at 8:45 AM, Harley Peters wrote:

> On Thu, 2 Jul 2009 20:27:52 -0700
> Brad DerManouelian <bderman [at] gmail> wrote:
>
>> On Jul 2, 2009, at 8:11 PM, Christopher Meredith wrote:
>>
>>> Do you have your STB set up to force 720p or 1080i all the time?
>>> The hdpvr still doesn't like resolution changes and that can cause
>>> the driver to crash sometimes.
>>
>> This being said, I still don't think it's actually the cause of the
>> problem since I can reboot everything and start with a bad recording
>> without any resolution change.
>
> Turn your tv on.
> Turn the cable box off.
> Press the menu button on the front of the cable box.
> Look for the option HDMI/YPbPr set it to 720P using the arrow and
> select buttons.
> Set the option 4:3 OVERRIDE to off using the arrow and select buttons.
> Press the menu button again and turn on the cable box and your done.

I've got both my STB's outputting 720p content only. I still have the
same problem. Randomly some programs record, some don't. The same
program that failed will at some point record correctly.

Firewire is equally unreliable. So frustrating to not being able to
record any more. Maybe Astound cable wasn't such a good idea. DirecTV
never gave me these problems.

-Brad

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


ylee at pobox

Jul 5, 2009, 10:29 AM

Post #8 of 43 (3566 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

Brad DerManouelian <bderman [at] gmail> says:
> Firewire is equally unreliable. So frustrating to not being able to
> record any more. Maybe Astound cable wasn't such a good idea. DirecTV
> never gave me these problems.

Here's what I've used for years for Astound FireWire with 100%
success:

Each box is set to Broadcast, 200mbps. One daisy chains to the other.

I have a crontab script that launches at 12,27,42,57[1] minutes after
each hour. The script is any one of a number of "firewire priming
scripts" available on the Wiki or in the mailing list archives. You
want one that is smart enough to skip priming a tuner in use, as it
will interfere with the signal otherwise.

Yes, every 15 minutes is required. I tried running it every 30 minutes
but found that a few FireWire recordings would get missed.

I intend to one of these days incorporate priming into the
channel-changing process itself to not need the crontab. The last time
I tried this there were issues, either from mythbackend timing out due
to the time it took the channel-changing script to prime then change,
or some issue with the script's exit codes, but I am sure I missed
something obvious.

[1] To more or less eliminate risk of it interfering with the start of
a recording

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


jeremy.thornhill at gmail

Jul 7, 2009, 9:33 PM

Post #9 of 43 (3497 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Thu, 2 Jul 2009 at 19:23:39 Brad DerManouelian wrote:
>
> Hello!
>
> I'm having a problem with random recordings failing with my 2 HD-PVR
> boxes.
>
> HD-PVR: They are connected to my Astound cable set-top boxes via
> Component+S/PDIF. They are running latest firmware from Hauppauge -
> dmesg reports firmware version 0x12. Not sure which driver version I'm
> using but I compiled it about 2 weeks ago.
>
> Random: Same show will record on either box just fine, sometimes it
> will fail. After a fail, I sometimes get a good recording, sometimes
> another failure. Sometimes the first show after a restart will fail,
> sometimes it will be ok. It doesn't appear to have anything to do with
> specific channels or anything like that.
>
> I'm changing channels via firewire.
>

Brad,

I've personally been seeing a similar issue, running 0.21 fixes with
HD-PVR patches applied (I'm aware that I'm doomed to minimal support).
I'm using kernel 2.6.28 with a recent copy of the v4l-dvb drivers from
their source repository. I'm running the firmware that came loaded on
my (rev 2) HDPVR, since I believe firmware updating requires Windows
at this point (please correct me if I'm wrong).

In my case, recordings seem to sporadically fail, and looking at the
backend log reveals that the same "Stop(): Not running. /
MPEGRec(/dev/video3) Error: Device error detected" stuff is coinciding
with the failed program start. Sometimes the recording will succeed
despite these errors, but it seems that failures correspond with an
increased number of error messages. My STB is set to always use 720P
output and the channel change script via firewire never has trouble.

The failure mode in my case is the recording actually does take place,
but the TS stream seems to be corrupted in a way that makes it
unplayable with any software I've thrown at it. Trying to play back
the files on the mythfrontend causes a crash or a hang, and
mythcommflag is unable to flag them. Neither VLC nor mplayer is
capable of playback, refusing to even start playing. The one exception
to this is the image preview in mythtv, which is somehow generated
properly.

I'm thinking (hoping?) that this is a firmware issue, and all I need
to do is track down a Windows box and update the thing, but it sounds
like your problems are very similar so I thought I'd chime in.

Jeremy
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


bderman at gmail

Jul 7, 2009, 9:42 PM

Post #10 of 43 (3502 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Jul 7, 2009, at 9:33 PM, Jeremy Thornhill wrote:

> On Thu, 2 Jul 2009 at 19:23:39 Brad DerManouelian wrote:
>>
>> Hello!
>>
>> I'm having a problem with random recordings failing with my 2 HD-PVR
>> boxes.
>
> Brad,
>
> I've personally been seeing a similar issue, running 0.21 fixes with
> HD-PVR patches applied (I'm aware that I'm doomed to minimal support).
> I'm using kernel 2.6.28 with a recent copy of the v4l-dvb drivers from
> their source repository. I'm running the firmware that came loaded on
> my (rev 2) HDPVR, since I believe firmware updating requires Windows
> at this point (please correct me if I'm wrong).

<snip>

Yes, I believe you need a Windows machine to update the firmware.
Luckily my son has one I could use.

> I'm thinking (hoping?) that this is a firmware issue, and all I need
> to do is track down a Windows box and update the thing, but it sounds
> like your problems are very similar so I thought I'd chime in.

I have the latest firmware and I'm not sure how to get an earlier
version to see if it would fix the problem so I don't know if
upgrading will help you much.

Now that I have switched over to 720p all the time I am getting many
more successful recordings that the frontend will play back (still
some failures), but TONS of errors in my logs. Along with the ones
reported earlier in this thread (Stop(): Not running. / MPEGRec(/dev/
video3) Error: Device error detected), I'm now getting:

2009-07-07 08:06:11.731 [libfaad @ 0xb6f82e10]faac: frame decoding
failed: Invalid number of channels
2009-07-07 08:06:11.832 [libfaad @ 0xb6f82e10]faac: frame decoding
failed: Bitstream value not allowed by specification

By "TONS" I mean enough to fill my hard drive if I don't clear my log
files every couple of days (13GB of these errors since yesterday).

-Brad

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


wambs at verizon

Jul 8, 2009, 5:53 AM

Post #11 of 43 (3488 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

Hi, I'm see the same problem as well. I just rebuilt my server, a few days ago. I'm using SuSe 11.1, and the lastest trunk as of 4 days ago. I compiled the HD-PVR driver from the v4l respoitory. I see the same error, although I have not use the newest software very long, just 4 days. But I have had this show up twice so far. I rebooted the server each time to see if that helps. But not sure so far. I still have the previous HD-PVR driver, so maybe I see if I can compile that with SuSe 11.1. It did with SuSe 11.0. I don't have the logs handle as I'm at work. I though I would add my problem to the list. Should we turn on some logs on the HD-PVR driver, would ones? And I guess we should maybe create a ticket for this?
Thanks, Kevin

Jul 7, 2009 11:33:37 PM, mythtv-users [at] mythtv wrote:
On Thu, 2 Jul 2009 at 19:23:39 Brad DerManouelian wrote:
>
> Hello!
>
> I'm having a problem with random recordings failing with my 2 HD-PVR
> boxes.
>
> HD-PVR: They are connected to my Astound cable set-top boxes via
> Component+S/PDIF. They are running latest firmware from Hauppauge -
> dmesg reports firmware version 0x12. Not sure which driver version I'm
> using but I compiled it about 2 weeks ago.
>
> Random: Same show will record on either box just fine, sometimes it
> will fail. After a fail, I sometimes get a good recording, sometimes
> another failure. Sometimes the first show after a restart will fail,
> sometimes it will be ok. It doesn't appear to have anything to do with
> specific channels or anything like that.
>
> I'm changing channels via firewire.
>

Brad,

I've personally been seeing a similar issue, running 0.21 fixes with
HD-PVR patches applied (I'm aware that I'm doomed to minimal support).
I'm using kernel 2.6.28 with a recent copy of the v4l-dvb drivers from
their source repository. I'm running the firmware that came loaded on
my (rev 2) HDPVR, since I believe firmware updating requires Windows
at this point (please correct me if I'm wrong).

In my case, recordings seem to sporadically fail, and looking at the
backend log reveals that the same "Stop(): Not running. /
MPEGRec(/dev/video3) Error: Device error detected" stuff is coinciding
with the failed program start. Sometimes the recording will succeed
despite these errors, but it seems that failures correspond with an
increased number of error messages. My STB is set to always use 720P
output and the channel change script via firewire never has trouble.

The failure mode in my case is the recording actually does take place,
but the TS stream seems to be corrupted in a way that makes it
unplayable with any software I've thrown at it. Trying to play back
the files on the mythfrontend causes a crash or a hang, and
mythcommflag is unable to flag them. Neither VLC nor mplayer is
capable of playback, refusing to even start playing. The one exception
to this is the image preview in mythtv, which is somehow generated
properly.

I'm thinking (hoping?) that this is a firmware issue, and all I need
to do is track down a Windows box and update the thing, but it sounds
like your problems are very similar so I thought I'd chime in.

Jeremy
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users"]http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


phil.linttell at rogers

Jul 8, 2009, 5:53 AM

Post #12 of 43 (3494 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

Hi Brad,

I have only an HD-PVR, firmware reported as 0x12, running under trunk
with which I'm recording everything at 720p with AC3 audio. I have a
combined back/front-end based on kubuntu 9.10 alpha (amd64 and VDPAU,
kernel 2.6.30-9 at the moment.)

Yes, it's much more stable with the STB fixed to 720p. I'll get
anywhere from 1 to a half-dozen successful recordings, and then all
subsequent recordings will fail, and LiveTV displays old frame buffer
information and refuses to start. The only way to get it working again
is a hard restart of my back-end (power cycling the STB and HD-PVR, and
restarting the back/front-ends has not effect.) I'm thinking the issue
is related to the hdpvr driver, and next step is to upgrade to kernel
2.6.31 and test with the latest v4l-dvb.

I also get "TONS" of (mainly ac3 decoding related) errors in my logs,
even after the latest FFmpeg sync. Although this is less of a concern
for me right now to the failed recordings.

On 07/08/2009 08:00 AM, mythtv-users-request [at] mythtv wrote:
> Now that I have switched over to 720p all the time I am getting many
> more successful recordings that the frontend will play back (still
> some failures), but TONS of errors in my logs. Along with the ones
> reported earlier in this thread (Stop(): Not running. / MPEGRec(/dev/
> video3) Error: Device error detected), I'm now getting:
>
> 2009-07-07 08:06:11.731 [libfaad @ 0xb6f82e10]faac: frame decoding
> failed: Invalid number of channels
> 2009-07-07 08:06:11.832 [libfaad @ 0xb6f82e10]faac: frame decoding
> failed: Bitstream value not allowed by specification
>
> By "TONS" I mean enough to fill my hard drive if I don't clear my log
> files every couple of days (13GB of these errors since yesterday).
>
> -Brad
>
>


jppoet at gmail

Jul 8, 2009, 6:55 AM

Post #13 of 43 (3483 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Wed, Jul 8, 2009 at 6:53 AM, Phil Linttell<phil.linttell [at] rogers> wrote:
> Hi Brad,
>
> I have only an HD-PVR, firmware reported as 0x12, running under trunk with
> which I'm recording everything at 720p with AC3 audio.  I have a combined
> back/front-end based on kubuntu 9.10 alpha (amd64 and VDPAU, kernel 2.6.30-9
> at the moment.)
>
> Yes, it's much more stable with the STB fixed to 720p.  I'll get anywhere
> from 1 to a half-dozen successful recordings, and then all subsequent
> recordings will fail, and LiveTV displays old frame buffer information and
> refuses to start.  The only way to get it working again is a hard restart of
> my back-end (power cycling the STB and HD-PVR, and restarting the
> back/front-ends has not effect.)   I'm thinking the issue is related to the
> hdpvr driver, and next step is to upgrade to kernel 2.6.31 and test with the
> latest v4l-dvb.
>
> I also get "TONS" of (mainly ac3 decoding related) errors in my logs, even
> after the latest FFmpeg sync.  Although this is less of a concern for me
> right now to the failed recordings.


Those ac3 decoding errors *might* be the clue to the problem. Next
time your system stop recording properly, please do a "ps -aux | grep
mythbackend" and see what is out there. I bet you will find a bunch
of generate-preview processes. Kill those, and myth will probably be
able to function normally again.

To combat this problem, I actually have "pkill -f generate-preview" in
a cron job which runs every 7 minutes.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


steve at heistand

Jul 8, 2009, 7:14 AM

Post #14 of 43 (3480 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

is it possibly heat related issues causing the failed recordings?
the hdpvr units themselves that is not being able to stay cool?
I do an average of 4-5 recordings a day and never have problems other
then the occasional log messages of:
2009-07-07 23:31:05.217 AFD Error: Unknown decoding error
2009-07-07 23:31:05.225 [h264 @ 0xb70391d0]B picture before any references, skipping
2009-07-07 23:31:05.234 [h264 @ 0xb70391d0]decode_slice_header error
2009-07-07 23:31:05.241 [h264 @ 0xb70391d0]no frame!

on some recordings but they were recorded and playback fine.



"Why is it so hot inside this handbasket?"
--
Steve Heistand
steve [at] heistand

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


bderman at gmail

Jul 8, 2009, 7:45 AM

Post #15 of 43 (3493 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Jul 8, 2009, at 7:14 AM, Steve Heistand wrote:

> is it possibly heat related issues causing the failed recordings?
> the hdpvr units themselves that is not being able to stay cool?
> I do an average of 4-5 recordings a day and never have problems other
> then the occasional log messages of:
> 2009-07-07 23:31:05.217 AFD Error: Unknown decoding error
> 2009-07-07 23:31:05.225 [h264 @ 0xb70391d0]B picture before any
> references, skipping
> 2009-07-07 23:31:05.234 [h264 @ 0xb70391d0]decode_slice_header error
> 2009-07-07 23:31:05.241 [h264 @ 0xb70391d0]no frame!
>
> on some recordings but they were recorded and playback fine.

I don't think heat is the problem. My setup is in a cooler place now
(in the garage, not living room) and has a lot more circulation (out
in the open, not tucked away in a rack unit). Plus, it's happening on
both of my units exactly the same way.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


jppoet at gmail

Jul 8, 2009, 8:44 AM

Post #16 of 43 (3475 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Wed, Jul 8, 2009 at 8:14 AM, Steve Heistand<steve [at] heistand> wrote:
> is it possibly heat related issues causing the failed recordings?
> the hdpvr units themselves that is not being able to stay cool?
> I do an average of 4-5 recordings a day and never have problems other
> then the occasional log messages of:
> 2009-07-07 23:31:05.217 AFD Error: Unknown decoding error
> 2009-07-07 23:31:05.225 [h264 @ 0xb70391d0]B picture before any references, skipping
> 2009-07-07 23:31:05.234 [h264 @ 0xb70391d0]decode_slice_header error
> 2009-07-07 23:31:05.241 [h264 @ 0xb70391d0]no frame!
>
> on some recordings but they were recorded and playback fine.

Those errors are normal. They happen when it is trying to seek to a
particular frame, and land on a non-keyframe in the process.

I get the impression that you are running -fixes? If so, you would
probably have more luck running trunk -- or waiting a month for 0.22
to be released.

My failure rate for recording from my pair of HD-PVRs is probably
around 1 out of every 500. I recorded every Wimbledon tennis episode
over the previous two weeks, and did not have a single problem.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


david at istwok

Jul 8, 2009, 9:01 AM

Post #17 of 43 (3478 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Wed, Jul 08, 2009 at 12:33:11AM -0400, Jeremy Thornhill wrote:
> In my case, recordings seem to sporadically fail, and looking at the
> backend log reveals that the same "Stop(): Not running. /
> MPEGRec(/dev/video3) Error: Device error detected" stuff is coinciding
> with the failed program start. Sometimes the recording will succeed
> despite these errors, but it seems that failures correspond with an
> increased number of error messages. My STB is set to always use 720P
> output and the channel change script via firewire never has trouble.
>
> The failure mode in my case is the recording actually does take place,
> but the TS stream seems to be corrupted in a way that makes it
> unplayable with any software I've thrown at it. Trying to play back
> the files on the mythfrontend causes a crash or a hang, and
> mythcommflag is unable to flag them. Neither VLC nor mplayer is
> capable of playback, refusing to even start playing. The one exception
> to this is the image preview in mythtv, which is somehow generated
> properly.

I've always had the recorder stopping and restarting problem. Things
seem to have gotten worse in the last month, though. Previously,
there would be a glitch during playback when a stop/restart point was
encoutered, but playback would usually resume. This was pretty much
exclusively with software decoding. Now, with software decoding, the
frontend usually segfaults when encoutering a stop/restart point.
With, VDPAU, playback tends to continue, but it gets very stuttery.

I think the apparent worsening of the problem around a month ago or so
is due to player change, but I haven't looked into it. Another
potential culprit is a change in the stop/restart handling in the
recorder when John Poet's patch to handle it was incorporated.

My current workaround for the playback failing is to restart the
player and then immediately skip past the problem area. I do this by
either making sure the bookmark gets save when I exit or I jumping to
the specific minute I want.

> I'm thinking (hoping?) that this is a firmware issue, and all I need
> to do is track down a Windows box and update the thing, but it sounds
> like your problems are very similar so I thought I'd chime in.

This is mainly for Janne. What is the recommended firmware these
days? I tried to follow the shspvr forum, but there seemed to be too
many versions floating around and no consensus on which one to use.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


steve at heistand

Jul 8, 2009, 9:07 AM

Post #18 of 43 (3477 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Wed, 8 Jul 2009 09:44:26 -0600, John P Poet wrote
> On Wed, Jul 8, 2009 at 8:14 AM, Steve Heistand<steve [at] heistand> wrote:
> > is it possibly heat related issues causing the failed recordings?
> > the hdpvr units themselves that is not being able to stay cool?
> > I do an average of 4-5 recordings a day and never have problems other
> > then the occasional log messages of:
> > 2009-07-07 23:31:05.217 AFD Error: Unknown decoding error
> > 2009-07-07 23:31:05.225 [h264 @ 0xb70391d0]B picture before any references, skipping
> > 2009-07-07 23:31:05.234 [h264 @ 0xb70391d0]decode_slice_header error
> > 2009-07-07 23:31:05.241 [h264 @ 0xb70391d0]no frame!
> >
> > on some recordings but they were recorded and playback fine.
>
> Those errors are normal. They happen when it is trying to seek to a
> particular frame, and land on a non-keyframe in the process.
>
> I get the impression that you are running -fixes? If so, you would
> probably have more luck running trunk -- or waiting a month for 0.22
> to be released.
>
> My failure rate for recording from my pair of HD-PVRs is probably
> around 1 out of every 500. I recorded every Wimbledon tennis episode
> over the previous two weeks, and did not have a single problem.
>
> John
> --

I should have mentioned version yes, running moderately recent
trunk:
MythTV Version : 20666
MythTV Branch : trunk
Library API : 0.22.20090424-2

I have no issues with my current setup so I try not to keep uptodate
on trunk.if it aint broke dont piss off the wife kind of thing...


"Why is it so hot inside this handbasket?"
--
Steve Heistand
steve [at] heistand

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


david at istwok

Jul 8, 2009, 9:08 AM

Post #19 of 43 (3469 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Wed, Jul 08, 2009 at 09:44:26AM -0600, John P Poet wrote:
> My failure rate for recording from my pair of HD-PVRs is probably
> around 1 out of every 500. I recorded every Wimbledon tennis episode
> over the previous two weeks, and did not have a single problem.

Johh, which kernel, V4L drivers and HD-PVR versions are you using? I
haven't kept exact numbers, but I suspect I'm averaging around 1.5 to
2.0 stop/restart cycles per hour. It used to only be a minor nuisance,
but with the playback handling getting worse as I described in an
earlier message, it's become a major annoyance.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


jppoet at gmail

Jul 8, 2009, 9:13 AM

Post #20 of 43 (3467 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Wed, Jul 8, 2009 at 10:01 AM, David Engel<david [at] istwok> wrote:
> On Wed, Jul 08, 2009 at 12:33:11AM -0400, Jeremy Thornhill wrote:
>> In my case, recordings seem to sporadically fail, and looking at the
>> backend log reveals that the same "Stop(): Not running. /
>> MPEGRec(/dev/video3) Error: Device error detected" stuff is coinciding
>> with the failed program start. Sometimes the recording will succeed
>> despite these errors, but it seems that failures correspond with an
>> increased number of error messages. My STB is set to always use 720P
>> output and the channel change script via firewire never has trouble.
>>
>> The failure mode in my case is the recording actually does take place,
>> but the TS stream seems to be corrupted in a way that makes it
>> unplayable with any software I've thrown at it. Trying to play back
>> the files on the mythfrontend causes a crash or a hang, and
>> mythcommflag is unable to flag them. Neither VLC nor mplayer is
>> capable of playback, refusing to even start playing. The one exception
>> to this is the image preview in mythtv, which is somehow generated
>> properly.
>
> I've always had the recorder stopping and restarting problem.  Things
> seem to have gotten worse in the last month, though.  Previously,
> there would be a glitch during playback when a stop/restart point was
> encoutered, but playback would usually resume.  This was pretty much
> exclusively with software decoding.  Now, with software decoding, the
> frontend usually segfaults when encoutering a stop/restart point.
> With, VDPAU, playback tends to continue, but it gets very stuttery.
>
> I think the apparent worsening of the problem around a month ago or so
> is due to player change, but I haven't looked into it.  Another
> potential culprit is a change in the stop/restart handling in the
> recorder when John Poet's patch to handle it was incorporated.

I am guessing the reason different people have recording problems,
while others don't, has to do with their STBs, and possibly their
channel change scripts. One variable you can play with, is adding a 1
or 2 second sleep to the bottom of your channel change script. With
the code currently committed to myth trunk, a 1 second sleep is needed
in my directv script for reliable operation.

Adding a signal handler for the HD-PVR removed the need for that one
second delay in the channel change script (as well as some other
hard-coded sleeps in the code), but causes problems for those people
using IR-blasters. While I came up with a solution, it became pretty
obvious that it would not be accepted for inclusion in Myth, so I
stopped working on it.


> My current workaround for the playback failing is to restart the
> player and then immediately skip past the problem area.  I do this by
> either making sure the bookmark gets save when I exit or I jumping to
> the specific minute I want.
>
>> I'm thinking (hoping?) that this is a firmware issue, and all I need
>> to do is track down a Windows box and update the thing, but it sounds
>> like your problems are very similar so I thought I'd chime in.
>
> This is mainly for Janne.  What is the recommended firmware these
> days?  I tried to follow the shspvr forum, but there seemed to be too
> many versions floating around and no consensus on which one to use.

Hauppauge themselves strongly recommends using the latest version. I
guess they fixed something which could brick your HD-PVR.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


harley at thepetersclan

Jul 8, 2009, 9:15 AM

Post #21 of 43 (3475 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Wed, 8 Jul 2009 09:44:26 -0600
John P Poet <jppoet [at] gmail> wrote:

> On Wed, Jul 8, 2009 at 8:14 AM, Steve Heistand<steve [at] heistand>
> wrote:
> > is it possibly heat related issues causing the failed recordings?
> > the hdpvr units themselves that is not being able to stay cool?
> > I do an average of 4-5 recordings a day and never have problems
> > other then the occasional log messages of:
> > 2009-07-07 23:31:05.217 AFD Error: Unknown decoding error
> > 2009-07-07 23:31:05.225 [h264 @ 0xb70391d0]B picture before any
> > references, skipping 2009-07-07 23:31:05.234 [h264 @
> > 0xb70391d0]decode_slice_header error 2009-07-07 23:31:05.241 [h264
> > @ 0xb70391d0]no frame!
> >
> > on some recordings but they were recorded and playback fine.
>
> Those errors are normal. They happen when it is trying to seek to a
> particular frame, and land on a non-keyframe in the process.
>
> I get the impression that you are running -fixes? If so, you would
> probably have more luck running trunk -- or waiting a month for 0.22
> to be released.
>
> My failure rate for recording from my pair of HD-PVRs is probably
> around 1 out of every 500. I recorded every Wimbledon tennis episode
> over the previous two weeks, and did not have a single problem.
>
>
> John

Using trunk won't fix the restarts. There caused by glitches in the
video or audio. Personally I think it has more to do with glitches in
the 5.1 audio rather than the video.
I had a lot less problems before 5.1 audio support was added.
It might help with the recordings not playing back. I am running trunk
and don't have any problems playing the recordings.
The problem isn't with Mythtv it's the firmware are the driver and are
crappy cable or satellite companies.


_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


jppoet at gmail

Jul 8, 2009, 9:18 AM

Post #22 of 43 (3478 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Wed, Jul 8, 2009 at 10:08 AM, David Engel<david [at] istwok> wrote:
> On Wed, Jul 08, 2009 at 09:44:26AM -0600, John P Poet wrote:
>> My failure rate for recording from my pair of HD-PVRs is probably
>> around 1 out of every 500.  I recorded every Wimbledon tennis episode
>> over the previous two weeks, and did not have a single problem.
>
> Johh, which kernel, V4L drivers and HD-PVR versions are you using?  I
> haven't kept exact numbers, but I suspect I'm averaging around 1.5 to
> 2.0 stop/restart cycles per hour.  It used to only be a minor nuisance,
> but with the playback handling getting worse as I described in an
> earlier message, it's become a major annoyance.

I am running the latest 2.6.27-fedora10 kernel, with hand built HD-PVR
drivers from linuxtv.org. Latest HD-PVR firmware.

Two HD-PVRs hanging off of a Gigabyte EP45 motherboard. Directv H2x
STBs controlled via USB.

When I got my first HD-PVR, I tried using it with an old P4
motherboard, and had lots of problems. I believe they were related to
the USB controller on that motherboard. Going the the P45 motherboard
fixed all that.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


bderman at gmail

Jul 8, 2009, 9:35 AM

Post #23 of 43 (3479 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

On Jul 8, 2009, at 9:18 AM, John P Poet wrote:

> I am running the latest 2.6.27-fedora10 kernel, with hand built HD-PVR
> drivers from linuxtv.org. Latest HD-PVR firmware.
>
> Two HD-PVRs hanging off of a Gigabyte EP45 motherboard. Directv H2x
> STBs controlled via USB.
>
> When I got my first HD-PVR, I tried using it with an old P4
> motherboard, and had lots of problems. I believe they were related to
> the USB controller on that motherboard. Going the the P45 motherboard
> fixed all that.

I started having the troubles when I moved from Satellite to Cable,
but I also upgraded the HDPVR firmware at that time (to get 5.1
audio), so I guess I'm not sure which is the problem. I have added 2
seconds of sleep to the end of the mythchanger script I'm using. I'll
report back if that has an effect.

-Brad


_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


wambs at verizon

Jul 8, 2009, 9:40 AM

Post #24 of 43 (3478 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

Jul 7, 2009 11:33:37 PM, mythtv-users [at] mythtv wrote:
On Thu, 2 Jul 2009 at 19:23:39 Brad DerManouelian wrote:
>
> Hello!
>
> I'm having a problem with random recordings failing with my 2 HD-PVR
> boxes.
>
> HD-PVR: They are connected to my Astound cable set-top boxes via
> Component+S/PDIF. They are running latest firmware from Hauppauge -
> dmesg reports firmware version 0x12. Not sure which driver version I'm
> using but I compiled it about 2 weeks ago.
>
> Random: Same show will record on either box just fine, sometimes it
> will fail. After a fail, I sometimes get a good recording, sometimes
> another failure. Sometimes the first show after a restart will fail,
> sometimes it will be ok. It doesn't appear to have anything to do with
> specific channels or anything like that.
>
> I'm changing channels via firewire.
>

Brad,

I've personally been seeing a similar issue, running 0.21 fixes with
HD-PVR patches applied (I'm aware that I'm doomed to minimal support).
I'm using kernel 2.6.28 with a recent copy of the v4l-dvb drivers from
their source repository. I'm running the firmware that came loaded on
my (rev 2) HDPVR, since I believe firmware updating requires Windows
at this point (please correct me if I'm wrong).

In my case, recordings seem to sporadically fail, and looking at the
backend log reveals that the same "Stop(): Not running. /
MPEGRec(/dev/video3) Error: Device error detected" stuff is coinciding
with the failed program start. Sometimes the recording will succeed
despite these errors, but it seems that failures correspond with an
increased number of error messages. My STB is set to always use 720P
output and the channel change script via firewire never has trouble.

The failure mode in my case is the recording actually does take place,
but the TS stream seems to be corrupted in a way that makes it
unplayable with any software I've thrown at it. Trying to play back
the files on the mythfrontend causes a crash or a hang, and
mythcommflag is unable to flag them. Neither VLC nor mplayer is
capable of playback, refusing to even start playing. The one exception
to this is the image preview in mythtv, which is somehow generated
properly.

I'm thinking (hoping?) that this is a firmware issue, and all I need
to do is track down a Windows box and update the thing, but it sounds
like your problems are very similar so I thought I'd chime in.

Jeremy
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users"]http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users Hi, I'm see the same problem as well. I just rebuilt my server, a few days ago. I'm using SuSe 11.1, and the lastest trunk as of 4 days ago. I compiled the HD-PVR driver from the v4l respoitory. I see the same error, although I have not use the newest software very long, just 4 days. But I have had this show up twice so far. I rebooted the server each time to see if that helps. But not sure so far. I still have the previous HD-PVR driver, so maybe I see if I can compile that with SuSe 11.1. It did with SuSe 11.0. I don't have the logs handle as I'm at work. I though I would add my problem to the list. Should we turn on some logs on the HD-PVR driver, would ones? And I guess we should maybe create a ticket for this?
Thanks, Kevin


wambs at verizon

Jul 8, 2009, 9:56 AM

Post #25 of 43 (3467 views)
Permalink
Re: Failed HD-PVR recordings [In reply to]

Hi John, Sorry for the top post, but stupid verizon webmail does not allow me to bottom post. I'm using DirectTV as well. Could you post your channel change script or send to me? What model of STB do you have? I think mine is H21-???. I'm at work right now. What version of the firmware in your HD-PVR do you have? Thanks for your help, Kevin


Jul 8, 2009 11:13:56 AM, mythtv-users [at] mythtv wrote:
On Wed, Jul 8, 2009 at 10:01 AM, David Engel<david [at] istwok> wrote:
> On Wed, Jul 08, 2009 at 12:33:11AM -0400, Jeremy Thornhill wrote:
>> In my case, recordings seem to sporadically fail, and looking at the
>> backend log reveals that the same "Stop(): Not running. /
>> MPEGRec(/dev/video3) Error: Device error detected" stuff is coinciding
>> with the failed program start. Sometimes the recording will succeed
>> despite these errors, but it seems that failures correspond with an
>> increased number of error messages. My STB is set to always use 720P
>> output and the channel change script via firewire never has trouble.
>>
>> The failure mode in my case is the recording actually does take place,
>> but the TS stream seems to be corrupted in a way that makes it
>> unplayable with any software I've thrown at it. Trying to play back
>> the files on the mythfrontend causes a crash or a hang, and
>> mythcommflag is unable to flag them. Neither VLC nor mplayer is
>> capable of playback, refusing to even start playing. The one exception
>> to this is the image preview in mythtv, which is somehow generated
>> properly.
>
> I've always had the recorder stopping and restarting problem. Things
> seem to have gotten worse in the last month, though. Previously,
> there would be a glitch during playback when a stop/restart point was
> encoutered, but playback would usually resume. This was pretty much
> exclusively with software decoding. Now, with software decoding, the
> frontend usually segfaults when encoutering a stop/restart point.
> With, VDPAU, playback tends to continue, but it gets very stuttery.
>
> I think the apparent worsening of the problem around a month ago or so
> is due to player change, but I haven't looked into it. Another
> potential culprit is a change in the stop/restart handling in the
> recorder when John Poet's patch to handle it was incorporated.

I am guessing the reason different people have recording problems,
while others don't, has to do with their STBs, and possibly their
channel change scripts. One variable you can play with, is adding a 1
or 2 second sleep to the bottom of your channel change script. With
the code currently committed to myth trunk, a 1 second sleep is needed
in my directv script for reliable operation.

Adding a signal handler for the HD-PVR removed the need for that one
second delay in the channel change script (as well as some other
hard-coded sleeps in the code), but causes problems for those people
using IR-blasters. While I came up with a solution, it became pretty
obvious that it would not be accepted for inclusion in Myth, so I
stopped working on it.


> My current workaround for the playback failing is to restart the
> player and then immediately skip past the problem area. I do this by
> either making sure the bookmark gets save when I exit or I jumping to
> the specific minute I want.
>
>> I'm thinking (hoping?) that this is a firmware issue, and all I need
>> to do is track down a Windows box and update the thing, but it sounds
>> like your problems are very similar so I thought I'd chime in.
>
> This is mainly for Janne. What is the recommended firmware these
> days? I tried to follow the shspvr forum, but there seemed to be too
> many versions floating around and no consensus on which one to use.

Hauppauge themselves strongly recommends using the latest version. I
guess they fixed something which could brick your HD-PVR.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users"]http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

First page Previous page 1 2 Next page Last page  View All MythTV users 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.