My MusicBrainz Picard file naming script

MusicBrainz Picard is a free and open-source software application for identifying, tagging, and organizing digital audio recordings. It was developed by the MetaBrainz Foundation, a non-profit company that also operates the MusicBrainz database.

Picard identifies audio files and Compact Discs by comparing either their metadata or their acoustic fingerprints with records in the database. Audio file metadata (or “tags”) are a means for storing information about a recording in the file. When Picard identifies an audio file, it can add new information to it, such as the recording artist, the album title, the record label, and the date of release.[3] In some cases, it can also add more detailed information, such as lists of performers and their instruments. The source of this information is the MusicBrainz database, which is curated by volunteers. The more information the database has about a recording, the more Picard can embed in users’ audio files.

This is my file naming script.

$if($eq(%albumartist%,Various Artists),
[Various Artists],
$left($if2(%albumartistsort%,%artistsort%),1)/$left($rreplace($if2(%albumartistsort%,%artistsort%),; [^\)]+,), 60))
$if(%date%,[$left(%date%,4)] )$left($replace(%album%,/,), 70)
$if($gt(%totaldiscs%,1),$if(%discnumber%, \(Disc %discnumber%\),),)
$num(%tracknumber%,2). $left(%title%,120),[:?"_]+,), , )

SSH/SFTP Rsync backups done with chroot


Rsync, for those who aren’t familiar, is a file copy tool, which, after the first copy, will only send changes during subsequent updates. This makes it a very efficient tool, especially when used over an internet connection.

Anyway, to enable rsync from server A to server B, it is common to perform the login via key. This means that on Server A you’d generate a SSH keypair for your backup user, then copy the public key that was generated into the ~/.ssh/authorized_keys file for your backup user on Server B.

Because rsync is going to be executed automatically via cron script, it is necessary to create the key file without a password.


  • Configure your SSH server
    • Open up /etc/ssh/sshd_config
    • At the end of the file, tell SSH to create a chroot jail for your backup user:
      ChrootDirectory %h
      AllowTcpForwarding no
      PermitTunnel no
      X11Forwarding no

      Note, because of the way chroot works, you’ll need to make sure the chroot directory is owned by ROOT, even if it’s actually the home directory of your backup user.

  • Save, and restart your SSH server.

This gets you part of the way, you should now be able to SSH/SFTP into Server B using your backup user, and when connected, you will be restricted to the location set in ChrootDirectory.

Unfortunately, rsync needs more than this, and in order to copy files it’ll need access to the shell (I’m assuming bash), as well as the rsync application itself, together with whatever libraries are required.

Therefore, it becomes necessary to create a partial chroot image in the backup user’s chroot directory. You could do this the traditional way (e.g. by using something like debootstrap), which will create a mirror of your base operating system files in the chroot jail. However, this generally takes a few hundred megabytes at least, and if all you want is to copy some files, you don’t want to give access to more than you need.

Instead, I opt to create a skeleton chroot jail by hand.

The goal here is to mirror the filesystem of your server inside the chroot jail, so that if a file exists in /foo/bar, then you need to copy it to /home/backup-user/foo/bar, and make sure it’s owned by root.

  • Copy bash from /bin/bash to the directory /home/backup-user/bin/
  • Copy rsync (on my system this was in /usr/bin)
  • Next, you need to copy the symbolic link libraries to which these files are linked against. You can use the tool ldd to interrogate the executable and get a list of files to copy, e.g:
    root@server-b:/home/backup-user# ldd /bin/bash =>  (0x00007fff52bff000) => /lib/x86_64-linux-gnu/ (0x00007f412810a000) => /lib/x86_64-linux-gnu/ (0x00007f4127f06000) => /lib/x86_64-linux-gnu/ (0x00007f4127b79000)
        /lib64/ (0x00007f4128340000)

    Copy the files which have directories into the appropriate locations, e.g./lib/x86_64-linux-gnu/ should go into/home/backup-user/lib/x86_64-linux-gnu/

  • Do the same for /usr/bin/rsync

Moto G (3rd generation)

I ordered the new Moto G. Normally $179, my total was $219 for doubled storage and RAM.

The third generation Moto G (marketed as simply moto g) is an Android smartphone developed by Motorola Mobility, announced on July 28, 2015.

The third generation Moto G has a 5-inch 720p Gorilla Glass 3 display, a 13-megapixel camera similar to the one from the Nexus 6, a quad-core Snapdragon 410 processor, the latest version of Android, the phone back is a removable textured plastic, comes in multiple colors available in Motorola’s Moto Maker and it is water resistant through the use of nano-coating and internal rubber gaskets giving it an IPX7 rating. The low end model comes with 8GB of storage and 1GB of RAM, and the high end model comes with 16GB of storage and 2GB of RAM.

The phone runs near stock Android 5.1 Lollipop. The phone has both a single sim and dual sim variant.