This is the English version (including later edits) of Xfburn: fehlgeschlagen, Burn Run failed.

I use Xubuntu 16.04.6 LTS, currently with Linux kernel 4.4.0-145-generic x86_64.

Xfburn has version 0.5.4 for Xfce 4.12.

I use a Lenovo W530 laptop, the CD/DVD-RW-drive in it is shown as MATSHITA DVD-RAM UJ8C0. Xfburn shows all possible check marks for it except for "write blue ray disks".

I am using blanks of type Verbatim CD-R 700 MB 52x.

The FIFO-buffer of Xfburn is set to the maximum possible, which is 16384 kB on this installation.

I always get error messages of this type

Failed: Burn Run failed.

Usage of the FIFO-buffer shows 99%, for the device buffer 100% usage is shown.

In the configuration check marks were set for:

  • Eject CD,
  • Simulate,
  • Burn Free,
  • Stream Recording.

There was no checkmark at "only create ISO".

(I also have tried to write with a reduced speed, but that also did not work.)

What‘s wrong here?

Edits: As suggested by a comment, I start xfburn from the command line to show its error messages:

$ xfburn
** Message: 18:09:48.866: Using UDEV
** Message: 18:09:52.110: Using gstreamer transcoder.

** (xfburn:12230): WARNING **: 18:12:50.707: [FATAL] 131357: SCSI error on write(32,16): [5 30 05] Illegal request. Cannot write medium, incompatible format. (0)

** (xfburn:12230): WARNING **: 18:12:50.707: [FATAL] 131339: Burn run failed (0)

Of course, the blank used in this trial gets lost: If I re-insert the disk drawer, many CD access operations happen. One has to be very patient to let them all finish. This time the file system on the CD is not mounted after the disk is inserted and all CD operations have come to an end. I remember that Thunar showed me the content of the disk with its directory structure and file names last night. When I tried to open one of the files, another almost endless sequence of CD operations took place. But this was without a reboot happened after writing the CD. Today after rebooting and re-inserting this CD and after sudo blkid I see a line

/dev/sr0: UUID="2019-04-08-18-12-20-00" LABEL="Bilder 2019-03-1" TYPE="iso9660"

with the disk label I had given to this disk. Then I tested

$ badblocks -v /dev/sr0
Es wird von Block 0 bis 233879 geprüft
Es wird nach defekten Blöcken gsucht (Nur-Lesen-Modus):60

The number of futile accesses goes on at least to 151 (I stopped it there) but surprisingly the number of read head movements between consecutive block numbers varies: sometimes it is one such noise from one number to the next one, sometimes there are several such movements.

I wonder about TYPE="iso9660" because the file names to be written to the CD were long ones, they did not follow the 8.3 name scheme known from the stone age of DOS! If I remember right, one needs something like the Joliet file system or similar to break out of the 8.3 name cage.

a) Is it possible to write CDs with xfburn with long filenames?

b) Is the presence of files with long file names or containing non-ASCII characters an explanation for this failure?

c) If the answer to a) is Yes: What do I have to do in order to write such files to a CD?

d) If there is an answer to c): Isn't it a bug of xfburn that it does not provide an error message before it actually tries to burn such files and destroys the CD blank in doing so?

  • Does it say anything else but "burn run failed" ? E.g. messages about libburn or libisofs ? ("Datenstromaufnahme" is "Stream Recording", a feature that disables Defect Management on DVD-RAM or formatted BD in order to get full burning speed.) Apr 7 '19 at 6:20
  • Unfortunately there is no additional information. Would it make sense to look for further information in logfiles? In this case: Which file would be the right one? Apr 7 '19 at 14:29
  • Maybe you get messages if you create a new terminal window and enter the command "xfburn" there. I see messages about using "UDEV" and "gstreamer" when i start my Xfburn 0.5.2. But in forums.gentoo.org/viewtopic-t-819687-start-0.html one can see in such a run a libburn error message about "SCSI error". (The theories made in that thread are questionable, though.) Apr 7 '19 at 15:55
  • Thomas, looking at the link you gave me, I see a discussion that xfburn can run with different backends: cdrtools (which is not installed on my computer) or alternatively with libburn (which, according to dpkg -l is libburn4:amd64 version 1.4.2.pl01-1). In the gentoo-discussion cdrtools enabled xfburn to do the job. Should I try to uninstall libburn and install cdrtools instead? How do I do such an exchange, if libburn also is a necessary part of other applications? Apr 8 '19 at 20:27
  • The message from libburn about SCSI error says that the drive does not like the medium. It is strange that it already took two write operations to block 0 and 16 without error message. Probably other burns got more far so that ISO directory tree was written. a: Yes. Rock Ridge takes care. b: No. c: Other media or other drive. d: Xfburn and libburn only learn from the drive's protest that it hates the medium. Xfburn does not use cdrtools. We could explore further by help of command line tool xorriso. Write to bug-xorriso@gnu.org . When we have results we can report them here. Apr 9 '19 at 8:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.