[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-xorriso] To Thomas Schmitt: how to go on, xorriso is installed

From: Thomas Schmitt
Subject: Re: [Bug-xorriso] To Thomas Schmitt: how to go on, xorriso is installed
Date: Thu, 11 Apr 2019 09:26:57 +0200


Adalbert Hanßen wrote:
> Thank you again for your patience and for your explanations.

Meanwhile it looks like you discovered a new problem between Xfburn and
some CD burners. So you contributed your due part to this endeavor.
So i can return your thanks.

> xorriso -for_backup -outdev /dev/sr0 -map ~/temp/'2019-03-17_Eselsburger Tal'
> However, my files were at
> /media/verwalter/ISOIMAGE/home/verwalter/temp/2019-03-17_Eselsburger Tal.

You left out the second parameter "/" of map:

  -map ~/temp/'2019-03-17_Eselsburger Tal' /

xorriso was tolerant enough to duplicate the first parameter so that it
effectively became

  -map ~/temp/'2019-03-17_Eselsburger Tal' ~/temp/'2019-03-17_Eselsburger Tal'

(New xorriso run proposal is below.)

> The drawer for the CD stayed closed. On Xubuntu's desktop the medium was
> still shown as empty medium and thunar was showing it as burn:///.

That's a known mis-coordination between the kernel call ioctl(SG_IO)
and the kernel's block device driver.
The block device driver does not know that SCSI commands were performed
via SG_IO which have changed the content of the medium.

The medium state gets re-assessed by the block device driver when the CD
gets loaded into the drive again. (That's why growisofs ejects the tray
and then reloads it at the end of a write run. Watch your fingers.)

You may let xorriso eject the tray, if the drive has a motor to do that.
Add as final xorriso commands:

  -commit -eject all

This will first start the burn run and then order the drive to eject the
tray. But with laptop drives the tray often has no motor and thus stays
ini until you eject it manually.

With the next run on a blank CD do it like this

  xorriso -for_backup \
          -outdev /dev/sr0 \
          -volid 'BILDER_2019_03_17' \
          -map ~/temp/'2019-03-17_Eselsburger Tal' / \
          -commit \
          -check_md5 fatal -- \
          -eject all

(The '\' characters tell the shell that the shell command line is continued
 by the next input line. You may as well write all commands in one line.)

More than one -map command is allowed. Each takes two parameters:
The input path on disk and the address for that path in the ISO.

Command -commit performs the burn. (This is done bey default when the
program ends and changes are pending.)

  -check_md5 fatal --
starts a checkread run which compares the freshly written session with
the MD5 which was recorded during the burn run.
In case of good result you will see messages like

  Checking loaded session by its recorded MD5.
  Session MD5 4341973300fc99c232963fc686328ce8 , LBA 0 , 116634 blocks
  Ok, session data match recorded md5.

In case of mismatch you will see

  Checking loaded session by its recorded MD5.
  Session MD5 4341973300fc99c232963fc686328ce8 , LBA 0 , 116634 blocks

and the program run will end prematurely, because of parameter "fatal".
The attempt to eject the tray will not happen. (Use "sorry" as first
parameter and the program will go on after a mismatch.)

> If I interpret these lines right, this CD is not yet finalized so additional
> data can be written to it. *Is this right?*.

Yes. Another xorriso run can load the directory tree and manipulate it.
You may add files, delete files, or rename them. In the end a new session
will get written which contains a new directory tree and the data content
of newly added files.
Linux kernel will by default mount the directory tree of the newest session.

Data content of files in previous sessions is re-used at its old storage
The old directory tree is not lost or overwritten. It can be mounted
by Linux mount(8) option "sbsector=" and will then show the old files
with old names. This includes files which are deleted in the newer directory
tree. (So deleting is not a way to destroy the affected content.)

The difference to a first session on blank media is only the command to
acquire the drive. Use instead of
  -outdev /dev/sr0
the command:

  -dev /dev/sr0

This will load the directory tree of the youngest session as base of the
newly emerging directory tree.

If you want to close the medium so that it cannot be written any more,
insert in the xorriso command list somewhere before command -commit:

  -close on

(As stated before, the command sequence matters. -close "on" must be set
 before the burn run beings.)

Above checkreading by
  -md5_sum failure --
only checks the newest session on the medium.
To check all sessions do:

  xorriso -for_backup -indev /dev/sr0 -check_media --

(Another xorriso background info:
 Some commands take a variable number of parameters. Their parameter list
 end has to be marked by "--", so that xorriso knows that the next argument
 is meant as next command.)

(Larger xorriso command compositions are usually done in a shell script
 file with some variables comming from outside, some other shell commands
 for preparation, and then the xorriso run with its many xorriso commands.)


Now back to Xfburn:

It looks like we have two candidates for being culprit:
Stream Recording and SAO. Much suspicion lasts on Stream Recording now.

So with the next CD you burn with Xfburn disable "Datenstromaufnahme" but
leave "Schreibmodus:" at "automatisch".

It would be interesting for me to learn whether this is really the
remedy for the problems. If so, then i have to ponder whether i disable
Stream Recording for CDs in libburn, regardless what Xfburn wants.
Regrettably, Xfburn development has effectively ended and i am not
an XFCE GUI programmer who could take over the project.

> Is it good if the buffers are close to 100% or at 100% or is
> this dangerous?

It's good. "buffer" means the drive's internal buffer of 1 to 4 MB.
If it runs empty then the drive becomes idle and maybe has to make
extra effort to re-start burning. (In the last century such a buffer
underrun spoiled a CD burn run completely. But then came "burn proof"
CD drives which are able to continue after such a pause.)

Another buffer is the "fifo". It is maintained by the burn program in
the computer's RAM. The purpose is to bridge over short times of no
output from the ISO 9660 producing process.
(In the past this was a remedy against buffer underrun. Nowadays it only
 helps to keep the drive busy during the whole burn run in order to get
 the job done as quick as possible.)

> *Where can I influence in xfburn whether the medium si to be finalized or
> not? Or is this inaccessible to xfburn?*

As said, i am not an Xfburn expert. But Debian can be of help for a libburn
expert who looks for API call burn_write_opts_set_multi:


This yields only one match where multi would be set to 1. And this code
snippet is disabled currently:

  /* enable this when there is some time for testing
  DBG ("Enabling multisession");
  burn_write_opts_set_multi(burn_options, 1);
  burn_write_opts_set_simulate(burn_options, params->dummy ? 1 : 0);

The pair of "/*" and "*/" encloses the code and makes it a mere comment.
The english sentence indicates that David Mohr planned to make use of
this feature, but did not do.

Somewhere between Xfburn and xorriso is xorriso-tcltk, the most ugly
GUI burn program ever:

It is meanwhile available as Ubuntu package:
but you will probably have to fetch it by

  chmod u+x xorriso-tcltk

Make sure you have installed Ubuntu packages "Tk" and "BWidget", and then
start it by


(You may move the file to /usr/local/bin so that you don't have to
 go into its directoru and prepend "./" to the program name.)

Click on the "Help" button at the upper right to get an introduction
with use cases.
Click by the right mouse button on any GUI element to get a help text
about its purpose and relation to xorriso commands.
Background info about commands is given in
  man xorriso

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]