mpg123-users — Mailing list for users of mpg123

[mpg123-users] mpg123 1.33.0 released

[Thomas O. <tho...@or...>]

Dear mpg123 afictionados,

after some messing around, there is a new mpg123 release now. The
question is still open how we continue with Windows binaries. Right
now, there are no new ones for this release. If anyone wants to build
the set: the Script windows-builds.sh in the archive helps with that,
be it in MSYS2 or via mingw-w64 cross toolchain.

But to the changes, as there are a few:

1.33.0
------
- mpg123
-- Fix printout of filenames at end (convert/limit text encoding).
-- Treat HTTP header encoding as unknown/ASCII and formally convert to UTF-8.
-- Make --continue mode work with --random.
-- Handle possible failure of __wgetmainargs on Windows (bug 375).
- mpg123-id3dump: Fix up command line arg handling for Windows.
- out123
-- Finally give zero exit code when generating sounds, not indicating
   spurious failure.
- build:
-- Use CCASFLAGS for assembler tests, to enable builds that enable instruction
   sets that way (bug 377).
-- PIC for compat libs (convenience libs used during build) only if building
   shared libs (github PR 17 by Wouter Wijsman).
- compat:
-- Map strtok use to strtok_r or strtok_s (MS platforms), if possible.
   users only in control_generic and libout123 so far. Out123 itself uses mytok.
   Shall fix bug 376 (build with MSVC again).
-- Enable build on PSP by merging in the hotfix of opmitting signal code
   (github PR 18 by Wouter Wijsman).
- libout123
-- modules/win32: Align waveOutGetDevCapsA to WAVEOUTCAPSA, in anticipation
   of some UNICODE change.
- libmpg123
-- API version 49 with added mpg123_open_handle64(), mpg123_open64(), and
   mpg123_open_fixed64() that are not subject to largefile renaming. This
   means you can still access internal I/O with MPG123_PORTABLE_API. The
   code has been there before, anyway.
-- With MPG123_PORTABLE_API, mpg123_open_handle() is hidden now (use
   mpg123_open_handle64() instead).
-- more silence on errors (sideband limit message)


Find it at the usual places and have fun, with mpg123 or in other ways …


Alrighty then,

Thomas

Re: [mpg123-users] For mpg123 users on MS Windows: wildcard expansion in the program or not?

[Thomas O. <tho...@or...>]

Am Thu, 8 May 2025 19:32:19 +0200
schrieb Martin Guy <mar...@gm...>: 

> I think that every program having to expand wildcards itself is usual

That's why I asked if users expect that from mpg123 or not. As in …
they could rely for some tool not to re-interpret wildcards. Real
trouble seems to come from programs taking some parametersr that shall
expand to file paths and others that are endangered of
misinterpretation … 

Anyhow, mpg123 will just keep it as-is. It's interpreting wildcards and
has so far no non-file arguments that are fuzzed up by wildcard
characters.

Note for Windows users: As of now, there won't be new official binaries
released on the mpg123 website. Anyone wanting to provide their own to
the public, within some packaging system or not, is invited to do so.
The full build only works in the mingw-w64 environment using the
autotools system, the libraries can be built in MSVC using CMake
(ports/cmake subdirectory).


Alrighty then,

Thomas

Re: [mpg123-users] For mpg123 users on MS Windows: wildcard expansion in the program or not?

[Martin G. <mar...@gm...>]

On 02/05/25 11:25, Thomas Orgis wrote:
> during reworking of entry points with better Unicode command line
> argument handling on MS Windows the question occured whether mpg123
> should enforce wildcard expansion of arguments or not.


I think that every program having to expand wildcards itself is usual

on Vindov, unfortunately. Each in a slightly different way, of course.


     M

[mpg123-users] For mpg123 users on MS Windows: wildcard expansion in the program or not?

[Thomas O. <tho...@or...>]

Dear mpg123 users on Windows,

during reworking of entry points with better Unicode command line
argument handling on MS Windows the question occured whether mpg123
should enforce wildcard expansion of arguments or not. On Linux, I am
used to the shell doing the wildcard expansion vom *.mp3 to a list of
files. On Windows, this usually does not happen. Depending on defaults
in the mingw toolchain, the reworked mpg123 binary might stop resolving
calls like

	mpg123 C:\dir\*.mp3

to play the list of files in the directory. There are ways to make it
resolve wildcards, but they have at least theoretical drawbacks.

The state in current trunk enforces wildcard expansion through a
somewhat hidden function of the Windows API that even changed its
prototype between Windows versions. This is dirty. But the alternative
may also have some dirt should we enforce wildcard expansion.

Before coming to a decision what to do there: What do the users say? Is
wildcard expansion something even relevant in your usage of mpg123.exe?
Are there examples of programs in a similar place that do or do not
expand them? What is the proper behaviour on that platform?


Alrighty then,

Thomas

Re: [mpg123-users] How to use a play list in remote mode?

[Thomas O. <tho...@or...>]

Am 5. April 2025 11:12:25 MESZ schrieb Seamus de Mora <sea...@gm...>:
>I just ran across this post, and wanted to share it with you :)
>
>>>> Why won't popen communicate with mpg123?
><https://stackoverflow.com/a/33862937/22595851>

Yes, this looks like my socat example. Chose what looks easiest to you.


Alrighty then,

Thomas

Re: [mpg123-users] How to use a play list in remote mode?

[Seamus de M. <sea...@gm...>]

On Thu, Apr 3, 2025 at 1:19 AM Seamus de Mora <sea...@gm...>
wrote:

