SakuraMedia: a Flutter media library app where the catalog comes from scrapers

The client is Flutter, the server is a separate repository

The repository holds the client, and the README is explicit that the backend lives elsewhere. The project links a separate backend repository, sakuramediabe, and the documentation site carries a quick start guide and a plugin development guide alongside the wiki itself. A second repository, sakuramedia-plugin-market, is where plugins are listed for distribution.

The client is a Flutter application, which the repository structure makes obvious. The primary language is Dart, and the tree carries the platform directories Flutter projects generate:

android/
ios/
macos/
windows/

Alongside them sit lib/ for the application code, test/ for tests, tool/ and scripts/ for development tooling, docs/ and wiki/ for documentation, packaging/ for distribution artefacts, and the usual pubspec.yaml, pubspec.lock and analysis_options.yaml for a Dart project.

The split into client, backend and plugins is the central architectural fact, and it explains most of the operational advice in the README. Bugs are reported as issues, usage questions go to Discussions, and there is a Telegram group for things that should not be public, such as application screenshots or film stills. The README also states plainly that the project is in a fast iteration phase and that, if you hit a problem, you should try upgrading the frontend, the backend and each plugin to their latest versions. That is a workable answer for a self-hosted enthusiast, and a poor one for a team that wants predictable versions.

Subscriptions turn a catalogue into a pipeline

The feature set splits into two halves that are worth separating, because they have different failure modes. The first half is discovery. The app can search for a title by its catalogue code, look up a performer by name, and browse content through tags, rankings and recommendations. Subscribing to a performer makes the app track her new releases continuously.

The second half is the subscription pipeline. When you subscribe to a title, the system periodically looks for a suitable resource, submits the download, and on completion imports the file into the media library automatically. If no resource is found, the title can stay on the subscription list and wait. That last behaviour is the honest one, and it is worth noticing: the app is a queue manager with a fallback, not a promise that every subscription resolves.

The local import path is the third door in. You can point it at films already on a NAS or a network drive, and it will try to recognise the code, scrape the metadata and fetch a cover. Where recognition or retrieval fails, the entry supports a manual search and match. That fallback matters, because scraping against third party sites is exactly the step that breaks when a site changes its markup.

Metadata and rankings are plugins, so a broken source is a plugin problem

The plugin mechanism is described as covering several plugin capability types, with ranking list sources, subtitle acquisition and performer profile completion listed as the examples that can be enabled as needed. Storage and download capabilities are also plugged in rather than hard coded.

That design has a clear benefit and a clear cost. The benefit is that a site that changes its layout, or a source you would rather not use, is replaced by writing or installing a different plugin instead of patching the application. The cost is that the behaviour of your installation is the sum of several independently versioned pieces, which is exactly what the README's advice about upgrading the frontend, the backend and each plugin to their latest version is telling you to expect.

The plugin market is where the distribution happens, and its rules are specific. To list a plugin you submit a pull request to the sakuramedia-plugin-market repository with the purpose of the plugin and its repository address, and the repository must be public and provide an install package in a Release. In other words, the marketplace is an index of public repositories rather than a hosted binary store, and each plugin is versioned and released by its own author. A plugin that is abandoned leaves a gap that only you can fill.

The thumbnail timeline is the feature that changes watching

Most of the feature list is catalogue plumbing. The client is where the project makes an argument, and the argument is about scrubbing.

The client builds a thumbnail timeline that spreads the frames of a film along the time axis, so a click lands on the corresponding image. The intent, stated in the README, is quick preview of scenes and locating good moments, alongside speed control, subtitles and resume, with the option to hand a file to an external player instead. VR video is handled by calling an external player, with multi-segment resources merged into one continuous film, and support for Pico style devices is experimental and limited to playing in 2D.

The honest reading is that this is a preview aid rather than a new player. It gives you a visual index of a file so you can find a moment, then hands playback to something else if you want the full experience. For a large personal library, that is a genuinely different way to navigate, because searching by title only tells you what a film is called, not what is in it.

