Thinking of moving to a container for my main / ‘production’ beets instance. In theory it will be easier to move it between servers / devices, and allow it to play nice with other stuff on my NAS (similar to a python virtualenv).
Anyone have thoughts? Anyone using it currently? Looks like linuxserver is the only one actively supported.
Configuration looks simple enough:
I currently use a container with a custom Dockerfile for running beets on my NAS (easier than installing Python and a bunch of other dependencies). It probably doesn’t use many (or any) of the best practices when working with Docker but it suits my needs pretty well.
FROM alpine:3.15.0
RUN \
apk add --no-cache --virtual build \
g++=10.3.1_git20211027-r0 \
make=4.3-r0 && \
wget -q "http://downloads.sourceforge.net/mp3val/mp3val-0.1.8-src.tar.gz" -P /tmp && \
echo "95a16efe3c352bb31d23d68ee5cb8bb8ebd9868d3dcf0d84c96864f80c31c39f /tmp/mp3val-0.1.8-src.tar.gz" | sha256sum -c && \
tar xf /tmp/mp3val-0.1.8-src.tar.gz -C /tmp && \
rm /tmp/mp3val-0.1.8-src.tar.gz && \
cd /tmp/mp3val-0.1.8-src && \
make -f Makefile.linux && \
mv mp3val /usr/local/bin/mp3val && \
cd && \
rm -rf /tmp/mp3val-0.1.8-src && \
apk del build
RUN \
wget http://ftp.acousticbrainz.org/pub/acousticbrainz/essentia-extractor-v2.1_beta2-linux-x86_64.tar.gz -P /tmp && \
echo "d9902aadac4f442992877945da2a6fe8d6ea6b0de314ca8ac0c28dc5f253f7d8 /tmp/essentia-extractor-v2.1_beta2-linux-x86_64.tar.gz" | sha256sum -c && \
tar xf /tmp/essentia-extractor-v2.1_beta2-linux-x86_64.tar.gz -C /tmp && \
rm /tmp/essentia-extractor-v2.1_beta2-linux-x86_64.tar.gz && \
mv /tmp/streaming_extractor_music /usr/local/bin/streaming_extractor_music
RUN \
apk add --no-cache \
ffmpeg=4.4.1-r2 \
flac=1.3.3-r0 \
imagemagick=7.1.0.16-r0 \
py3-pip=20.3.4-r1 \
python3=3.9.7-r4 && \
apk add --no-cache --virtual build \
g++=10.3.1_git20211027-r0 \
jpeg-dev=9d-r1 \
musl-dev=1.2.2-r7 \
python3-dev=3.9.7-r4 \
zlib-dev=1.2.11-r3 && \
pip3 install \
beets==1.6.0 \
beets[absubmit]==1.6.0 \
beets[fetchart]==1.6.0 \
beets[embedart]==1.6.0 \
beets[import]==1.6.0 \
beets[lastgenre]==1.6.0 && \
apk del build
To spin this up I have a little wrapper script called beet.sh:
#!/bin/bash
ID=$(docker build -qt beets .) || exit $?
docker run \
--env BEETSDIR=/music/Music/.beets \
--rm \
--tty \
--interactive \
--volume /mnt/user/music:/music \
"$ID" \
beet "$@"
This allows me to just do ./beet.sh import /music/To\ Import without having to worry about messing with docker every time I run beets. This script could probably be improved somewhat in its volume mapping behaviour (maybe mapping the current working directory or doing something clever with argument parsing?), but it works well for my needs.
For context, my setup is that /mnt/user/music/Music contains my music library, with the configuration living at /mnt/user/music/Music/.beets. I’ve also got directory set in my beets configuration so that it points to /music/Music in the container.
I’ve found that --tty doesn’t play nice with piping output into other tools. Here’s an updated version of the script which omits --tty if output is not a terminal:
#!/bin/bash
ID=$(docker build -qt beets .) || exit $?
ARGS=(
--env BEETSDIR=/music/Music/.beets
--rm
--interactive
--volume /mnt/user/music:/music
)
if [ -t 1 ]; then
ARGS+=(--tty)
fi
ARGS+=(
"$ID"
beet
"$@"
)
docker run "${ARGS[@]}"
I’m using the container from linuxserver.io.
It makes it’s work pretty well and the mounting is already done.
The config.yaml is easy to edit as it gets mounted in the host.
So I just can recommend it.
Especially, the implementation of the web interface is pretty easy if you’re using docker and a reverse proxy as traefik.