[pvrusb2] recent problem: getting frontend status failed

[Roger]

>So, to summarize: it appears that running myth causes the driver or the OnAir
>Creator to go into a not-quite working state after a while.  Then, the
>/dev/video0 device is not accessible until a re-init (unplug/replug).  When
>in this state, if myth does some (sequence of?) operations, the I/O error
>previously reported happens.  This is also solved by an unplug/replug.
>
>Does anyone have other tests I could perform?  Any ideas as to what is
>happening?
>
>Thanks.
>
>Augustine

I think MythTV runs a background process called mythbackend as root, started 
via sysv, openrc, etc...

Since this process is being run as root, mythbackend has priority over the 
device and usually tends to hold the /dev files within an open state.  (ie.  
/dev/dvb devices are usually also held open or polled for obtaining EIT 
information.  There's an option to toggle this option on and off.  
http://www.mythtv.org/wiki/EIT)

If I'm not mistaken, it's usually best to assumed once mythbackend has started, 
any device files given within the configuration will be held open.  (With the 
exception of disabling the EIT for /dev/dvb devices?)

I used MythTV briefly five to ten years ago, but got tired of the constant 
problems with bugs, bloat and breaking upgrades.  As such, I'm a minimalistic 
person these days, using less code usually means better stability.  It's a 
balancing act, which usually means creating Bash scripts for wrapping around 
simple tools such as 'cat' or 'dd', etc.  I've never needed all the features of 
such a larger utility such as MythTV, and prefer to just to record the raw 
streams avoiding remixing.

Using two programs at once on one device does tend to cause access problems.  
Handling sound or audio is a very good example, as only one sound can be played 
at one time with any audio device.  Playing more than one sound file at once is 
accomplished by the operating system having a software layer remixing the audio 
streams so that all audio files passing through this layer can be heard playing 
all at once using one audio device.  (ie.  ALSA DMix, PulseAudio, and Windows 
KMixer/WASAPI)  One of the pros for having direct access to the /dev device, 
there's usually a significant redundancy for delays and the stream can be 
captured within it's original detail without any loss.  (ie.  Audio Stream 
Input/Output Wikipedia)

I've never heard of a software layer for holding open or mixing more than one 
video device or video stream at one time, although Mike may have as he's been 
coding the video driver.

Hope this helps.

-- 
Roger
http://rogerx.freeshell.org/