-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] autoloader support #55
Comments
For example,
It might be helpful to have a similar option Eject option if the disc is fully failed, to allow the stack to continue processing. |
That's generally not really going to happen. It's possible that a heavily damaged disc can lock CDParanoia up. Is -Q, plus a bash for-loop enough to handle autoloaders? |
Sorry for the delay.
Yes, if the discs are all good. If there is a disc that cyanrip decides is a "fail", if it aborts and does not eject the disc, then the process would stop. On a long run (for example, overnight), that is a large bummer. In a case where CDparanoia is able to abort / report a fail to Cyanrip, and the disc isn't going to be used anymore, that's the perfect use case for a "Eject on failed" that works the same way as the "Eject on success". |
cyanrip returns a non-zero error code on errors. Basically what do you want cyanrip to do? Explain to someone who has never seen an autoloader, how they work, what they expect "eject" to mean, or how they move to other discs? |
A few autoloaders on the market allow the processing of a stack of discs (FIFO), like the Acronova/Datatronics Nimbie and Primera. It would be very helpful to implement/document a procedure to use autoloaders with cyanrip.
The text was updated successfully, but these errors were encountered: