[feature request] Fully local option

[hankiew]

I really enjoy this UI, and I would like to use this app locally for music on my computer.

[htkhiem]

Good news, that's actually how many people, me included, use Euphonica :). We've got a wiki article about doing exactly that here.

[hankiew]

Yes, but that's rather long winded. Do you have plans to add an option in settings to simply select a local directory?

[htkhiem]

Since this is a client to MPD, you'll still need to set that up. ~90% of that article is actually about MPD, not Euphonica. Even if I were to add a way to select the directory via the GUI, it'd only automate setting a single config line, and then you'll still need to open up the terminal to restart MPD itself (Euphonica shouldn't be expected to be able to do that, especially not when sandboxed).

I do recommend going through it since it's a once-and-done affair and will also lay the groundwork for more complex setups, such as NAS-backed multiroom playback down the line.

[htkhiem]

Converting to a discussion since I wanna get serious about implementing some sort of "managed MPD subprocess", turning Euphonica into a self-contained player for real. Users would ideally only need to install Euphonica as a package, then fire it up and have a wizard asking them whether they want the easy option (managed MPD) or already have a server, then if managed, where the music folder is et voilà.

How this MIGHT work:

• Add MPD as a package dependency (AUR, future DEB, maybe ask the Nixpkgs maintainer to help out with theirs, etc). For Flatpak, MPD must be bundled as a module in the manifest.
  • Can we create additional Flathub "editions" of Euphonica? Like one with permissions strictly limited to the internal managed MPD instance only (no more PipeWire & lock to FIFO visualiser). It'll look less bad than our current offering which shows a big red "I CAN READ YOUR SCREEN" kinda warning just because we wanted a funky viz.
• Both executables live side by side. The MPD executable remains unmodified and except for the Flatpak case can still be used by other apps. However, when Euphonica runs its own managed MPD instance, it'll be a separate process configured to read off a managed configuration file which in turns specifies an internal Unix socket connection.
  • Technically even that connection will be available to any other client on the same machine.
  • We can also go one step further and allow specifying a TCP connection. This way Euphonica can even be used as a basic server control panel for a server your other clients connect to (...not its intended purpose, but still).
• The managed MPD process' lifetime should probably be tied to Euphonica's, both should start, stop (and crash?) together. It's easier to control that way than to have a runaway MPD process that the next Euphonica boot has to re-detect. Should you want a standalone server then...do it the standalone way and don't use the managed one :).
• Optional features, like stickers and playlists, are forced on to reduce fussiness & ensure that all of Euphonica's features are enabled in the "easy option".

Things to do to achieve the above:

• Double-check GPL-2.0 (MPD's). Apparently if we're separated by the process barrier, do not run MPD like a linked library, and do not modify MPD, then Euphonica can stick to GPL-3.0 and the bundle can be distributed under two licences at the same time, each applying to one of its components (?).
• Start with just trying to automate starting/stopping the existing MPD process + keeping a SEPARATE config file (NOT whatever the user touches). Said config file can live in an app-specific temp path and might be regenerated on each boot so we can steamroll over broken manual edits. Euphonica keeps its own dconf config keys and uses them to generate that config file. Config changes during runtime will require restarting the managed process.
• Expose GUI controls in lieu of letting the user edit said managed config file. This will be the most taxing of all the items here (imagine the output controls section). No need to enable control of things like paths to DB file, stickers DB file, playlists folder, etc. We'll stick to somewhere the XDG directories standard say is most suitable, and at most just allow OPTIONAL control of a "system path" just in case said default is on a less-than-favourable block device (slow, no space left, etc). All of the above things will live within the specified path.
• Lots and lots of testing and debugging.

No matter what happens, Euphonica WILL retain the option to connect to another server.