[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 #54 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

the proposal to let libburn ignore SG_ERR_DID_NO_CONNECT is:

- Download the current cdrskin development tarball

   http://scdbackup.sourceforge.net/cdrskin-1.4.7.tar.gz

- Unpack in some directory of your choice and go to the unpacked top directory

   tar xzf cdrskin-1.4.7.tar.gz
   cd  cdrskin-1.4.7

- Modify the transport driver for Linux SG_IO:

----------------------------------------------------------------------------
--- libburn/sg-linux.c  2016-07-23 12:35:51.030269903 +0200
+++ .../libburn/sg-linux.c  2016-11-30 14:18:58.745724400 +0100
@@ -1906,6 +1906,13 @@ static int evaluate_transport_success(st

        /* See http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html */

+#define Libburn_cdemu_host_status_test yes
+#ifdef Libburn_cdemu_host_status_test
+       if (host_status == 0x01 &&
+           (driver_status & 0xf7) == Libburn_sg_driver_oK) {
+               /* SG_ERR_DID_NO_CONNECT */
+               {ret = 1; goto ex;}
+       }
+#endif
+
        switch(host_status) {
        case 0x00:
                host_problem =
----------------------------------------------------------------------------

  I understand that this would act like growisofs.
  Triggering a retry, like probably cdrecord does, needs some change with
  the caller of this function.

- Compile the modified libburn and create a statically linked cdrskin,
  which does not use your system-wide installed libburn.so:

    make
    cdrskin/compile_cdrskin.sh -g

- Check whether your cdrskin binary is willing to run

    ls $(pwd)/cdrskin/cdrskin
    cdrskin/cdrskin -version

  This should say

    /...absolute.path.../cdrskin/cdrskin
    cdrskin 1.4.7 : limited cdrecord compatibility wrapper for libburn
    ...
    Version timestamp :  2016.11.18.132335
    Build timestamp   :  ...

- Let K3B use that binary.
  Either by putting it where K3B found cdrskin before, or by letting
  K3B execute the binary by its absolute path.

  If the cdrskin version number 1.4.7 then appears in the K3B log, we
  know that the change is in effect.


Have a nice day :)

Thomas

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