DVD Eject not working properly

[skd5aner@…]

I'm running current SVN (r14526) and over the past summer I've seen a regression in ejecting my DVD drive.

1) I used to be able to open and close the DVD drive manually via the physical button on the dvd drive. I lost that functionality a few months ago 2) I then used to be able to use the "eject media" option in myth with no problems.

Now, I can no longer manually use the eject button and the eject option within mythfrontend isn't working properly. What happens is when mythfrontend first starts up, the physical eject button no longer works. It works during boot and when mythfrontend is not running. In addition, when I use mythfrontend to eject the media, it'll work maybe 2 or 3 times. Then it no longer ejects the drive. I get the following:

"Unable to open orclose the empty drive LITE-ON DVDRW SHW-160P6S (/dev/scd0). You may have to use the eject button on the drive". However, like I've said, it's like myth locks the utilization of the physical eject button. If the frontend isn't running, it works just fine. When I use the "eject media" options, it'll turn on the LCD light on the drive, spin it up for about a second, and then the message comes up.

The only way I can ever get the tray to eject after this occurs is by rebooting.

Please let me know if there's any more information I can provide to help fix this.

[Nigel]

Hi Matt. Thanks for the clear description. Sorry you are having this problem. It has been a while since I made those eject changes, but if you are feeling brave, reverting to r13092 or r13174 (of libs/libmyth/mythcdrom-linux.cpp) may revert the behavior for you?
Against SVN, can I get you to 1) run the frontend with -v media, and provide the output when ejecting/injecting before/after the "lock" occurs, and 2) after the lock occurs, try the eject command from another xterm?

[maverik044]

As you have indicated /dev/scd0, you seem to be using a newer kernel. Newer kernels place all IDE/ATA devices under the SCSI/SATA driver model. Your harddrives will be /dev/sda even if they are ATA/IDE and not SATA/SCSI.

In this model the CDROMs are handled by the SCSI driver rather than the older IDE CDROM driver. The SCSI driver does not report the drive status properly if there is no media in the tray. Therefore myth will fail to determine if it should open or close the tray.

When myth checks the CDROM status using ioctl with CDROM_DRIVE_STATUS, a SCSI managed CDROM will always return CDS_TRAY_OPEN when there is no media in the CDROM, whether the tray is open or closed.

In your case, the CDROM is probably reporting CDS_TRAY_OPEN when the tray is closed with no media. Myth may fail to open it thinking it is already open.

If this is your problem, I suspect it is, the bug is in the kernel driver, not myth. I've tried to find a way to have myth recognize this special case but have been unable to figure a way. I plan to patch the kernel(​http://lkml.org/lkml/2004/12/27/1) as I've given up trying to figure it out in myth. As of 2.6.22 this problem still existed.

[Nigel]

Hi Maverik. I guess this is only going to afftect more users until the kernel is patched? We definitely need a MythTV workaround, then.
I am thinking a bool in MythCDROMLinux that is set if the status reporting problem is detected. Eject would use "eject -T" if it is set.

[skd5aner@…]

Nigel, I'll do my best to get you that info later today. I do not think it's soley an issue with what Maverik pointed out, although that might be contributing as well and should definitely be looked at. I need to do some more testing, but I think I might have some other ideas as to why it "sometimes" works then then stops. Just need to see if I can figure out how to replicate it.

Thanks! Matt

[maverik044 <level42@…>]

Attached is a patch that fixes eject with drives managed by the kernel SCSI driver. If the drive is managed by the SCSI driver (/dev/scdx) and returns status CDS_TRAY_OPEN, this patch uses ioctl to send a packet to the drive to query its status.

Packet format is per "Mt Fuji Commands for multimedia devices" SFF8090i, version 1.0 and therefore independent of the kernel. The only thing I can't test is BIG_ENDIAN machines, the structure format in the code is correct, I just don't know if the right includes files are there for WORDS_BIGENDIAN to be defined.

