MusicPod puts local files, internet radio, TV and podcasts in one Flutter app

Four kinds of audio in one desktop window

MusicPod is a local music, radio, television and podcast player for Linux Desktop, macOS and Windows. The description also names Android as planned, with no estimated date attached to it.

The interesting decision is the bundling. A system usually ships one media player for files, another for streaming radio, and a third for podcasts, and each wants your attention. MusicPod takes the opposite position and puts local audio, internet radio, television streams and podcast episodes behind one interface, with light and dark themes for both Linux and macOS.

It is written in Dart with the Flutter toolkit, which is visible in the repository layout: the lib/ directory holds the application code, with separate platform folders for linux/, macos/, windows/ and android/, alongside a design/ directory, a scripts/ directory and a test/ directory. The primary language for the project is recorded as Dart, and the .fvmrc file at the root pins a Flutter version for contributors.

The licence is GPLv3, and the project lives under the ubuntu-flutter-community organisation, which suggests it is maintained as community work rather than as a product with a support contract behind it.

Where to install it on each platform

The install options differ by operating system, and the project documentation sets out exactly what is available.

On Linux there are three routes. A Snap package is published in the Snap Store, and a Flatpak is published on Flathub under the identifier org.feichtmeier.Musicpod. For Arch Linux, the project directs users to install from the archlinuxcn repository with the pacman command sudo pacman -S musicpod, which is a third party repository rather than one of the official Arch mirrors.

On Windows and macOS, binaries come from the release page on the project repository, and the release table shows a recent pattern of updates, with v3.1.1 and v3.1.0 both published on 2026-10-17 and v3.0.3 on 2026-09-24.

Android is listed simply as work in progress. The project documentation describes it as planned with no ETA, and the repository still contains an android/ directory, so the platform work has started, but there is nothing to install.

The split between distribution channels has a practical consequence for a Linux user. A Snap and a Flatpak sandbox the application, which is convenient for isolation but can complicate access to a music library outside your home directory. The Arch package installs straight onto the system with no sandbox in between, which is the most direct option for a user who is comfortable with an unofficial repository.

The Windows local audio caveat the project documents itself

The project documentation does not hide its weakest point, and it is worth reading before installing on Windows.

The stated caveat is that metadata loading for local audio takes ages, and because of that the Windows version is not considered stable if the local audio feature is what you are after. The issue is tracked as number 264 in the project repository. That is a specific, reproducible complaint about a specific feature rather than a vague sense that the build is rough around the edges.

The mechanism behind the feature explains why it is slow. The library used to read local audio metadata is the Dart audio_metadata_reader package, and finding local files sorted by metadata means walking the library and reading tags for each file before anything can be shown. On a large collection that scan is the dominant cost.

For a Linux or macOS user this is a background annoyance. For a Windows user it is the difference between a usable player and a slow one, and the project's own documentation tells you to look elsewhere for that use case. Radio, podcasts and television streams do not depend on the local library scan, so a Windows user whose interest lies there is not affected in the same way.

Radio discovery with RadioBrowser and icy metadata

The radio side of the app is the part that goes furthest beyond playing a file.

Stations can be played with their icytags and artwork looked up, which is the metadata the internet radio protocol carries about the current track and the station logo. Discovery is a separate feature: the application lets you browse radio stations and filter them as you like, and the repository topics list both radiobrowser and radiobrowser-api, which points to the RadioBrowser service as the source of the station directory behind that filtering.

That distinction between playing and discovering is what makes the radio feature useful. A stream URL you already have is easy to open in anything. Sorting a directory of several thousand stations by country, language, codec or bitrate, and then seeing artwork before you commit to a stream, is a job a single app does better than a list of URLs.

The filtering options are what you will spend time with, and the project documentation describes them only by name, so the exact set of filters available is something to check in the running application rather than in the README.

A podcast player built around resuming and downloading

Podcasts get their own section of the feature list, and it is more than a playback shortcut.

The application can play and download podcast episodes, keeps safe progress so that a partially listened episode resumes where it stopped, and can sort episodes. Downloads are the part that changes the character of the app: once an episode is on disk, listening no longer depends on a live connection, which is what a podcast client is for.

Video podcast support is listed as its own feature, with separate screenshots for dark and light Linux themes and for macOS. The application also has a discovery view for podcasts that can be filtered as you like, mirroring the radio discovery, so a new show can be found without leaving the app.

The four-column screenshot layout for the feature table, dark Linux, light Linux, dark macOS and light macOS, is itself informative. It shows that the project treats the visual design as part of the feature set and tracks it across platforms, and it implies that the Windows build does not have the same theme coverage, which is consistent with the stability caveat in the project documentation.

The repository also carries a l10n.yaml file and a translation status badge pointing at Weblate, so the interface is set up for translation by contributors rather than being maintained in one language only.

Repository anatomy and a same-day release cadence

The tree shows a conventional Flutter application with a few things worth noting.

There is a pubspec.yaml and pubspec.lock, an analysis_options.yaml for the Dart analyser and devtools_options.yaml for the Flutter devtools configuration. The privacyscope.md file is unusual and interesting: it is a document about privacy scope, which for a player that reaches out to radio directories, podcast feeds and artwork servers is a reasonable thing to publish. renovate.json is present, so dependency updates are handled by an automated tool rather than by hand.

The snap/ directory holds the Snap packaging, and the releases for Windows and macOS are built from the same repository.

The changelog is kept in a CHANGELOG.md file at the root, and the release history is quick. Three of the recent tags are v3.1.1 and v3.1.0 on the same afternoon, 2026-10-17, and v3.0.3 on 2026-09-24. Publishing a patch and a minor version within half an hour of each other is normal for a project that is shipping continuously, but it also means the version number in a bug report tells you less than the commit or changelog entry would.

The last push to the main branch was on 2026-10-20, three days after those tags, so the working tree is ahead of the latest release.

Where a separate player per medium is the better answer

The alternative to MusicPod is the arrangement most Linux desktops already have, a media player for local files, a separate podcast client, and a stream URL pasted into something else. The difference in approach is scope rather than quality.

For a user with a large local library and a tidy podcast queue, separate tools can be better, because each one is tuned for its medium and you are not paying for a single interface to cover four of them. The cost is having four windows, four sets of settings and no single place to see what is playing.

For a user who discovers radio through a directory rather than a saved playlist, the difference is sharper. The repository topics list the radiobrowser-api service, and MusicPod's discovery and filtering features sit on top of it. The alternative approach is to query that API yourself, build your own list of stations, and play them in any audio player. That gives you the directory without the application, at the cost of writing and maintaining the client, and it is the reason to look at the API directly if you only want the radio part.

What MusicPod adds over that approach is the surrounding media handling. Downloads for podcasts, resume positions, video episodes, artwork lookup and local library browsing are all in one place, and the Flutter codebase means the same interface behaves consistently on Linux, macOS and Windows.

The honest boundary is the Windows local audio case, where the project's own documentation says the feature is not ready.

Editorial conclusion

MusicPod is a good fit for a Linux or macOS user who wants one application for a local music library, internet radio, television streams and podcasts, and a poor fit for a Windows user whose main interest is local audio, since the project states that metadata loading is slow enough there to make the Windows build unstable. Before adopting it, install the Flatpak or Snap build on Linux, and if radio discovery matters to you, check the RadioBrowser dependency and the filtering options in the app.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. ubuntu-flutter-community/musicpod on GitHub