====== DVD Drives ======

  * [[dvd_drive_status]]
  * [[dvd_eject]]
  * [[regionset]]
  * [[trayopen]]

==== Polling a Drive: Is Open / Has Media ====

Polling DVD drives to see if it is closed or not is a real pain to do in Linux. (**Edit:** it was!  Check out [[dvd_drive_status]] which solves everything here)

I highly recommend reading [[http://wonkabar.org/2013/07/03/reading-ejecting-ripping-and-polling-dvd-devices-in-linux-also-notes-on-my-dvd-library/| this blog post]] where I describe various ways I poll the drive to see if it is empty or not.

Also, check out [[trayopen]], which I added to this wiki after writing that blog post.

The reason is because there are race conditions.

Consider this scenario, with this sequenced timeline:

  - Open tray
  - Insert media into tray
  - Close tray
  - Access device

Ideally, this would work perfectly fine.  However, the problem happens after step #3, closing the tray.  The device becomes available **before** it is actually ready to read from.  This is particularly annoying with DVD drives because some firmware (most of them, that I've seen) for the devices will freak out if you are trying to access the data encrypted by CSS.

The best solution I've found to work around this mess?  Close the DVD tray and wait 30 seconds for the device to finish polling.  Seriously.  Just avoid the problem by applying some patience.

You can duplicate the scenario if you like, like this:

Insert a DVD into your tray, and tell Linux to close the tray:

<code>
eject -t /dev/dvd
</code>

''eject'' will finish and return an exit code of 0.  If you physically watch your computer though, you will see the LED flashing as the disk is being polled.

Now, immediately after eject has finished, run a command to read the DVD drive contents:

<code>
lsdvd /dev/dvd
</code>

Next, run ''dmesg'' to see if anything unexpected has happened.  For this, you'll need the actual device name, and not the symlink.  So, ''/dev/dvd'' is going to be a symlink (most likely) to ''/dev/sr0''.

<code>
[ 3788.293554] sr 0:0:0:0: [sr0]
[ 3788.293561] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 3788.293564] sr 0:0:0:0: [sr0]
[ 3788.293566] Sense Key : Illegal Request [current]
[ 3788.293569] sr 0:0:0:0: [sr0]
[ 3788.293576] Add. Sense: Read of scrambled sector without authentication
[ 3788.293579] sr 0:0:0:0: [sr0] CDB:
[ 3788.293580] Read(10): 28 00 00 00 04 00 00 00 02 00
[ 3788.293587] end_request: I/O error, dev sr0, sector 4096
[ 3788.293744] quiet_error: 18 callbacks suppressed
[ 3788.293746] Buffer I/O error on device sr0, logical block 512
[ 3788.325401] sr 0:0:0:0: [sr0]
[ 3788.325408] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 3788.325411] sr 0:0:0:0: [sr0]
[ 3788.325413] Sense Key : Illegal Request [current]
[ 3788.325417] sr 0:0:0:0: [sr0]
[ 3788.325425] Add. Sense: Read of scrambled sector without authentication
[ 3788.325427] sr 0:0:0:0: [sr0] CDB:
[ 3788.325429] Read(10): 28 00 00 00 04 00 00 00 02 00
[ 3788.325436] end_request: I/O error, dev sr0, sector 4096
[ 3788.325570] Buffer I/O error on device sr0, logical block 512
</code>

Normally this isn't a problem, because the device and software just move on with their merry little lives, and given some time, it can access the data just fine.

The place this is a problem is that sometimes this happening multiple times, it can lock up your DVD drive in the sense that it won't read anymore for that session.  You can sometimes hear the DVD drive physically clunking if it errors out.  In cases where it gives up like that, simply reboot your box, and go on with your life.

In *very* rare cases, it will lock up your box with a kernel panic and you'll be forced to reboot.  And by rare, I mean I've had it happen maybe three or four times when accessing the drive thousands of times over a number of years.  Worst cases scenarios are statistically unlikely, but it's worth mentioning in case it happens to you.