[GH-ISSUE #1287] Support for External Daemons as Backends for Media. #8816

New issue

Closed

opened 2026-05-23 03:54:26 +01:00 by JakeStanger · 1 comment

JakeStanger commented

2026-05-23 03:54:26 +01:00

Owner

Originally created by @Windblows2000 on GitHub (Dec 20, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1287

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I've been looking into the Music Module for a while now and I think it might benefit from a split in the logic. I was specifically using player_type = "mpris" for clarity, as mpd seems to not be working properly on my system.

the persistence of media metadata: I faced scenarios where the metadata is strangely dropped after a while of inactivity. Falling back to a blank module until the media is invoked again.
discovery is limited: from what I see, the code only picks a single client and keeps track of it. I think that its a huge missed opportunity to not have a per-player widget style. Similar to how KDE Plasma does it.
general overhead: it seems that everything is running within Ironbar? From the thumbnail to general metadata.

Describe the solution you'd like

A clear and concise description of what you want to happen.
The more info here about what you are trying to achieve, the better - there's likely more than one way to go about implementing a solution.

I believe the introduction of a backend that can separately handle the logic Ironbar is doing would be much healthier for Ironbar. A standalone daemon for handling the MPRIS clients and metadata would ideally lift off the weight from Ironbar., such as album art handling, metadata requests, timers, and proper tracking when multiple clients are active This actually occured to me while working on my own daemon for MPRIS clients interaction.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

mpd/mpris: They seem to be internally handled in the code and add overhead as previously explained.
playerctl: We'd be working with a tool written in C and has not been maintained in a long while (the github repo shows the last commit as 4 years ago). And you'd still likely have to jump through hoops to satisfy its quirks.

Additional context

Add any other context or screenshots about the feature request here.

I made a reference GUI implementation for the current code. its still unfinished and quite ugly, but it should help with clearing up the fog on whether this is worth pursuing or not.

even if the architectural shift isnt in line with what you expect from the project, I'd be more than willing to discuss what can actually be done to improve on it. Thank you for your time and efforts on Ironbar!

Originally created by @Windblows2000 on GitHub (Dec 20, 2025). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1287 **Is your feature request related to a problem? Please describe.** > A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] I've been looking into the Music Module for a while now and I think it might benefit from a split in the logic. I was specifically using ```player_type = "mpris"``` for clarity, as mpd seems to not be working properly on my system. - the persistence of media metadata: I faced scenarios where the metadata is strangely dropped after a while of inactivity. Falling back to a blank module until the media is invoked again. - discovery is limited: from what I see, the code only picks a single client and keeps track of it. I think that its a huge missed opportunity to not have a per-player widget style. Similar to how KDE Plasma does it. - general overhead: it seems that everything is running within Ironbar? From the thumbnail to general metadata. **Describe the solution you'd like** > A clear and concise description of what you want to happen. > The more info here about what you are trying to achieve, the better - there's likely more than one way to go about implementing a solution. I believe the introduction of a backend that can separately handle the logic Ironbar is doing would be much healthier for Ironbar. A standalone daemon for handling the MPRIS clients and metadata would ideally lift off the weight from Ironbar., such as album art handling, metadata requests, timers, and proper tracking when multiple clients are active This actually occured to me while working on my own [daemon](https://github.com/Windblows2000/Nexa) for MPRIS clients interaction. **Describe alternatives you've considered** > A clear and concise description of any alternative solutions or features you've considered. * mpd/mpris: They seem to be internally handled in the code and add overhead as previously explained. * playerctl: We'd be working with a tool written in C and has not been maintained in a long while (the github repo shows the last commit as 4 years ago). And you'd still likely have to jump through hoops to satisfy its quirks. **Additional context** > Add any other context or screenshots about the feature request here. I made a [reference GUI implementation](https://github.com/Windblows2000/Nexa-IPC-GUI-implementation) for the current code. its still unfinished and quite ugly, but it should help with clearing up the fog on whether this is worth pursuing or not. even if the architectural shift isnt in line with what you expect from the project, I'd be more than willing to discuss what can actually be done to improve on it. Thank you for your time and efforts on Ironbar!

JakeStanger

2026-05-23 03:54:26 +01:00

closed this issue
added the
T:Module Enhancement

M:Music
labels

JakeStanger commented

2026-05-23 03:54:27 +01:00

Author

Owner

@JakeStanger commented on GitHub (Dec 22, 2025):

Okay there's a few things going on here, but the general consensus I'm getting is a few observed issues that a daemon probably would not help.

To start with, it's worth pointing out the current architecture already uses a daemon - media players speak to DBus over the MPRIS protocol, and Ironbar connects to DBus as a client to consume the metadata. All the MPRIS code in Ironbar is client code, and introducing yet another daemon would do very little to reduce this (we'd then need to pull all the same data out of that daemon).