The VR path shows the boundaries. The client is not a VR renderer, it is a client that can drive one, and the device support is described as experimental.

A sampling fingerprint is what makes duplicates detectable

Library management is treated as a first class feature rather than an afterthought, and the mechanism behind it is the file fingerprint. The README describes a dedicated sampling fingerprint algorithm that reads only a small number of file fragments in order to identify duplicate media quickly, and that works across libraries and across storage.

This is the design decision that makes duplicate detection affordable. Comparing whole files is exact and expensive, so a library with terabytes of media cannot afford to hash everything on every scan. Sampling a few fragments and treating the result as a signature is a compromise, and the compromise is in the accuracy: two different encodes of the same content may not sample identically. The README does not state how many fragments are read, nor what happens on a fingerprint collision, so both are things you would have to measure on your own collection.

The payoff is the set of views the library can offer: duplicate files, multiple versions of the same title, and dead media. Alongside those, migration between supported storages is supported and preserves media records and playback progress, which matters because a collection organised by hand is expensive to rebuild.

Storage and downloading are plugin choices, currently local, qBittorrent and 115

The supported set is described concretely: local storage together with qBittorrent, and the 115 cloud drive configured for 115 offline download. The framing is that storage and download capability is accessed through plugins, with more to be added later, and the download side feeds the same import pipeline that the local import path uses.

That last point is the interesting one. Whether a file arrives through the subscription pipeline or is copied onto the NAS by hand, it ends up in the same library, with the same scraping, the same fingerprint, the same duplicate view and the same playback history. The plugin boundary sits at the transfer, not at the catalogue.

Around that sits a task and notification centre, where downloads, imports and background jobs are viewed together with their progress and results, and reminders arrive through notifications, with an extension mechanism so that additional notification channels can be plugged in. For a library that updates itself, that is the part that decides whether the system is trustworthy: a subscription list that silently stalls is worse than one that reports failure.

GPL v3 and a non-commercial clause that pulls in two directions

The licence field says GPL-3.0 and the README links a LICENSE file, but the risk and disclaimer section adds conditions of its own. The project states that it is for technical exchange only, that it provides no film resources and no resource download links, that users bear all consequences of using the tool, that users must comply with local law and should not use it where that breaks, and that commercial use of the software is prohibited, with the instruction not to use the software if any of those terms is not accepted.

That is a set of use restrictions laid on top of a GNU GPL v3 grant, and the two do not sit together neatly. GPL v3 grants broad rights to use, modify and redistribute the code, and a plain non-commercial clause added in a README is not the same as a licence exception with the legal machinery to enforce it. Anyone planning to redistribute the code, ship a modified build, or use it inside a commercial product needs to read the LICENSE file and decide for themselves what the combination means. This paragraph is not legal advice and does not try to be; it is a flag that the repository contains two different statements about what you may do with it.

On maintenance, the repository is not archived and the last push was on 2026-10-15, the same day as release v0.11.0, with v0.10.1 on 2026-10-13 and v0.9.6 on 2026-10-08. Releases are frequent, which matches the stated fast iteration phase, and it is the reason the README tells users to upgrade everything to the latest version rather than to pin.

Editorial conclusion

Adopt SakuraMedia if you keep a personal media library on a NAS and want automatic metadata, subscription driven downloads and an in-app scrubbing timeline without wiring together separate scraper, download client and player pieces. Do not adopt it for commercial use, since the README forbids commercial use outright, and do not adopt it if you need a stable catalogue, because the metadata depends on external sites and plugin versions that the project itself describes as fast moving. Verify first that the backend project and every plugin you install are on matching versions, that the licence terms in the LICENSE file match the non-commercial statement in the README, and that the download and storage plugins you plan to use are published as public repositories with release artefacts.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. tinypinglite/sakuramedia on GitHub