The wrong server for the job
Using one program for everything wastes resources and hurts playback.
Most people start a media server with a single program. They install Jellyfin and try to make it play music, audiobooks, and movies all at once. That is the trap. A media server is not a Swiss Army knife; it is a specialized tool for a specific job. When you force one program to handle every file type, you fight its design. The file organization becomes messy, the database gets bloated, and the app feels slow. The book calls this the "one program for everything" mistake. The result is a library that feels like a broken file browser instead of a polished streaming service.
The trap: one program for everything
The book warns that a media server does not find media for you. It only serves the files you give it. You cannot fix a bad folder layout by choosing a different program. However, you can choose the right program for the right media. The book explains that films, music, and audiobooks have different needs. Trying to satisfy all of them with one tool is a mistake.
Jellyfin is built for films and series. It needs artwork, episode order, subtitles, and several audio tracks. It also needs transcoding for phones and old TVs. Navidrome is built for music. It needs fast browsing by artist and album across tens of thousands of tracks, gapless playback, and good phone apps with offline caching. Audiobookshelf is built for audiobooks and podcasts. It needs chapter support, playback speed, bookmarks, and progress that syncs between devices.
If you put music in Jellyfin, you fight its interface. If you put audiobooks in Navidrome, you fight its layout. The book suggests a better approach. It recommends running three small servers. Each server reads its own part of the media share and keeps its own small database. This separation means each program does exactly what it is good at.
The fix: three servers, three media types
The book lays out a clear architecture. You do not need to buy new hardware. You can run all three as containers. They read from the same media share, so you do not duplicate files. The book states that Navidrome and Audiobookshelf are light. Only Jellyfin needs real resources when it transcodes. This saves money and keeps your system responsive.
The servers share the media folder. You organize your files by type. You put movies in one folder, music in another, and audiobooks in a third. The servers scan these folders separately. Jellyfin only looks at the movie folder. Navidrome only looks at the music folder. Audiobookshelf only looks at the audiobook folder. This keeps the databases small and the scans fast.
The book also notes that each server has its own config and database. These live on fast local storage, separate from the media. This follows the rule "Config and media apart." You can back up the database of one server without touching the media files. You can move the database to a different drive if you need to.
The fix: direct play first, GPU transcoding second
The book follows a specific rule for playback. It says "Direct play first, GPU transcoding second, CPU transcoding never by design." This means you should configure your servers to try direct play before converting the file. If the client cannot play the file, you use the GPU for transcoding. You should never use the CPU for transcoding.
This rule applies to all three servers. However, it is most important for Jellyfin. Jellyfin is the only server that needs real resources when it transcodes. Navidrome and Audiobookshelf are light. They do not need to transcode. They only need to stream the file to the client. The book emphasizes that you should keep the CPU free for other tasks.
The book covers this in Chapter 7. It shows how to get most playback to need no conversion at all. This reduces the load on the server. It also improves the quality of the stream. You get the full bitrate and the full quality of the file. The client app handles the rest.
The fix: private by default
The book also has a rule about security. It says "Private by default. Reach the servers from outside through your tailnet. A public URL is an exception you choose on purpose, with a reverse proxy and HTTPS in front." This means you should not expose your servers to the open internet. You should use a tailnet to reach them.
A tailnet is a private network. It connects your devices to your servers without exposing them to the public. You can use Tailscale or ZeroTier for this. The book recommends using a reverse proxy and HTTPS in front of the public URL. This adds an extra layer of security. It also encrypts the traffic.
The book warns that a media server on the open internet is a target like any other web app. Chapter 8 exists because of this. It shows how to make an exposed port safe. However, the book prefers to keep the servers private. You can still access them from outside your home network, but you do it through the tailnet.
Checklist
- Run three separate servers for films, music, and audiobooks.
- Put each media type in its own folder on the shared media share.
- Configure Jellyfin to read only the film folder.
- Configure Navidrome to read only the music folder.
- Configure Audiobookshelf to read only the audiobook folder.
