--- Comment #31 from Thomas Schmitt <> ---

> Plan A - rewrite K3b::Device::Device::getNextWritableAdress()

Augment it by the equivalent of growisofs code, if the multisession
-C parameters turn out as 0,0:

        next_session = from_733(descr->volume_space_size);
        /* pad to closest 32K boundary */
        next_session += 15;
        next_session /= 16;
        next_session *= 16;
        sprintf (C_parm,"16,%u",next_session);

(The "16" as first -C value is actually wrong but mkisofs will understand
 what is meant. Legacy tradition.)

I would advise to align to 64 K at least for BD media.
But that is not what growisofs does.

Whatever, determination of -C values is needed in any case, because K3B
needs to hand over the values to mkisofs.

> Plan B - avoid risky design, don't have to specify -C option, let growisofs
> construct one

You got me wrong here.
I deem it risky if you bet on K3B's capability to determine the same
second number for -C as growisofs does.
I.e. if you do not use:
   -use-the-force-luke=seek=... -C ... -Z /dev/sr0=/dev/fd/0

I did not yet get to the experiment whether
   -C ... -M /dev/sr0=/dev/fd/0
works fine if i submit the same value to -C as growisofs computes.

It does not help to omit with the growisofs run. If the value is
acceptable then growisofs will go on. If you gave mkisofs a value
which growisofs will not accept, then it is ok to abort the burn run,
because mkisofs prepared the add-on session with incorrect offset.

(Remember: The statement "You don't have to specify the -C option"
 in the man page is about the use case which K3B does *not* use.
 In case of /dev/sr0=/dev/fd/0 the statement is not really true.)

Have a nice day :)


You are receiving this mail because:
You are watching all bug changes.

Reply via email to