> On Tue, Apr 1, 2025 at 5:03 AM Thomas Orgis <tho...@or...>
> wrote:
>
>> Am Mon, 31 Mar 2025 20:12:40 -0500
>> schrieb Seamus de Mora <sea...@gm...>:
>>
>> > Is is accurate to summarize what you've said as follows?:
>> >
>> >    - As of today, loop-playing a playlist using the remote mode is not
>> >    possible; only the terminal mode can accommodate this.
>> >    - Loop-playing via remote mode might be added at some point in the
>> >    future.
>>
>> Yes. But also, looping applies to tracks, not whole playlists. So you'd
>> need to apply the overall loop on the outside. What we have is endless
>> random play (--random). Maybe you mean that?
>>
>
> Yes - I just looked up '--random' in 'man mpg123'. That seems a very good
> option for a typical case of someone listening to popular music (like my
> son).
>
> > If this is an accurate synopsis, can you give me a clue or two on what a
>> > 'terminal-mode' command to loop-play a list would look like?
>>
>> Your case seems to me like it could be covered by running
>>
>> mpg123 --continue --listentry $track --skip $position plist.m3u
>>
>
> So - is there no possibility to use the 'PAUSE/P: pause playback' command
> from the remote?
>
> and just killing (SIGINT) mpg123 when the button is pressed,
>> remembering the info printed for CONTINUE, like
>>
>> cont=$(mpg123 --continue --listentry "$track" --skip "$frames" -@
>> /dev/shm/plist.m3u )
>>
>> then parse $cont value, which looks like
>>
>> [CONTINUE] track 27 frame 376
>>
>> Those two numbers give the position to resume playback on the next
>> button press, which just starts mpg123 anew.
>>
>> You need some scripting around that, but not too much.
>>
>> > tell me if the aforementioned "loop-play-via-terminal-mode" could be
>> paused
>> > via the 'remote-mode` command for 'PAUSE/P'??
>> > i.e. 'echo "pause" > /tmp/mpg123_fifo'
>>
>> pkill -INT mpg123
>>
>> would be the simple approach (more sophistication: Remember the PID of
>> the process and specifically kill that). Then start mpg123 again on
>> un-pause.
>>
>> I realize that the --random mode doesn't interact nicely with
>> --continue right now. The latter was coded for someone playing folders
>> of audiobook pieces, where everything needs to be in order. I need to
>> fix it so that --listentry is honoured properly also with random and
>> shuffled play. For now, if you do want random playback, you could
>> randomize your playlist beforehand and let mpg123 play it in order. If
>> the CONTINUE info tells you that the list ended (track > number of
>> tracks in list), you reset it to 1 and start again with the same or a
>> newly shuffled list. This is suboptimal regarding perceived randomness,
>> but should serve until next minor mpg123 release fixes things.
>>
>> Before adding playlists to remote control mode, it needs to be decided,
>> if and how --random and --shuffle command-line switches would apply
>> there, or if there are commands to enable/disable these modes.
>>
>
I just ran across this post, and wanted to share it with you :)

>>> Why won't popen communicate with mpg123?
<https://stackoverflow.com/a/33862937/22595851>

Re: [mpg123-users] How to use a play list in remote mode?

[Thomas O. <tho...@or...>]

Am Thu, 3 Apr 2025 01:19:09 -0500
schrieb Seamus de Mora <sea...@gm...>: 
> 
> So - is there no possibility to use the 'PAUSE/P: pause playback' command
> from the remote?

What is missing is the playlist handling in remote mode. Or the remote
mode in the normal operation. But then … as you are not interested in
responses, you can simply automate the normal terminal control using
socat with pty.

For example this command line

	(sleep 3; echo ' '; sleep 3; echo ' '; sleep 3) \
	| socat - "EXEC:mpg123 -q --random -@ test.m3u",pty,ctty,stderr

(without the leading tabs, of course) will open the playlist test.m3u
and then play for 3 seconds, then pause for 3 seconds, then play for 3
seconds and quit because the input stream to socat ended.

Your task would be to write the script before the | socat, reacting to
your button event (however it arrives in your system) and printing out
<space><endofline> each time, instead of printing to the fifo before.

This is one option. Another option is a little wrapper over --continue
mode that just kills mpg123 and remembers the position, then starts it
again. This needs some shell/perl/python programming as glue, but is
perfectly doable.

> I don't know Thomas... after reading this "terminal mode work-around", I am
> feeling a bit confused. If there's no way to simply add an option to the
> 'remote-mode' that will play a designated playlist, 

There is a way, and I might be prompted to program it. But not today. I
need to fight for my programming time with real life, like so many
others …

At least I fixed --random together with --continue in the development
trunk now. The socat hack above doesn't need that, though. Some playing
around with the Unix toolset should get you there!


Alrighty then,

Thomas

Re: [mpg123-users] How to use a play list in remote mode?

[Seamus de M. <sea...@gm...>]

On Tue, Apr 1, 2025 at 5:03 AM Thomas Orgis <tho...@or...> wrote:

> Am Mon, 31 Mar 2025 20:12:40 -0500
> schrieb Seamus de Mora <sea...@gm...>:
>
> > Is is accurate to summarize what you've said as follows?:
> >
> >    - As of today, loop-playing a playlist using the remote mode is not
> >    possible; only the terminal mode can accommodate this.
> >    - Loop-playing via remote mode might be added at some point in the
> >    future.
>
> Yes. But also, looping applies to tracks, not whole playlists. So you'd
> need to apply the overall loop on the outside. What we have is endless
> random play (--random). Maybe you mean that?
>

Yes - I just looked up '--random' in 'man mpg123'. That seems a very good
option for a typical case of someone listening to popular music (like my
son).

> If this is an accurate synopsis, can you give me a clue or two on what a
> > 'terminal-mode' command to loop-play a list would look like?
>
> Your case seems to me like it could be covered by running
>
> mpg123 --continue --listentry $track --skip $position plist.m3u
>

So - is there no possibility to use the 'PAUSE/P: pause playback' command
from the remote?

