Menu

#323 -R / --remote option regression

svn
closed-invalid
nobody
None
5
2021-10-23
2021-10-03
jvalkon
No

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.

Discussion

  • Thomas Orgis

    Thomas Orgis - 2021-10-03

    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 …

    $ src/mpg123 -t -R | while read n; do echo "mpg123 response: $n"; done
    load /path/to/file.mp3
    []
    mpg123 response: @F 3571 4 93.28 0.10
    mpg123 response: @F 3572 3 93.31 0.08
    mpg123 response: @F 3573 2 93.34 0.05
    mpg123 response: @F 3574 1 93.36 0.03
    mpg123 response: @F 3575 0 93.39 0.00
    mpg123 response: @P 0
    

    I get the status info just fine to stdout, or to stderr with --remote-err.

     
  • jvalkon

    jvalkon - 2021-10-04

    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

     
  • Thomas Orgis

    Thomas Orgis - 2021-10-04

    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?

     
    • jvalkon

      jvalkon - 2021-10-06

      Yes i can and i will, but not immediately, maybe next weekend

       
  • jvalkon

    jvalkon - 2021-10-06

    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

    06-10-2021, 17:47:48 ===== rr player started =====
    06-10-2021, 17:47:48 1 files added
    06-10-2021, 17:47:48 @R MPG123 (ThOr) v9
    06-10-2021, 17:47:48 -> 'LOAD 440.mp3'
    06-10-2021, 17:47:48 @I {
    06-10-2021, 17:47:48 @I ID3v2.title:440 Hertz test tone
    06-10-2021, 17:47:48 @I ID3v2.artist:Audacity
    06-10-2021, 17:47:48 @I ID3v2.album:Test tones
    06-10-2021, 17:47:48 @I ID3v2.year:2021
    06-10-2021, 17:47:48 @I ID3v2.comment:Generated with Audacity
    06-10-2021, 17:47:48 @I ID3v2.genre:Sound Clip
    06-10-2021, 17:47:48 @I }
    06-10-2021, 17:47:48 @P 2
    06-10-2021, 17:47:48 @S 1.0 3 44100 Single-Channel 0 104 1 0 0 0 32 0 1
    06-10-2021, 17:47:51 process_key: 51 '3'
    06-10-2021, 17:47:51 -> 'JUMP 345'
    06-10-2021, 17:47:51 @J 345
    06-10-2021, 17:47:52 process_key: 54 '6'
    06-10-2021, 17:47:52 -> 'JUMP 691'
    06-10-2021, 17:47:52 @J 691
    06-10-2021, 17:47:52 process_key: 57 '9'
    06-10-2021, 17:47:52 -> 'JUMP 1036'
    06-10-2021, 17:47:53 @J 1036
    06-10-2021, 17:47:55 @P 0
    06-10-2021, 17:47:55 -> 'QUIT'
    

    v1.26.5

    06-10-2021, 18:07:17 ===== rr player started =====
    06-10-2021, 18:07:17 1 files added
    06-10-2021, 18:07:17 @R MPG123 (ThOr) v8
    06-10-2021, 18:07:17 -> 'LOAD 440.mp3'
    06-10-2021, 18:07:17 @I ID3v2.title:440 Hertz test tone
    06-10-2021, 18:07:17 @I ID3v2.artist:Audacity
    06-10-2021, 18:07:17 @I ID3v2.album:Test tones
    06-10-2021, 18:07:17 @I ID3v2.year:2021
    06-10-2021, 18:07:17 @I ID3v2.comment:Generated with Audacity
    06-10-2021, 18:07:17 @I ID3v2.genre:Sound Clip
    06-10-2021, 18:07:17 @P 2
    06-10-2021, 18:07:17 @S 1.0 3 44100 Single-Channel 0 104 1 0 0 0 32 0 1
    06-10-2021, 18:07:20 process_key: 51 '3'
    06-10-2021, 18:07:20 -> 'JUMP 345'
    06-10-2021, 18:07:20 @J 345
    06-10-2021, 18:07:21 process_key: 54 '6'
    06-10-2021, 18:07:21 -> 'JUMP 691'
    06-10-2021, 18:07:21 @J 691
    06-10-2021, 18:07:21 process_key: 57 '9'
    06-10-2021, 18:07:21 -> 'JUMP 1036'
    06-10-2021, 18:07:21 @J 1036
    06-10-2021, 18:07:24 @P 0
    06-10-2021, 18:07:24 -> 'QUIT'
    
     

    Last edit: jvalkon 2021-10-06
  • Thomas Orgis

    Thomas Orgis - 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.

     
  • Thomas Orgis

    Thomas Orgis - 2021-10-23
    • status: open --> closed-invalid
     

Log in to post a comment.

Auth0 Logo