If we have to jettison our physical CD's and DVD's in the name of space, we unfortunately must back them up first. At that point, we lose the convenience of...
- easy playback (pull the CD/DVD off the shelf, put it in a player, and press 'play')
- in lieu of pressing 'play' in a player, how do we play an entire set of MP3's from a CD with a single click?
- global selection is lost (how do we easily observe our entire collection of CD's/DVD's, as we used to on on a shelf?)
- the portability of a bookshelf CD player is gone, and we now require a device with an interface to select and play the music
solution
Turns-out that 1, 2, and 4 are related questions. We can create an M3U for each CD (not a trivial task), then create an HTML page with hyperlinks to the M3U's. So when we click the HTML link from our browser, the M3U is opened by the default application (eg. VLC) which plays the CD's MP3's in the order they used to be on the CD.
This fundamentally solves problems 1 and 2. And since HTML pages open on nearly any device with a web browser, we have a good start on solving problem 4.
To solve problem 3, perhaps we can also eventually add thumbnails -- a thumbnail for each CD -- to our HTML page, and then embed an M3U link into the thumbnail: see a thumbnail for a CD, click the thumbnail. Since we can place infinite thumbnails on an HTML page, we can likely see our entire collection on a single webpage. At that point, we'd only need to consider what device and speakers to connect, the hardware.
This is a fairly simple schema, and attainable, but it's a significant investment of work: we must create an intuitive HTML page, and multiple M3U's. The CD's song order and file locations cannot be determined by the application (eg, VLC) without an M3U, so an individual M3U must be created for each CD, and for any mixes.
nested additional problem
We want to open our HTML file in a browser to click on a link to the CD's M3U. However links to M3U's have no default application and thus do not natively work when clicked in browsers. So now our job is two-fold.
- We must create functional M3U files
- We must configure our browser or OS to make hyperlinks to M3U's click-to-play. That is, we must associate an application with the HTML link. The OS uses XDG to manage these associations.
xdg 'desktop' files
The XDG system is a script which connects file types and applications. Suppose our browser is Chromium and we click on a website link to a PDF. Chromium makes a call to the XDG system (xdg-open). If we've registered an app for our PDF fileswith XDG, the application (eg. Evince) opens the PDF.
It's a chain, so if we haven't registered a default for PDF's in XDG, Chromium's call to XDG produces no information. In these circumstances, Chromium simply downloads the PDF. XDG itself has its own files and file types with which it makes these connections. We'll configure XDG to connect the M3U to VLC, the same way it connects a PDF to Evince.
This seems simple, but later we will find out that Chromium refuses to open M3U's even when XDG is properly configured for it. See "troubleshooting" further down the page.
m3u xdg registration
Our clickable schema depends on M3U's being played from the browser. However, XDG does not typically have a default application for M3U's. Until we configure one, browsers that contact XDG get no information. As noted above, browsers typically just download the M3U file. In order for the browser to process a click on an M3U hyperlink (without downloading), we must create an association between M3U's and an application. XDG manages this.
add a file type (arch) scroll down to xdg-open and perl-mime-types. Perl mime types is straightforward, and this worked IME. informative arch page. see also their additional page.
add a file type (stack) add an existing file type.
add a file type (stack) the most thorough description. Includes syntax for any file type.
add a file type (superuser) another method, slightly more superficial, for existing file types. Create a desktop file then add to mimeapps.list or run xdg-register.
add a file type (askubuntu) have an existing file type and need to associate it with an application.
list of associations (unix exchange) how to get a list of default file apps.
configure m3u
Verify M3U is already defined within the XDG system.
$ xdg-mime query filetype foo.m3u
m3u: audio/x-mpegurl
...or...
# pacman -S perl-mime-types [incl mimetype]
$ mimetype foo.m3u
m3u: audio/x-mpegurl
...then, to associate it to vlc, or whatever player....
$ mimeopen -d foo.m3u
...verify that (in this example) vlc was associated with it...
$ xdg-mime query default audio/x-mpegurl
vlc.desktop
# update-desktop-database
# update-mime-database
...or...
$ update-mime-database ~/.local/share/mime
verify file opens natively via xdg
$ xdg-open foo.m3u
it should open with vlc.
thumbnails
We need thumnails of CD insert/booklet art for our omnibus music page. Imagemagick is our friend for processing an entire directory of photos to provide us with thumgnails. NB: not sure which of its commands is destructive or additive resize, mogrify, or convert.
$ mogrify -format gif -path /home/foo/thumbs -thumbnail 100x100 *.jpg
troubleshooting
1. M3U access through browser
Install a browser such as Falkon which respects XDG settings for M3U's
Chromium will not open an M3U. Probably a DMCA protection, since M3U's can be built to do streaming, not simply play local files the way I use them. Priority (top of foodchain) is supposed to be the ~/.config/mimeapps.list, but Chromium does not honor any XDG M3U settings or files.
IME, the simplest, fastest solution to this Chromium problem is to install a browser such as Falkon, which respects xdg-open settings. For our music schema to work, we need a browser to open our HTML files.
$ cat .config/mimeapps.list
[Added Associations]
application/pdf=org.gnome.Evince.desktop;
image/jpeg=geeqie.desktop;
text/plain=org.gnome.gedit.desktop;
image/png=geeqie.desktop;
image/gif=vlc.desktop;geeqie.desktop;
video/mp4=xplayer.desktop;
video/mpeg=xplayer.desktop;
application/octet-stream=org.gnome.gedit.desktop;
[Default Applications]
application/pdf=org.gnome.Evince.desktop
image/jpeg=geeqie.desktop
text/plain=org.gnome.gedit.desktop
image/png=geeqie.desktop
image/gif=geeqie.desktop
video/mp4=xplayer.desktop
video/mpeg=xplayer.desktop
audio/x-mpegurl=vlc.desktop;
2. browser path requirements lead to permanent mount point naming
Create a mountpoint and identical /etc/fstab entry. Put it on all devices that need access to USB external drive. All links in our music setup will use these links.
Seems impossible but, when a browser opens an HTML page, the links to M3U's cannot be just the file, eg. "foo.m3u", even if the M3U is in the same folder with the HTML file. We're not used to this. HTML files easily display photos in the same directory or in a subfolder such as 'images'. But for the M3U to open, it must be called with the complete path to the file starting from its mount point eg, "/run/media/[USER]/[LABEL]/music/foo.m3u".
This poses a problem for the user. Each computer has a different username, and the "run" mountpoint is temporary. Gvfs or fusermount inserts the USER and partition LABEL when it mounts the drive, eg, /run/media/[USER]/[LABEL]/. But we can't change the HTML links to our 100+ M3U files every time we mount the USB back-up drive in a different system.
To pass the environmental variable of '$USER' into our URL is also not easy due to security problems with URL's on non-local systems that connect to internet. I tried USER, $USER, %USER%, 'USER', '$USER', '%USER%', `USER`, `$USER`, and `%USER%`. None worked.
To obtain USER, we simply whoami or a larger list of environmental variables with printenv. To determine LABEL, we can of course use 'lsblk', or the more complete...
$ lsblk -o name,mountpoint,label,size,uuid
The next level is a udev rule or fstab configuration that I would place on any machine I use with the backup drive. But GVFS is extremely powerful and udev, fstab, etc may only unreliably/unpredictably override GVFS.
I decided to try an fstab addition since this post (scroll down) made it seem the simplest solution. If I had done the udev rule, the persistent naming setup would have been from kernel detection.
In either case, we basically want to override gvfs when the UUID or LABEL of the backup USB is detected. Unfortunately, we will never be sure GVFS might be fickle on some system and disallow being overriden by /etc/fstab. But we must attempt it, otherwise we cannot use HTML and a browser to manage the media collection. The process is from this post.
- Create a permanent mount point. "run/media" is a temporary file system used by GVFS. I decided to create /mnt/[label], where 'label' is the label of the partition. In this case...
# mkdir -p /mnt/bigdata
- update /etc/fstab, then do systemctl daemon-reload
# nano /etc/fstab
# UUID=ba60a72e-0db3-4a5f-bea5-c3be0e04cda1 LABEL=bigdata
UUID=ba60a72e-0db3-4a5f-bea5-c3be0e04cda1 /mnt/bigdata xfs rw,auto,user 0 0
# systemctl daemon reload
# mount -a - With the "mount all", the device should load and at that directory with proper permissions. We can verify...
$ cat /etc/mtab
...and of course try a test write and erase to the drive to verify user permissions.
/dev/sdd1 /mnt/bigdata xfs rw,nosuid,nodev,noexec,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0 - Now whenever we create a hyperlink in our music oversight HTML file, we can use a persisting, cross-platform, link. Eg, for the M3U, we might have an address of /mnt/bigdata/foo.m3u in the link. If we connect to any other systems, 1) create /mnt/bigdata, and 2) modify their fstab. All links to music and M3U's in our HTML page should then work.
- The USB drive will *not* appear in our temporary drive list in our file manager. We'll have to navigate to /mnt/bigdata to see or edit the drive's contents.
