[Paranoia] Getting paranoia to quit on CD eject

Bill Davidsen davidsen at tmr.com
Tue Oct 19 07:27:22 PDT 2004


On Mon, 18 Oct 2004, Peter Jones wrote:

> On Sun, 2004-10-17 at 08:03 -0400, Bill Davidsen wrote:
> > On that topic, it would be nice if there were more control over error 
> > handling, such as a limit on errors per track, after which the track 
> > would be abandoned, etc.
> 
> Right now, pretty much everything about errors and warnings is on my
> "can stand some serious work" list.  If nothing else, the way messages
> are reported from the libraries to the front end (and consequently from
> the libraries to gstreamer/grip/abcde/etc) is really inflexible.  I
> think having the frontend register a callback is probably the best plan,
> but I'd love to hear other peoples' opinions.
> 
> It might be nice to have the callbacks be able to alter the plan for
> ripping the disk, as well, but that's not nearly as important.
> 
> And, of course, this would be for libcdda_interface level errors, not
> sg/SG_IO/ioctl level errors.  Still, the stuff e.g. grip does to display
> our percentage bars is pure pain -- I think it actually causes things to
> be slower, because libcdda_* get stuck into a select() loop talking to
> X, but that's just my quick reading of an strace, so it may not be 100%
> accurate.  Anyway, it looks quite silly.

What I had in mind was either (a) have a signal like usr1 mean skip to
start of next track and just give up, or (b) putting a limit on how long
in real time will be spent on a track before punting to the next.

These are not mutually exclusive, nor the only useful ways to tackle the
problem. But options to quit after N errors (or try less hard on that
track) and/or do the same after some elapsed clock time might be generally
useful. There are times when I'll settle for close and times when I want
perfect or nothing, and options to do both would be used by me. The harder
any ripping program has to work the less confidence I have in the result.

-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.



More information about the Paranoia mailing list