On Sat, Nov 13, 2010 at 3:06 PM, Andy Walls <[email protected]> wrote: > On Sat, 2010-11-13 at 16:59 +0200, Artem Astafyev wrote: >> Hi All, > > Hi. > >> I'm testing a new card GoTView PCI DVD3 with patch Alexey Chernov >> provided recently. I have problem changing channel in MythTV but it >> seems that it's not because of this patch. The problem is that cx18 >> driver rejects standard changing if there are some active analog >> streams. > > That is valid behavior per the V4L2 API: > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-std.html > > the driver is allowed to return an errno of EBUSY when it is busy. > > That check exists, because it is not possible to change the capture and > MPEG encoding engine between a 525 line standard (NTSC), 625 line > stanadrd (PAL, SECAM), or audio only (FM radio) capture in mid-stream.
Wow, so the only way to change channels is to close and reopen all descriptors pointing to the device? Ouch. I don't doubt that's how the cx18 works, but it's kind of a bitch for application developers, especially since we have other drivers which will put the tuner to sleep on v4l close (requiring a firmware reload when it gets woken up). I guess it's less surprising to me now that the MythTV codebase is littered with checks based on the driver and version it is interacting with. There's got to be a less dumb way to deal with this issue. I can understand the goal behind not allowing the user to change the standard in the middle of streaming (returning EBUSY), but there really should be some way to accomplish this without having to have the application close all the filehandles (and in some cases this isn't even practical - think of users who run something like mplayer to view the video and ZVBI to get captions). I guess this is less of an issue for those devices that let you explicitly stop streaming, although I realize that interface is typically associated with the "streaming" interface as opposed to the read() interface. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
