I have a TV card (PCI) and a USB webcam. If I restart my Mageia, the TV card no longer works. I then have to go into TVtime.xml (I use TV time to view my TV) and then modify this line that I have included in the file: <option name="V4LDevice" value="/dev/video0"/> or <option name="V4LDevice" value="/dev/video1"/> Is there anyway to prevent the video call from changing at reboots? I just bought a webcam for my 78 year old mother with the same TV card and I wouldn't want her to go through the same procedure each time she re-boots her Mageia. Thanks for any help. Marc How reproducible: Happens on each system/computer reboot. Steps to Reproduce: You just need to have a TVCard and a Webcam to see that the mixup occurs on reboots. I first noted this in 2008 on the Mandriva forums. It would be nice if there were a permanent fix in Mageia for this. Thanks for any help. Marc
Hi, I had a similar problem... I solved it http://www.fotosik.pl/pokaz_obrazek/pelny/8c1582645d1a73ad.html It is now: $ cat /etc/modprobe.conf ... options cx8800 video_nr=1 $
CC: (none) => chmielu1_a
Thanks, this does solve the problem of changing the videoX line in the TVTime.xml file at every boot-up. However, this does not solve the original problem of Mageia not identifying the PCI and then USB cards in the right order at boot up. I take care of approximately 15 Mageia setups for friends (some older in age) and if they plug in a USB webcam, their TV cards will no longer work. I would have to mod. their TV card setup each time. Plus, I have another approximately 30 Mageia setups coming on board before the end of the year. I am switching them all from Mandriva 2010.2 to Mageia. There must be a way to fix this so that the detection of cards and USB devices is better implemented. Marc BTW -- Thanks for the MCC image capture that you included in your last post. This really helped.
Hi, thanks for reporting this bug. Thierry, I guess it's ldetect ?
Keywords: (none) => TriagedComponent: Release (media or process) => RPM PackagesSource RPM: (none) => ldetect
No.
CC: (none) => thierry.vignaud, tmbSource RPM: ldetect => (none)
CC: (none) => mageiaSummary: TV Card and Webcam switch /dev/video1 and /dev/video0 on reboots => TV Card and Webcam switch /dev/video1 and /dev/video0 on reboots if a webcam is plugedSource RPM: (none) => udev harddrake
cc'ing two more udev committers @ Colin You're aware that Thierry cc'ed you before?
CC: (none) => dmorganec, mageia, marja11
I'm not really sure what the offical fix for this should be, but kernel level module loading has just landed so perhaps this will offer some more sane defaults. I'll try and ask Kay if it's something that might help this problem. Col
OK, so the latest stuff in kernel land won't help. Hey how. But, having poked around a bit, this is exactly the same problem as hard disks with the /dev/sdX device nodes. Nowadays we prefer UUID to access disks as it avoids this problem. udev does a lot of work to create more static symlinks for devices e.g. for disks, the /dev/disks/by-* folders contain links by uuid, by label etc. With video devices, there are also some links... they might not be visible for all devices so this might not always work, but try this: Say you want to use what is currently /dev/video0... run the following command: udevadm info -n /dev/video0 -qall | grep DEVLINKS for me with some crappy camera plugged in I get: E: DEVLINKS=/dev/v4l/by-id/usb-STMicroelectronics_USB_Dual-mode_Camera-video-index0 /dev/v4l/by-path/pci-0000:00:1d.7-usb-0:7.5:1.0-video-index0 So in this case, the link: /dev/v4l/by-id/usb-STMicroelectronics_USB_Dual-mode_Camera-video-index0 Now I'm hoping the "index0" suffix here does not refer to it's actual index (as in video0) but I only have one device here to test with so I'll have to wait and see when I get home whether this name is truly static. Anyway, in theory at least, it should be more static than /dev/video0... maybe this helps?
@ Colin Since you're working on this bug, being brutal and assigning to you. :þ Please assign back to bugsquad if my brutality offends you.
Assignee: bugsquad => mageiaSource RPM: udev harddrake => udev
@ Marja Don't worry :). I suspect it'll be a WONTFIX anyway, but I'm curious to see if the links do actually solve the problem.
Status: NEW => ASSIGNED
OK, tested at home, and for me at least, the symlinks are static. The index0 suffix would appear to handle the case where two devices have the same usb-id. Tested with two completely different cameras and the symlink name remained static regardless of the order of insertion and thus regardless of whether it was video0 or video1. Sadly I also tried with two identical cameras and the symlink was overwritten for the second device... (i.e. an index1 suffix was not used...) Not sure if this is a bug or not, but will ask Kay or some v4l folks. Either way, if you have two different devices (as in this case) I'm pretty sure the symlinks in /dev/v4l/ are the way to go rather than directly using /dev/videoN. Therefore, closing this bug as wontfix until any other information might change that resolution.
Status: ASSIGNED => RESOLVEDResolution: (none) => WONTFIX