and just killing (SIGINT) mpg123 when the button is pressed,
> remembering the info printed for CONTINUE, like
>
> cont=$(mpg123 --continue --listentry "$track" --skip "$frames" -@
> /dev/shm/plist.m3u )
>
> then parse $cont value, which looks like
>
> [CONTINUE] track 27 frame 376
>
> Those two numbers give the position to resume playback on the next
> button press, which just starts mpg123 anew.
>
> You need some scripting around that, but not too much.
>
> > tell me if the aforementioned "loop-play-via-terminal-mode" could be
> paused
> > via the 'remote-mode` command for 'PAUSE/P'??
> > i.e. 'echo "pause" > /tmp/mpg123_fifo'
>
> pkill -INT mpg123
>
> would be the simple approach (more sophistication: Remember the PID of
> the process and specifically kill that). Then start mpg123 again on
> un-pause.
>
> I realize that the --random mode doesn't interact nicely with
> --continue right now. The latter was coded for someone playing folders
> of audiobook pieces, where everything needs to be in order. I need to
> fix it so that --listentry is honoured properly also with random and
> shuffled play. For now, if you do want random playback, you could
> randomize your playlist beforehand and let mpg123 play it in order. If
> the CONTINUE info tells you that the list ended (track > number of
> tracks in list), you reset it to 1 and start again with the same or a
> newly shuffled list. This is suboptimal regarding perceived randomness,
> but should serve until next minor mpg123 release fixes things.
>
> Before adding playlists to remote control mode, it needs to be decided,
> if and how --random and --shuffle command-line switches would apply
> there, or if there are commands to enable/disable these modes.


I don't know Thomas... after reading this "terminal mode work-around", I am
feeling a bit confused. If there's no way to simply add an option to the
'remote-mode' that will play a designated playlist, then perhaps I should
try to find a different player. I'll try your suggestions, and attempt to
weigh it all up over the next few days...

But in any case, I appreciate the time and effort you've put into these
answers and suggestions!

Best Regards,
~S

Re: [mpg123-users] How to use a play list in remote mode?

[Thomas O. <tho...@or...>]

Am Mon, 31 Mar 2025 20:12:40 -0500
schrieb Seamus de Mora <sea...@gm...>: 

> Is is accurate to summarize what you've said as follows?:
> 
>    - As of today, loop-playing a playlist using the remote mode is not
>    possible; only the terminal mode can accommodate this.
>    - Loop-playing via remote mode might be added at some point in the
>    future.

Yes. But also, looping applies to tracks, not whole playlists. So you'd
need to apply the overall loop on the outside. What we have is endless
random play (--random). Maybe you mean that?

> If this is an accurate synopsis, can you give me a clue or two on what a
> 'terminal-mode' command to loop-play a list would look like?

Your case seems to me like it could be covered by running

mpg123 --continue --listentry $track --skip $position plist.m3u

and just killing (SIGINT) mpg123 when the button is pressed,
remembering the info printed for CONTINUE, like

cont=$(mpg123 --continue --listentry "$track" --skip "$frames" -@ /dev/shm/plist.m3u )

then parse $cont value, which looks like 

[CONTINUE] track 27 frame 376

Those two numbers give the position to resume playback on the next
button press, which just starts mpg123 anew.

You need some scripting around that, but not too much.

> tell me if the aforementioned "loop-play-via-terminal-mode" could be paused
> via the 'remote-mode` command for 'PAUSE/P'??
> i.e. 'echo "pause" > /tmp/mpg123_fifo'

pkill -INT mpg123

would be the simple approach (more sophistication: Remember the PID of
the process and specifically kill that). Then start mpg123 again on
un-pause.

I realize that the --random mode doesn't interact nicely with
--continue right now. The latter was coded for someone playing folders
of audiobook pieces, where everything needs to be in order. I need to
fix it so that --listentry is honoured properly also with random and
shuffled play. For now, if you do want random playback, you could
randomize your playlist beforehand and let mpg123 play it in order. If
the CONTINUE info tells you that the list ended (track > number of
tracks in list), you reset it to 1 and start again with the same or a
newly shuffled list. This is suboptimal regarding perceived randomness,
but should serve until next minor mpg123 release fixes things.

Before adding playlists to remote control mode, it needs to be decided,
if and how --random and --shuffle command-line switches would apply
there, or if there are commands to enable/disable these modes.


Alrighty then,

Thomas

Re: [mpg123-users] How to use a play list in remote mode?

[Seamus de M. <sea...@gm...>]

On Mon, Mar 31, 2025 at 3:56 PM Thomas Orgis <tho...@or...> wrote:

