Subject: Re: oh yay (pkgsrc/audio/cdd vs cddb)
To: None <firstname.lastname@example.org>
From: Wolfgang Rupprecht <email@example.com>
Date: 03/12/2001 10:34:56
firstname.lastname@example.org (Laine Stump) writes:
> CDDB recently began pounding the nails in their own coffin (more
> restrictive license).
> Can it be reconfigured to use freedb (http://www.freecddb.org)?
> An alternate method might be to make cdd untruthfully report itself as
> some other, licensed, application.
I've started seeing this under grip (a gnome-lib based
ripper/encoder/labeler). Switching to freedb-only mode was painless.
Netbsd diffs for grip on demand. It does take some effort to get grip
A side question: Netbsd's cdrom driver seems to try to "help" the
user by not allowing the CD information that the kernel presents to
userland to be updated while the cdrom device-file is open. The grip
code does this to try to detect when a new disc is inserted:
ret = ioctl(cdromfd, CDIOCREADSUBCHANNEL, &discstatus);
Netbsd is effectively "protecting" the user from a quick game of
three-disc-monte, where the cdrom changes unexpectedly. The problem
is that this feature is not included in any other common OS, so the
grip code never got structured to allow some lowlevel code to "burp"
the cdrom file by closing it and opening it. (cdromfd was passed by
value, so even doing a quick close()/open() on cdromfd was very
painful and unclean.
Now putting an open/close in the poll loop did cause me a bit of moral
pain. It did seem like this netbsd feature caused this loop to become
quite a bit more expensive. Could I convince the-powers-that-be to
revisit this issue, and perhaps remove this "no disc info changes
while the device file is open" restriction?
Wolfgang Rupprecht <email@example.com>
Coming soon: GPS mapping tools for Open Systems. http://www.gnomad-mapping.com/