Batch Ripper Eject Timeout to short?

[MTWolf]

I using dbpoweramp R14 (licensed) Batch Ripper 1.4 with a primera composer (USB Drive interface) (Primera loader R3 Drivers) and everything works, but... When a rip gets the CD drive upto 24x or better the eject command that is sent to unload the CD times out before the drive fully ejects, sometimes.

So here is what I see:
Disc rips at 24x or better.
Rip Completes
Eject command to unload disc is sent (drive is still spinning the cd)
CD spins down
Drive tray starts to eject then retracts back into the drive
aprox 20 second Pause
Drive tray ejects
Loader runs
Every thing is normal from here on until the next disc that rips at high speed.

Sometimes the timing is perfect, but sometimes it isn't.

Any way to tweak the Unload CD Eject timeout? I'd say it needs about 3 to 4 more seconds.

Thanks

[Spoon]

Re: Batch Ripper Eject Timeout to short?

Eject command to unload disc is sent (drive is still spinning the cd)
CD spins down
Drive tray starts to eject then retracts back into the drive

How many seconds before the CD opens the first time?

[MTWolf]

Re: Batch Ripper Eject Timeout to short?

I changed the setting to SPT (SCSI Pass Thru) and that improved the problem, now it only seems to happen when the CD is Accurate Rip and it gets the speed above 24x.

Time from completion of last track to attempt to eject is about 7-8 seconds, the second eject follows 20 seconds later.

Thanks.

[Spoon]

Re: Batch Ripper Eject Timeout to short?

>I changed the setting to SPT (SCSI Pass Thru)

Try:

http://forum.dbpoweramp.com/showthread.php?t=13285

A full clear then reinstall, and try ripping on the default settings (use CD Ripper to configure the drive offset if ripping in secure mode, for each drive, then move to batch ripper).

[MTWolf]

Re: Batch Ripper Eject Timeout to short?

Spoon,

I Know this is an old thread, but I have an update.

I have additional hardware and have been doing more testing. The computer is a Clean install of XP Pro all patches and a clean install of dbPowerAmp with Batch ripper 1.4 beta (june version).

After some lucky moments I have a question that might suggest a solution.

Reject and Unload: when they execute the --Open command what I am seeing is the drive starts to open and then is reset (causing it to close) when the drive completes the load of the cd still in the tray (going ready?), it receives an eject command then a moment later it gets a reset. This cycle continues for 3 times then times out, or the the drive is able to complete it's open before the reset is sent. If I grab the tray and hold it open the drive tries to close, but eventually gets an eject and stays open. This and a happy accident are what clued me to what seems to be going on. The Happy accident was that one drive started to open while the other drive was ripping, When the opening drive started close again the ripping STOPPED on the other drive for a moment.

Does any of this ring a bell?

The hardware is a Primera Composer Pro with the drives converted to USB. The unit will run correctly, no "drive failed to open" messages for several discs. Sometimes the drives open on the first try, some times they open/close once or twice before opening, sometimes they time out and the "drive failed to open" message comes up. (the "Drive failed to open, correct the problem and hit ok" sometimes won't clear even though the drive is open.)

JohnC

[MTWolf]

Re: Batch Ripper Eject Timeout to short?

Oh, I should add that I have this happen with different USB interfaces and different cd/dvd Drives. I'm using Lite-on DVD and CD drives and the problem shows up. The way I know it's not the usb interfaces is that I have used the USB interfaces with original Primera drives and the problem doesn't show up. But it does show up across every current manufacture CD/Dvd drive I have tried.

[MTWolf]

Re: Batch Ripper Eject Timeout to short?

One more piece of the puzzle. If one drive is open when the second drive tries to eject BOTH drives will close when the second drive tries to open then closes.

[Spoon]

Re: Batch Ripper Eject Timeout to short?

There are some new primera drivers in the beta section of this forum, it is a long shot but worth a try.

[MTWolf]

Re: Batch Ripper Eject Timeout to short?

I was able to get ahold of the "same" 1394 cards that primera was using in later versions of the Composer series. A slightly newer version, but made by the same company and physically identical. Swapped these into the Composer Pro that I was running with USB and not a problem since. Looks like it's usb and the Composer drivers that don't play nice together. I've gotten a supply of the cards so I'll convert the remaining USB units to 1394. The USB units were ones that started life as SCSI or CONDRE duplicators.

I am though on the verge of writing new composer drivers to handle how the software deals with out of disk conditions. We are running multiple Composers on the same machine and it just doesn't quite work. Or there is something about how the input stack should be setup that I don't know. When the loader hits the end of the input stack (no more disks to rip) the Load.exe doesn't really handle it well. And we end up with a disk lift in the other drive that doesn't get unloaded.

[Spoon]

Re: Batch Ripper Eject Timeout to short?

2 drives even on the same robot should be independent, it should atleast try to unload the 2nd drive later, if it is left in.

[MTWolf]

Re: Batch Ripper Eject Timeout to short?

Been looking at this from a different angle. I was researching another project and ran into old posts by Brendan with some code dealing with checking if a cd drive is open or closed. Brendan was doing direct dll calls that could be causing my problem with the USB interfaces.

As to not unloading disks, this is because Load keeps the serial port locked until it exits, and when the batch rip is done (no more disks in input, which isn't handled correctly in ULCLI) Load pops up an error message and the only way out is to select abort which aborts the batch rip and the other pending CD is rejected not unloaded. Or the other case were the pending unload/reject crashes after waiting all night for the error from load to be cleared.