> Am Sun, 30 Mar 2025 20:05:14 -0500
> schrieb Seamus de Mora <sea...@gm...>:
>
> > Yes - I can see that would complicate things. However, in my case I do
> not
> > need "both sides" controlling the playing;
> > i.e. *"if <remote mode>; then <disable local mode>; fi"*
> > This is how I *imagined* it would work. I am not a fan of complexity!
>
> Well, the implementation is different. The remote control mode is
> kindof a separate main program, its own control loop, where the normal
> mpg123 control flow, optionally with terminal control keys, is a
> different one.
>
> > So - First: what is '$n' in your loadlist command? - does it refer to a
> > single line/track from 'playlist.m3u' ?  (sorry, but the remote help is
> > unclear to me in this respect)
>
> $n is any number between 1 and the number of tracks in the list,
> causing mpg123 to start playing that track from the list. The value 0
> would start the last track, -1 causes the listing only.
>
> > Another question is wrt the meaning of '<url>'. Is this for playing a
> > "streaming radio station"??
>
> This means any file path or HTTP(S) URL for remote playlists. Playlist
> support is strongly linked to web radio streams, as they usually come
> in form of a playlist URL.
>
> > I don't follow this command...  I tried it on my system; I got no errors,
> > and no response. ?
> > […]
> > pi@rpi3a:~/soundfiles $ playlist=$(echo loadlist -1
> > /home/pi/soundfiles/plist.m3u | mpg123 -R - | grep '^@I LISTENTRY' | cut
> -f
> > 4- -d ' ')
>
> It just stores the playlist in the variable named 'playlist'.
>
> $ echo "$playlist"
>
> should print something. But working with this relies on your track file
> names not having spaces in them, so is fragile.
>
> > Here's the result in terminal 1:
> >
> > @I {
> > @I LISTENTRY 1: /home/pi/soundfiles/Sinatra-Morning.mp3
> > @I LISTENTRY 2: /home/pi/soundfiles/Sinatra-String.mp3
> > @I LISTENTRY 3: /home/pi/soundfiles/Sinatra-TakeAway.mp3
> > @I LISTENTRY 4: /home/pi/soundfiles/Sinatra-Watch.mp3
> > @I }
>
> This is your playlist, parsed by mpg123 code. Of course not that useful
> for simple m3u files without comments, etc.
>
> > And then again from terminal 2, the ONLY thing that seemed to yield a
> > result was this:
> >
> > 'echo "load /home/pi/soundfiles/Sinatra-Morning.mp3" > /tmp/mpg123_fifo'
>
> Though
>
>         loadlist 1 plist.m3u
>
> should do the same. If not, I got a serious bug at my hands.
>
> > IOW - I can find no way to initiate playing a list via the (-R) remote
> > mode; this is what I need to be able to do. ???
>
> Currently, you can issue the playing of a single track from the list
> only. Your frontend script would need to wait until mpg123 signals end
> of playback and then issue loading of the next track.
>
> > And just one other Q re remote mode (-R)...  when I did manage to play a
> > song, <MANY> of these strings appeared in terminal 1:
> >
> > ...
> > @F 6484 448 169.38 11.70
> > @F 6485 447 169.40 11.68
> > @F 6486 446 169.43 11.65
> > ...
> >
> > How do I stop this?
>
> silence
>
> (see `help silence').
>
> > No - I'm not interested in "fine-grained control of playback"; as I said
> > I'd like to have a command (remote or otherwise) that simply "loop
> plays" a
> > playlist from beginning to end, and recognizes a "pause" command to
> toggle
> > the playback process.
>
> Ah … you want the playlist in a loop? Or shuffled? There's a number of
> options there. Right now the only way to have mpg123 play a list of
> files by itself is running it normal/terminal control mode (which you
> could also automate, btw.). If we add playlist playing to the remote
> control mode, looping and shuffling should also be included, probably
> via extra commands. This is not too bad, as the concerned code has been
> factored out of the main program in the meantime, just the clear demand
> should be there. I'm not totally opposed to doing that, it's not really
> hard and a detour from that Windows portability mess.
>
> > WRT "--continue mode", I see nothing about continue mode in the remote
> > help... are you suggesting that from 'terminal 1' I enter this?:
>
> This is something independent of remote control mode. See --continue in
> the man page. It results in something like
>
> [CONTINUE] track 3 frame 3083
>
> being printed when mpg123 is interrupted (`pkill -INT mpg123` works,
> too). You can use this data to re-start mpg123 on the correct track and
> offset again.


Is is accurate to summarize what you've said as follows?:

   - As of today, loop-playing a playlist using the remote mode is not
   possible; only the terminal mode can accommodate this.
   - Loop-playing via remote mode might be added at some point in the
   future.

If this is an accurate synopsis, can you give me a clue or two on what a
'terminal-mode' command to loop-play a list would look like? And can you
tell me if the aforementioned "loop-play-via-terminal-mode" could be paused
via the 'remote-mode` command for 'PAUSE/P'??
i.e. 'echo "pause" > /tmp/mpg123_fifo'

And of course, any comments you care to add re how to "automate" this
'terminal-mode' approach would be much appreciated!

Thanks again for your time :)

Re: [mpg123-users] How to use a play list in remote mode?

[Thomas O. <tho...@or...>]

Am Sun, 30 Mar 2025 20:05:14 -0500
schrieb Seamus de Mora <sea...@gm...>: 

> Yes - I can see that would complicate things. However, in my case I do not
> need "both sides" controlling the playing;
> i.e. *"if <remote mode>; then <disable local mode>; fi"*
> This is how I *imagined* it would work. I am not a fan of complexity!

Well, the implementation is different. The remote control mode is
kindof a separate main program, its own control loop, where the normal
mpg123 control flow, optionally with terminal control keys, is a
different one.

> So - First: what is '$n' in your loadlist command? - does it refer to a
> single line/track from 'playlist.m3u' ?  (sorry, but the remote help is
> unclear to me in this respect)

$n is any number between 1 and the number of tracks in the list,
causing mpg123 to start playing that track from the list. The value 0
would start the last track, -1 causes the listing only.

> Another question is wrt the meaning of '<url>'. Is this for playing a
> "streaming radio station"??

This means any file path or HTTP(S) URL for remote playlists. Playlist
support is strongly linked to web radio streams, as they usually come
in form of a playlist URL.

> I don't follow this command...  I tried it on my system; I got no errors,
> and no response. ?
> […]
> pi@rpi3a:~/soundfiles $ playlist=$(echo loadlist -1
> /home/pi/soundfiles/plist.m3u | mpg123 -R - | grep '^@I LISTENTRY' | cut -f
> 4- -d ' ')

It just stores the playlist in the variable named 'playlist'.

$ echo "$playlist"

should print something. But working with this relies on your track file
names not having spaces in them, so is fragile.

> Here's the result in terminal 1:
> 
> @I {
> @I LISTENTRY 1: /home/pi/soundfiles/Sinatra-Morning.mp3
> @I LISTENTRY 2: /home/pi/soundfiles/Sinatra-String.mp3
> @I LISTENTRY 3: /home/pi/soundfiles/Sinatra-TakeAway.mp3
> @I LISTENTRY 4: /home/pi/soundfiles/Sinatra-Watch.mp3
> @I }

This is your playlist, parsed by mpg123 code. Of course not that useful
for simple m3u files without comments, etc.

> And then again from terminal 2, the ONLY thing that seemed to yield a
> result was this:
> 
> 'echo "load /home/pi/soundfiles/Sinatra-Morning.mp3" > /tmp/mpg123_fifo'

Though

	loadlist 1 plist.m3u

should do the same. If not, I got a serious bug at my hands.

> IOW - I can find no way to initiate playing a list via the (-R) remote
> mode; this is what I need to be able to do. ???

