Thank you very much for looking into this, and I'll apologise for having, at best, asymptotically approached the scientific method whilst attempting to burn a set of back-up discs. My first burn used the k3b GUI. I had to install the brandonsnider cdrtools PPA, before it would even start writing to the disc (ref. https://help.ubuntu.com/community/CdDvd/Burning#Blu-Ray_Burning). This burn proceeded at a reasonable speed but, contrary to (my understanding of) my choice of settings, the disc was finalised (complete, not appendable). (OK, my ISO was not much less than the disc capacity and I won't open myself to ridicule by suggesting I mourned this loss. However, the final disc of the set was to be only half full, and I also wanted to take the opportunity to learn the correct technique.) The only interesting result, from dvd+rw-mediainfo on that disc, is that Speed Descriptor#n is 00/12219391 c.f. 00/11826175 on the cdrskin and xorriso burns I reported earlier. (I've no idea what that means and, hence, the compass of “interesting” might be minimal.) From this, I turned to the command line (OK, I first tried to obtain silicon-empire, but it appears to have been pulled) and tried a couple of discs with growisofs, both of which were left in the desired, appendable, state, but at the cost of five to six hours' burning: growisofs -Z /dev/sr0=disc02.iso growisofs -speed=20 -Z /dev/sr0=disc03.iso I'll admit, here, that some/all of my speed requests were ambitious. I'd let myself be guided by the dvd+rw-mediainfo output, and forgotten to check the paper, on the top of the spindle, which said “6x”. So, I then turned to libburn (installing cdrskin & xorriso) : cdrskin dev=/dev/sr0 -v padsize=300k blank=format_if_needed -multi disc04.iso cdrskin dev=/dev/sr0 -v -v padsize=300k gracetime=60 blank=format_if_needed speed=10 --adjust_speed_to_drive -multi disc05.iso xorrecord -v dev=/dev/sr0 speed=26970k fs=8m -multi --grow_overwriteable_iso blank=as_needed padsize=300k disc06.iso And that was where I'd reached when I filed the bug report. (With thanks to ~/.bash_history!) In answer to your other questions: I think the xorriso run did format the disc. The dvd+rw-mediainfo output is very similar to that for the cdrskin disc. (Sorry I did not paste that on the original report.) Reading back the discs seemed fairly fast. I'd checked the md5sums after each burn. I'll capture a more formal metric, if necessary, but I'm confident in saying reading is fine. I haven't tried disabling defect management. That doesn't sound attractive, but I accept it could be a valuable investigative test. I've just tried a DVD-RW 2x, in the drive. Performance seemed consistent with my experience with my DVD writers, and I calculated it as proceeding about twice as quickly as the problem BD-Rs. Subsequent to my posting of the problem report, it did occur to me to check the version details the programs declare (rather than just relying on the package headline): cdrskin --version cdrskin 1.3.8 : limited cdrecord compatibility wrapper for libburn Cdrecord 2.01a27 Emulation. Copyright (C) 2006-2014, see libburnia-project.org System adapter : internal GNU/Linux SG_IO adapter sg-linux libburn interface : 1.3.8 libburn in use : 1.3.8 cdrskin version : 1.3.8 Version timestamp : 2014.06.28.060001 Build timestamp : -none-given- xorrecord --version xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project. Cdrecord 2.01-Emulation Copyright (C) 2013 see libburnia-project.org xorriso xorriso 1.3.2 ISO 9660 Rock Ridge filesystem manipulator and CD/DVD/BD burn program Copyright (C) 2013, Thomas Schmitt <…@gmx.net>, libburnia project. xorriso version : 1.3.2 Version timestamp : 2013.08.07.110001 Build timestamp : -none-given- libisofs in use : 1.3.8 (min. 1.3.6) libjte in use : 1.0.0 (min. 1.0.0) libburn in use : 1.3.8 (min. 1.3.4) libburn OS adapter: internal GNU/Linux SG_IO adapter sg-linux libisoburn in use : 1.3.2 (min. 1.3.2) Provided under GNU GPL version 2 or later. There is NO WARRANTY, to the extent permitted by law. libisoburn is rather stale, but the change log does not show anything pertinent to my problem as having subsequently been addressed. (Also, cdrskin --version did not mention that library, which could truly take it out of the equation.) I will insert the balance of the output I captured, as separate “comments”, in the belief this will aid navigation. Thank you very much, once again.