[mythtv-users] HD PVR Device Error Detected

Sat Apr 7 11:55:21 UTC 2012

Replying to my own email as I finally found the solution, and I figured 
it was worth recording for posterity.  Maybe if someone else has this 
issue in the future they will stumble upon these emails.  Ultimately, 
the problem was that my firmware was too new.

The mythtv wiki page mentions this problem:

"*Note:* 29-Aug-2011: The latest version of the firmware, 1.6.29207, 
dated July 27, 2011, causes oversaturation and color issues with the 
encoding of the analog signal. Until this is resolved, you do not want 
to upgrade to this version. Version 1.5.7, from June 17, 2010 appears to 
work. Hauppauge has acknowledged the issue and provided a link to the 
earlier firmware for non-Windows systems on their support page: 
Hauppauge HD-PVR support 
<http://www.hauppauge.com/site/support/support_hdpvr.html>"

Note though that the link included actually points to the latest driver 
(1.7.1.30059) which includes an unsupported firmware.  This was 
confirmed by using:

dmesg | grep hdpvr

And noting there was a message indicating that the firmware was not 
supported.  Digging through Hauppauge's webiste, I finally came across 
this page:

http://www.hauppauge.com/site/support/support_faq_linux.html

Which includes a download for the older driver (1.1.5.7.0).  Installing 
this driver on a WIndows box with the HD PVR connected flashed the 
firmware back down to a supported version, and now it works great with 
Myth.  Hallelujah.

On 4/3/2012 8:35 AM, Paul Siegel wrote:
> There is definitely sound when playing back the .ts file created via 
> 'cat /dev/video0 > test.ts'.
>
> On 4/2/2012 10:30 PM, Richard Woelk wrote:
>> On 4/2/2012 3:14 PM, Paul Siegel wrote:
>>> Been bashing my head against this one for a couple days now, was 
>>> hoping someone on this list might be able to help.  Bought myself an 
>>> HD PVR, running on an Ubuntu 11.04 back-end, and custom-built the 
>>> drivers per this page: 
>>> http://www.mythtv.org/wiki/Hauppauge_HD-PVR#HD-PVR_Driver_Compilation_Howto
>>>
>>> Using 'cat /dev/video0 > test.ts' works great, the file plays fine 
>>> with vlc.  However, when I tried to set it up to work within myth, I 
>>> get errors.  I ran my back-end using '-v all' in hopes of finding 
>>> something more useful in the output, but I'm not seeing anything 
>>> obvious.  Here it is:
>>>
>>> 2012-04-01 22:50:18.948 DevRdB(/dev/video0): buffer size 9400 KB
>>> 2012-04-01 22:50:18.948 MPEGRec(/dev/video0): DRB ready
>>> 2012-04-01 22:50:18.948 MPEGRec(/dev/video0): 
>>> HandleSingleProgramPAT(NULL)
>>> 2012-04-01 22:50:18.948 MPEGRec(/dev/video0): Initial startup of 
>>> recorder
>>> 2012-04-01 22:50:18.948 MPEGRec(/dev/video0): Checking Resolution
>>> 2012-04-01 22:50:18.949 TVRec(1): 
>>> SetFlags(RecorderRunning,RingBufferReady,) -> 
>>> FrontendReady,RunMainLoop,CancelNextRecording,NeedToStartRecorder,RecorderRunning,RingBufferReady,
>>> 2012-04-01 22:50:18.949 TVRec(1): ClearFlags(NeedToStartRecorder,) 
>>> -> 
>>> FrontendReady,RunMainLoop,CancelNextRecording,RecorderRunning,RingBufferReady,
>>> 2012-04-01 22:50:18.949 MPEGRec(/dev/video0): Got Resolution 1920x1080
>>> 2012-04-01 22:50:18.949 MPEGRec(/dev/video0): StartEncoding
>>> 2012-04-01 22:50:18.950 MSqlQuery::exec(DBManager1) UPDATE cardinput 
>>> SET startchan = '4' WHERE cardinputid = '1'
>>> 2012-04-01 22:50:18.951 MSqlQuery::exec(DBManager2) UPDATE 
>>> capturecard SET defaultinput = 'Component' WHERE cardid = '1'
>>> 2012-04-01 22:50:18.964 MPEGRec(/dev/video0): Encoding started
>>> 2012-04-01 22:50:21.467 DevRdB(/dev/video0) Error: Poll giving up
>>> 2012-04-01 22:50:21.467 DevRdB(/dev/video0): fill_ringbuffer: error 
>>> state
>>> 2012-04-01 22:50:21.467 MPEGRec(/dev/video0) Error: Device error 
>>> detected
>>> 2012-04-01 22:50:21.467 MPEGRec(/dev/video0): RestartEncoding
>>> 2012-04-01 22:50:21.468 MPEGRec(/dev/video0): StopEncoding
>>> 2012-04-01 22:50:21.641 MPEGRec(/dev/video0): Encoding stopped
>>> 2012-04-01 22:50:21.641 MPEGRec(/dev/video0): Checking Resolution
>>> 2012-04-01 22:50:21.642 MPEGRec(/dev/video0): Got Resolution 1920x1080
>>> 2012-04-01 22:50:21.642 MPEGRec(/dev/video0): StartEncoding
>>> 2012-04-01 22:50:21.657 MPEGRec(/dev/video0): Encoding started
>>> 2012-04-01 22:50:24.167 DevRdB(/dev/video0) Error: Poll giving up
>>> 2012-04-01 22:50:24.168 DevRdB(/dev/video0): fill_ringbuffer: error 
>>> state
>>> 2012-04-01 22:50:24.172 MPEGRec(/dev/video0) Error: Device error 
>>> detected
>>> 2012-04-01 22:50:24.172 MPEGRec(/dev/video0): RestartEncoding
>>> 2012-04-01 22:50:24.172 MPEGRec(/dev/video0): StopEncoding
>>> 2012-04-01 22:50:24.351 MPEGRec(/dev/video0): Encoding stopped
>>>
>>> Looks like it tries a couple more times before completely giving 
>>> up.  Given that catting /dev/video0 works fine, I'm inclined to 
>>> think this problem is on the myth end, and not the driver, cables, 
>>> etc.  That said I've run the gamut of trying different usb ports, 
>>> cables, turning off legacy usb support in the bios, etc.  I'm always 
>>> stuck with this same problem.
>>>
>>> Any help would be appreciated.  Thanks.
>>>
>>> Paul
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users at mythtv.org
>>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>>
>>
>> Just a silly thought, When you play the file with VLC, do you have 
>> sound?
>> I had an issue with my optical cable that prevented the HDPVR from 
>> recording in mythtv, but recorded fine with cat /dev/video0
>> I thought the file played fine, but it had silent audio. (I don't 
>> have speakers on my backend)
>>
>> - Richard
>>
>>
>>
>>
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120407/d9ffd2ec/attachment.html>