Two instances of CDGrab.exe - Eject button

[bhoar]

Spoon,

I'm running the 13.1.0.2 (10/10/2008) version of the cdgrab.exe.

I'm running discs through robots on one machine with three drives using the batch ripper. I am taking the small number of discs (rejected from robo-ripping due to scratches or no meta data) to a different machine for hand fixing.

On this other machine, I have two drives and I am not using the batch ripper. Instead, I have two instances of the cdgrab.exe program open.

I just ran across the bug (which was supposed to be fixed) where pressing the Eject button in one window (configured for my PX-716a drive) caused the currently-ripping disc in the other window (configured for my PX-W5224A drive) to eject instead of the disc in the PX-716a drive. The window I pressed eject in had a disc loaded, but had failed metadata lookup, so only track #s, lengths etc. were shown. When I hit eject, that window cleared but the wrong drive opened. When I alt-tabbed over to the other window, the ripping task was slowly generating track errors because the disc had been ejected out from underneath it.

-brendan

[bhoar]

Re: Two instances of CDGrab.exe - Eject button

Hmm, I wonder if it would be smart for multiple instances of the cd ripper to communicate through a shared temporary file, registry entry or memory store about which drive they are currently using. For example, if one cdgrab.exe process is currently ripping from a CD in "G:", when another instance of the cdgrab.exe process is run, it should know to avoid transacting with the "G:" drive.

For example, I'm ripping a damaged disc in drive "F:" and I/O is very slow on the last track in Pass 2. I just launched another cdgrab.exe and it has been spending at least a minute starting up because it seems to want to check out the disc in drive F: before putting up the interface.

So now the drive is being told by two masters to thrash back and forth, speeding up (for the new process's requests having to do with TOC, etc.) and slowing down (for the old process's requests, having to do with reading the end of the damaged last track).

Yes, I should have run both cdgrab.exe's first, and will remember to do so next time...but still, the current behavior is not optimal.

-brendan

[Spoon]

Re: Two instances of CDGrab.exe - Eject button

This should only happen if say your communication was ASPI not the native scsi, can you check?

[bhoar]

Re: Two instances of CDGrab.exe - Eject button

This should only happen if say your communication was ASPI not the native scsi, can you check?

Spoon - communication is/was set to SCSI Pass Through (SPT).

-brendan