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

Mon May 28 19:18:11 UTC 2012

---- "Michael T. Dean" <mtdean at thirdcontact.com> wrote: 
> On 05/28/2012 03:05 AM, Kenan Ezal wrote:
> > Unfortunately I have been unable to get my PVRs 150/250/350 to operate
> > consistently since upgrading to Myth 0.25 (Fedora 16). I have tried:
> >
> > 1. Deleting all tuners and then re-adding them back in (along with the
> > inputs).
> > 2. Completely uninstalling 0.25 after removing the tuners, and then
> > re-installing 0.25 and adding back the tuners.
> > 3. One-by-one removing one of the tuners from my master backend and
> > trying to get it to work with the other tuner alone.
> > 4. Uninstalling and re-installing the ivtv-firmware.
> > 5. Repairing mythconverg (just in case)
> > 6. Different combinations of the above.
> >
> > In all cases the PVRs record X number of shows successfully before
> > failing on X+1. X appears to be larger if I have a single tuner in the
> > master backend. X~1 when I have two tuners (PVR 150&  250) in the master
> > backend.
> >
> > However even when the recording is successful I get the following errors
> > in the log:
> >
> > 2012-05-26 14:00:16.119246 E [2716/2758] DeviceReadBuffer
> > DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
> > 2012-05-26 14:00:16.119379 E [2716/2756] RecThread mpegrecorder.cpp:1010
> > (run) - MPEGRec(/dev/video0): Device error detected
> > 2012-05-26 14:00:18.586740 E [2716/2864] DeviceReadBuffer
> > DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
> ...
> > When it finally does fail:
> >
> > 2012-05-27 17:59:47.849584 I [2716/2724] TVRecEvent tv_rec.cpp:1014
> > (HandleStateChange) - TVRec(1): Changing from None to RecordingOnly
> > 2012-05-27 17:59:47.849651 I [2716/2724] TVRecEvent mythdbcon.cpp:395
> > (PurgeIdleConnections) - New DB connection, total: 12
> > 2012-05-27 17:59:47.850950 I [2716/2724] TVRecEvent tv_rec.cpp:3456
> > (TuningCheckForHWChange) - TVRec(1): HW Tuner: 1->1
> > 2012-05-27 17:59:47.870471 I [2716/2724] TVRecEvent v4lchannel.cpp:661
> > (SetInputAndFormat) - V4LChannel(/dev/video0): SetInputAndFormat(1,
> > NTSC) (v4l v2) input_switch: 0 mode_switch: 0
> > 2012-05-27 17:59:48.033973 N [2716/2725] Scheduler autoexpire.cpp:263
> > (CalcParams) - AutoExpire: CalcParams(): Max required Free Space: 2.0 GB
> > w/freq: 15 min
> > 2012-05-27 17:59:48.043975 I [2716/2724] TVRecEvent tv_rec.cpp:3950
> > (TuningNewRecorder) - TVRec(1): rec->GetPathname():
> > '/data/recordings/1003_20120527180000.mpg'
> > 2012-05-27 17:59:48.070399 I [2716/2725] Scheduler scheduler.cpp:2460
> > (HandleRecordingStatusChange) - Started recording: "KEY News at 6":
> > channel 1003 on cardid 1, sourceid 1
> > 2012-05-27 17:59:50.991443 E [2716/7354] DeviceReadBuffer
> > DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2
> > 2012-05-27 17:59:50.991528 E [2716/7353] RecThread mpegrecorder.cpp:1010
> > (run) - MPEGRec(/dev/video0): Device error detected
> > 2012-05-27 17:59:55.941410 E [2716/7355] DeviceReadBuffer
> > DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2
> 
> This indicates that the capture device isn't responding to MythTV's 
> requests for data.  Therefore, MythTV attempts to stop the card, then 
> restart it (which, also, seems to fail).
> 
> > Occasionally, the show records, but in triplicate: I see three vertical
> > stripes of the same scene on one screen shot.
> 
> I've seen this type of failure in the STB, not the PVR-x50.  I actually 
> had to reboot my DISH network STB at least once/month to prevent 
> similar, "it's outputting garbage," issues.
> 
> > I don't think this is a hardware problem because I can make all three of
> > my PVRs fail eventually (and on two different machines: a master backend
> > and a slave backend). I'm worried it has some connection with the
> > database because of the database errors that I see.
> 
> The only part of the database that has information that could cause a 
> recording failure is the part that you completely cleared and 
> reconfigured with "Delete all capture cards" (not "Delete all capture 
> cards on <hostname>").  So, assuming you actually configured things 
> correctly, it's not a problem.
> 
> The database errors you're getting are due to the fact that your capture 
> card is failing to work properly--MythTV hasn't had a lot of testing for 
> (let alone wasn't designed for) use with broken/failing capture devices.
> 
> >   Also, there may be
> > some link with how long the tuner has been unused. There is a higher
> > likelihood of a successful follow-on recording (even with error
> > messages) if the tuner was used recently. The longer the pause
> > (overnight), then the higher likelihood that the next recording will
> > fail
> >
> > Any help or suggestions would be very much appreciated.
> 
> FWIW, it sounds to me like an issue well below MythTV--such as with the 
> capture card hardware/drivers/configuration and/or OS-/kernel-level issues.
> 
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users

Hi Mike,

You could be right. But my problems started immediately after upgrading to 0.25 (from 0.24). I am planning on down-grading to 0.24 this week to see if everything works again. If not, then you will be right. If it does work, then its 0.25. (Luckily I saved my database from before the 0.25 upgrade!!).

BTW, I'm not the only one with this problem:

http://code.mythtv.org/trac/ticket/10732#

I was about to report a bug myself when I found the ticket. I'm now collecting some debug information that I will also post to the ticket.

I also wonder if this is related to the LiveTV problem with PVRs... apparently there is a fix for it now so I will try it out when its available. 

If it is a "capture card hardware/drivers/configuration and/or OS-/kernel-level issue" then it affects PVR-150 & -250 & -350, and both 32-bit and 64-bit versions of Fedora 16. My slave backend is my original mythtv box and is a 32-bit system. Whatever it is, it makes MythTV unreliable for my setup, which is admittedly relatively old (all analog), but I refuse to pay more monthly fees for the digital one. I know its inevitible, but I can delay as long as possible ;-)

-Kenan