[mythtv-users] HD-PVR Dropouts

Tue Feb 23 16:00:06 UTC 2010

On Tue, Feb 23, 2010 at 12:01 AM, Douglas Choma <doug at polaritylabs.com> wrote:
> On 2/22/10 6:59 PM, Richard Woelk wrote:
>>
>> Douglas Choma wrote:
>>>
>>> On 2/18/10 2:30 PM, greg wrote:
>>>>
>>>> Douglas Choma wrote:
>>>>>
>>>>> On 2/18/10 8:01 AM, greg wrote:
>>>>>>
>>>>>> Douglas Choma wrote:
>>>>>>>
>>>>>>> I'm experiencing a similar issue after moving to 0.22-fixes (and 0.23
>>>>>>> trunk).
>>>>>>>
>>>>>>> When watching live tv and changing the channel, I get the following
>>>>>>> error on the backend...
>>>>>>> DevRdB(/dev/video0) Error: Poll giving up
>>>>>>> MPEGRec(/dev/video0) Error: Device error detected
>>>>>>> DevRdB(/dev/video0): Stop(): Not running.
>>>>>>>
>>>>>>> And this happens on the frontend...
>>>>>>> [aac @ 0x7f2128a14920]channel element 0.5 is not allocated
>>>>>>> audio stream changed
>>>>>>> DEnc, Error: Could not open codec, invalid bitrate or samplerate
>>>>>>> Segmentation fault
>>>>>>>
>>>>>>> I'm guessing this has to be an issue with Myth, because the same
>>>>>>> setup worked when I was using 0.22 from trunk.  It only started after 0.22
>>>>>>> moved to stable.
>>>>>>>
>>>>>>> I get the same results with the 0.23 trunk.
>>>>>>>
>>>>>>> Here's my current build...
>>>>>>> MythTV Version   : 23504M
>>>>>>> MythTV Branch    : trunk
>>>>>>> Network Protocol : 56
>>>>>>> Library API      : 0.23.20100131-1
>>>>>>> QT Version       : 4.4.3
>>>>>>> Options compiled in:
>>>>>>>  linux release using_oss using_alsa 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_bindings_perl
>>>>>>> using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3
>>>>>>> using_live using_mheg
>>>>>>
>>>>>> I am running trunk and have been since the HDPVR became available. I
>>>>>> don't experience the problems you are seeing.. My setup is pretty stable.. I
>>>>>> compared my setup to yours and they are very similar...  I am running a
>>>>>> newer version of Myth,plus a different version of QT...
>>>>>> The only problem I've had with the HDPVR was it was switching
>>>>>> nodes,but with the help of a few people on here I got that working...
>>>>>> OS Ubuntu 9.10 Nvidia 195.36.03
>>>>>>
>>>>>> MythTV Version   : 23567
>>>>>> MythTV Branch    : trunk
>>>>>> Network Protocol : 56
>>>>>> Library API      : 0.23.20100212-1
>>>>>> QT Version       : 4.5.2
>>>>>> Options compiled in:
>>>>>> linux debug using_oss using_alsa using_backend using_dvb
>>>>>> using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv
>>>>>> using_joystick_menu using_lirc using_mheg using_opengl_video
>>>>>> using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11
>>>>>> using_xrandr using_xv using_bindings_perl using_bindings_python using_opengl
>>>>>> using_vdpau using_ffmpeg_threads using_live using_mheg
>>>>>
>>>>> Thanks Greg,
>>>>>
>>>>> Are you running any patches against trunk?  I noticed the wiki still
>>>>> mentions "recommended" patches, which I've applied.  It sounds like I might
>>>>> just need to purge everything and do a clean build.
>>>>>
>>>>> Which version of the v4l-dvb drivers are you working with?
>>>>>
>>>>>
>>>> No, I have don't have any patches installed ..Since I moved to Ubuntu
>>>> 9.10 the driver just works...
>>>
>>> Anybody have advice for other things to try debugging?  This is driving
>>> me nuts.  :-(
>>>
>>> I did a clean build on both the backend and the frontend from trunk,
>>> which seems to have cured the segfaults on my frontend.  But I still get the
>>> audio errors when I change channels on LiveTV.  The video changes fine, but
>>> the audio is missing after a channel change.  If I exit LiveTV and go back,
>>> everything tunes in without error.  So it's only switching from one stream
>>> to another that causes problems.
>>>
>>> I'm using the latest firmware, the most current driver, and myth trunk
>>> (23578).  This problem never occurred until the 0.22 branch went mainstream.
>>>  I had been using the 0.22 trunk with HD-PVR without issue.
>>>
>>> The frontend goes bezerk with these errors when I change channels...
>>> ###
>>> audio stream changed
>>> AO: Using resampler. From: 88200 to 192000
>>> Opening audio device 'default'. ch 2(1) sr 192000 (reenc 0)
>>> Opening ALSA audio device 'default'.
>>> AFD Error: Unknown audio decoding error
>>> [aac @ 0x7ff558ffeb20]Error decoding AAC frame header.
>>> AFD Error: Unknown audio decoding error
>>> [aac @ 0x7ff558ffeb20]Not evaluating a further program_config_element as
>>> this construct is dubious at best.
>>> [aac @ 0x7ff558ffeb20]channel element 1.5 is not allocated
>>> audio stream changed
>>> AO: Using resampler. From: 24000 to 192000
>>> Opening audio device 'default'. ch 2(1) sr 192000 (reenc 0)
>>> Opening ALSA audio device 'default'.
>>> AFD Error: Unknown audio decoding error
>>> [aac @ 0x7ff558ffeb20]Error decoding AAC frame header.
>>> AFD Error: Unknown audio decoding error
>>> [aac @ 0x7ff558ffeb20]channel element 3.0 is not allocated
>>> audio stream changed
>>> AO: Using resampler. From: 7350 to 192000
>>> Opening audio device 'default'. ch 2(1) sr 192000 (reenc 0)
>>> Opening ALSA audio device 'default'.
>>> AFD Error: Unknown audio decoding error
>>> [aac @ 0x7ff558ffeb20]Error decoding AAC frame header.
>>> AFD Error: Unknown audio decoding error
>>> [aac @ 0x7ff558ffeb20]channel element 0.4 is not allocated
>>> ###
>>
>>
>> I have been using an HD-PVR since it came out as well, but on Fedora. I
>> currently use compiled trunk packages from ATRPMS, which now is version
>> 23405. I use the driver that comes with the kernel, I have not needed to
>> compile the driver in a while.  - my current kernel is
>> 2.6.30.10-105.2.16.fc11.x86_64
>>
>> I also have had trouble changing channels with live tv, I had to set a 5
>> second delay in my channel change script to get it to work. It turns out, it
>> takes that long for my set top box to "settle down" after changing channels.
>> I rarely use livetv, so I usually leave that delay commented out.
>>
>> - Richard
>
> Interesting.  So it sounds like it might be caused when Myth tries to start
> the new stream before the cable box is ready to go.  Sadly, the audio
> decoding never seems to settle down.  Unless I exit LiveTV, that audio
> decoding error goes on indefinitely.
>
> I wonder if there's some way (aside from hacking the driver) that I could
> get the audio to reinitialize a few seconds after the channel change.
>
> How are you able to introduce the delay in your channel changing script?

In my case, I just add 'sleep 4' as the last line.