Currently, you can issue the playing of a single track from the list
only. Your frontend script would need to wait until mpg123 signals end
of playback and then issue loading of the next track.

> And just one other Q re remote mode (-R)...  when I did manage to play a
> song, <MANY> of these strings appeared in terminal 1:
> 
> ...
> @F 6484 448 169.38 11.70
> @F 6485 447 169.40 11.68
> @F 6486 446 169.43 11.65
> ...
> 
> How do I stop this?

silence

(see `help silence').

> No - I'm not interested in "fine-grained control of playback"; as I said
> I'd like to have a command (remote or otherwise) that simply "loop plays" a
> playlist from beginning to end, and recognizes a "pause" command to toggle
> the playback process.

Ah … you want the playlist in a loop? Or shuffled? There's a number of
options there. Right now the only way to have mpg123 play a list of
files by itself is running it normal/terminal control mode (which you
could also automate, btw.). If we add playlist playing to the remote
control mode, looping and shuffling should also be included, probably
via extra commands. This is not too bad, as the concerned code has been
factored out of the main program in the meantime, just the clear demand
should be there. I'm not totally opposed to doing that, it's not really
hard and a detour from that Windows portability mess.

> WRT "--continue mode", I see nothing about continue mode in the remote
> help... are you suggesting that from 'terminal 1' I enter this?:

This is something independent of remote control mode. See --continue in
the man page. It results in something like

[CONTINUE] track 3 frame 3083

being printed when mpg123 is interrupted (`pkill -INT mpg123` works,
too). You can use this data to re-start mpg123 on the correct track and
offset again.


Alrighty then,

Thomas

Re: [mpg123-users] How to use a play list in remote mode?

[Seamus de M. <sea...@gm...>]

>
> On Sun, Mar 30, 2025, 6:53 AM Thomas Orgis <tho...@or...> wrote:
>
>>
>> PS: It comes up again and again that the evolved player logic should be
>> combined with other audio decoders besides libmpg123. Maybe, one of
>> those days, the decoder library will have to be shipped as a separate
>> package and mpg123 becomes music player general 1, 2, 3 …
>>
>
Or, maybe just add a 'libflac123'?...  or a 'libcodec123' ?  :)
The mind boggles at the possibilities!

Re: [mpg123-users] How to use a play list in remote mode?

[Seamus de M. <sea...@gm...>]

Hello Thomas & Alan, and thank you for taking the time to reply.

First - Thank you for 'mpg123'; I've used it every day for nearly a year
now, and it meets 100% of my needs... it's my *non-cognoscenti* son that I
am trying to accomodate here  :)

On Sun, Mar 30, 2025, 6:53 AM Thomas Orgis <tho...@or...> wrote:
>
>> Hi!
>>
>> Am Sat, 29 Mar 2025 18:57:26 -0500
>> schrieb Seamus de Mora <sea...@gm...>:
>>
>> > In my reading of earlier posts in this thread, I gather that there are
>> no
>> > plans to incorporate a "playlist" feature into the "remote mode" - as
>> it is
>> > implemented in the "local mode"... is that correct?
>>
>> Indeed. The idea of the remote control mode is that you do the
>> controlling of playback. Working on a playlist makes the player open
>> and play tracks itself, complicating matters as both sides now could
>> cause loading of new tracks. Of course it's possible to combine all
>> features, but complex control flow breeds complex issues.
>>
>
Yes - I can see that would complicate things. However, in my case I do not
need "both sides" controlling the playing;
i.e. *"if <remote mode>; then <disable local mode>; fi"*
This is how I *imagined* it would work. I am not a fan of complexity!

If there is a strong use case where you want playback control, but
>> leave playlist control to mpg123, perhaps with added commands to
>> influence that, it might be considered. If you observe that gapless
>> playback of continuing tracks doesn't work well otherwise, that could
>> be something that bugs me. But I suppose things would still be fast
>> enough.
>>
>
Yes - I think we are "on the same page" :)

Your control program can use loadlist to parse the list and return
>> the paths to play, but your program controls when which track is
>> played. You could do
>>
>> loadlist $n playlist.m3u
>>
>
That might work, but I need to ask for some clarification on the "remote
help" for 'loadlist'... Here's what I see in my terminal when I run:

$ mpg123 -R --fifo /tmp/mpg123_fifo
$ echo "help" > /tmp/mpg123_fifo

@H {
...
@H LOADLIST/LL <entry> <url>: load a playlist from given <url>, and display
its entries, optionally load and play one of these specificed by the
integer <entry> (<0: just list, 0: play last track, >0:play track with that
position in list)
...
@H PAUSE/P: pause playback
...

So - First: what is '$n' in your loadlist command? - does it refer to a
single line/track from 'playlist.m3u' ?  (sorry, but the remote help is
unclear to me in this respect)

Second, I do not need a display of entries from 'mpg123' as none of this
will be visible to "the user" (my son). What I would like is instead of
'$n' (a track number from the .m3u file?) :
... Perhaps a *'$*'* to indicate that *the "entire list" is to be played???*
Do you foresee any complications arising from a change such as this?

Another question is wrt the meaning of '<url>'. Is this for playing a
"streaming radio station"??

to play the respective track, though I probably would just use
>>
>> playlist=$(echo loadlist -1 playlist.m3u | mpg123 -R - |grep '^@I
>> LISTENTRY' | cut -f 4- -d ' ')
>
>
I don't follow this command...  I tried it on my system; I got no errors,
and no response. ?

pi@rpi3a:~/soundfiles $ pwd
/home/pi/soundfiles
pi@rpi3a:~/soundfiles $ ls -1
'In the Middle of a Dream.mp3'
'Milenberg Joys Pt1.mp3'
'Milenberg Joys Pt2.mp3'
plist.m3u
rain-short.mp3
rainstorm.mp3
Sinatra-Morning.mp3
Sinatra-String.mp3
Sinatra-TakeAway.mp3
Sinatra-Watch.mp3
pi@rpi3a:~/soundfiles $ cat plist.m3u
/home/pi/soundfiles/Sinatra-Morning.mp3
/home/pi/soundfiles/Sinatra-String.mp3
/home/pi/soundfiles/Sinatra-TakeAway.mp3
/home/pi/soundfiles/Sinatra-Watch.mp3
pi@rpi3a:~/soundfiles $ playlist=$(echo loadlist -1
/home/pi/soundfiles/plist.m3u | mpg123 -R - | grep '^@I LISTENTRY' | cut -f
4- -d ' ')

I also tried 'echo "loadlist -1 plist.m3u" > /tmp/mpg123_fifo' without
success.
Let me explain how I set up for this:

two terminal windows open to host
at terminal 1, I enter: 'mpg123 -R --fifo /tmp/mpg123_fifo'
at terminal 2, I enter: 'echo "loadlist -1 plist.m3u" > /tmp/mpg123_fifo'

Here's the result in terminal 1:

@I {
@I LISTENTRY 1: /home/pi/soundfiles/Sinatra-Morning.mp3
@I LISTENTRY 2: /home/pi/soundfiles/Sinatra-String.mp3
@I LISTENTRY 3: /home/pi/soundfiles/Sinatra-TakeAway.mp3
@I LISTENTRY 4: /home/pi/soundfiles/Sinatra-Watch.mp3
@I }

And then again from terminal 2, the ONLY thing that seemed to yield a
result was this:

'echo "load /home/pi/soundfiles/Sinatra-Morning.mp3" > /tmp/mpg123_fifo'

IOW - I can find no way to initiate playing a list via the (-R) remote
mode; this is what I need to be able to do. ???

And just one other Q re remote mode (-R)...  when I did manage to play a
song, <MANY> of these strings appeared in terminal 1:

...
@F 6484 448 169.38 11.70
@F 6485 447 169.40 11.68
@F 6486 446 169.43 11.65
...

How do I stop this?

or such if I really do not want to do the m3u/pls parsing myself and
>> give the main mpg123 instance just the files to play. Hm, both variants
>> have something to them.
>>
>> If you are not interested in fine-grained control of playback, the
>> --continue mode may be something to be considered. That would also
>> serve to continue playback at the previous track+position when
>> rebooting the machine. You also might want to check how this interacts
>> with random play.
>
>
No - I'm not interested in "fine-grained control of playback"; as I said
I'd like to have a command (remote or otherwise) that simply "loop plays" a
playlist from beginning to end, and recognizes a "pause" command to toggle
the playback process.

WRT "--continue mode", I see nothing about continue mode in the remote
help... are you suggesting that from 'terminal 1' I enter this?:

mpg123 --continue -R --fifo /tmp/mpg123_fifo


mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users
>

Re: [mpg123-users] How to use a play list in remote mode?

[Alan C. <ala...@gm...>]

I had a program that scanned directories and built HTML playlists, the
links in the playlist called mpg123 with a filename passed.  I don't have
it available, I was working on setting volumes remotely, which was usually
done from a smartphone running a web browser.

Alan Corey

On Sun, Mar 30, 2025, 6:53 AM Thomas Orgis <tho...@or...> wrote:

> Hi!
>
> Am Sat, 29 Mar 2025 18:57:26 -0500
> schrieb Seamus de Mora <sea...@gm...>:
>
> > In my reading of earlier posts in this thread, I gather that there are no
> > plans to incorporate a "playlist" feature into the "remote mode" - as it
> is
> > implemented in the "local mode"... is that correct?
>
> Indeed. The idea of the remote control mode is that you do the
> controlling of playback. Working on a playlist makes the player open
> and play tracks itself, complicating matters as both sides now could
> cause loading of new tracks. Of course it's possible to combine all
> features, but complex control flow breeds complex issues.
>
> If there is a strong use case where you want playback control, but
> leave playlist control to mpg123, perhaps with added commands to
> influence that, it might be considered. If you observe that gapless
> playback of continuing tracks doesn't work well otherwise, that could
> be something that bugs me. But I suppose things would still be fast
> enough.
>
> You control program can use loadlist to parse the list and return
> the paths to play, but your program controls when which track is
> played. You could do
>
> loadlist $n playlist.m3u
>
> to play the respective track, though I probably would just use
>
> playlist=$(echo loadlist -1 playlist.m3u | mpg123 -R - |grep '^@I
> LISTENTRY' | cut -f 4- -d ' ')
>
> or such if I really do not want to do the m3u/pls parsing myself and
> give the main mpg123 instance just the files to play. Hm, both variants
> have something to them.
>
> If you are not interested in fine-grained control of playback, the
> --continue mode may be something to be considered. That would also
> serve to continue playback at the previous track+position when
> rebooting the machine. You also might want to check how this interacts
> with random play.
>
>
> Alrighty then,
>
> Thomas
>
> PS: It comes up again and again that the evolved player logic should be
> combined with other audio decoders besides libmpg123. Maybe, one of
> those days, the decoder library will have to be shipped as a separate
> package and mpg123 becomes music player general 1, 2, 3 …
>
>
> _______________________________________________
> mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users
>

Re: [mpg123-users] How to use a play list in remote mode?

[Thomas O. <tho...@or...>]

Hi!

Am Sat, 29 Mar 2025 18:57:26 -0500
schrieb Seamus de Mora <sea...@gm...>: 

> In my reading of earlier posts in this thread, I gather that there are no
> plans to incorporate a "playlist" feature into the "remote mode" - as it is
> implemented in the "local mode"... is that correct?

Indeed. The idea of the remote control mode is that you do the
controlling of playback. Working on a playlist makes the player open
and play tracks itself, complicating matters as both sides now could
cause loading of new tracks. Of course it's possible to combine all
features, but complex control flow breeds complex issues.

If there is a strong use case where you want playback control, but
leave playlist control to mpg123, perhaps with added commands to
influence that, it might be considered. If you observe that gapless
playback of continuing tracks doesn't work well otherwise, that could
be something that bugs me. But I suppose things would still be fast
enough.

You control program can use loadlist to parse the list and return
the paths to play, but your program controls when which track is
played. You could do

loadlist $n playlist.m3u

to play the respective track, though I probably would just use

playlist=$(echo loadlist -1 playlist.m3u | mpg123 -R - |grep '^@I LISTENTRY' | cut -f 4- -d ' ')

or such if I really do not want to do the m3u/pls parsing myself and
give the main mpg123 instance just the files to play. Hm, both variants
have something to them.

If you are not interested in fine-grained control of playback, the
--continue mode may be something to be considered. That would also
serve to continue playback at the previous track+position when
rebooting the machine. You also might want to check how this interacts
with random play.


Alrighty then,

Thomas

PS: It comes up again and again that the evolved player logic should be
combined with other audio decoders besides libmpg123. Maybe, one of
those days, the decoder library will have to be shipped as a separate
package and mpg123 becomes music player general 1, 2, 3 …

Re: [mpg123-users] How to use a play list in remote mode?

[Seamus de M. <sea...@gm...>]

Hello,

First day on this list, so please excuse my "fumbles". I'm attempting to
follow-up/resurrect an old thread from 2021 - as in the subject. Anyway -
to get into it:

I'm trying to build a "music player" from a Raspberry Pi (Debian Linux,
bookworm) using 'mpg123'. My version of 'mpg123' is: "1.31.2" - which is
the latest "package" offered by Debian. This music player is to be a gift
to my son on his birthday next month. My son is not "into"
computers/software, and so I am trying to make this music player as simple
as possible. Briefly, the RasPi will be in a box/housing with a single
pushbutton exposed. One button push starts the music, another button push
"pauses" the music. The music will be from a "playlist" that my son will
create.

My prior experience with 'mpg123' is limited to a similar "music player"
that I have for my personal use. Used as follows: Created a `bash` script
that runs under 'cron @reboot'; the script verifies the BT speaker is
connected (via 'bluetoothctl'), and then launches 'mpg123' to play a single
file (73 minute mp3 recording of thunderstorm) in a repetitive loop. I use
it as "sleep music"  :)  It has been wonderfully reliable, and has not
"missed a beat" in over 6 months! Anyway - this experience prompted me to
consider mpg123 for my son's music player.

When I learned of mpg123's "remote mode", I began exploring it earlier
today. I was very pleased as I imagined it would allow me to launch
'mpg123' with the same options available from the command line. I echoed
help to the fifo ('echo "help" > /tmp/mpg123_fifo'), and initially mis-read
the 'LOADLIST/LL' description. After a quick trial & failure, I re-read the
description, and decided to come here for some help.

In my reading of earlier posts in this thread, I gather that there are no
plans to incorporate a "playlist" feature into the "remote mode" - as it is
implemented in the "local mode"... is that correct?

Thanks,
~S

[mpg123-users] releasing mpg123-1.32.10 with some fixes

[Thomas O. <tho...@or...>]

Dear mpg123 people,

there is a new release of mpg123. Get it at the usual places, indicated
by https://mpg123.org/download.shtml .

1.32.10
------
- scripts/tag_lyrics.py: fix for python3 (thanks to cclauss,
  github PR 16)
- libout123: Use strtok_r() to avoid conflicts multithreaded contexts
  (both sides should avoid plain strtok()! Debian-bug 1089543).
- libmpg123:
-- Un-break DLL builds that need I/O functions defined in libmpg123.c
   (like mpg123_open(), bug 374).
- ports/cmake: More fixup to also produce .pc files with Libs.private.


Alrighty then,

Thomas

Re: [mpg123-users] Do mpg123_distversion and mpg123_libversion really not exist?

[Thomas O. <tho...@or...>]

See released 1.32.9 now...and just a small one:

>+   * so that in the future this workaround will go away.
>+   * https://mpg123.de/#2024-10-26
>+   */

A more permanent link is

<https://mpg123.de/cgi-bin/news.cgi#2024-10-26>

Thr 1.32 news will vanish from the main page once 1.33 arrives.


Alrighty then,

Thomas

Re: [mpg123-users] Do mpg123_distversion and mpg123_libversion really not exist?

[Martin G. <mar...@gm...>]

On 01/11/24 09:03, Thomas Orgis wrote:
> Am Wed, 30 Oct 2024 05:13:55 +0100
> schrieb Martin Guy <mar...@gm...>:
>> Instead, both 1.32.7 and 1.32.8 have
>>
>>       #define MPG123_API_VERSION 48
>>       /** library patch level at client build time */
>>       #define MPG123_PATCHLEVEL  2
>   The MPG123_PATCHLEVEL only helps you at build-time, anyway.

Build time is fine by me - but can a distributed binary dynamically link 
against different versions of libmpg123 depending where it lands?


It seems that even MPG123_API_VERSION appeared at some point between 
1.0.0 and now, and I'm not hacking the configure script to check for the 
existence of mpg123_*version() so I'm using:


+  error = mpg123_param(p->handle, MPG123_FLAGS, MPG123_FUZZY | 
MPG123_SEEKBUFFER | MPG123_GAPLESS | MPG123_FORCE_FLOAT

+  /* Before mpg123-1.32.8 there was a potential exploit for which one 
workaround
+   * is to set MPG123_NO_FRANKENSTEIN but there seems to be no way to check
+   * the exact mpg123 version (mpg123_distversion() is undefined),
+   * so do this for all versions up to and including the fixed version
+   * so that in the future this workaround will go away.
+   * https://mpg123.de/#2024-10-26
+   */
+#if !defined(MPG123_API_VERSION) || !defined(MPG123_PATCHLEVEL) || 
MPG123_API_VERSION < 48 || (MPG123_API_VERSION == 48 && 
MPG123_PATCHLEVEL <= 2)
+                                 | MPG123_NO_FRANKENSTEIN
+#endif
+                                 , 0);


so it should be OK even if PATCHLEVEL++ happens in the far future.


> Sorry for the messup.

Worry not, old friend. The more you do, the more mistakes you make.

You should *see* some of the mistakes I make, and a lot of them 
embarrassingly public.

Fixing a stupid compiler warning with a bracket in the wrong place and 
making the reverb distort. The test suite caught that before it went 
public, thank Knuth.

The only ones who don't make mistakes are the ones who never do anything

Alrighty then

     M

[mpg123-users] Releasing mpg123 1.32.9

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

here comes just a small followup to the release fixing CVE-2024-10573.
I forgot to increase the reported library patchlevel last time and a
build improvement for MSVCRT also went in.

1.32.9
------
- libmpg123:
-- enable 64 bit offset path for MSVCRT and avoid warnings about
   MS's game about POSIX API with and without underscores (bug 373).
-- Increase the library patchlevel, as was forgotten on previous
   release. Now you can check for distversion >= 1.32.8 or
   mpg123 libversion >= 48 patchlevel 3 to see if you're vulnerable
   to CVE-2024-10573.

Ger it per usual via pointers on

	https://mpg123.org/download.shtml


Alrighty then,

Thomas

Re: [mpg123-users] Do mpg123_distversion and mpg123_libversion really not exist?

[Thomas O. <tho...@or...>]

Am Wed, 30 Oct 2024 05:13:55 +0100
schrieb Martin Guy <mar...@gm...>: 

> Instead, both 1.32.7 and 1.32.8 have
> 
> 
>      #define MPG123_API_VERSION 48
>      /** library patch level at client build time */
>      #define MPG123_PATCHLEVEL  2

Yes, you noticed correclty. I've also seen that just after doing the
release and am _really_ annoyed by this mistake. I'll have to push a
1.32.9, I guess. People then can check for API 48 patchlevel 3. But
this does not yet really matter for running more conservative Linux
distros, as those don't yet have picked up 1.32 at all and there is no
mpg123_libversion().

> so maybe the PATCHLEVEL could be bumped in the next micro release so 
> that there will be something to check against to have everything smooth 
> out at some point in the future.

Well, what you can do is check the distversion. If it is present and
indicates ≥ 1.32.8, you got the fix. The MPG123_PATCHLEVEL only helps
you at build-time, anyway.

#include <mpg123.h>
#include <stdio.h>

int main()
{
  unsigned maj=0, min=0, patch=0;
  mpg123_distversion(&maj, &min, &patch);
  if((maj == 1 && min < 32) || (maj == 1 && min == 32 && patch < 8))
  {
     printf("vulnerable\n");
     return 1;
  }
  return 0;
}


Once the new release is out, this simplifies to

int main()
{
  unsigned api=0, patch=0;
  api = mpg123_libversion(&patch);
  if(api < 48 || (api == 48 && patch < 3))
  {
     printf("vulnerable\n");
     return 1;
  }
  return 0;
}

Sorry for the messup.


Alrighty then,

Thomas

Re: [mpg123-users] Do mpg123_distversion and mpg123_libversion really not exist?

[Martin G. <mar...@gm...>]

On 30/10/24 04:54, Martin Guy wrote:

>
> If mpg123_*version() really don't exist, I thought I could enable 
> monster protection if MPG123_API_VERSION <= 47 and ask you to bump the 
> API_VERSION in the next release but just noticed that its value has 
> dropped from 48 to 47 between 1.32.7 and 1.32.8 so I'm now even more 
> confused than before.


Oops, my bad. I was looking at the installed header (Debian stable) not 
the 1.32.8 header. Definitely confused.


Instead, both 1.32.7 and 1.32.8 have


     #define MPG123_API_VERSION 48
     /** library patch level at client build time */
     #define MPG123_PATCHLEVEL  2


so maybe the PATCHLEVEL could be bumped in the next micro release so 
that there will be something to check against to have everything smooth 
out at some point in the future.


Sorry for the noise


     M

[mpg123-users] Do mpg123_distversion and mpg123_libversion really not exist?

[Martin G. <mar...@gm...>]

Thanks again. On a different subject, I thought I'd check for the mpg123 
version being earlier than 1.32.8 before setting NO_FRANKENSTEIN, but am 
getting that mpg123_distversion() is undefined despite being documented 
and I can't find any mention of it in mpg123.h, (nor of 
mpg123_libversion() as it happens) only the #define MPG123_API_VERSION.


If mpg123_*version() really don't exist, I thought I could enable 
monster protection if MPG123_API_VERSION <= 47 and ask you to bump the 
API_VERSION in the next release but just noticed that its value has 
dropped from 48 to 47 between 1.32.7 and 1.32.8 so I'm now even more 
confused than before.


It would be nice to let people deal with monster files safely in the 
future - how should I proceed?


Blessings


     M

Re: [mpg123-users] Security update mpg123 1.32.8: Frankenstein's Monster

[Thomas O. <tho...@or...>]

Am 29. Oktober 2024 21:22:38 MEZ schrieb Martin Guy <mar...@gm...>:

>Does this affect apps that use mpg123_open_feed() 

Depends. If you seek around in weird streams, possibly. So, yes.

> and, if so, that call seems not to have an "options" parameter, so what would I use to set NO_FRANKENSTEIN for that handle?

<http://mpg123.org/api/group__mpg123__init.shtml#gga12f1bf1105a9b0c1501b20516a9719d4ae751251ef31d1ccaa526dd36764c89f1>

You call mpg123_param() with ADD_FLAGS.


Alrighty then,

Thomas

Re: [mpg123-users] Security update mpg123 1.32.8: Frankenstein's Monster

[Martin G. <mar...@gm...>]

On 26/10/24 17:38, Thomas Orgis wrote:

> If you do work with stream dumps, usage of MPG123_NO_FRANKENSTEIN or
> the --no-frankenstein option to the mpg123 application is a workaround
> to avoid the formerly dangerous situation in earlier mpg123 releases.


Does this affect apps that use mpg123_open_feed() and, if so, that call 
seems not to have an "options" parameter, so what would I use to set 
NO_FRANKENSTEIN for that handle? I've searched the docs for half an hour 
but haven't found it yet.


Thanks Tom, always on the ball


    M