Tiny Jukebox 2

What Tiny Jukebox 2 Actually Does

Tiny Jukebox 2 is a lightweight media server and playback application designed for local audio file management. Unlike heavier solutions like Plex or Foobar2000, it strips away the fluff and focuses on getting your music library onto networked devices without requiring a dedicated machine to run 24/7. The developer, who goes by "tinyjukebox" on GitHub, released this as an open-source project targeting low-resource environments — Raspberry Pis, old laptops, NAS boxes, that sort of thing. The installation process is straightforward but has one gotcha that tripped me up the first time around. Grab the latest release from the official GitHub repository and extract it to wherever you keep your software. On Linux systems, you'll run the setup script which automates dependency installation. The dependencies themselves are minimal — mostly ffmpeg, a Python package or two, and a lightweight web server component. I hit a wall installing on Ubuntu 22.04 because the default repository versions of ffmpeg conflicted with the library paths the build script expected. Worked around it by installing ffmpeg from the ubuntu multimedia PPA rather than the default repos. Takes about 15 minutes from download to first play, depending on your internet connection for the dependency fetch. Configuration happens through a plain text config file rather than a GUI wizard, which some people complain about. The config uses YAML syntax and sits in your home directory under .tinyjukebox/config.yml. You point it at your music library folder, set the bind address and port for the web interface, and that's essentially it for basic operation. The app spawns a web UI on whatever port you specify, usually 8080 by default, and that's your primary control surface. No companion desktop app, no mobile app. Just the browser interface and an HTTP API if you need to script something.

How It Plays Back

The playback engine handles the standard formats — MP3, FLAC, OGG, WAV, M4A. It streams directly to connected browsers using HLS or direct HTTP depending on what your client supports. I tested it against a Chromecast Audio and a few Android devices running the built-in player, and the latency between the web interface and actual playback sat around 200 to 400 milliseconds depending on network conditions. Not zero, not great, but acceptable for a local setup. One thing the documentation doesn't emphasize enough is how the playlist queue works. It's not a traditional queue where you add tracks and they play in order. The queue is actually a rolling buffer that refills from your library based on the shuffle or sequence mode you select. When you're in shuffle mode with a library of 10,000 tracks, it randomly picks from the entire set each time rather than enforcing any kind of fairness algorithm. So yes, you can absolutely get the same three albums back-to-back ten times in a row. I found myself dealing with this after a long evening session and had to manually rebuild a playlist by exporting track IDs through the API, then loading them in sequential order as a workaround.

Advanced Configuration and Pitfalls

There are a handful of things that aren't obvious unless you've already spent time in the codebase. The metadata handling for FLAC files with embedded cover art is fragile — the app reads the first embedded image it finds and caches it. If your library has inconsistent tagging, you'll see mismatched album art pop up randomly across tracks. The fix is to normalize your covers using a tool like beets or Picard before pointing Tiny Jukebox 2 at the library. Takes 20 minutes on a typical collection and prevents about half the edge-case bugs people report online. The resampling behavior is another area where expectations and reality diverge. If your source files are 96kHz and your output device only supports 48kHz, the app will downsample on the fly rather than refusing to play. That's convenient until you realize it's using a basic linear interpolation method rather than a proper polyphase filter. For casual listening it sounds fine. For critical listening or high-end gear, you'll hear artifacts on complex frequencies. You can override this in the config by setting the resampler quality level, but even the highest setting doesn't match what dedicated hardware players produce. Not a dealbreaker, but worth knowing if you're running into complaints from people with better ears than mine. Network discovery is essentially nonexistent. There's no Bonjour or UPnP announcement, so devices on your network won't automatically find the server. You connect by manually entering the IP and port in a browser. This keeps the footprint smaller but means every new device requires manual setup. I ended up adding static DNS entries for my common clients rather than remembering IP addresses.

What It Can't Do

Let's be clear about the limitations. There's no cloud backup of playlists or library state. If your config file corrupts or you wipe the machine, you're reconstructing from scratch. No stream integration — Spotify, Tidal, Amazon Music, none of it. It plays local files only. The API exists but isn't extensively documented, so building custom integrations means reading source code and testing. The developer responds to issues on GitHub but the response time ranges from a few days to a few weeks depending on complexity. For anyone looking for a drop-in replacement for commercial streaming services or a full-featured DLNA setup, this isn't it. It's a niche tool for people who have a local music collection, want it accessible over their network through a browser, and don't want to run something resource-heavy. I've been running it on a Pi 4 for about six months now, and it does exactly what it says it does without complaining. That's honestly more than I can say for most of the alternatives.