-R / --remote option regression
Brought to you by:
sobukus
mpg123 has a remote option (-R / --remote) to allow external frontends to communicate with a forked mpg123 process.
Somewhere after version 1.26.5 a regression has been introduced, a working frontend no longer receives information / statusinfo from a running mpg123 process. It is playing fine (i.e. there is audio and it correctly responds to commands via the remote interface) but the returned statusinfo is not sent/received correctly. Version 1.26.5 still works ok.
If i remember correctly, mpg123 uses stderr to send statusinfo to the controlling front-end. Maybe recent changes introduced an alternative use of stderr that conflicts with the remote option.
Can you give some more detail? Are you using the --remote-err switch? I just did a quick check and I normally get the status info with all feedback on stdout. This changes to stderr with the switch. I remember implementing it that way. But maybe the simple test in an interactive terminal is different from your use case …
I get the status info just fine to stdout, or to stderr with
--remote-err.Ok, user error, i missed out on the --remote-err option. There's still something different than before (i.e. playing doesn't start) but i think i can handle that on the front-end part. Maybe some change in the sequence of msgs, i'll check the logging.
Issue can be closed, thanks for your reply
Could you still please confirm if there is an actual behavioural change in mpg123? Did you get the progress information on stderr by default with your old build of mpg123?
Yes i can and i will, but not immediately, maybe next weekend
Ok i found some time. It is unrelated to stderr usage.
It looks as though the remote @I statusmessage has 2 new entries which the client's parser did not (yet) expect:
@I {
and
@I }
In older versions of mpg123 these were not present (i tried, see below).
I relaxed the parser function in the clientcode and now it works again.
I leave it up to you to decide to call this a 'regression' :)
For my part this issue can be closed.
v1.29
v1.26.5
Last edit: jvalkon 2021-10-06
Yeah, in v9 of the API, I added the brace delimiters to all multiline outputs to indicate to the client when the full response is received. To a very strict parser, this can be upsetting, but I did not expect mpg123 remote control users to be that strict. See doc/README.remote for the changes in the differing versions and the rationale behind them.
Anyhow: If you see the info string with v9 in the greeting, you should expect the delimiters for safer communication. If you just ignore them, you stay compatible to older mpg123. You can also parse them opportunistically: If there's an opening brace, wait for the closing one.