MythTV should use the static device names in /dev/v4l/by-path/* to stop video devices changing on boot

Bug #310820 reported by Aaron Whitehouse
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mythbuntu
Expired
Medium
Unassigned

Bug Description

I am using Mythbuntu 8.04 fully updated.

I have two tuner cards, a Hauppauge PVR-150 (MPEG2 hardware encoder) and a bttv WinFast 2000XP (V4L software encoder).

Every few reboots, the two cards will switch device nodes. Earlier today, the Hauppauge was /dev/video0 and the bttv was /dev/video1. Now, they have switched so that the Hauppauge is /dev/video1 and the bttv is /dev/video0. I will attach an lshal from before and after.

Every time that this happens, it causes me real issues. The cards do not work until I switch the setup as the MPEG2 card will be setup as a V4L card and vice-versa, with the wrong input selected (one uses "Tuner 1" and the other uses "Television"). Even worse, when I switch the device nodes in the setup, it often seems to break my scheduled recordings in unexpected ways. I have set it up as if I were moving everything to new hardware a few times, but it takes an age.

If I can be of any further help, please let me know.

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

This sounds like a really common issue out there. Normally, I just reboot the thing until it goes back to how it was. Couldn't something be clever about this and be persistent until both cards weren't there (similar to DHCP, which tries to give everyone the same IP address but copes if things have changed)?

Alternatively, could Mythbuntu create udev rules in the setup so that these don't change?

As a workaround, can somebody please step me through creating a udev rule to stop this happening? I found:
http://ubuntuforums.org/showpost.php?p=6440182&postcount=7
which talks about creating a udev rule (in that case to stop a remote from jumping around device nodes) by changing /etc/udev/rules.d/60-symlinks.rules; added the following line:

# Create /dev/input/irremote symlink for Nova-T 500
KERNEL=="event*", ATTRS{name}=="IR-receiver inside an USB DVB receiver", SYMLINK+="input/irremote"

Could I do a similar thing and have symlinks created to /dev/video_bttv and /dev/video_pvr150 and then set MythTV up to use those instead of video0 and video1? If so, where do I get the "name" field for that line?

Thanks!

Revision history for this message
Nick Fox (nickj-fox) wrote : Re: [Bug 310820] Re: Tuner cards change /dev/video device node on reboot

Aaron,

Do some googling on details, but what you need to accomplish this is to
create a udev rule to assign each card to a specific node. This will prevent
the issue from happening in the future.

-Nick

On Sat, Feb 28, 2009 at 2:44 PM, Aaron Whitehouse
<email address hidden>wrote:

> This sounds like a really common issue out there. Normally, I just
> reboot the thing until it goes back to how it was. Couldn't something
> be clever about this and be persistent until both cards weren't there
> (similar to DHCP, which tries to give everyone the same IP address but
> copes if things have changed)?
>
> Alternatively, could Mythbuntu create udev rules in the setup so that
> these don't change?
>
> As a workaround, can somebody please step me through creating a udev rule
> to stop this happening? I found:
> http://ubuntuforums.org/showpost.php?p=6440182&postcount=7
> which talks about creating a udev rule (in that case to stop a remote from
> jumping around device nodes) by changing
> /etc/udev/rules.d/60-symlinks.rules; added the following line:
>
> # Create /dev/input/irremote symlink for Nova-T 500
> KERNEL=="event*", ATTRS{name}=="IR-receiver inside an USB DVB receiver",
> SYMLINK+="input/irremote"
>
> Could I do a similar thing and have symlinks created to /dev/video_bttv
> and /dev/video_pvr150 and then set MythTV up to use those instead of
> video0 and video1? If so, where do I get the "name" field for that
> line?
>
> Thanks!
>
> --
> Tuner cards change /dev/video device node on reboot
> https://bugs.launchpad.net/bugs/310820
> You received this bug notification because you are a member of Mythbuntu
> Developers, which is subscribed to Mythbuntu.
>

Revision history for this message
frytek (newsgrabber) wrote : Re: Tuner cards change /dev/video device node on reboot

this is how i do it, because i have a tv card and two (cheap :) webcams.
i use udev rules to create symlinks.

connect all devices. they will create /dev/video0 and /dev/video1 /dev/video2 (or something similar). write down which is which.

now, for each device type:

1.
udevinfo -a -p $(udevinfo -q path -n /dev/video0)
2.
udevinfo -a -p $(udevinfo -q path -n /dev/video1)
3.
udevinfo -a -p $(udevinfo -q path -n /dev/video2)

you will get a very loooong list of attributes. you must find something that differs your devices and is also easy to identify. it might be the vendor, model or numeric ID.

in my case i select (to give you some idea):

1.
ATTR{model}=="Labtec Webcam Elch2 "

2.
ATTR{card}=="36"
(there were probably some better options, but i found my particular card with this number on google, so it seems to be quite unique ;)

3.
ATTR{model}=="Qtec Webcam 100"

once you define these, you go to the /etc/udev/rules.d

you create 3 files, respectively:
11-labtec-webcam.rules
11-qtec-webcam.rules
11-tv-card.rules

an easy method is to copy one of existing files to a new name. inside you paste (or modify) one line (you may get it from other files from this directory) which will be as follows, respectively:

1.
ATTR{model}=="Labtec Webcam Elch2 ", SYMLINK+=labtec-cam

2.
ATTR{card}=="36", SYMLINK+=tv-card

3.
ATTR{model}=="Qtec Webcam 100", SYMLINK+=qtec-cam

after rebooting your system, you will find 3 symlinks in your /dev/ directory. they will be pointing to right devices, no matter if they are temporarily named video0, 1 or 2. in my case these are

/dev/labtec-cam, /dev/qtec-cam and /dev/tv-card

then you reconfigure your programs (tvtime, motion, xawtv - whatever you use) to use /dev/symlink instead of /dev/videoN. this means for instance that i run tvtime with this command:

tvtime -d /dev/tv-card

enjoy.

Revision history for this message
Nick Latheron (nick-latherons) wrote :

I'm having the same problems with a TBS8920 and a Hauppauge HVR 4000 in MythTV. In addition I can't see the DVB-T tuner on the HVR as it says the card ID is already in use.

Temporarily pulling the TBS 8920 from the system to make it usable.

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

See Bug #370696. Sorry, I didn't realise I had already reported the issue.

Revision history for this message
MarcRandolph (mrand) wrote :

Thank you for helping to make Mythbuntu and Ubuntu better through this and the other ticket. I've closed the other one and renamed this one to have that title so that we do not have two tickets for the same issue.

Changed in mythbuntu:
importance: Undecided → Medium
status: New → Triaged
summary: - Tuner cards change /dev/video device node on reboot
+ MythTV should use the static device names in /dev/v4l/by-path/* to stop
+ video devices changing on boot
Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

I have attached the script from the other bug report with an updated copyright statement containing Jason's real name.

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :
Revision history for this message
frytek (newsgrabber) wrote : Re: [Bug 310820]

i do not have two tuners anymore, but here is the solution i was using back
then. 'by the way - it is my post from the bugtrack

this is how i do it, because i have a tv card and two (cheap :) webcams.
i use udev rules to create symlinks.

connect all devices. they will create /dev/video0 and /dev/video1
/dev/video2 (or something similar). write down which is which.

now, for each device type:

1.
udevinfo -a -p $(udevinfo -q path -n /dev/video0)
2.
udevinfo -a -p $(udevinfo -q path -n /dev/video1)
3.
udevinfo -a -p $(udevinfo -q path -n /dev/video2)

you will get a very loooong list of attributes. you must find something that
differs your devices and is also easy to identify. it might be the vendor,
model or numeric ID.

in my case i select (to give you some idea):

1.
ATTR{model}=="Labtec Webcam Elch2 "

2.
ATTR{card}=="36"
(there were probably some better options, but i found my particular card
with this number on google, so it seems to be quite unique ;)

3.
ATTR{model}=="Qtec Webcam 100"

once you define these, you go to the /etc/udev/rules.d

you create 3 files, respectively:
11-labtec-webcam.rules
11-qtec-webcam.rules
11-tv-card.rules

an easy method is to copy one of existing files to a new name. inside you
paste (or modify) one line (you may get it from other files from this
directory) which will be as follows, respectively:

1.
ATTR{model}=="Labtec Webcam Elch2 ", SYMLINK+=labtec-cam

2.
ATTR{card}=="36", SYMLINK+=tv-card

3.
ATTR{model}=="Qtec Webcam 100", SYMLINK+=qtec-cam

after rebooting your system, you will find 3 symlinks in your /dev/
directory. they will be pointing to right devices, no matter if they are
temporarily named video0, 1 or 2. in my case these are

/dev/labtec-cam, /dev/qtec-cam and /dev/tv-card

then you reconfigure your programs (tvtime, motion, xawtv - whatever you
use) to use /dev/symlink instead of /dev/videoN. this means for instance
that i run tvtime with this command:

tvtime -d /dev/tv-card

enjoy.

Revision history for this message
Thomas Mashos (tgm4883) wrote :

We really do appreciate you opening this ticket to help improve Mythbuntu, but it needs to be closed for a number of reasons. The biggest one is that upstream has moved on to a new version and believes this to be fixed. Could you please verify if this issue still exists in the latest version?

Please do not let the closing of this ticket dissuade you from opening a new ticket if this (or any other) problem occurs with the newer versions.

Changed in mythbuntu:
status: Triaged → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.