How To Burn Blu-ray Movies using Linux – via the GUI

One project which I had half-installed on my laptop named ‘Klystron’ some time ago, but which was not working, was software that would make the task straightforward to carry out, to burn Blu-ray movies from a Linux computer. Because I finally wanted to get that working, I spent time on this in-depth today.

One fact which many people understand, but few people know how to manage, is that Blu-ray movies are not supposed to be burned using the ISO9660 File-System, nor, with the .ISO-Files typically associated with that FS, that store its images. Technically, Blu-ray movies are supposed to be burned using a File-System called ‘UDF’, and version 2.50 of that preferably. Under certain circumstances, v2.01 of UDF may have to suffice, since Linux support for v2.50 is still lagging.

(Edit 10/19/2017 :

I suppose that one detail which I should have included all along, is that I was doing this on a Debian / Jessie system, which is also known as Debian 8. This is also known as the ‘oldstable’ version of Debian now, just because of technological progress. Therefore, Debian 8 was unable to do certain things, which Debian 9 can do out-of-the-box.

I will explain below, why The patch which I described in this posting, should not be undertaken on a Debian / Stretch system, which is also known as Debian 9, and which would be the up-to-date version of Debian as I’m writing this. )

I will spare the reader a lengthy account of what did not work. In order for this to work, I needed to have the Debian Multimedia Repository installed in my /etc/apt/sources.list , which should be straightforward for other people to duplicate. And my main purpose in having this repository, was to get the package ‘tsmuxergui’, version 2.6.11 . In addition, I was working with ‘K3b’ , v2.0.2 .


‘tsmuxergui’ is a GUI-front-end for ‘tsMuxer’, which is a program that can be used to set up Chapters and other playback details, as well as the 1920×1080, H.264-compressed video files of course, that are supposed to make up the program on the final Blu-ray.


As my burner, I used the external ‘Pioneer BDR-XD05′, that connects via USB 3.

There is one additional component which I needed, before K3b was willing and able to burn the UDF File System required, which it is not able to do out-of-the-box:

An out-of-tree version of ‘cdrecord’ , v3.02a7

According to its authors, the versions of cdrecord that have been placed in the standard repositories belongs to ‘cdrkit’, not ‘cdrtools’, and cdrkit fails to provide the back-end, which K3b would need to burn UDF. Yet, to try to perform a binary install of the out-of-tree version, would have been very dangerous to my system. So what I did, and what I would urge other people to do, is to use one of the source-code (tarballs) from above.

First, if the reader has ‘wodim’ installed from the package-manager, I would recommend uninstalling that, just to make sure that package-version-binaries are not overwritten by the out-of-tree versions. Then, I used the above source-code, to custom-compile ‘cdrtools’.

(Edit 10/19/2017 :

If the reader is using Debian / Stretch. aka Debian 9, then the above precaution should fail. The reason for this is the fact, that under Debian / Stretch, K3b depends on ‘wodim’. Therefore, telling the package-manager to uninstall ‘wodim’, will most probably also cause the uninstallation of ‘K3b’.

Now, I can think of several reasons for which Debian Maintainers might have made K3b to depend on ‘wodim’ in Debian Stretch. One possibility, is that they might just not like this patch being applied.

But it seems to be confirmed to me – according to this test – that under Debian / Stretch, K3b is able to burn UDF / Blu-ray File-Systems out-of-the-box. And what that would mean is that to apply this patch is neither required nor desired. )

The nice feature about this version, is that it does not even install itself to ‘/usr/local/bin’. Instead, it installs its binaries to ‘/opt/schily/bin’ , when we finally give the command ‘make install’ with root privileges, so that the ultimate risk of messing up the system is small.

(Updated 10/23/2017 : )


So once we have the required software installed, the work-flow to burning a Movie-Blu-ray is as follows:

  • Verify that K3b 2.0.2 recognizes the directory with the special ‘cdrtools’, and that it offers their use as a potential default, by checking “Settings” -> “Configure K3b” -> “Programs”. By default, it will already have Schily’s directory listed in its search-path, which I find convenient, because that way, if I’m to share my laptop with other users, those users will not have to do any special configuring to get their K3b to work.
  • Use ‘tsMuxer’ to create a folder of sub-folders, that will include ‘BDMV’ and ‘CERTIFICATES’, that will contain our movie-project.
  • With our Blu-ray burner connected, fire up K3b, and select ‘New Data-Project’. Name the volume as desired.
  • Add the sub-folders named above to the root folder of our project.
  • In the settings within K3b, after we click to open the ‘Burn’ dialog, choose the UDF File-System explicitly in the ‘File-System’ tab, as well as to go to the final tab, and to make sure we do not burn a Multi-Session Disk. Leave the back-end to ‘Auto’.
  • Burn.



