Hi,
name: jellytunes
description: >
Desktop app that syncs a music library from a self-hosted Jellyfin server onto portable
playback devices: MP3 players, USB drives and SD cards. The user picks artists, albums,
playlists or genres on the server and a destination device; JellyTunes downloads the tracks,
converts formats where needed (FLAC to MP3), embeds lyrics and cover art, and mirrors the
server's folder layout onto the device.
snapcraft: https://github.com/orainlabs/jellytunes/blob/main/package.json
(the snap is packaged with electron-builder, so snapcraft.yaml is generated at build time
from the build.snapcraft.core24 key of package.json rather than checked in)
upstream: https://github.com/orainlabs/jellytunes
upstream-relation: >
Publisher is upstream. I develop JellyTunes and I publish the snap. It is built from that
repository in CI, under GPL-3.0-or-later, with no third-party repackaging involved.
plugs:
removable-media:
request-type: auto-connection
reasoning: >
Writing to a removable device is the purpose of the application, not an extra feature of
it. The plug is used to write the synced music files to the destination device, to read
back what is already there so later syncs only transfer what changed, to list the mounted
volumes for the device picker, and to report free space and filesystem type on the
selected one. Without it every sync target a user would realistically choose, a USB stick,
an SD card or an MP3 player mounted under /media/$USER/..., is unreachable: the app can
browse the Jellyfin library and then fail at the moment of writing. The access pattern is
narrow. JellyTunes writes into the destination directory the user picked and reads back
the files it previously wrote there; it does not walk arbitrary user data.
Auto-connection of removable-media is normally reserved for mature applications where
removable storage is the point of the app rather than a convenience, and I’d argue that is the
case here, in the same sense as cura-slicer writing gcode to an external drive or kdiskmark
benchmarking external drives. The snap has been on latest/stable since 0.6.0, is built and
released from CI, and has been developed in the open since March 2026 across six releases.
This is the only interface I’m asking for. Earlier builds plugged three more, all removed rather
than requested: password-manager-service (session credentials now go through secret-tool and
the Secret portal), hardware-observe (the usb-detection native addon is no longer loaded, so
device attach and detach polls the mount roots) and mount-observe (fstype now comes from
statfs(2) on the path, and mount enumeration compares st_dev against the parent directory,
both inside what removable-media already grants).
The snap already detects the missing plug on first run with snapctl is-connected and shows the
exact snap connect command and the restart note, so nobody is left guessing. It still means
opening a terminal before the app can do anything, which is a real barrier for the audience this
one targets: people syncing music to an MP3 player.
Thanks for considering this.