>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/ _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