One detail in this undertaking which had me frustrated, was that K3b would generally display that it was starting a new Blu-ray disk, using ISO9660, even if it was using the package-provided ‘cdrecord’ as its Writing App. I can finally tell that it is using UDF, through its progress dialog now being changed slightly, and through it automatically telling me that it is burning using ‘CDRecord‘, and not, using ‘GrowISOFS’. As the naming might suggest, ‘GrowISOFS’ will only grow an ISO FS, and in my configuration, is still located in the directory ‘/usr/bin’, where the package-manager left it.

After that, I was able not only to play my movie on my dedicated Blu-ray player, but also to mount this disc, and then to do the following:

  • In a command-console, as user, navigate to the ‘/dev’ directory, and give the command:
  • ‘df -T sr1′

Where ‘/dev/sr1′ is the name of the external burner. As long as the disc is mounted, my command-line tells me that it is of a UDF File-System Type.

(Edit 10/23/2017 :

One fact which I have learned, after setting up this version of ‘cdrtools’ to work with ‘K3b’, is that specifically when used to burn a Video-DVD, ‘mkisofs’ builds a hybrid file system, that starts out as an ISO File System, but to which – in this scenario – only UDF content is added.

What this means in practice, is that the UDF Version compliance will not be very strict. There might be a version-number embedded (1.02) , but customized behavior when adding files. Therefore, since I have already written shell-scripts that use the package ‘udftools’, and that are capable of growing and then burning strict version 2.01 file systems, those may continue to have some advantage to me in the future.

It can just be more fun sometimes, to use the GUI.

This also means that the ‘CDRecord’ utility in question is only capable of adding files, to the file system which the bundled ‘mkisofs’ has created.

More recently I have been able to pinpoint, that when this configuration is used to burn a Data Project, which has been set to Type UDF, ‘cdrecord’ will burn a satisfactory v1.50 File System. )

I do know that the movie plays on my Blu-ray playback-device.

There is another way to use ‘tsMuxer’, by telling it to output what it calls ‘a Blu-ray ISO File’. This also works, but not with K3b. The resulting file-name will have the .ISO extension, but will actually be a .UDF File-System Image, which K3b does not know how to open. I was able to burn that so-called .ISO File, by using a shell-script. And its resulting Blu-ray also played fine, on my playback-device.

Note: Another detail which has slowed down my own pursuit of a solution, is that If we simply tell K3b via the GUI, to burn a DVD, but to burn it using UDF, then K3b just ignores this setting. In that situation, K3b decides for us that when it comes to the older-format DVDs, ISO9660 is the standard to be used. The majority of DVDs are burned with ISO.

There’s some possibility however, that if I simply select the Writing App to be ‘cdrecord’ now, instead of ‘Auto’, I may be able to override that…

When I decided to burn a Data-DVD using UDF ( v2.01 ) several weeks ago, again I needed to use a special shell-script…

(Edit 10/23/2017 :

One observation I’ve made about this type of project in practice, through tests, is that a Video-Blu-ray disk can result, which our own Linux computer’s customary applications can no longer play back, but which does play properly on a Standalone Playback-Device – i.e. which still plays fine on my Sony.

Because any serious author of Blu-ray content would want to preview the disks he created, on the Linux computer he used to create them, I would draw the reader’s attention to This latest observation, on how this can be achieved. )


(Edit :

I believe that the use of UDF for Blu-ray disks also needs to be seen in a differing context. This file-system was once meant to be used for DVD-RAMs. These were optical storage disks which acted as ‘an extended hard drive’ for a computer – back in the days when optical discs still tended to offer greater capacity than (magnetic) hard drives. We could just use those as an external HD, also in a time when we didn’t have USB-keys.


What this meant was that the DVD-RAM would be accessed, written to and read, in turn, by numerous computers. For this reason it was important that these disks has a sophisticated file system.

Under Linux, users were not expected to burn them per se with special software, but also, like Windows users, just to insert them into compatible DVD-drives, and access them at random. It was the responsibility of the kernel to be able to mount them. However, when we typically bought them from the store, they weren’t formatted. So some Linux users were advised at the time, only to use K3b to format them.

! Better advice would be to use ‘mkudffs’ from the command-line.

When UDF gets used to store video information statically, one important fact changes: Suddenly, they will be formatted, and written to within a short space of time, by a small group of connected programs – all running on one computer. After that, other computers are expected to read them, but no longer to modify their contents. UDF has been downgraded, to a file system for write-once, read-mostly storage.

For that reason, the strict compliance with a specific standard, should not be as important as it once was. The fact that ‘CDRecord’ is suddenly only able to write data once, to an FS that was formatted with ‘mkisofs’, when both programs belong to the same package: ‘CDRTools’, is not a big problem. The only real issue that comes next, is whether every computer / media-player / gaming station, can read those disks as intended.

At that point it also becomes easy for the programmers of the burning-software just to say, ‘We only use a subset of the features. But what we use works.’ If these were DVD-RAMs, then the other computer could suddenly start to use features, which the present computer neglected to implement. The other computer could write changes to the DVD-RAM, which the present computer stated it had the version-number for, but which maybe it cannot read. )

