Namida: a Flutter music and video player with YouTube, Subsonic and Jellyfin libraries

What Namida actually solves for an Android listener

Most Android music players pick one side. They either scan local files well and ignore streaming, or they stream from a server and treat local files as an afterthought. Namida's README describes a single app that does both: a folder-based indexer for on-device audio and video, plus multi-library support for Local, YouTube, Subsonic, Jellyfin, WebDAV and SMB sources. The target user is someone who already has a music collection on a phone or SD card and also listens to YouTube rips or a self-hosted server, and who does not want three apps for that.

The feature list is unusually wide for a one-person Flutter project. The indexer handles artist and genre separators, duplicate prevention, minimum file size and duration filters, folder exclusion, and sorting by almost any track or album property. The tag editor moved from jaudiotagger to taglib in v6.4.0, according to the README. On top of that sit lyrics fetching with word-synced LRC and TTML support, ReplayGain, crossfade, skip silence, a sleep timer, and a queue that persists across sessions.

The video side is where the project is least like a normal player. It supports SponsorBlock and Return YouTube Dislike integration, a video view with swipe gestures for volume and seeking, a waveform seekbar, and a downloads system with an output filename builder modelled on yt-dlp. That builder is the clearest sign of who the project is aimed at: people who want predictable file naming, not a black box.

How the indexer, libraries and download pipeline fit together

The repository layout is a standard Flutter app: lib/ holds the Dart source, android/, linux/ and windows/ hold platform folders, assets/ holds images, and pubspec.yaml declares dependencies. The README does not document the internal module boundaries, so the architecture has to be read from behaviour rather than from a diagram. What the documentation does describe is a library abstraction with several backends behind it: Local, YouTube, Subsonic, Jellyfin, WebDAV and SMB. A track's origin determines whether playback reads a file, a stream URL, or a remote path.

Indexing is folder-driven rather than purely tag-driven. You point the app at folders, optionally exclude some, and set thresholds for minimum file size and duration so that ringtones, voice notes and broken files do not pollute the library. Artist and genre separators exist because a single tag field often contains several names joined by a character; the separator setting tells the indexer how to split them. Duplicate prevention works on top of that, which matters when the same album exists in two folders at different bitrates.

YouTube handling is the second pipeline. The README lists audio-only and data saver modes, downloads, caching and offline playback, plus a cache priority system that keeps selected items. Downloads use a filename template with fields such as video_id, title, artist, channel, upload_date, playlist_autonumber and ext. The README notes that the extension is added automatically and need not appear in the template. Optional auto extraction of title, artist and album from the video title feeds both downloads and scrobbling, and the README gives the example of pulling the artist out of a string like a name followed by a dash and a track title, falling back to the channel name when no separator is found. That heuristic will misfire on channels that do not follow the pattern, and the README does not claim otherwise.

Installing Namida and building a first library

The README points to the GitHub releases page for the app and to Obtainium for updates. There is no Play Store link and no iOS target in the repository layout, so the practical install path on Android is the APK from the latest release, which at the time of writing is v7.1.2.

Download the APK from the releases page, or add the repository to Obtainium so that new releases arrive as updates. The README's Obtainium badge points at this URL:

https://apps.obtainium.imranr.dev/redirect?r=obtainium://add/https://github.com/namidaco/namida/

The README does not give a build-from-source command sequence, but the repository is a Flutter project, so check pubspec.yaml for the SDK constraint before attempting a build. On first launch, grant the storage permission the app requests, then add a folder. The README describes the library as folder-based, so the flow is: open the folders page, add the directory that holds your music, and let the indexer run. If your tags pack multiple artists into one field, set the artist separator before indexing rather than after, because changing it later means re-indexing.

To add a YouTube download, open a video in the app and use the download action. If you want a specific naming scheme, configure the output filename builder first. The README gives two templates as examples. The first numbers tracks by playlist position and appends the channel name in brackets:

# [04] music title [(channel name)]
[%(playlist_autonumber)s] %(title)s [(%(channel)s)]

The second groups files into per-playlist folders, with the extension appended automatically:

# saving to separate folders
# music playlist/02. music title.m4a
%(playlist)s/%(playlist_autonumber)s. %(title)s.%(ext)s

