Re: cdrskin + k3b doesn't work SOMETIMES

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Helmut Jarausch wrote:
> I have configured k3b to use cdrskin (libburn-0.7.0)
> On one of identical machines - at least, I think so -
> this works just fine, but on some machines it doesn't work.
>
> When I do it 'by hand', e.g.
> mkisofs -R -J -iso-level 4 -pad -o OUTPUT.iso SOME_DIR
> cdrskin -v dev=/dev/sr0 speed=52 fs=50m padsize=300k OUTPUT.iso
> it works!

How large is OUTPUT.iso ?

The k3b run produces a very unusually small
ISO image:
> 186 extents written (0 MB)

150 of them are due to mkisofs option -pad.
About 20 more are non-payload parts of the image.

Does this happen with larger images ?


It looks like k3b runs mkisofs and cdrskin
in a pipe. Did you try this manually ?

/usr/local/bin/mkisofs -gui -graft-points -quiet \
  -volid  'gentoo-headers-2.6.30-2.tar' -volset '' \
  -appid 'K3B THE CD KREATOR (C) 1998-2006 SEBASTIAN TRUEG AND THE K3B TEAM' \
  -publisher '' -preparer '' -sysid 'LINUX' \
  -volset-size 1 -volset-seqno 1 -sort /tmp/kde-jarausch/k3bC8YoLa.tmp \
  -rational-rock -hide-list /tmp/kde-jarausch/k3bqOujrc.tmp -joliet \
  -joliet-long -hide-joliet-list /tmp/kde-jarausch/k3beHqcka.tmp \
  -no-cache-inodes -full-iso9660-filenames -iso-level 2 
  -path-list /tmp/kde-jarausch/k3bqOujrc.tmp \
| \
/usr/bin/cdrskin -v gracetime=2 dev=/dev/sr0 speed=48 -tao \
  driveropts=burnfree -eject -multi -xa1 -tsize=186s - 

Since i have no clue about the following
mkisofs options, i would omit them for now:
  -sort /tmp/kde-jarausch/k3bC8YoLa.tmp
  -hide-list /tmp/kde-jarausch/k3bqOujrc.tmp
  -hide-joliet-list /tmp/kde-jarausch/k3beHqcka.tmp

I would write my input file names into the file
given to -path-list
  /tmp/kde-jarausch/k3b2i6G3a.tmp


> Are any options used by k3b the culprit?

The only unusual option with cdrskin is "-xa1" which
gets recognized and ignored. You get a classical
CD which is ok for pure data or pure audio.
mkisofs of course produces pure data into the only
track source. So no CD-XA is needed.


> (SIGTERM has been caused by <ctrl> C)

I assume you saw no progress for a while.
That means cdrskin was still waiting for EOF at
standard input.
This EOF would be caused by mkisofs closing stdout
resp. ending.

If the problem is reproducible with above pipe
then you may insert a tee process:

  mkisofs ... | tee -i /tmp/pipe_log | cdrskin ...

wait a due while, abort by Ctrl+C and look
what you caught in /tmp/pipe_log .


For now it looks as if mkisofs is waiting for
something to happen before it ends itself.

If this suspicion is correct then you may
replace cdrskin by dd of=/dev/null while you
are exploring the reason.
(This is not the same as >/dev/null. Stay with
 the pipe.)


If you cannot reproduce the problem with
the pipe then it might help to inspect
and use the four file /tmp/kde-jarausch/k3b/*
It should be possible to copy them while k3b
is stalled before you press Ctrl+C.


Have a nice day :)

Thomas