Tried the scd0 fix on my main machine, a dual core AMD 64 with SATA2
drive and SATA dvd/cd writer with same good results, Kaffeine, xine and
kscd all fixed.
So hopefully one update perhaps this will be cleverly automated, but I
fear pigs may fly first.
This was by bringing the same drive across from the AMD 2400+ single
core it was on before with IDE drives it was installed on----pretty neat.
Kubuntu is the only linux distro I have found that can do this so far
If there are 2 dvd drive, you could doubtless find out what they are
called in storage media properties and maybe fix them too.
> Tried the scd0 fix on my main machine, a dual core AMD 64 with SATA2
> drive and SATA dvd/cd writer with same good results, Kaffeine, xine and
> kscd all fixed.
> So hopefully one update perhaps this will be cleverly automated, but I
> fear pigs may fly first.
I redirected the bug report to udev, but I rather doubt clever automation
will fix this to everybody's enjoyment. The problem is that the software
can't tell whether the PCI path has changed because the kernel has changed,
or because the hardware has changed. If the hardware has changed, perhaps
you're planning to put the old hardware back. Now, it seems to me that
deleting the rules file on _every_ boot would do the job well enough, but I
suspect there are users out there who'd be screaming for my blood if I were
the developer who made that change :-)
Perhaps it's time for udev to have two rules directories - one in /etc and
one in /tmp, for rules it generates itself on boot.