Cinetry: A Local Client for Jellyfin, Emby, WebDAV and IPTV Sources

What Cinetry is for, and who it leaves out

Cinetry targets people who run more than one media backend. The README describes it as a cross-platform client that integrates media servers the user adds, naming Jellyfin, Emby, CMS, WebDAV, Subsonic, Navidrome, GD Music Station, audiobookshelf, Daoliyu, Feiniu Video and IPTV. The problem it addresses is fragmentation: each of those backends normally has its own app, its own login and its own search box. Cinetry puts them behind one interface and adds server switching and aggregated search across servers.

The scope is deliberately narrow. The README states the client does not provide any data and does not scan libraries; it fetches only the data needed for the current page through the server API. That matters for large libraries, because the client is not indexing your files. It also means Cinetry cannot show you anything your configured server does not already expose. If you have no server, the app has nothing to display. The disclaimer repeats this: all content acquisition, display and playback is decided by the user's own CMS, IPTV, WebDAV, AList, OpenList, Jellyfin, Emby, Subsonic, Navidrome, GD Music Station or Feiniu Video service.

The audience is therefore media hobbyists with existing infrastructure, not casual viewers looking for a catalog. The repository topics confirm the emphasis: jellyfin-client, emby-client, navidrome-client, subsonic-client, webdav-client, tvbox, mpv.

How the client talks to your servers

The architecture is a local client that speaks directly to each configured server. Per the README, all operations happen on the local device, and data flows go straight to the services you configured; the app does not record or forward data. There is no relay component described, and no account system is mentioned. The privacy claim rests on that direct connection model.

The README also says the app does not scan libraries and only requests the data needed for the current page. So the flow is: you add a server, the client calls that server's API for the current view, and playback happens on the device. Aggregated search is the feature that spans servers, letting one query hit multiple backends. Server switching changes which backend the UI is pointed at.

The repository's top-level entries include a file named lib_share_0912.txt and sqlite3.wasm. The presence of sqlite3.wasm suggests a WebAssembly build of SQLite is shipped with the project, which is consistent with the README's TODO entry that a Web (docker version) is being adapted. The README does not document the schema or what is stored locally, so the exact role of that database cannot be confirmed from the repository files. Treat any assumption about local caching as unverified.

Installing Cinetry and adding a first server

Cinetry is distributed as builds rather than through a package manager. The README's download section points to GitHub releases, the 123 cloud drive and the Xiaofeiji cloud drive, with separate links for the stable and test versions. For iOS, the README says to use i4Tools or TrollStore, and to leave an email after a donation of any amount to receive a TestFlight invite link. There is no documented Homebrew, winget, apt or npm install path, so do not expect one.

Start by downloading the build for your platform from the releases page:

# Open the releases page in a browser and pick the asset for your platform
# https://github.com/gstory0404/Cinetry/releases

The README does not list asset filenames per platform, so the exact file to choose is not documented in the repository. Once installed, the documented workflow is to add a server you already run, for example a Jellyfin or Emby instance, then browse it. The README gives no configuration snippet, no environment variables and no port numbers, so none are reproduced here. Configuration happens inside the app, not through a config file that the repository documents.

After adding at least two servers, the aggregated search and one-click switching features become usable. The README describes these as the core conveniences, but it does not document a CLI or an API for scripting them. Everything is done through the client UI.

Where Cinetry stops being the right tool

The clearest limitation is the missing web client. The README's TODO section lists Web (docker version) as being adapted, which means there is no documented self-hosted browser interface today. If your requirement is to watch from a browser on a machine where you cannot install an app, Cinetry does not currently cover that case. The sqlite3.wasm file in the repository suggests work in that direction, but the README does not describe a working Docker deployment.

iOS distribution is another constraint. The README routes iOS users through i4Tools or TrollStore, or through a TestFlight invite obtained by donating and leaving an email. That is not the App Store, and it adds friction and a dependency on the author's TestFlight capacity. A user who needs a standard App Store install will not find one documented.

Finally, Cinetry is a client only. If your problem is organizing or serving media, this is the wrong layer. The disclaimer is explicit that the app hosts, stores and distributes nothing, and that legality of the content depends on the services you configure. There is also no documented rollback procedure for a bad release; the README does not describe downgrading, so keeping the previous installer from the releases page is the only obvious precaution.

How it compares with a single-server client

The obvious alternative is the official client for whichever server you run most: the Jellyfin app for Jellyfin, the Emby app for Emby, and so on. Those clients are built by the server project itself, track that server's API closely, and typically ship through standard app stores. The difference in approach is scope. A first-party client assumes one backend and optimizes for it. Cinetry assumes several backends and optimizes for switching between them and searching across them.

That trade-off cuts both ways. If you run exactly one Jellyfin server, a first-party client gives you a closer match to the server's features and a simpler install path, and Cinetry's aggregation buys you nothing. If you run Jellyfin plus Navidrome plus an IPTV source plus a WebDAV share, the first-party route means several apps and no unified search, which is precisely the gap Cinetry claims to fill.

The privacy model is a second axis. Cinetry's README states it collects, stores and transmits no personal information or server data, and that all operations are local. A client that proxies through a vendor's cloud would behave differently. Whether that claim holds is something you can only assess from the code or by observing network traffic, and the README does not document a way to do the latter. The repository is not archived, and the last push was on 2026-09-18, the same date as the 0.8.4 release.

Licence, maintenance and upgrade cost

The repository does not state a licence. The README calls Cinetry a free tool and asks for donations, and the iOS instructions tie a TestFlight invite to a donation, but no licence identifier appears in the repository. Without a licence file, the terms under which you may redistribute or modify the client are unclear, and that is a real gap for anyone considering it in a workplace or bundling it with other software. This is an observation about what the repository documents, not legal advice; if the terms matter to you, ask the author directly.

On maintenance, the release history shows 0.8.2 on 2026-05-27, 0.8.3 on 2026-06-26 and 0.8.4 on 2026-09-18. The gaps are roughly one to three months, and the last push coincides with the 0.8.4 tag. The project is not archived. That cadence suggests fixes arrive on a monthly-to-quarterly rhythm rather than continuously, so a server API change on one of the supported backends could leave you waiting for the next release.

Upgrade cost is low in principle because builds come from the releases page, but the README does not document an in-app updater, a changelog file or a migration step between versions. Keeping the installer for your current version is the only rollback path the repository supports. On iOS, each upgrade depends on the TestFlight or sideload route you used, which is more effort than an App Store update.

Editorial conclusion

Cinetry fits people who already run several media servers and want one client to switch between them without exposing credentials to a third party. It is a poor fit if you need a self-hosted web UI, since the README lists the Web (docker version) as still being adapted, or if you expect the app to supply any content. Before adopting it, check the releases page for the build matching your platform, confirm your server types appear in the supported list, and read the disclaimer section about content legality in your region.

Frequently asked questions

Official sources

1. gstory0404/Cinetry on GitHub
2. Issues
3. Project website
4. README
5. Releases