If you leave the template at its default, expect whatever naming the default produces; the README does not spell out the default.

Where Namida gets in the way

The permission model is the first real constraint, and the README flags it with a dedicated Permission Note section. An Android app that indexes arbitrary folders and downloads media needs broad storage access, and on recent Android versions that means the user has to grant it explicitly. If you cannot or will not grant it, the local library feature is effectively unavailable, and you are left with the streaming side.

The YouTube side depends on extraction that YouTube can change at any time. The README does not describe how the app handles a broken extractor, and there is no documented fallback for a video that fails to resolve. SponsorBlock and Return YouTube Dislike are third-party integrations, so their availability is outside the project's control as well.

The multi-library feature is broad but shallow in places. Subsonic, Jellyfin, WebDAV and SMB are listed as supported sources, and the README does not detail what each backend supports beyond playback: no word on whether server-side playlists, transcoding preferences or offline sync behave the same across all four. Treat the list as a statement of connectivity, not of feature parity.

The tag editor change from jaudiotagger to taglib in v6.4.0 is a dependency swap that could alter how unusual files are written. The README does not document a migration path or a rollback for library changes, so anyone with a large, carefully tagged collection should test on copies first. Finally, the project is Android-first: the repository contains linux/ and windows/ folders, but the README's installation section and the Obtainium link are Android, and no desktop build is documented.

How Namida differs from Symfonium and other Android players

The closest comparison is Symfonium, another Android player built around local files plus remote sources. Symfonium is closed source and paid, and it targets server-backed libraries such as Subsonic, Jellyfin and Plex as first-class citizens. Namida is open source, free to build from the repository, and treats the local folder as the primary library with servers as additional sources. If your collection lives on a server and the phone is just a client, Symfonium's model fits better. If the phone holds the files and YouTube is a regular part of your listening, Namida's model fits better.

Against a plain local player such as a folder-based Android music app, the difference is the YouTube pipeline and the download template. A local-only player will not resolve a YouTube URL, will not cache it for offline playback, and will not offer SponsorBlock segments. Against a command-line tool like yt-dlp, the difference runs the other way: yt-dlp gives you a scriptable, headless pipeline with far more control over formats and post-processing, while Namida gives you a touch interface, a library and a queue. They solve adjacent problems rather than the same one, and the README's own filename builder is explicitly modelled on yt-dlp's template syntax, which is a reasonable indication of where the inspiration came from.

Maintenance, releases and the licence question

The last push to the main branch was on 2026-09-19, and v7.1.2 was released the same day. Before that, v6.0.1 landed on 2026-04-18 and v5.6.1 on 2026-01-01. That is a release cadence measured in months, with a long gap between the January and April releases and a longer one before September. The repository is not archived, so the project is live, but the version jumps (5.6 to 6.0 to 7.1) suggest larger, less frequent milestones rather than continuous small updates.

Upgrade cost is mostly about the library index. A major version bump in an app that owns a database of your tracks can mean a re-index, and the README does not document a migration or backup procedure for the library. If you have spent time curating tags through the built-in editor, keep your own copy of the files. The CHANGELOG.md at the repository root is the place to check what changed between the version you run and the one you are considering.

The licence is the least clear part. The repository metadata reports NOASSERTION, meaning GitHub could not match the LICENSE file to a known identifier. That is not the same as having no licence, and it is not the same as a permissive one. If you plan to fork Namida, ship it inside another product, or redistribute a modified APK, read the LICENSE file itself and get your own advice; nothing in the README or the repository metadata tells you what the terms are. The README does link to translation and contribution sections, so the project accepts outside work, but contribution terms and distribution terms are separate questions.

Editorial conclusion

Adopt Namida if you keep a local music library on Android and want one player that also handles YouTube audio, cached downloads and Subsonic or Jellyfin servers. Skip it if you need an iOS build, a headless server component, or a client whose licence terms you can read from the repository metadata alone, because the LICENSE file is not a standard identifier. Before relying on it, install v7.1.2 from the GitHub releases page, confirm that the indexer picks up your folder layout, and check whether your device can grant the storage permission the app asks for.

Frequently asked questions

Official sources

1. Issues
2. namidaco/namida on GitHub
3. README
4. Releases