[Libburn-hackers] Re: libburn never finishes burning DVD image

Thomas Schmitt scdbackup at gmx.net
Wed Oct 28 12:21:32 CDT 2009


Hi,

> Don't you think that this is a little bit too long for a timeout these days?
> A full DVD usually takes 7 or 8 minutes to burn with 16x and about 30
> seconds to finalize and flush the buffer.

It is inpired by 1x CD speed.
Actually i never expected that it would have
to snap. It is still questionable whether it
will do any good.


> > Heiko, do you feel apt
> I'm not using apt

I meant whether you feel able. :))

David, do you understand german language ?
It is a bit error prone when two germans
use english.


> I generally don't think that reducing the timeout is the solution
> for this problem. But I think for testing purposes it's ok. ;-)

It will at least shorten the suffering.

> I'll test it but it can take some days because I haven't got any discs
> anymore. So I first need to order new ones.

It would be interesting whether there are
problems with CD-RW (and a smaller image).
DVD- and CD are quite similar.

Did you try other DVD types ? DVD+RW ?
Or DVD+R ? (Despite the name similarity they
are quite different.)


> I guess the slow down in Xfburn is because Xfburn reads the libburn
> output and calculates the average speed. And because libburn doesn't
> finish burning and gives no output or only the timeout the average
> speed gets slower and slower. Just a guess.

Sounds reasonable.
cdrskin issues the "thank you for being patient"
when it cannot detect progress and actually has
no idea what the libburn thread is doing
currently.
It waits for the library drive object to get into
state BURN_DRIVE_IDLE. But that does not happen.


> The problem is that I don't know how to tell K3b to use growisofs.

I once explored with a very old K3B how to
make it use cdrskin. Maybe you find inspiration:
  http://scdbackup.sourceforge.net/k3b_on_cdrskin.html


Apropos growisofs. Look what i found in its
source code:

    if (even_sync)              // Pioneer apparently needs this,
    {                           // non-IMMED FLUSH that is...
        cmd[0] = 0x35;          // FLUSH CACHE
        cmd[9] = 0;
        if (is_dao) cmd.timeout (15*60);
        if ((err=cmd.transport()))
        {   sperror ("SYNCHRONOUS FLUSH CACHE",err);

I will see what i can learn from this.
(Sensei Andy considers 900 seconds timeout
appropriate.)
liburn does IMMED flushing.
We shall test that.

Wait with further burn test burns until i make
change proposals or upload a new tarball.
Maybe we can avoid further reboots and misburns.


David Mohr:
> That's what xfburn is doing,
> burn_write_opts_set_write_type (burn_options, BURN_WRITE_TAO,
> burn_write_opts_set_write_type (burn_options, BURN_WRITE_SAO,

With DVD-R:
"TAO" triggers Incremental Streaming, a 32 kB
packet write mode which is used by growisofs in
most cases. "SAO" triggers Disk-At-Once, which
is quite similar to CD Session-At-Once but does
not allow to leave the DVD-R appendable for more
sessions.


Have a nice day :)

Thomas



More information about the Libburn-hackers mailing list