09-28-2022, 12:42 PM
Yes and no, because the "how" is basically done (uhubctl) but to be nicely integrated it needs a little help from the service (moode) that's running on the system. Also there is nothing the Pi could do better because it's the hardware that's lacking, and even if there would be some power management it's still the service that would need to configure suspending behavior. Kodi for example has those features (suspending the device, not USB per se) integrated because its expected to exclusively manage the system, just like moode.
I have currently scripted it with a service running on the device that waits for mpc events and triggers the USB wakeup and shutdown. But the wakeup is too late because mpd tries to connect to the output device before emitting the event. So for it to work flawlessly it would be required that moode waits for the USB to come up before actually sending the play command to mpd. That's why this feature request even exists.
As I said it doesn't need to be such a specialized feature. If it's reasonable to implement a hook system, that would actually be better because it's versatile and would enable users to implement their own stuff easily.
And by thinking about this, it would be nice to have "blocking" and "non-blocking" hooks so you can trigger something like a device wake up (my use case) where moode would need to wait for completion or just be informed about an event and do something with that (idk. like updating your digital picture frame with the current album cover). Such a feature would enable many niche use cases that someone might have without having to build a full fledged plugin system.
I am currently trying to understand the code and am willing to contribute, but the first thing on my list is improving the mounts and general systemd integration.
I have currently scripted it with a service running on the device that waits for mpc events and triggers the USB wakeup and shutdown. But the wakeup is too late because mpd tries to connect to the output device before emitting the event. So for it to work flawlessly it would be required that moode waits for the USB to come up before actually sending the play command to mpd. That's why this feature request even exists.
As I said it doesn't need to be such a specialized feature. If it's reasonable to implement a hook system, that would actually be better because it's versatile and would enable users to implement their own stuff easily.
And by thinking about this, it would be nice to have "blocking" and "non-blocking" hooks so you can trigger something like a device wake up (my use case) where moode would need to wait for completion or just be informed about an event and do something with that (idk. like updating your digital picture frame with the current album cover). Such a feature would enable many niche use cases that someone might have without having to build a full fledged plugin system.
I am currently trying to understand the code and am willing to contribute, but the first thing on my list is improving the mounts and general systemd integration.
