I manage my music with iTunes (why iTunes?) on a desktop, and I use a Raspberry Pi 3 B+ with a USB harddrive running minidlna as a music media server in my living room. I have weekly script that copies my iTunes folder onto that Raspberry Pi. This makes all my music available, but it doesn't make my playlists available.
There are a few available programs that do a similar task, but none that I found were written in a way that could run without worry on my Raspberry Pi.
This project is written in C and built to run quickly on Linux/Raspberry Pi.
I do not consider this fully tested. I am now running it unattended to create my playlists on the Raspberry Pi that serves as my home media hub and it works for me, which is no substitute for being well tested. What this needs is some other folks to use it with iTunes Music Library XML files of different sizes and playlists.
The following contain the same files, with the same UNIX line endings. These are updated automatically whenever I run 'make install' in my Ubuntu development environment (which has a more permanent link to this web server than my laptop).
Licensed under CDDL 1.0.
To run playlister on Raspbian (or other Debian based distros) requires this package to be installed:
UNIX is UNIX for the most part. Though this is primarily built to run on a Raspberry Pi 3, Playlister was developed on my MacBook Air running macOS Mojave 10.14.6, and first compiled with XCode command line tools. Once the principle program was done and running on macOS, I checked out the code under Raspbian Buster and made the few adjustments. Compiles and tests are verified on:
|macOS||Catalina (see Future)||x86_64|
Details on compiling playlister.
$ ./playlister --help playlister: Version 0.6.45 Extract playlists from iTunes Music Library.xml to m3u License: see --about -c --config Configuration File. --format (m3u|extm3u) m3u format, whether or not to include extended format (not compatible with all players). --verify Verify existance of output (warn/omit if not found). --randomize Randomize m3u ouput. -x --xml <file> iTunes XML file. -r --rempath <path> Original Path in iTunes XML (to remove from output filenames). -n --newpath <path> New Path to prefix on output filenames. -o --output <path> Path to place generated playlists. -X --extension <ext> Playlist extension (defaults to m3u). --nolist Remove all lists (like from a config). -l --list Playlist to include (can use multiple times). -v --verbose More verbose. -q --quiet Less verbose. -h -? --help This help. --about Copyright and License Information
The following shows the search order, using the default executable name.
In the examples above, if playlister were renamed to it2m3u the first thing searched would be $(HOME)/.it2m3u.conf. I called the program Playlister. It compiles as playlister. If you change the name of the compiled file, it will look for a differently named configuration file. That may have been a bad idea, but it is what I did. This can be overridden by simply using the command line option instead. All of these will be checked, even if you supply a full path on the command line.
Sample Configuration file:
# Sample playlister configuration file. itunesxml = /path/to/iTunes/iTunes Music Library.xml output_dir = /path/to/create/m3u/playlists extension = m3u # This is the default setting verify = no # This is the default setting format = m3u # This is the default setting, also support extm3u location_remove = C:\Users\windowsuser\Music\iTunes location_replace = /path/to/iTunes [lists] Downloaded Recently Added
Playlists will only be created for those listed in [lists].
This program compiles and even works on Catalina, however, iTunes no longer works on Catalina. It was replaced by Apple Music. Apple Music can manually output an XML share file, similar to iTunes, but it no longer has the ability to create one on every library change.
I'm looking into the binary file that Apple Music uses for Library management on macOS Catalina. I'm currently in the process of figuring out what is inside that file.
If you download and use this, I want to know about your experience.
Unless this extremely niche use-case blows up, I will reply (unless you specifically ask me not to).