GioF71 / mpd-alsa-docker

Easily run mpd with Alsa or PulseAudio output with Docker. Upsampling 2x 4x 8x with "Goldilocks" settings by Archimago. Scrobbling support.
Apache License 2.0
20 stars 7 forks source link

[Enhancement] Add support for always_on option for shout output #355

Closed vari closed 10 months ago

vari commented 10 months ago

As per the MPD docs, it is possible to set the always_on flag for all output plugins.

It would be great if we can add another env variable for the shout plugin which lets users specify the value for always_on for shout output. Looking at the build_additional.sh script, it seems like this should be a one line code change.

In terms of defaults, I think yes would make sense since shout is typically used for streaming to Icecast/shoutcast and hence having always on is a reasonable default (to ensure the stream is always active).

Additionally, it would be great if we could consider adding an environment variable which will disable the default generation of the mpd.conf file so that users can supply their own mpd.conf file if desired (which should future proof things/provide a workaround for any options that cannot be set via env vars currently)

GioF71 commented 10 months ago

Hello, please try one of the images here

About the other request, you are not the first to ask this, but I never agreed to the change. Thinking again, maybe one variable specifiying the user-provided config file is an easy change. The whole purpose of this container image is to NOT having to build your own mpd.conf file but instead to instruct to script to do that for us. But yes, I will do that after all, please open a separate issue so we can keep track of the changes.

What has always stopped me from doing that is the possibility to receive, after the change, complaints for non working configurations. MPD is quite articulate in its configuration.

vari commented 10 months ago

The image you linked worked! Thanks for the quick response 😄

I created #356 for providing a custom mpd.conf file.

I understand and agree with your rationale of avoiding complaints for non-working configurations, but I think if you preface the docs regarding the new environment variable to explicitly say "use at own risk" / only use if no other existing env vars work for your use case, you may be able to avoid most of the complaints. I like the idea of having it as a backup option, just in case it is needed but definitely don't see it as the primary way people should be using this container.

GioF71 commented 10 months ago

Branch merged, new images building now!