[k3b] [Bug 137436] Adding support for cdrskin as an alternative to cdrecord/wodim

[Thomas Schmitt]

https://bugs.kde.org/show_bug.cgi?id=137436

--- Comment #63 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

sorry, i did not yet get to installing an Archlinux with CDEmu.
Real life and some other free software obligations ...

cdrskin3.log looks like a full success.
(It becomes more eye-friendly by:  sed -e 's/\r/\n/g' < cdrskin3.log | less )

Does it stem from a cdrskin run underneath K3B ?

If not, then please test whether this cdrskin survives a run under K3B.

--------------------------------------------------------------------------

Whatever, it looks like i'd need to install something similar to your
K3B development environment in order to reproduce the problem with CDEmu.

That's quite some hurdle.
So for now i have to ask you to make the crash experiments.

Interesting would be if you could temporarily hack your K3B so that
we get to see:

- Messages of (patched) cdrskin-1.4.7 under K3B with options -v -V .

- Messages of cdrecord under K3B with options -d -v -V.


cdrecord.log.tar.bz2 did not contain any host_status lines that were
not "00". But unpatched cdrskin succeeded in the same environment and
thus did not experience any other host_status than 0.

The resulting message list is indeed gigantic. I scanned for interesting
lines by
  cat cdrecord.log | grep 'host_status:' | grep -v 'host_status: 00'

--------------------------------------------------------------------------
cdrskin-burn-archlinux-iso-debugging-output4.txt

Hrmpf. CDEmu seems to hate the RESERVE TRACK command. This SCSI command
was triggered by libburn's automatic decision for the behavior of
option -sao because: The DVD+R was blank, no -multi was desired,
the input size was known in advance by option tsize=.

On a real DVD+R in a real drive this should well work.

For now i retract my objections against a hard coded option -tao.
If the user does not explicitely demand SAO (or DAO or Reserve Track),
then it is the safer bet with your kind of "optical drive".

So in
 
https://cgit.kde.org/k3b.git/commit/?id=a8074105e842babab18d7adcb290dd6eca3304bb
you will have to revert the first change:

> - d->process << "-tao"/* << "-sao"*/;
> +#ifdef K3B_DEBUG
> + qDebug() << "DEBUG:" << __PRETTY_FUNCTION__ << "let libburn choose "
> + "the write type according to other parameters and the medium state.";
> +#endif

Does the K3B user get an opportunity to explicitely choose SAO/DAO ?
If so, then this should be taken into repsect here.

--------------------------------------------------------------------------
Other half of /commit/?id=a8074105e842babab18d7adcb290dd6eca3304bb :

>  emit infoMessage(i18n("Writer does not support raw writing."), MessageWarning);
> - if (d->cdrskinBinObject->hasFeature("tao"))
> - d->process << "-tao";

A warning is not enough. If the program gets to this point then the input
data will not be written to the CD medium in the way that is expected by
the producer of those input data. Readers will perceive the written medium
as CD-ROM (i.e. computer data) with garbage sprinkled over the payload.
Maybe the burn run will exceed the CD capacity.

The intention of the input producer is rather to influence parts of the
CD sectors which are not read by normal readers as payload but rather
tell the reading drive what kind of payload the CD sectors bear.
Further there are the "sub-channels" which bear a few bytes per sector
for various purposes.

Raw burning is a CD thing. DVD and BD have only sector format -data.
I assume raw is mainly used for cloning of CDs with unusual sector content.

--------------------------------------------------------------------------

Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.