Eject annoyance new in 14.4

[matt_t]

Click the "Eject" button and the CD tray opens. Insert CD, close the tray, and the program just keeps ejecting the tray until the screen refreshes and the Eject button appears unpressed again.

Don't know if anyone else has noticed this. For me it is new in 14.4 - 14.2 didn't do this (I skipped 14.3 due to a couple of the tagging bugs which have now been fixed).

[Spoon]

Re: Eject annoyance new in 14.4

This suggests the CD drive is not able to inform when it has the tray open, this is quite a basic command (tray open, disc loaded...)
R14.3 changed the size of the information structure to the exact one required (previously it was much bigger, but this caused a BSOD with any intel driver loaded...)

[matt_t]

Re: Eject annoyance new in 14.4

Sorry, I don't follow this. You mean that my CD drive is so stupid (and poorly designed) that it doesn't know when it's open or not, but dBp versions up to and including 14.2 hid this fault and made it look like it works properly?

[Spoon]

Re: Eject annoyance new in 14.4

Technically dBpoweramp has never had a fault, but our method of doing something exposed a bug in Intel drivers, by changing our method, your drive now no longer works as it should. It is my view that the intel drivers and your CD drive have a bug.

[bhoar]

Re: Eject annoyance new in 14.4

Technically dBpoweramp has never had a fault, but our method of doing something exposed a bug in Intel drivers, by changing our method, your drive now no longer works as it should. It is my view that the intel drivers and your CD drive have a bug.

The Intel Storage Matrix drivers? Assuming you're talking about those, yeesh. What a pile of badness. The proper thing to do to work around the bugs in them is UNINSTALL them. They have caused me nightmares every year or so when I forget how unstable they are.

Spoon: what ATAPI command are you using for the tray monitoring? Mechanism Status (BDh)? There are some drives out there, including some older Plextors I tested, that don't implement this one correctly. I had to add the --olderdrives directive to the ULCLI to tell it to not query the drive about the tray status and just use a reasonably conservative hardcoded delay for the disc to spin down and the tray to open. Not as efficient but the priority was avoiding situations where the robot and the drive tray slam into each other.

If that's the command you're using, you may want to consider making it optional for proper operation, esp. since your user base tends to want to use drives that handle CD audio extraction well, which many newer drives are not optimized for.

Brendan

[Spoon]

Re: Eject annoyance new in 14.4

4A GetMediaStatus is used

[bhoar]

Re: Eject annoyance new in 14.4

4A GetMediaStatus is used

4A or DA?

Edit: Oh, I see, perhaps you're using 4A "GET EVENT STATUS NOTIFICATION"?

Brendan

[matt_t]

Re: Eject annoyance new in 14.4

Technically dBpoweramp has never had a fault, but our method of doing something exposed a bug in Intel drivers, by changing our method, your drive now no longer works as it should. It is my view that the intel drivers and your CD drive have a bug.

I don't believe this at all. No other program that I have currently or previously installed has ever done this. Just for the sake of it I have just tested this with CyberLink Power2Go and Burnaware, and they are fine, as I knew they would be.

This eject problem looks like a different angle on a similar issue which has been around ever since I started using dBp around late release 12, during which time I have used 3 different computers. This is most apparent when removing a CD/exiting the program after ripping: when closing the (empty) tray, if you then try to exit the program before it is "ready" you get "program not responding". You don't notice this so much if you've just inserted a CD to rip because you expect the program to be busy reading the disc, getting metadata and so on. Anyway, it's during this period that the repeated ejecting has started happening. It's as if an invisible finger is holding down the eject button.

Hopefully I have explained this clearly....

FYI, my CD drive is a CDDVDW TS-L633R in a HP laptop. I see there is a TS-L633A in the drive accuracy list. Are these drives known for being buggy??

I'm not a programmer, so I freely admit I don't understand about the Intel drivers or what most of bhoar says below. dBp is a great program and I recommend it to others, but this sounds an awful lot like a developer blaming a problem on anything/everything else before admitting that there might be a bug in his own software. In this case it looks like working round one bug has created another.

I've spent some time and effort attempting to explain all this as clearly as possible. Hopefully it can be fixed, or it's permanently back to 14.2 for me.

[Spoon]

Re: Eject annoyance new in 14.4

Here is our code in question...previously with a buffer size set to anything > 8 would BSOD Windows (intel driver), as you can see the code is really simple, I am sure someone with time on their hands can validate the parameters.

//--------------------------------------------------------------------------------------------------------------
bool cddaSCSIPassTru::GetMediaStatus(wchar_t *NiceDrive, int &RetMediaEvent, bool &RetMediaPresent, bool &RetDoorOpen)
{
STSCSI_PT_CDDrive *pCDDrive = FindDrive (NiceDrive);
if (!pCDDrive)
return(false);

if (!OpenCDDrive (pCDDrive))
return(false);

XMem Buffer(8, true);
if (Buffer())
{
SRB_ExecSCSICmd cmd;
ZeroMemory(&cmd, sizeof(SRB_ExecSCSICmd));
cmd.SRB_Cmd = SC_EXEC_SCSI_CMD;
cmd.SRB_Flags = SRB_DIR_IN;
cmd.SRB_BufLen = Buffer.Size();
cmd.SRB_BufPointer = (BYTE *)Buffer();
cmd.SRB_SenseLen = SENSE_LEN;
cmd.SRB_CDBLen = 10;
cmd.CDBByte[0] = 0x4a;
cmd.CDBByte[1] = 1; // immediate return
cmd.CDBByte[4] = 16; // request media class
cmd.CDBByte[8] = (BYTE)Buffer.Size(); // buffer size LSB

if (ExecuteSCSICommand( pCDDrive, &cmd ))
{
char *pBuffer = (char *)Buffer();
if ((pBuffer[2] & 7) == 4) // is valid?
{
pBuffer+=4; // over the header
RetMediaEvent = pBuffer[0] & 15;
RetDoorOpen = (pBuffer[1] & 1) ? true : false;
RetMediaPresent = (pBuffer[1] & 2) ? true : false;
return(true);
}
}
}
return(false);
}

[thexfile]

Re: Eject annoyance new in 14.4

I had a issue with my CD tray.. http://forum.dbpoweramp.com/showthre...l=1*post127565

What worked for me was reinstalling Microsoft Visual C++ 2005, 2008 & 2010 with all the security updates/fixes.

[Olivechicago]

Re: Eject annoyance new in 14.4

I have the same issue. Ripper is set to eject after rip, which it does. However, the try will not always immediately retract when asked to, and when it does not, Ripper is still in its <ejecting CD...> state. It's far from consistent or repeatable. One CD that ejects and the tray is observed in an idle state one session will leave the tray in a busy state for a few to 10 or 15 seconds after another session.

Drive is an Asus DRW-2014L1T

[thexfile]

Re: Eject annoyance new in 14.4

This is an easier way to get around the tray issue.

Visual C++ Installer/Uninstaller

http://www.majorgeeks.com/files/details/visual_c_aio_installeruninstaller.html

It 100% free and clean.