Ok, i restested everything as it was 2am last night when i did and made some oversights...<br><br>RIP, cant get cdrecord to work, it will not accept my dev=/dev/sr0 or dev=scsi:1,0,0 but i did get dmesg errors when inserting disk<br>
<br>so i booted into Mint Linux on USB stick (my main distro is Arch Linux) and got same results, then rebooted with ACPI changed to ATA. Disk access was very slow, took forever to open up apps BUT burning worked altough at low speeds 1x - 3x for DVD.<br>
Now I am confused.... Why did it work for a few burns under ARCH before failing again? If it is another process accessing the drive how do i figure out wich?<br>Thank you for your help<br>Sascha<br><br><div class="gmail_quote">
On Sat, Jan 30, 2010 at 5:13 AM, Thomas Schmitt <span dir="ltr"><<a href="mailto:scdbackup@gmx.net">scdbackup@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<div class="im"><br>
Age Jan Kuperus wrote:<br>
> I looked for processes that tried to access sr0 and<br>
> found several<br>
> children of udevd (they seem to be run in sequence):<br>
> /lib/udev/devkit-disks-part-id /dev/sr0<br>
> /sbin/blkid -o udev -p -u noraid /dev/sr0<br>
> /lib/udev/cdrom_id --export /dev/sr0<br>
<br>
</div>I don't know about devkit-disks-part-id and<br>
cdrom_id but libblkid is a known reader of block<br>
devices.<br>
Nevertheless, this should not constantly try to<br>
read from the drive. At most for a short while<br>
after a media was inserted.<br>
<br>
So if it can slow down a complete DVD run, then<br>
this is not the normal behavior.<br>
One should try to get advise from the distro<br>
community.<br>
<br>
(Ted T'so, Eduard Bloch and me once tried to get<br>
libblkid, wodim and libburn into better<br>
co-existence. This ended with the result that<br>
none of the available locking mechanisms was<br>
sufficient in all cases.)<br>
<div class="im"><br>
<br>
> Hope this helps (and somebdy can fix it).<br>
<br>
</div>The offending processes should at least restrict<br>
themselves to a short examination. In that case<br>
the user can load the tray manually, wait a while<br>
and only then start the burn run.<br>
<br>
The responsible programmers would be those who<br>
set up the udev stuff in the distro. Maybe they<br>
have to forward the problem upstream then.<br>
<br>
(Again, i would participate in a technical<br>
discussion.)<br>
<div class="im"><br>
<br>
Have a nice day :)<br>
<br>
Thomas<br>
<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">Debburn-devel mailing list<br>
<a href="mailto:Debburn-devel@lists.alioth.debian.org">Debburn-devel@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/mailman/listinfo/debburn-devel" target="_blank">http://lists.alioth.debian.org/mailman/listinfo/debburn-devel</a><br>
</div></div></blockquote></div><br>