I mentioned previously that there is a kernel driver patch floating around for this. I would like to add that it has been since around 2.6.11 of the kernel, and never made it in the kernel, not even the recent 2.6.23 release. Therefore I assume it will never be for some reason. Thus requiring this patch as all IDE/ATA/SATA devices are managed by the SCSI driver in recent kernels (by default) unless specifically configured otherwise.

This should partially fix the above problem as the "Unable to open orclose the empty drive xxxx (/dev/scd0). You may have to use the eject button on the drive" message is the same I get for my Pioneer drive. This patch fixes that. I suspect that skd5aner also has a problem with the locking function of the drive from Myth.

[skd5aner@…]

Maverik and nigel - unfortuantly I haven't had much time to try and replicate these errors in order to provide the additional information needed to help with this ticket (and to possibly differentiate any root causes from what marverik might be seeing). I should be able to provide something this week. Sorry for the delay, it's been one of those months.

Thanks!

[Matthew Wire <devel@…>]

This patch fixes problems for me. Mediastatus and drive state is always detected correctly with this patch.
I've added an extra line to mythmediamonitor chooseandejectmedia() to prevent it displaying an error message when ejecting laptop cdrom drives. Previously it was successfully ejecting but then showing a message saying it had failed. (updated patch - cdromeject-311007.diff)

[Matthew Wire <devel@…>]

Updated patch to fix displaying failed when ejecting laptop drives

[danielk]

Nigel, I believe you are the current expert on the eject code...

[skd5aner@…]

I haven't been able to replicate this recently. Not sure if it got fixed, or what, as it was sort of tempermental to begin with.

[Nigel]

"Current expert?" Oh dear - the burden of responsibility!
Yes, I ran out of time trying to reproduce it. Maverik/Matthew? W.'s patch looks good, but unless we absolutely have to, I would prefer not to implement part of the old Linux kernel to work around problems in the new.
Maybe after the new year ... ?

[Bill <level42@…>]

Easy to reproduce if you have your cdrom/dvd as /dev/scd0. Please note that the patch is written using the ioctl function and also according to the "Mt Fuji Commands for multimedia devices SFF8090i, version 1" and therefore not kernel specific. Its specific to the packet format of the DVD/CDROM drive itself which is a standard. Given that this problem has been around since 2.6.12 or so, I guess we'll never see a fix for it. Even if it is fixed, this patch should still work.

I couldn't test BIG ENDIAN (ie. powerpc) cause I don't have the hardware. The patch will work, just not sure the WORDS_BIGENDIAN constant is pulled in from the include files correctly.

[anonymous]

I would prefer to have a test rig that demonstrates the problem before applying, but haven't yet worked how to force my test machines (most are 2.6.18) to use the SCSI emulation layer to test this. If anyone has any ideas?

[Bill <level42@…>]

Do you have an external USB CDROM drive? I think (but not sure) this will be under the SCSI driver. Also I don't recall when the kernel moved over to SCSI driver for the majority of the IDE devices, but I think it was around 2.6.18 so it nay not be possible with your test rig.

If it would help I can provide additional debug information.

[Nigel]

(In [15380]) For SCSI-managed drives, use a "Mt Fuji command" to query the real tray status. Excellent patch by maverik044 (Bill) and Matthew Wire. See #4025.

[Nigel]

Bill, good thinking with the USB suggestion. There was a minor error in the memset of buffer, and I reorganised things a fair bit, but the underlying logic was sound. Thanks for the hard work you put into this. I am testing a PowerPC build now, but don't expect a problem.
Matthew, I want to test your addition further before I apply it. Logically it doesn't make sense to me, because eject() will already have called driveStatus(), so I don't see the point in doing checkMedia() (which will call driveStatus() a few more times).

[Nigel]

I haven't been able to test Matthew's change, but I'm pretty sure it was just hiding a kernel problem (the driver is returning an error from the CDROMEJECT ioctl). There is the potential to add more checking in MythCDROMLinux::eject(), but for now I will just close this.