Re: CDRECORD errors with "fancy formatted" text files
From: stu7 (stuseven_at_hotmail.com)
Date: 9 Jan 2004 17:06:21 -0800
firstname.lastname@example.org (james) wrote, after stu7 wrote...
> > What do I need to do in cdrecord/mkisofs to produce
> > a CD which works with these file types ??
> You didn't post the command line you use for mkisofs.
> You also didn't post the commandline for cdrecord, or the
> error messages.
*** no I didnt... because Im just doing the ordinary, making
*** an image file, then cdrecord... it works for ANY set of files
*** but these... go figure. The error messages arent especially
*** useful Id say... just the ordinary "no medium found"...
*** "seek error" all that... the same as if there was a power surge
*** the issue is, the resulting CD cant be mounted or read, even
*** though it shows the tracks visibly burnt onto the plastic.
> You can probably troubleshoot this without burning any more coasters,
> if you'll stop at the mkisofs step, and mount the volume loopback, and
> check it out.
*** yes, I did that loopback.
*** I can produce an image file, and I can read the image file fine...
*** it just will not produce a good CD in this situation (with these
*** mixed files).
> You might need to use graft-points.
*** I'll try anything that makes sense... will have to look at graft
*** points... something Ive never used
> You may have specific requirements for your final cd, but one
> thing I do a lot is to make a tar.bz2 of the dirs I want to
> record, and mkisofs from the tar's. It adds a step for reading
> the CD, but it also makes it much easier to validate, and I
> don't run into filename collisions or ISO9660 directory issues,
> and so on. cdrecord won't care about "file types" if the only
> file type is bzip2 or tar.gz...
*** this makes the most sense here... "filename collisions" isnt really
*** the problem I think, but thats close... it HAS to be something
*** about the special formatting of these specific files.
*** this is why I went to image files in the first place... trying to
*** hide whatever it is that cdrecord doesnt like. I will try one
*** with tgz ...that data is more likely not visible to cdrecord
> I hope you're running mkisofs and making an iso first, and then
> running cdrecord on the iso, and not as a pipe in a single call.
> You're asking for buffer underruns if you do that (== coaster).
> Even so, you might be getting buffer underruns, and I don't think
> driveropts=burnfree is set by default on some versions.
*** actually, I get the same excellent results using image files /
*** or from a single directory / or from symlinks... USUALLY that is :)
*** This problem is devastating my CD budget... and certainly Im not
*** the only one who has encountered it... but there is nothing about
*** this bug in newsgroups... and the cdrecord developer thinks
*** Im pulling a joke or something... he told me flat out "there
*** is no such bug". This is a bit troublesome... their faq
*** specifically asks for people with unreported bugs to email them.
*** Thank you very much for all your excellent suggestions.