Amcfy Music is a cross-server client for the Subsonic API family

One client for a family of self-hosted music servers

Amcfy Music describes itself as a music player and Subsonic client that connects to Daoliyu Music, Songloft, Subsonic, Navidrome, Jellyfin, Emby and Plex servers, and the project description adds WebDAV to that list. That set matters more than it first appears. These servers overlap but are not identical: Subsonic defines the API, Navidrome and Songloft implement it, and Jellyfin, Emby and Plex have their own APIs that this project evidently also speaks. A user with a Navidrome at home and an Emby server elsewhere is the case the app is built around, and the extra features section lists one-tap switching between multiple servers as a headline capability. The project is MIT-licensed, and the last push was on 2026-10-19 with recent version tags 1.2.15 from 2026-09-24 and 1.2.11 from 2026-08-28, so the app is being updated even though the repository shows no code.

The repository is a download page, not a codebase

The top level of the repository contains four entries: LICENSE, README.md, README-ZH.md and a single image file, home-1.webp. There is no source tree, no build configuration, no package manifest and no test suite. The README also gives no installation instructions, no download links for specific platforms and no command line steps; it points at the project site and describes the app's features. That is the single most important fact for an engineer evaluating it. You cannot audit the binary from this repository, you cannot build it, you cannot file a bug against a known version, and you cannot contribute a patch to it, even though the licence is MIT and the repository is publicly described as a project. Anyone who wants to change the software has to start from somewhere else.

The offline cache is the feature that changes daily use

The README describes a smart offline cache that automatically stores the current and next tracks for playback when the connection drops, aimed at travel and limited network conditions. Caching the next track as well as the current one is the detail that makes it useful: a player that only caches what is playing stops at the end of the song, while one that looks ahead keeps going. This is also the feature with the sharpest edge in a self-hosted setup, because the cache is where server credentials meet stored audio, and the README does not describe how the cache is stored, whether it is encrypted, or how it is invalidated when you remove an album from the server. The one-tap switching between servers also implies more than one cache, and the README does not say whether the caches are per-server or shared.

Playback controls beyond the usual transport buttons

The audio feature set goes past play and skip. There is volume control, pitch adjustment and speed adjustment, so you can slow a track down without changing its pitch, which is the pairing people want in a player. There is a built-in equalizer, and crossfade transitions between songs. The player also keeps the screen awake during playback, which sounds trivial until you have used a phone player that times out mid-song, and there is a car mode plus a horizontal-orientation layout listed under the extra features. Sync and playback memory is described as remembering the last played track and syncing progress with the music server, so that you can pick up where you left off on another device. The README frames the interface as modern and responsive with a premium feel, which is a design claim rather than a measurement.

Browsing, searching and metadata

The library side is organised around the usual server-side categories: browse and stream by artists, albums, playlists, favorites or folders, with an advanced search that is described as finding any song across multiple servers. Since the underlying servers index metadata themselves, the interesting difference between clients is what they do with what the server returns, and the README is specific on two points. Lyrics are supported both embedded in the file and fetched from external APIs, so a track with no embedded lyrics can still show text when a lyrics provider knows the song. Album covers and artist artwork are fetched automatically, which saves the user a round trip to an artwork service. Both features depend on the server's metadata quality, and the README does not document the external lyrics providers it uses, so the privacy picture of the app depends on choices made elsewhere.

Five languages and a self-service translation path

The interface ships in Simplified Chinese, Traditional Chinese, English, Japanese and Korean, and the README points to a self-service translation page at /i18n for adding more languages. That is an unusual arrangement for a music client and it tells you something about who the project is for: a player built by and for a Chinese-speaking self-hosting community, with the community process shipped in the same repository as the app itself. It also means the translation flow is a page in the project rather than a locale file workflow, which for a repository with no source is the only part of the project where a contributor can actually do something. The other practical implication is that if your preferred language is not one of the five, you are relying on a community translation rather than a translator, with whatever quality that implies.

Where Amcfy Music is the wrong tool

Three cases, and the first is the serious one. If you need to know what the app does with your server credentials, your library metadata and your network traffic, this repository cannot answer that question, because there is no code here to read. For a tool you install on a phone and point at a music server you own, that is a risk you may accept, but it is a different posture from reviewing a library you build on. The second case is a listener whose library sits in a service that is not on the list, where the answer is a different client. The third is anyone who wants a web player they can open in a browser tab on any device without installing anything, since this is an application rather than a page, and the README gives no browser or web build. Against the browser clients that the Subsonic ecosystem already ships, the difference in approach is a native-feeling app with the offline cache, the equalizer and the multi-server switching, at the cost of an install and of trusting a binary you cannot inspect.

Editorial conclusion

Amcfy Music is a good fit for someone who already runs a self-hosted music server and wants one player that talks to several of them, with the offline cache and playback controls that a phone app needs rather than a browser tab. It is a poor fit for a developer who wants to read or extend the code, because the repository contains only a licence, two README files and a screenshot, and it is a poor fit for a listener whose library lives somewhere the Subsonic API does not reach. Check three things before you commit to it: that your server actually speaks one of the protocols the README lists, that your library is reachable over the network the app will use, since local LAN streaming is called out as a feature and remote servers are the other case, and that the build you install is the one you trust, because with no source in the repository there is no way to check what the binary does beyond taking the project's word for it.

Frequently asked questions

Official sources

1. amcfy-music/amcfy-music on GitHub
2. License: MIT
3. Project website
4. README
5. Releases