Attempting to move from MPD, questions regarding logging and streaming

[vevets]

[rant] MPDs alsa mixer control is horribly broken, and Max appears completely disinterested in fixing it or helping me to figure out where it’s borking - in fact he appears completely disinterested in being constructive in any way towards anyone for any reason, as browsing the MPD forum will quickly reveal.
The best I got was effectively “I copied that code from alsamixer and I don’t really know how it works, I use SPDIF anyway. Go read the code and figure it out yourself.”
After spending considerable time trying to debug code I don’t understand in a language I’m not familiar with, effectively unassisted, I’m over it. Time to look for another solution.
[/rant]

Mopidy can at least control my mixer properly, and otherwise seems rather nice, but there are two remaining hurdles holding up replacing MPD on my devuan beowulf systems:

1. With mopidy running as a traditional sysvinit service, how do I get it to log to a file or (better) to syslog, like every other service?
   ‘journalctl -u mopidy’ as mentioned in the docs obviously doesn’t work, as I am not running systemd.
   I see some scattered references to /etc/mopidy/logging.conf, but the file appears to be missing from current debian packages and I don’t see it in the release tarballs either.
   Can I just snag a copy from an old package and expect it to work, and to continue to work for the foreseeable future?
   Is there some documentation for this file somewhere that I am missing, or am I expected to learn python to get such a basic feature working?

2. What is the status of an MPD-compatible HTTP streaming output?
   I’d very much like to use the stream playback feature present in pretty much every MPD client, but all I can find is issues/56, which has been open since 2011(!) with no apparent interest.
   From what I can deduce icecast is the preferred solution, yet it looks like it still has a bunch of problems (primarily streams ending when they shouldn’t), and as far as I can tell? it’s not compatible with MPD clients anyway so I’d need not only additional server-side software but a separate client as well. That makes it extremely awkward and pretty much useless for my needs.
   Being able to simply select “Start Streaming” in MPDroid/MALP" or “Play HTTP Output Stream” in Cantata is the goal here, is there a way to do this with Mopidy?

[Christopher_Lowden]

I am a total tech newby but I have been able to deploy MDP on a PI4 in my bedroom that I can access, amongst anywhere in my flat, over http from anywhere in the world using snapcast and the Iris front end.
It works pretty well.

badaix/snapcast

aawsome/mopidy-snapcast

Mopidy-Iris

[vevets]

I’ve seen both of those. Valid suggestions indeed, but not really what I’m asking.

Iris is nice, though overkill for my needs as I really don’t need a webui. Also the requirement to run on a high/unprivileged port or proxy behind a full webserver is pretty annoying. It’s a nice bonus, but it doesn’t help with logging to a file or HTTP streaming to an MPD client.

Snapcast is overkill as well TBH, I have no need at all for synchronised audio. Simple flac/ogg over HTTP would do just fine.
It’s also just as non-compatible with MPD streaming as icecast is, and would likewise require a separate client.

And no, in before someone asks, I do not consider a web browser a suitable client in this instance. I’ll want to be able control it from a remote CLI, which is why I’m using the MPD protocol in the first place.

As you might guess from the above, I’m kinda trying to keep the bloat to a minimum here. One of the machines I would want to run this on is considerably slower than a Pi4, and I don’t exactly need snapcast, icecast, or a webserver eating into my precious 512MB of RAM either.

Really, I just want to play FLAC files from my local fileserver, on an old-school PCI soundcard (with hardware mixer), and occasionally stream it to my mobile or desktop with the standard MPD client features. I’m kinda wondering why that is such a big ask.
Is it really ARM SBCs and web browsers all the way down these days or what?

Aside, how the hell does anyone stay sane on this discourse thing? All this animating fading popping-in dynamic-loading magic-disappearing-buttons nonsense is giving me one mother of a headache… Not to mention all the gratuitous empty whitespace. I think I’m going snowblind.

[kingosticks]

We no longer ship a /etc/mopidy/logging.conf file. Here’s an example one you could use:

[loggers]
keys = root

[logger_root]
handlers = myHandler

[handlers]
keys = myHandler

[formatters]
keys = simpleFormatter

[handler_myHandler]
class = handlers.RotatingFileHandler
formatter = simpleFormatter
level = INFO
args = ('/tmp/mopidy-info.log','a',1024*1024*10,1,)

[formatter_simpleFormatter]
format = %(asctime)s %(levelname)s [%(process)d:%(threadName)s] %(name)s: %(message)s

A syslog one would be very similar but with a tweaked [handler_myHandler] section, maybe something like this (I’ve not tested this one):

[handler_myHandler]
class = handlers.SysLogHandler
formatter = simpleFormatter
level = INFO
args = ('/dev/log', 'local0')

You can see all the handlers and their arguments at logging.handlers — Logging handlers — Python 3.9.2 documentation.

Make sure you point to this /etc/mopidy/logging.conf file using the config_file setting in the [logging] section of your main Mopidy config file. For example:

[logging]
config_file = /etc/mopidy/logging.conf

We don’t have a solution for HTTP streaming.