(Edit 10/13/2017 : )

I had a nagging doubt, about whether the present configuration would still allow me to burn legacy ISO9660-File-System disks. And so I carried out another test.

In theory, what the reconfigured K3b-setup does, is to use ‘mkisofs’ every time, in order to create the initial, empty File-System, regardless of whether we want an ISO or a UDF File-System grown. Then, depending on how we set up the Burning Preferences, either ‘cdrecord’ or ‘growisofs’ will be used to populate that FS with our data, where ‘growisofs’ has remained as the package-version on my system. In my case, the GUI will actually choose ‘cdrecord’ by default.

What could go wrong here, is that ‘mkisofs’ could always create a hybrid file-system, ignoring my other settings, and then to give the command:

  • ‘df -T /dev/sr0′

Would always indicate a UDF-type file-system, because that Linux command will always state the maximum of the two capabilities, even if my intent had been to grow ISO content only.

So what my latest test consisted of, was to use the same configuration of K3b that my posting describes, but to burn a Data-DVD, and to set the Burning Preferences to “Linux + Windows” (i.e., not UDF) , and to set the back-end to ‘growisofs’. The result was, that once I mounted the DVD+R that I just burned, and gave the above command, it revealed that the File-System-type was truly ‘iso9660′, not ‘udf’ (even though it had been created with ‘mkisofs’.

And so while it is possible, that ‘cdrecord’ as a back-end will always grow a UDF File-System using its own, internal preferences, we can actually override that by specifying that we want our FS grown with ‘growisofs’ instead, which will never grow a UDF…

What this means, is that I did not, after all, give any reader of this blog poor advice.

(Edit 02/08/2018 : )

I thought that I should write a detail down, which one commenter mentioned in passing, because it became a stumbling-block for him.

‘tsMuxer’ under Debian, is only available as a 32-bit application, from the Debian / Multimedia repository. What I have myself, is 64-bit Debian computers, which have 32-bit support. This is due to a feature called ‘Multiarch’, which stands for Multi-Architecture support, which my systems have enabled by default because they all started out as ‘Kanotix’ systems.

Depending on how determined some users are, to get ‘tsMuxer’ working, although they may be using 64-bit systems too, one possible way to go, could be to enable this feature.

For Debian specifically, these is a WiKi-entry which explains how to do that.

An attitude which many people take is: ‘Allow these scripts and package-managers to do their jobs; after waiting for a few minutes, we’ll have our Multiarch systems set up.’ If my own PCs and laptops had not been Multiarch-capable from the start, I’d possibly have been too skittish to make this transition myself.

The reason for which such a job would intimidate me, is the fact that with this feature set-up, there are essentially three places where the file-system will store its (package-installed) libraries:

  • /usr/lib
  • /lib/x86_64-linux-gnu
  • /lib/i386-linux-gnu

So, the first location will be for libraries, which are platform-agnostic, while the next two will be for platform-differentiated libraries. If we enable Multiarch-support, we are telling our computers to move specific libraries, and sometimes, even to create symlinks. Depending on how cautious the user is, the fear may seem more important, that the power could fail, while this is happening. And if there is any risk of that, then maybe, the way to go might be without this little package, named ‘tsmuxer:i386′ ?

Also, the link above is for Debian. For Fedora systems etc., the reader will need to Google the subject.



Print Friendly, PDF & Email

15 thoughts on “How To Burn Blu-ray Movies using Linux – via the GUI”

  1. I’m on Ubuntu 16.04.03. I followed your guide. I still get the error that it cancels the burn and the message says maybe I should specify a slower speed. It’s a BD-RE and it says it formats it when I try to burn. Here’s the K3B debug log:

    WD Virtual CD 1130 1008 (/dev/sr2, CD-ROM) [CD-ROM] [None] [%7]
    HL-DT-ST DVD-RAM GH22LP21 1.00 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL) [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump] [%7]
    ATAPI iHBS212 2 5L06 (/dev/sr1, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, BD-ROM, BD-R, BD-RE, DVD+R, DVD+RW, DVD+R DL) [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW, BD-ROM, BD-R Sequential (SRM), BD-R Random (RRM), BD-RE] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump, Random Recording, Sequential Recording, Sequential Recording + POW] [%7]

    mkisofs print size result: 12108517 (24798242816 bytes)

    K3b Version: 2.0.3
    KDE Version: 4.14.16
    QT Version: 4.8.7
    Kernel: 4.10.0-28-lowlatency

    Used versions
    mkisofs: 3.2a09
    cdrecord: 3.2a09

    scsidev: ‘/dev/sr1′
    devname: ‘/dev/sr1′
    scsibus: -2 target: -2 lun: -2
    Warning: Open by ‘devname’ is unintentional and not supported.
    Linux sg driver version: 3.5.27
    SCSI buffer size: 64512
    cdrecord: Warning: Cannot read drive buffer.
    cdrecord: Warning: The DMA speed test has been skipped.
    Cdrecord-ProDVD-ProBD-Clone 3.02a09 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2016 Joerg Schilling
    TOC Type: 3 = CD-ROM XA mode 2
    Using libscg version ‘schily-0.9′.
    Driveropts: ‘burnfree’
    atapi: 1
    Device type : Removable CD-ROM
    Version : 5
    Response Format: 2
    Capabilities :
    Vendor_info : ‘ATAPI ‘
    Identifikation : ‘iHBS212 2 ‘
    Revision : ‘5L06′
    Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
    Current: BD-RE
    Profile: BD-RE (current)
    Profile: BD-R random recording
    Profile: BD-R sequential recording
    Profile: BD-ROM
    Profile: DVD+R/DL
    Profile: DVD+R
    Profile: DVD+RW
    Profile: DVD-R/DL layer jump recording
    Profile: DVD-R/DL sequential recording
    Profile: DVD-RW sequential recording
    Profile: DVD-RW restricted overwrite
    Profile: DVD-RAM
    Profile: DVD-R sequential recording
    Profile: DVD-ROM
    Profile: CD-RW
    Profile: CD-R
    Profile: CD-ROM
    Profile: Removable Disk (current)
    Using generic SCSI-3/mmc-3 BD-RE driver (mmc_bdre).
    Supported modes: PACKET SAO LAYER_JUMP
    Drive buf size : 5898240 = 5760 KB
    FIFO size : 4194304 = 4096 KB
    Track 01: data 23649 MB
    Total size: 23649 MB = 12108517 sectors
    Current Secsize: 0
    Capacity Blklen/Sparesz. Format-type Type
    12219392 20480 0x00 Unformated or Blank Media
    11826176 12288 0x00 Reserved (0)
    11564032 2048 0x01 Reserved (0)
    11826176 12288 0x30 Reserved (0)
    11564032 20480 0x30 Reserved (0)
    12088320 4096 0x30 Reserved (0)
    12219392 2048 0x31 Reserved (0)
    Format was needed.
    Starting to write CD/DVD/BD at speed 1 in real FORMAT mode for single session.
    Last chance to quit, starting real write in 3 seconds.
    2 seconds.
    1 seconds.
    0 seconds. Operation starts.
    Formatting media
    operation 0% done
    operation 24% done
    operation 49% done
    === last message repeated 100 times. ===
    Formatting time: 205.991s (00:03:25.991)
    cdrecord: Disk capacity is unknown.
    cdrecord: Data will not fit on any CD.
    cdrecord: DVD/BD capacity is unknown.
    cdrecord: Cannot write more than remaining DVD/BD capacity.

    cdrecord command:
    /opt/schily/bin/cdrecord -v gracetime=2 dev=/dev/sr1 speed=1 -sao driveropts=burnfree -xa -tsize=12108517s –

    mkisofs: Warning: Cannot add inode hints with -no-cache-inodes.
    === last message repeated 2 times. ===
    Setting input-charset to ‘UTF-8′ from locale.

    mkisofs calculate size command:
    /opt/schily/bin/mkisofs -gui -graft-points -print-size -quiet -volid BlueRayTest -volset -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher -preparer -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-don/k3bTP8534.tmp -rational-rock -hide-list /tmp/kde-don/k3bRJ8534.tmp -no-cache-inodes -udf -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-don/k3bwy8534.tmp

    mkisofs command:
    /opt/schily/bin/mkisofs -gui -graft-points -volid BlueRayTest -volset -appid K3B THE CD KREATOR (C) 1998-2010 SEBASTIAN TRUEG AND MICHAL MALEK -publisher -preparer -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-don/k3bBQ8534.tmp -rational-rock -hide-list /tmp/kde-don/k3bVm8534.tmp -no-cache-inodes -udf -full-iso9660-filenames -iso-level 3 -path-list /tmp/kde-don/k3buF8534.tmp

    1. I sympathize with your problem. But I do see one problem out of the debug logs:

      cdrecord: Disk capacity is unknown.

      Before I set out to burn any BD, I do inspect the GUI, to see if it displays the disk capacity correctly. If not, there is no point in continuing. Is it possible that your kernel-version just fails to read the burner properly?

      And, please check the permission-bits of ‘/dev/sr1′ . Yours also looks like an external burner. If it is somehow creating a device-node, which user-space does not have permission to write to, then all your attempts to burn from the GUI will also fail…


      1. Could it be that something is having a problem with BD-RE disks? UDFINFO says there is no medium in the drive. K3B says there is no medium in the drive. But there is. I don’t have any regular BD-R disks right now to test it, but I’ll let you know how it works when I get some.

        1. I think you may have found the problem. To the best of my knowledge, ‘Rewritable Blu-Ray Discs’ are a special technology. I don’t know whether Linux software can handle them. Are you sure your burner can? In any case, I hope you didn’t blow a whole stack of (expensive) BD-RE blanks…


        2. At first I didn’t know what BD-RE stands for, because the industry is constantly inventing new acronyms. My own burner states that it can read double-layered Blu-Ray disks, and its manual doesn’t state whether it can also burn other formats. So for burning, I stick to single-layered – write-once – disks. Some of the fancier formats may entail compatibility problems, especially since Linux is a free and open-source platform, and since commercial software can afford to pay serious money to its programmers, specifically to support BD-RE, for example.


        3. I got a bunch of BD-R discs. Got an error that says invalid function. Tried to burn a DVD it failed the same way. I concluded my drive went bad. Got a new one. This time with BDXL and M-disk support. Burnt a Blu-ray successfully. I’m thinking it’s all fixed now. BTW, your blog is excellent!

  2. I thank you for putting to words your easy to follow, step by step and thought by thought process. Using your outline, I was able to get my Fedora 27 system to create a UDF blue ray video that was playable on my old Samsung player.
    I found that since your experience, or perhaps because I use Fedora, the cdrecord version from my distro was in fact 3.2a07. I did learn that the tsMuxer program is only to be had as a 32bit application which I can’t use on my system. I was able to simply burn an mkv video over to the disk however. While this is less than optimal (no menus, no chapters), it does work in my player and that’s enough for now. Some folks indicated that Handbrake would do the job, but I was not able to figure out how that might work for the purpose at hand.

    It was your description on how to use K3B to select the UDF file system that was key to making a usable copy for me.

    1. I’m happy to hear, that you were able to burn a UDF File System. Further, I did know that ‘tsMuxer’ is only to be had as a 32-bit package. Yet, the way my packages are installed, certain dependencies are already installed on my machine, both as 64-bit and as 32-bit libraries, for which I reason I can also install ‘tsMuxer’. But, I do see a drawback to your solution.

      Normally, a Blu-ray Video DVD is supposed to have at least the following folders in its root folder: ‘BDMV’ and ‘CERTIFICATE’. This is similar to how a Video-DVD is supposed to have the folders ‘VIDEO_TS’ and ‘AUDIO_TS’, with specific files. The fact that your Samsung player was willing to play your Data-Blu-ray, would be similar to how it might just play any video you store, let’s say on a USB-Stick, or, again, on a Disk of your choosing. The problem with that is, that some players are much more picky about what sorts of discs they will play.

      Anyway, it would not be something that tsMuxer can do anyway, to add Disc Menus etc.. tsMuxer is only supposed to set up that folder-system, to try to convince a choosier disk player that indeed, it has been given a Video-Blu-ray, and not a Data-Blu-ray…


  3. While I still created a BD-R mobile, wanted to say many thanks. With wodim not previously installed, and using Platform Version 4.14.16 of K3B, in addition to your info and specs, it was also necessary to enable “advanced GUI elements”, and to specify “cdrecord” as writing app under writing tab prior to burning to get a BD player recognised disc.

    Mkvmerge, Handbrake, tsMuxeR, and K3B, completely 100% Linux and gui.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>