New configuration option??

[sredmyer]

I just noticed that there is a new configuration option for the Batch Ripper called "Keep Unload Order Same as Load (on multi-drive systems)".

I am not clear on the purpose of this. It sounds like it will load drive one and begin ripping then load the other drive. Then it will unload them in that same order (drive 1 then drive 2) even if drive 2 completes first.

Is this correct? If so (just out of curiosity) why would this feature be important? In my process it would just serve to slow things down.

Just curious as to what purpose it might serve in other workflows.

[bhoar]

Re: New configuration option??

To sredmeyer:

Typically this would usefule be if you were ripping a library (radio station, on-site project) and you wanted to more easily ensure that you did not get the CD cases out of order out of fear of enraging the librarian(s). Throughput, indeed, suffers.

To spoon:

I've received reports it doesn't work with my drivers for multi-drive robots, but I have not yet tested it (so the following is unconfirmed). If the reports are accurate, then the batch ripper code does not limit pending dispatches to one unload/reject at a time, even if it does dispatches them in the correct FIFO order. In the case of my drivers, if multiple unloads/rejects are pending when some other request finishes (say, a load), then the unload/reject that gets serviced is random as there's no inherent queue in my drivers*, the executables keep retrying access to the robot using a random, but short, timer. In order for it to work with my drivers, the batch ripper would have to know to only dispatch a single unload/reject at a time. Alternately I'd have to rearchitect my drivers to have a FIFO queueing system.

-brendan

* not quite true: unloads/rejects leave a lock file that is checked by pending robot processes so that the only one allowed to move forward is the load pending on the same drive that was just unloaded/rejected - this is for obvious performance reasons. However, this particular mini-queue has no bearing on the argument above.

[sredmyer]

Re: New configuration option??

To sredmeyer:

Typically this would usefule be if you were ripping a library (radio station, on-site project) and you wanted to more easily ensure that you did not get the CD cases out of order out of fear of enraging the librarian(s). Throughput, indeed, suffers.

Ah I get it. It prevents the stacking order from being changed. I can see how this could be useful for systems using robots (stacker/picker type). Reason I couldn't see the point is I use changers. Changers always load/unload in order.