anacrolix/dms: A Terminal-Based DLNA Server for Local Media With On-Demand Transcoding

What dms Solves and Who Should Care

dms solves a narrow but real problem: getting media from a local filesystem onto a UPnP DLNA client without a heavyweight media server. The README describes it as a UPnP DLNA Digital Media Server that runs from the terminal and serves content directly from the working directory or a given path. The target user is someone who already manages files on a Linux or BSD box, does not want a graphical configuration layer, and needs their TV or mobile app to see those files. The README mentions it has been tested on a Panasonic Viera television, several Android UPnP apps, and Chromecast, which gives a concrete idea of the client ecosystem it targets. This is not a tool for a non-technical household; it expects you to run commands, understand PATH variables, and accept that some features will silently disappear if external binaries are missing.

How the Server Works: SSDP, Raw Files, and Alternate Streams

The server's mechanism is straightforward, and the README explains it in a few sentences. The SSDP component broadcasts and responds to requests on all available network interfaces, which is how DLNA clients discover the server. Once discovered, dms advertises and serves the raw files, plus alternate transcoded streams when it can produce them. The README gives two concrete examples of such alternate streams: mpeg2 PAL-DVD and WebM for the Chromecast. That means the server does not simply stream the original file; it can present a second, transcoded version to the client, letting the client choose what it can actually play. The README also states that dms supports dynamic streams, such as a live rtsp stream, generated on the fly with the help of an external application like ffmpeg. This is a notable design choice: rather than embedding codec logic, dms delegates to external tools and only enables the related features if those tools are present in the PATH.

Installing and Running: Commands and PATH Dependencies

Installation is a single Go command, assuming Go and GOPATH are configured. The README gives: go install github.com/anacrolix/dms@latest. Then you run it with "$GOPATH"/bin/dms. There is no mention of configuration files or flags in the README beyond the working directory or path given; the server serves content from the current directory unless you specify a path. The critical dependency is external binaries: dms uses ffprobe or avprobe to get media data such as bitrate and duration, ffmpeg or avconv for video transcoding, and ffmpegthumbnailer for generating thumbnails when browsing. The README is explicit that these commands must be in the PATH given to dms or the features requiring them will be disabled. That is a sharp constraint: if ffmpeg is missing, you get a raw file server, not a transcoding one. The README also includes a FreeBSD service example, with a helper file at helpers/bsd/dms, and mentions adding dms_enable="YES" to /etc/rc.conf, along with optional dms_root and dms_user settings. This suggests the project has some operational maturity beyond a quick hack.

Limitations: Silent Feature Loss and External Tool Dependence

The biggest limitation is that dms does not fail loudly when dependencies are absent. The README says features will be disabled, but it does not say how the user is informed. You could run dms without ffmpegthumbnailer and only discover later that no thumbnails appear. That is a real usability trap. Another limitation is the scope of transcoding. The README mentions mpeg2 PAL-DVD and WebM for Chromecast, which are specific outputs. It does not claim to transcode arbitrary formats to any device. If your client cannot play the raw file and the transcoded alternatives do not match its supported codecs, you get nothing. The README also notes that dms is looking for funding for further development, which is a signal that maintenance is not guaranteed. The last push is from 2026, but the funding request suggests the project may not have a dedicated maintainer. For a production media server, that is a risk you need to weigh.

Maintenance and Upgrade Cost: What the Repository Shows

The repository has a CHANGELOG.md and a FAQ.md, both linked from the README, which is a good sign for anyone tracking changes. The release history shows v1.6.0 from 2023, v1.7.2 from 2025, and v1.8.0 from 2026, so there is a pattern of annual or so updates. The project is not archived and the default branch is master. The license is BSD-3-Clause, which is permissive and imposes few obligations beyond retaining the copyright notice. There is no mention of a database, plugins, or a configuration schema, so upgrade cost likely means rebuilding the binary with go install and checking the changelog for behavior changes. The README does not describe any migration steps, which either means upgrades are trivial or that the project has not documented them. The funding request is the strongest maintenance signal: if you adopt dms, you should expect to handle issues yourself or contribute code, because the author is explicitly asking for sponsorship.

Alternatives: What a Different Approach Looks Like

The obvious alternative is a full-featured DLNA server like Plex or Jellyfin, which bundle their own transcoding, metadata scraping, and a web interface. The difference in approach is significant: those servers run as daemons with a client-server architecture, maintain a media library index, and perform transcoding internally, often with hardware acceleration. dms, by contrast, is a single binary that serves whatever is in a directory, with no library management and no web UI. If you need to organize a large collection, search metadata, or have non-technical users, dms is the wrong tool. Another lighter alternative is minidlna, which also serves DLNA but does not transcode at all; it only streams raw files. That highlights dms's differentiator: it can present alternate transcoded streams, which minidlna cannot. So the choice is between a minimal server with some transcoding (dms) and a minimal server with none (minidlna), or a full media platform (Jellyfin). The trade-off is complexity versus control.

Editorial conclusion

Adopt anacrolix/dms if you are a technical user who wants a lightweight, terminal-based DLNA server without a web UI, and you already have ffmpeg and ffprobe installed. Avoid it if you need a GUI, broad codec support without manual setup, or guaranteed long-term maintenance, since the project explicitly seeks funding and the last release is v1.8.0 from 2026. Before relying on it, verify that your media files are in formats your target device can play natively or that your ffmpeg build supports the required transcoding. Also check the FAQ and CHANGELOG for known device quirks and recent changes, as the README does not detail them.

Official sources

1. Official README
2. Project repository
3. Release notes