I faced scenarios where the metadata is strangely dropped after a while of inactivity

This is more than likely an implementation detail in your MPRIS client. Ironbar listens to changes and won't clear this itself. I can't see a good way around this, because a player is going to clear its status when playback stops, so attempting to cache this would be nigh-impossible.

the code only picks a single client and keeps track of it

That's correct and a current limitation. Future versions will definitely include support for multiple players. Most of the work involved in that is more than likely going to be the UI and module code.

it seems that everything is running within Ironbar? From the thumbnail to general metadata.

I'm not sure what you're getting at here. Ironbar pulls all that data because it needs that data to display it. Adding a separate process that Ironbar needs to communicate bidirectionally with to pull out all the same metadata will add much more overhead than handling it.

I believe the introduction of a backend that can separately handle the logic Ironbar is doing would be much healthier for Ironbar.

Why and how?

Introducing daemon support also adds overhead in the following way:

In one scenario, we would drop support for the existing backend(s). This would be a major breaking change that would require all users of the module to set up a separate process to regain the functionality they already had.
In the other, we keep support for the existing backends. This means I now have to maintain an additional backend that offers no additional functionality.

There's potentially an argument to be made that some of the client code could be split into its own library, but that would end up being a library which exists purely to consume existing high-level client libraries for Ironbar's specific needs. It'd serve little purpose to anybody else and create more work for me to maintain.

@JakeStanger commented on GitHub (Dec 22, 2025): Okay there's a few things going on here, but the general consensus I'm getting is a few observed issues that a daemon probably would not help. To start with, it's worth pointing out the current architecture already uses a daemon - media players speak to DBus over the MPRIS protocol, and Ironbar connects to DBus as a client to consume the metadata. All the MPRIS code in Ironbar is client code, and introducing yet another daemon would do very little to reduce this (we'd then need to pull all the same data out of that daemon). > I faced scenarios where the metadata is strangely dropped after a while of inactivity This is more than likely an implementation detail in your MPRIS client. Ironbar listens to changes and won't clear this itself. I can't see a good way around this, because a player is going to clear its status when playback stops, so attempting to cache this would be nigh-impossible. > the code only picks a single client and keeps track of it That's correct and a current limitation. Future versions will definitely include support for multiple players. Most of the work involved in that is more than likely going to be the UI and module code. > it seems that everything is running within Ironbar? From the thumbnail to general metadata. I'm not sure what you're getting at here. Ironbar pulls all that data because it needs that data to display it. Adding a separate process that Ironbar needs to communicate bidirectionally with to pull out all the same metadata will add much more overhead than handling it. > I believe the introduction of a backend that can separately handle the logic Ironbar is doing would be much healthier for Ironbar. Why and how? --- Introducing daemon support also adds overhead in the following way: - In one scenario, we would drop support for the existing backend(s). This would be a major breaking change that would require all users of the module to set up a separate process to regain the functionality they already had. - In the other, we keep support for the existing backends. This means I now have to maintain an additional backend that offers no additional functionality. There's potentially an argument to be made that some of the client code could be split into its own library, but that would end up being a library which exists purely to consume existing high-level client libraries for Ironbar's specific needs. It'd serve little purpose to anybody else and create more work for me to maintain.