FeelUOwn: a Python music player you can script, extend and control over TCP

What FeelUOwn solves, and for whom

Most desktop music players make one assumption: that your library comes from local files or from a service the player's vendor already integrated. FeelUOwn starts from the opposite position. The pyproject.toml declares the core player with a small dependency set (janus, requests, qasync, tomlkit, packaging, pydantic, mutagen, fluent-runtime), and everything that reaches a music service arrives as an optional plugin. The README lists fuo-netease, fuo-qqmusic, fuo-ytmusic and feeluown-bilibili under the battery extra, and fuo-kuwo is present in the file but commented out. That structure tells you who the project is for: someone who wants one player window, several sources behind it, and the ability to add a source that nobody has written a plugin for yet. The README's own framing is a player that is stable, user-friendly and highly customizable, with a TCP control protocol, an experimental MCP server, text-based playlists, and a Python config file .fuorc in the spirit of .vimrc. Hackability is not a side feature here; it is the reason the project exists.

How the player, the library and the providers fit together

The repository layout separates concerns more cleanly than most Python desktop apps. feeluown/library/ holds the library model, feeluown/player/ holds playback, feeluown/server/ and feeluown/cli/ hold the control surfaces, and feeluown/gui/ holds the PyQt6 interface. The Makefile confirms this split by running mypy over feeluown/library/, feeluown/player/ and feeluown/app/, and pylint over the GUI, server and nowplaying packages, which suggests the core is typed and the edges are linted. Playback goes through mpv rather than a Python audio stack; the topics list mpris2 and mpv, so on Linux the player integrates with desktop media controls. Providers are plugins that expose media resources to the library, which is why adding a service does not mean touching the player. The control story is the unusual part. The README describes a TCP-based interactive control protocol, and the pyproject extras add jsonrpc and webserver (sanic plus json-rpc) for programmatic access, plus mcpserver (mcp>=1.8.0,<3) marked experimental. A player you can drive from another process is a different product from a player you click.

Installing FeelUOwn and playing something

The README's quick-try section routes you through system package managers first. On Arch Linux, yay installs the stable package and the provider plugins separately. Note that the README says the latest package is named feeluown-git, so the stable and bleeding-edge names differ.

# Arch Linux
yay -S feeluown          # stable; latest is feeluown-git
yay -S feeluown-netease  # install extensions as needed
yay -S feeluown-ytmusic
yay -S feeluown-bilibili

On macOS the README recommends trying the packaged build from the Releases page first, then falls back to Homebrew through the project's own tap. The brew line installs FeelUOwn together with the battery extra and the Tsinghua PyPI mirror, and feeluown genicon writes a desktop icon.

brew tap feeluown/feeluown
brew install feeluown --with-battery --tsinghua-pypi
feeluown genicon

Windows and macOS users can download prebuilt binaries from the Releases page, and the README states that Gentoo, NixOS, Debian and openSUSE also package it. If you install from PyPI instead, the extras in pyproject.toml are the switchboard: qt pulls in PyQt6, macOS and win32 pull in aionowplaying, and ai pulls in langchain with the OpenAI extra for the AI radio and natural-language-to-playlist features. The README does not document a first-run wizard, so expect to configure your providers through the GUI or .fuorc.

Where FeelUOwn gets in your way

The dependency split is the first real cost. PyQt6 is an optional extra, not a base dependency, and the pyproject.toml carries a FIXME noting that the code depends on PyQt6.QtWidgets, QtCore, QtGui, QtSvg and QtOpenGL, with a feeluown.compat module choosing the right package per Python version. If you install the bare package expecting a window, you have installed the wrong thing. The provider situation is the second constraint, and it is a legal one as much as a technical one. The README's disclaimer states that the software is a personal media resource player, that its functions and materials must not be used commercially, and that the feeluown organization will remove content reported as infringing. That is a project telling you its plugins reach services whose terms may not permit this kind of access. The README also does not document rollback or downgrade steps, so if a release regresses on your machine, the recovery path is not written down. Finally, if you want a player that works identically on a phone, a car head unit and a desktop with no plugins, FeelUOwn is the wrong tool: its strengths are exactly the places where a fixed, closed player would be simpler.

Alternatives and the difference in approach

The related searches around FeelUOwn name several other players, and the contrast is instructive. Tauon Music Box and Fooyin are desktop players aimed at local libraries, with their own UI and their own tag-handling; they do not ask you to install a provider plugin per service, and they do not expose a TCP protocol or a Python config file. YesPlayMusic is a client for one streaming service rather than a general player hosting many providers. TTKMusicPlayer is a Qt-based player in a different ecosystem with its own bundled sources. FeelUOwn's distinguishing move is architectural: the player core is thin, the sources are plugins, and the control surface is a protocol. That makes it worse as a turnkey app and better as a base. If you want to write a script that changes the playlist based on something else happening on your machine, or you want a provider for a service nobody supports, the plugin and server packages are the reason to pick this over the others.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-09-22, one day before the date used for this assessment, so the codebase is being touched. Releases are not frequent: v5.1 in March 2026, v5.1.1 in April 2026 and v5.1.2 in June 2026, which is roughly a quarterly cadence. The README claims good test coverage for core modules and backward compatibility for core interfaces, and the Makefile shows the intent behind that claim with separate pytest, integration_test, pylint, mypy, pyright and flake8 targets. The licence is GPL-3.0-or-later per pyproject.toml. For anyone embedding FeelUOwn in another product, that matters: the GPL's copyleft terms apply to distributed derivatives, and the README's disclaimer separately forbids commercial use of the software's functions and materials. Those two statements are not the same kind of restriction, and the README does not reconcile them. Upgrade cost is mostly the extras matrix: a Python version bump can change which PyQt6 package feeluown.compat selects, and provider plugins version independently of the player, so a player upgrade and a plugin upgrade are two separate decisions.

Editorial conclusion

Adopt FeelUOwn if you are comfortable in Python and want a player whose library, UI and control surface you can rewrite, and if your music sources are covered by the fuo-* provider plugins. Do not adopt it if you want a zero-configuration consumer app: the README points at the docs for anything beyond installation. Before committing, verify that a provider plugin exists for your main music source, and confirm that the extras you need (qt, battery, mcpserver) install cleanly on your platform.

Frequently asked questions

Official sources

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