On Thu, 11 Dec 2008, Daniel Pope wrote: > Thanks for your quick reply. > > No further message about the cx2341x firmware.
OK. > > I tried recording the stream to an mpeg file but, as you predicted, I > ended up with an empty file. Yup. No surprise there. > > I confess I didn't try the sysfs thing - I've managed to avoid getting > to involved with the driver up to now - but did try the connection with > xawTV. Oddly, when starting xawTV I saw a light appear on the box that > I'd not seen before... However, I could get no signal on composite > despite plugging my DVD player into it. A quick dmesg | tail -n 50 > revealed no record of the box, so I powered down the Wintv unit and > started it up again. The message below then appeared on checking, but > xawTV wouldn't run - the terminal told me it couldn't get access to the > device at /dev/video0. There's a single red LED inside the device. Operation of the LED is handled by the host driver. In the case of the Windows driver, that LED is lit as soon as the device is initialized - and it stays lit. That seems kind of useless. In the case of the Linux pvrusb2 driver, I only turn on the LED when you're trying to stream video from it (think "busy" indicator). Power cycling the device causes it to logically disconnect from the host. From the view of Linux (or for that matter Windows) it looks the same as if you unplugged the USB cable and plugged it back in. For Linux, this causes the driver to tear down all of its internal state for the device you just disconnected. Then when you plug it back in, the pvrusb2 initializes a new instance to track the newly "discovered" hardware. (The driver handles multiple instances of the hardware just by instancing its internal state however many times it needs.) The tear-down is the interesting part of this picture - because it can't complete the tear-down unless all references to the driver's instance being torn-down have gone away. If an app has the device open, i.e. somebody has /dev/vidoe0 open, then that's a reference and the driver will actually suspend its tear-down until that reference goes away. Meanwhile if you plug the device back in, the driver will then create a NEW instance for that device - right alongside the old instance being torn down. The net effect is that now the driver is tracking two instances: the new instance and the one still being torn down. Since the old instance was still there, then the new one can't get /dev/video0 assigned to it; instead it will probably get /dev/video1. So your xawtv app - which is still hanging onto /dev/video0 - won't be able to operate the new device. This behavior is not unique to the pvrusb2 driver. It's a fact of life when dealing with hotpluggable hardware. Similar behavior happens when you unplug/replug a USB serial converter while somebody still has, say, /dev/ttyUSB0 still open. > > I've tried this a couple of times with no luck and, given my experiences > in both Windows and Linux, I get the distinct impression I'm flogging a > dead horse here. I appreciate your help - any last ideas before I get > back to my ebay seller..? Not getting anything with a DVD player plugged in (and the input selection changed appropriately) is not a good sign at all. I don't know what else to suggest - the fact that you couldn't get it going under Windows either kind of rules out just about everything software-wise. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
