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

Thomas Schmitt bugzilla_noreply at kde.org
Tue Nov 29 09:11:08 UTC 2016


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

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

> https://bugs.kde.org/attachment.cgi?id=102515
> cdrskin: FAILURE : SCSI command 2Ah yielded host problem: 0x1 SG_ERR_DID_NO_CONNECT (Could not connect before timeout period)

This is a Linux SCSI command transport error emitted by iotcl(SG_IO).
Listed in http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html but
not much explained there.

In any case it is not the fault of cdrskin, libburn, or your cdrskin options.

If it was a real drive, i would advise to first check the cables and
to try another SATA or USB port. Another suspect would be the drive's
power supply.

The fact that cdrskin started burning without own error message is
an intermediate indication of programming success on your side.
The DVD emulator seems to have worked in the beginning, until it ran into
a problem with the Linux kernel.


> Starting to write CD/DVD at speed 18 in real TAO mode for single session.
> ...
> Track 01:   30 of  734 MB written (fifo 100%) [buf   0%]  42.5x.
> Track 01:   35 of  734 MB written (fifo  93%) [buf   0%]  189.6x.
> ...
> /usr/sbin/cdrskin -v gracetime=0 dev=/dev/sr1 speed=18 -sao -tao driveropts=burnfree -data -tsize=375808s -

Obviously the emulated drive does not honor the speed wishes issued
by libburn. (It is so fast that the watcher thread of cdrskin misses
several MB between its inquiries.)

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

For command line experiments with cdrskin i could offer libburn's emulated
drives.
cdrskin option

  --allow_emulated_drives

enables this feature. A (possibly not yet existing) data file can then be
used by an address option like

  dev=stdio:/tmp/my_pseudo_drive

This yields a behavior similar to DVD+RW media.

Disadvantage is that these pseudo drives will not show up as CD drives to
the kernel and thus will not be realistic examples when used from K3B.
(For anything but libburn the files are just plain data files. Like an
ISO image.)

Advantage is that no ioctl(SG_IO) is involved but just POSIX calls like
open(2), lseek(2), write(2). If the computer can reliable write files,
then it also can perform libburn pseudo-drive operations.

Have a nice day :)

Thomas

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


More information about the k3b mailing list