## 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 : )

## Misidentified Problem, Was: Latest ‘libgcrypt’ Update breaks ‘Enigmail’.

This morning, an update installed itself on my Linux computer ‘Phoenix’, that brought the version of my ‘libgcrypt‘ libraries to ‘1.6.3-2+deb8u3‘. This is under Debian / Jessie, a version of Linux. These libraries are supposed to give access to GnuPG encryption capabilities, to certain applications.

Within my ‘Thunderbird’ email client, I have an add-on installed from the package manager, called ‘Enigmail’ (version ‘2:1.8.2-4~deb8u1‘), which gives a full suite of encryption capabilities to my email.

The latest ‘libgcrypt‘ update has broken Enigmail, which was working fine before today.

More specifically, it is no longer possible to encrypt an email to oneself. Being able to do so, is essential for two purposes:

1. When we send an encrypted email to the public key of a contact, we are also asking the software to encrypt the same email to ourselves,
2. The way we may sometimes configure our Drafts folder, is to encrypt any Draft emails saved there, so that we need to enter the passphrase to unlock our Private Key, before we can reopen our Saved, Draft emails. This is a nifty capability, to secure the emails on our hard-drive, before we’ve made the decision to Send them.

(Edit : )

I have identified the true cause of my problem. In order to make this explanation more clear, I should also add that I’ve recently revoked some keys, and created a new, main email-key.

There exists a configuration file for GnuPG, which under Linux systems is stored at:

~/.gnupg/gpg.conf

What can happen is that settings in this file, override whatever settings we choose in our GUI-application, such as with Enigmail, in Thunderbird. More specifically, I had entries which went something like this:


default-key  586A6C0052A087C0
###+++--- GPGConf ---+++###
utf8-strings
encrypt-to 586A6C0052A087C0
keyserver hkp://pool.sks-keyservers.net
###+++--- GPGConf ---+++### Tue 16 Aug 2016 01:42:05 PM EDT
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.



The problem was, that the encrypt-to entry did not at first match my default-key entry, and referred to an old, revoked key. The encrypt-to entry has as effect, that GnuPG will always try to encrypt any messages that are meant for use with hybrid encryption, also to the specified key.

I edited this file manually, to make the two entries equal. I suppose that another way to solve this problem could have been, just to remove the encrypt-to entry…

The reader might wonder, by what sort of black magic that setting got into the configuration file, and, It’s usually not advised for users to edit this file directly, with a text-editor