[mythtv-users] Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point

Tue May 8 15:36:35 UTC 2012

On 05/08/2012 07:44 AM, Michael Harnden wrote:
> Quoting Kenan Ezal:
>
>> Summary of problem:
>>
>> After I reboot both my master backend and slave backend I schedule 
>> recordings (that are currently on) to test my three tuners 
>> (PVR-250/PVR-150 on master backend and PVR-350 on slave backend). All 
>> three tuners record their respective shows and I am able to play back 
>> during recording. I delete the shows and try again for a different 
>> set of programs on different channels. Once again everything works 
>> and I am pleased thinking my kids will be happy with the new Mickey 
>> Mouse Clubhouse show that is scheduled to be recorded the next morning.
>>
>> The following morning I wake up to find that the first show that was 
>> scheduled for recording at 2am (Phineas and Ferb) recorded fine 
>> although the backend did report a database error (see below). 
>> However, the second show (Doc McStuffins at 7:30am) and the third 
>> show (Mickey Mouse Club House at 8am) did not record, although they 
>> show up in grey on my list of recordings. All three shows were 
>> scheduled to use Tuner 1 (PVR-250).
>>
>> I am puzzled so I sellect three other shows (such as the highly 
>> provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for 
>> immediate recording. All three appear to be recording. However, when 
>> I check Tuner 1 I see that it is not. I stop the recording on Tuner 1 
>> (leaving the others recording) and try LiveTV and receive the 
>> following error: "Error opening jump program buffer." The other two 
>> tuners are in fact recording. However, I am able to recreate the same 
>> issue with any of the tuners. For example, the other night I decided 
>> to disable Tuner 1 so that Tuner 2 was the first in line to record. 
>> The next morning same problem. I then disabled Tuners 1 and 2, and 
>> the same problem occurred with Tuner 3 (on slave backend). They all 
>> initially record fine, but fail during a later scheduled recording, 
>> usually after successfully recording the first show.
>>
>> Extended Discussion:
>>
>> Unfortunately, this started about two weeks ago when I upgraded from 
>> 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At 
>> first I thought it was a power supply problem because we had been 
>> having some power problems in our area and I found my master backend 
>> completely off one morning. However, I believe that was a false alarm 
>> and now it appears to be a software problem. The system was very 
>> stable and recording away happily before the upgrade.
>>
>> I have noted that other people have been reporting similar problems 
>> with their PVRs although the descriptons vary a some and many seem to 
>> be focused on LiveTV. We never watch LiveTV, always recorded shows so 
>> I know it isn't a problem solely related to LiveTV.
>>
>> See for exampe:
>>
>> http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
>> https://bugs.archlinux.org/task/29627
>>
>> I did discover that there is a possible fix, but I"m not sure when 
>> its going to get into the packages:
>>
>> https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7da14196cedd8c 
>>
>>
>> However, I'm not completely convinced that is the only problem on my 
>> system since I can't seem to make it fail on will. It's repeatable in 
>> that after a reboot, it will happen (probably overnight).
>>
>> 1. I'm curious if anyone else has had similar issues and was able to 
>> fix it without the above mentioned fix (I did try deleting all the 
>> tuners and inputs and adding them back in and it did not help).
>>
>> snip
>
> I can add a "me too". Upgraded from 0.24 to 0.25 last night using 
> Mythbuntu. My PVR-350 now exhibits the same behavior. It will work 
> once following a reboot. I can watch live tv once, then failure, or 
> record one show, then failure.
>
> Log;
>
> May  8 07:29:25 mythtv-server mythbackend[1930]: I TVRecEvent 
> tv_rec.cpp:1521 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 23 
> 0 0
>
> May  8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent 
> tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from None to 
> RecordingOnly
>
> May  8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent 
> tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
>
> May  8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent 
> v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): 
> SetInputAndFormat(2, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
>
> May  8 07:29:49 mythtv-server mythbackend[1930]: N Scheduler 
> autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required 
> Free Space: 2.0 GB w/freq: 15 min
>
> May  8 07:29:49 mythtv-server mythbackend[1930]: I Scheduler 
> scheduler.cpp:2459 (HandleRecordingStatusChange) Tuning recording: 
> "College Football Live": channel 1216 on cardid 1, sourceid 1
>
> May  8 07:29:50 mythtv-server mythbackend[1930]: I Scheduler 
> scheduler.cpp:2459 (HandleRecordingStatusChange) Started recording: 
> "College Football Live": channel 1216 on cardid 1, sourceid 1
>
> May  8 07:29:50 mythtv-server mythbackend[1930]: I TVRecEvent 
> tv_rec.cpp:3953 (TuningNewRecorder) TVRec(1): rec->GetPathname(): 
> '/mnt/store/d4/video/1216_20120508073000.mpg'
>
> May  8 07:29:53 mythtv-server mythbackend[1930]: E DeviceReadBuffer 
> DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
>
> May  8 07:29:53 mythtv-server mythbackend[1930]: E RecThread 
> mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
>
> I will dig into this a bit more when I get home from work tonight.

Did you guys do a "Delete all capture cards" (not "Delete all capture 
cards on <hostname>"), then re-create cards and re-connect inputs?  (Any 
time you change cards or drivers, you should probably do that--and 
should definitely do that if you have failures after the upgrade.)  It 
won't affect Video Sources or channels, so, it's a quick 30-second 
process that allows MythTV to configure your cards for the current drivers.

Mike