https://bugs.kde.org/show_bug.cgi?id=367639
--- Comment #31 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> 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 :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
