Hi, Stuart Longland wrote: > Silly question, but why does re-loading a disc take more than 197 seconds?
It comes out (intentionally) after a backup run is complete and went well. (See man xorriso example "Incremental backup of a few directory trees".) Then i'd expect it to stay out until i remove the medium. It may well be that i am not at the machine when the backup finishes. > To me, a tray automatically retracting itself after being open for more > than a minute sounds a perfectly reasonable damage-prevention measure. One may discuss whether this is a helpful feature. (My machine is located where a protruded tray is not in danger to be hit by humans.) But for me it is a fundamental goal to be in control of my optical drives. That's why i have a Linux desktop and not an iPhone. Debian's kernel says it does not send commands, LG Germany says the drive does not pull in on its own. > To me, a tray automatically retracting itself after being open for more > than a minute sounds a perfectly reasonable damage-prevention measure. To be a user-grade feature it would have to work in an equal way for all attached drives. But at my machine it happens only with one out of five. > it discourages the tray's misuse by the illiterate (e.g. as a > carry handle or cup holder). I consider myself the last remaining programmer for optical drives in the GNU/Linux world. Andy Polyakov does not work on dvd+rw-tools any more and Joerg Schilling of cdrtools fell into disgrace nearly 10 years ago. cdrkit (fork-founded by Debian) even lost its website meanwhile. So if not i can control a burner - who else would ? My initial reason to post the question here was the theory that one of the new desktop's automats was to blame. They changed with each computer i got in the last 15 years. So i hoped for a quick solution by editing some udev rule file or a similar remedy. Now the riddle goes much deeper. > I can think of two possibilities: > 1. This is a built-in feature of the drive for the above reasons LG support denies. My own experience agrees to this denial. > 2. Some software on the host periodically 'polls' the drive for disc > insertion status Yes, the kernel usually does issue command 0x4A GET EVENT STATUS every 2 seconds. But it is a harmless command which cannot move the drive. Further, about a hundred of these commands are executed before the tray gets pulled in. Nevertheless i disabled this kernel feature by echo 0 >/sys/block/sr1/events_poll_msecs and now btrace(8) does not show any SCSI traffic when the tray goes in. Even more strange, i had two incidents of unexpected eject meanwhile. Both happened when the drive device file got operated by programs. Once by btrace(8), once by a run of xorriso -devices At least in the latter case i am sure that no 0x1B START/STOP UNIT command was issued by libburn with Load/Eject bit set. My best theory currently is that the drive had an eject request from another originator while 0x1E PREVENT/ALLOW MEDIA REMOVAL was active with Prevent bit set. When libburn closes the connection to the drive, it issues a 0x1E with Prevent bit cleared. This would allow the drive to perform the pending eject. > Maybe try boot up GRUB, break into the command prompt, Still my uptime is more important than the solution of this riddle. But when maintainance time comes, i will try with other OSes, and also with pure EFI waiting for user interaction. As last resort i will have to put the drive into a different computer or into a USB box. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/15600560287579445...@scdbackup.webframe.org
