mpg123-users — Mailing list for users of mpg123

[mpg123-users] releasing mpg123-1.33.5 and 1.32.12 with serious regression fixes

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

Dear people,

I am announcing the release of mpg123 1.33.5 and 1.32.12 to fix
breakage introduced in 1.32.0 with the largefile overhaul. Of course
that introduced issues, but only for

- users of remote control interface
- on 32 bit platforms with largefile support

A minor regression is proper handling of large files in mpg123-id3dump,
also fixed. While mpg123-strip is also not enabling large file support,
this does not seem to impact functionality on 32 bit Linux, as the I/O
is 64 bits inside libmpg123, anyway (for proper error messages about
invalid headers and certain offset).

I also release 1.32.12 to offer easy patching for distributions that
ride on 1.32.x. This absolutely should be patched!

1.33.5
------
- mpg123: Fix generic control mode for largefile-sensitive builds, where 32 bit
  off_t was used with mpg123 API calls expecting 64 bit off_t.
  I am appalled that it took a user on 32 bit ARM and a specific https stream
  to notice this (bug 385, regression since 1.32.0).
  The security impact of this could be serious, with memory corruption including
  segfault being observed.
- mpg123-id3dump, out123: Enable 64 bit offset usage on largefile-sensitive
  platforms (regression since 1.32.0).
- libmpg123:
-- Announce support for shadow stack / IBT in x86-64 assembly.
-- Also announce PAC/BTI for non-accurate neon64 (aarch64) synth.
- libout123: Add a safeguard to ensure variable-length records from buffer
  communication are always zero-terminated.
- libsyn123: Use union work buffer to avoid casts that may look like breaking
  strict aliasing.

1.32.12
------
- mpg123: Fix generic control mode for largefile-sensitive builds, where 32 bit
  off_t was used with mpg123 API calls expecting 64 bit off_t.
  I am appalled that it took a user on 32 bit ARM and a specific https stream
  to notice this (bug 385, regression since 1.32.0).
  The security impact of this could be serious, with memory corruption including
  segfault being observed.
- mpg123-id3dump, out123: Enable 64 bit offset usage on largefile-sensitive
  platforms (regression since 1.32.0).


I also updated the win32/win64 binaries this one time using a cross
build, without any functionality checking. We still do not have a
regular process in place to provide those, and I just do not want that
as a regular task.

Head over to 

	https://sourceforge.net/projects/mpg123/files/mpg123/
or
	https://mpg123.org/download.shtml

to get your stuff.


Alrighty then,

Thomas

[mpg123-users] Fwd: GPIO "keys" for headless terminal mode?

[Ted S. <ted...@gm...>]

---------- Forwarded message ---------
From: Ted Saylor <ted...@gm...>
Date: Sat, Feb 21, 2026 at 8:53 AM
Subject: Re: [mpg123-users] GPIO "keys" for headless terminal mode?
To: Thomas Orgis <tho...@or...>


Thank you for your reply, Thomas

The reason I'm going to use terminal mode is, I'm lazy. I can feed it +2000
mp3's (thru a filelist) in multiple directories and I don't have to code a
thing to go forward/back with tracks or directories.
Ironically, I found another post on this list recently and socat was
mentioned. There was a tce for it and it takes a fifo as one "end". Seems
to control terminal mpg123 perfectly.
So far, the minimal GPIO scripting is working very well, when it's finished
I will post what I did here.
I want to thank you for keeping mpg123 minimal and focused - it's exactly
what I need, just play mp3 files thru the DAC board.

Regards,
Ted

On Sat, Feb 21, 2026 at 5:44 AM Thomas Orgis via mpg123-users <
mpg...@li...> wrote:

> Am Fri, 20 Feb 2026 14:17:32 -0700
> schrieb Ted Saylor <ted...@gm...>:
>
> > My use case will be a completely "headless" car mp3 player using GPIO
> from
> > toggle switches to change volume, tracts, folders, stop/start. Things the
> > terminal mode does perfectly from the keyboard. Can the terminal mode
> take
> > fifo commands?
>
> The terminal mode is different from the fifo mode. Terminal mode gets
> input from the terminal (which could be emulated and programmatically
> coupled to gpio input). The fifo mode, meaning remote control mode via
> fifo instead of stdin, takes the remote control commands.
>
> > How might this be accomplished? Perhaps someone has already
> > solved this situation?
>
> People wrote frontends that controlled mpg123 using pipe to a forked
> process a long time ago. The fifo is another way to access the same
> functionality.
>
> > Any help on direction to make this happen would be appreciated.
> > Ted
>
> Well … any reason you do _not_ want to use remote control mode? One
> point could be that you want seamless playing of a playlist … the
> remote control mode assumes that the external agent handles the
> playlist, we only added parsing and output of playlist files as an aid.
> The control flow of remote control and normal (terminal) mode is quite
> different.
>
>
> Alrighty then,
>
> Thomas
>
>
> _______________________________________________
> mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users
>

Re: [mpg123-users] GPIO "keys" for headless terminal mode?

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

Am Fri, 20 Feb 2026 14:17:32 -0700
schrieb Ted Saylor <ted...@gm...>: 

> My use case will be a completely "headless" car mp3 player using GPIO from
> toggle switches to change volume, tracts, folders, stop/start. Things the
> terminal mode does perfectly from the keyboard. Can the terminal mode take
> fifo commands? 

The terminal mode is different from the fifo mode. Terminal mode gets
input from the terminal (which could be emulated and programmatically
coupled to gpio input). The fifo mode, meaning remote control mode via
fifo instead of stdin, takes the remote control commands.

> How might this be accomplished? Perhaps someone has already
> solved this situation?

People wrote frontends that controlled mpg123 using pipe to a forked
process a long time ago. The fifo is another way to access the same
functionality.

> Any help on direction to make this happen would be appreciated.
> Ted

Well … any reason you do _not_ want to use remote control mode? One
point could be that you want seamless playing of a playlist … the
remote control mode assumes that the external agent handles the
playlist, we only added parsing and output of playlist files as an aid.
The control flow of remote control and normal (terminal) mode is quite
different.


Alrighty then,

Thomas

[mpg123-users] GPIO "keys" for headless terminal mode?

[Ted S. <ted...@gm...>]

Hello All, thank you in advance for taking the time to consider my question.
I have a RasPi Nano w/PCM5102 DAC running TinyCoreLinux (PiCore). TCL has a
tce (build) of mpg123 that works out of the box with the DAC card. Terminal
and fifo remote modes both play mp3 file(s) perfectly. However...
My use case will be a completely "headless" car mp3 player using GPIO from
toggle switches to change volume, tracts, folders, stop/start. Things the
terminal mode does perfectly from the keyboard. Can the terminal mode take
fifo commands? How might this be accomplished? Perhaps someone has already
solved this situation?
Any help on direction to make this happen would be appreciated.
Ted

Re: [mpg123-users] mpg123 won't play sound when run from startup script

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

Am Sun, 1 Feb 2026 03:49:56 +0100
schrieb Martin Guy <mar...@gm...>: 

> Mixers are at zero?

Yes, this would be my first check … ensure that the pulseaudio and
possibly bluetooth mixer controls are not silencing things.

But then, you said you can play things from the cli without errors?
Does that apply to the current situation where bluetooth connection
happened at startup? You can log in as user hnie and start

	/bin/mpg123 -o pulse --no-control --quiet -z -@ /home/hnie/playlist.m3u

and this will play audio (perhaps after systemctl stop
play_music.service)?

Also, I am not totally sure if there might be pulseaudio user
management issues. You seem to have a pulseaudio instance for the user
running, it seems to have the bt speaker linked up. Just saying that
pulseaudio system/user daemon modes could complicate things.

In any case, you'll find people with more insight into this in systemd
and pulseaudio forums. If mpg123 works from the CLI, the mpg123 part is
fine … Can you verify that mpg123 is _really_ playing and not stalling?
Drop the --quiet, even add some --verbose (-vvv or excessive progress
info) and observe the log being filled with playback messages.

What does jump into my eye is the lot of sleep before and after
starting your commands. This indicates that the service dependencies
are not right. You should probably define the speaker connections
service so that it is only active once the speaker really is online
(like the network-wait-online services/targets). Then, you don't need
spurious 'sleep 60' before and after commands to make up for unsafe
dependencies and waiting periods.

Another idea would be to simplify the setup to do the bt connection and
the playback in the same script, as sequential steps. Decoupling this
into multiple systemd services may just complicate things. And even
then … if you are not mixing output from multiple applications, on a
raspi you could consider dropping pulse altogether and going directly
to the ALSA output device to save CPU cycles and needless context
switches. Pulse (or the modern pipewire thing) is useful for desktop
setups with dynamic routing of audio, but for a headless background
music player it's unecessary bloat, IMHO.


Alrighty then,

Thomas

Re: [mpg123-users] mpg123 won't play sound when run from startup script

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

Mixers are at zero?

[mpg123-users] mpg123 won't play sound when run from startup script

[<sou...@fa...>]

Hi there,
*Project intention:* I want to use my Raspberry Pi as an MP3 player: at startup connect to my bluetooth speaker and then play the songs from the playlist. The songs are locally stored on the CD card.

*Current status and problem:* Extensive searching on forums and man pages got me to the point where I can execute scripts from the cli and they work without errors, but when I execute the scripts through systemd on startup - the bluetooth speaker connects, the play music script executes, but there's no sound from the speaker. I also get no more error messages. So I'm stumped and would like some advice from the experts, please.

Here is some of the detail that I imagine could be relevant:

*Hardware:* Raspberry Pi, model 3B

*OS:* Raspberry Pi OS Lite (64 bit) released 2025-12-04

*Users defined:*
hnie@raspberrypi:~ $ getent passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin
dhcpcd:x:100:65534:DHCP Client Daemon:/usr/lib/dhcpcd:/bin/false
systemd-timesync:x:991:991:systemd Time Synchronization:/:/usr/sbin/nologin
messagebus:x:990:990:System Message Bus:/nonexistent:/usr/sbin/nologin
sshd:x:989:65534:sshd user:/run/sshd:/usr/sbin/nologin
dnsmasq:x:988:65534:dnsmasq:/var/lib/misc:/usr/sbin/nologin
avahi:x:101:104:Avahi mDNS daemon:/run/avahi-daemon:/usr/sbin/nologin
polkitd:x:987:987:User for polkitd:/:/usr/sbin/nologin
hnie:x:1000:1000::/home/hnie:/bin/bash
rtkit:x:102:105:RealtimeKit:/proc:/usr/sbin/nologin
pulse:x:103:106:PulseAudio daemon:/run/pulse:/usr/sbin/nologin
*Groups defined:*
hnie@raspberrypi:~ $ getent passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin
dhcpcd:x:100:65534:DHCP Client Daemon:/usr/lib/dhcpcd:/bin/false
systemd-timesync:x:991:991:systemd Time Synchronization:/:/usr/sbin/nologin
messagebus:x:990:990:System Message Bus:/nonexistent:/usr/sbin/nologin
sshd:x:989:65534:sshd user:/run/sshd:/usr/sbin/nologin
dnsmasq:x:988:65534:dnsmasq:/var/lib/misc:/usr/sbin/nologin
avahi:x:101:104:Avahi mDNS daemon:/run/avahi-daemon:/usr/sbin/nologin
polkitd:x:987:987:User for polkitd:/:/usr/sbin/nologin
hnie:x:1000:1000::/home/hnie:/bin/bash
rtkit:x:102:105:RealtimeKit:/proc:/usr/sbin/nologin
pulse:x:103:106:PulseAudio daemon:/run/pulse:/usr/sbin/nologin
I created two systemd service scripts to run at startup: 1) to connect to the bluetooth spaker and 2) to play the music.

*1) Connect to bluetooth speaker:*
hnie@raspberrypi:~ $ cat /etc/systemd/system/connect_bt_speaker.service

[Unit]
Description=connect the bluetooth speaker
After=bluetooth.target
Wants=bluetooth.target
Requires=bluetooth.service

[Service]
Type=simple
User=hnie
ExecStartPre=/bin/sleep 30
ExecStart=/bin/bash /home/hnie/connect_bt_speaker.sh
ExecStartPost=/bin/sleep 30
Restart=on-failure
RestartSec=30
StandardOutput=journal

[Install]
WantedBy=multi-user.target

hnie@raspberrypi:~ $ cat /home/hnie/connect_bt_speaker.sh

#!/bin/bash
# scrip to play mp3 files on a bluetooth speaker
SPEAKER_MAC="40:C1:F6:9B:D3:17"  # JBL Charge 5
LOG_FILE="/tmp/bluetooth-connect.log"

#define subroutines
check_connection() {
    bluetoothctl info "$SPEAKER_MAC" | grep -q "Connected: yes"
}

log_message() {
    echo "$(date) - $1" >> "$LOG_FILE"
}

if check_connection; then
    log_message "Speaker already connected"
    exit 0
fi

#connecting to bluetooth speaker
log_message "Attempting to connect speaker"
bluetoothctl power off > /dev/null 2>&1
sleep 3
bluetoothctl power on > /dev/null 2>&1
sleep 5

(echo "connect $SPEAKER_MAC"; echo "quit") | bluetoothctl
sleep 5

if check_connection; then
    log_message "Successfully connected"
else
    log_message "Failed to connect"
    exit 1
fi
*2) Play music:*
hnie@raspberrypi:~ $ cat /etc/systemd/system/play_music.service

[Unit]
Description=play playlist through the connected bluetooth speaker
After=multi-user.target connect_bt_speaker.target pulseaudio.target
Wants=multi-user.target connect_bt_speaker.target pulseaudio.target
Requires=connect_bt_speaker.service pulseaudio.service

[Service]
Type=oneshot
User=hnie
SupplementaryGroups=audio users
ExecStartPre=/bin/sleep 60
ExecStart=/bin/bash /home/hnie/play_music.sh
Restart=on-failure
StandardOutput=journal

[Install]
WantedBy=multi-user.target

hnie@raspberrypi:~ $ cat ./play_music.sh

#!/bin/bash
set -o xtrace
# scrip to play mp3 files on a bluetooth speaker
SPEAKER_MAC="40:C1:F6:9B:D3:17"  # JBL Charge 5
LOG_FILE="/tmp/play_music.log"

#define subroutines
check_connection() {
    bluetoothctl info "$SPEAKER_MAC" | grep -q "Connected: yes"
}

log_message() {
    echo "$(date) - $1" >> "$LOG_FILE"
}

if check_connection; then
    log_message "Speaker already connected"
fi

#checking the bluetooth speaker connection and playing if ready
if check_connection; then
    log_message "Start playing playlist"
    /bin/mpg123 -o pulse --no-control --quiet -z -@ /home/hnie/playlist.m3u
else
    log_message "Can't play because speaker is not connected"
    exit 1
fi
Checking status of services:
hnie@raspberrypi:~ $ sudo systemctl status connect_bt_speaker.service

● connect_bt_speaker.service - connect the bluetooth speaker
     Loaded: loaded (/etc/systemd/system/connect_bt_speaker.service; enabled; preset: enabled)
     Active: activating (start-post) since Sat 2026-01-31 13:32:23 GMT; 1min 7s ago
        Job: 137
 Invocation: a9f7a4a39531492e9f66e090a59da7cc
    Process: 572 ExecStartPre=/bin/sleep 30 (code=exited, status=0/SUCCESS)
    Process: 816 ExecStart=/bin/bash /home/hnie/connect_bt_speaker.sh (code=exited, status=0/SUCCESS)
   Main PID: 816 (code=exited, status=0/SUCCESS); Control PID: 817 (sleep)
      Tasks: 1 (limit: 759)
        CPU: 339ms
     CGroup: /system.slice/connect_bt_speaker.service
             └─817 /bin/sleep 30

Jan 31 13:32:23 raspberrypi systemd[1]: Starting connect_bt_speaker.service - connect the bluetooth speaker.>
Jan 31 13:33:24 raspberrypi bash[831]: [93B blob data]
Jan 31 13:33:24 raspberrypi bash[831]: Attempting to connect to 40:C1:F6:9B:D3:17
Jan 31 13:33:24 raspberrypi bash[831]: [158B blob data]
Jan 31 13:33:24 raspberrypi bash[831]: [bluetoothctl]> quit
Jan 31 13:33:29 raspberrypi bash[831]: [bluetoothctl]> 

hnie@raspberrypi:~ $ sudo systemctl status play_music.service

● play_music.service - play playlist through the connected bluetooth speaker
     Loaded: loaded (/etc/systemd/system/play_music.service; enabled; preset: enabled)
     Active: activating (start) since Sat 2026-01-31 13:33:45 GMT; 1min 11s ago
        Job: 136
 Invocation: 2413ad5db24a45428feb3d0c07e10315
    Process: 855 ExecStartPre=/bin/sleep 60 (code=exited, status=0/SUCCESS)
   Main PID: 874 (bash)
      Tasks: 3 (limit: 759)
        CPU: 585ms
     CGroup: /system.slice/play_music.service
             ├─874 /bin/bash /home/hnie/play_music.sh
             └─881 /bin/mpg123 -o pulse --no-control --quiet -z -@ /home/hnie/playlist.m3u

Jan 31 13:34:46 raspberrypi bash[874]: + log_message 'Speaker already connected'
Jan 31 13:34:46 raspberrypi bash[877]: ++ date
Jan 31 13:34:46 raspberrypi bash[874]: + echo 'Sat 31 Jan 13:34:46 GMT 2026 - Speaker already connected'
Jan 31 13:34:46 raspberrypi bash[874]: + check_connection
Jan 31 13:34:46 raspberrypi bash[878]: + bluetoothctl info 40:C1:F6:9B:D3:17
Jan 31 13:34:46 raspberrypi bash[879]: + grep -q 'Connected: yes'
Jan 31 13:34:46 raspberrypi bash[874]: + log_message 'Start playing playlist'
Jan 31 13:34:46 raspberrypi bash[880]: ++ date
Jan 31 13:34:46 raspberrypi bash[874]: + echo 'Sat 31 Jan 13:34:46 GMT 2026 - Start playing playlist'
Jan 31 13:34:46 raspberrypi bash[874]: + /bin/mpg123 -o pulse --no-control --quiet -z -@ /home/hnie/playlist>
lines 1-23/23 (END)
The two scripts write log files:
hnie@raspberrypi:~ $ cat /tmp/bluetooth-connect.log

Sat 31 Jan 13:33:16 GMT 2026 - Attempting to connect speaker
Sat 31 Jan 13:33:29 GMT 2026 - Successfully connected

hnie@raspberrypi:~ $ cat /tmp/play_music.log

Sat 31 Jan 13:34:46 GMT 2026 - Speaker already connected
Sat 31 Jan 13:34:46 GMT 2026 - Start playing playlist
Other info:
hnie@raspberrypi:~ $ pactl info

Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 2
Tile Size: 65472
User Name: hnie
Host Name: raspberrypi
Server Name: pulseaudio
Server Version: 17.0
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: bluez_sink.40_C1_F6_9B_D3_17.a2dp_sink
Default Source: bluez_sink.40_C1_F6_9B_D3_17.a2dp_sink.monitor
Cookie: d0f8:dcff
Any advice will be greatly appreciated! Thank you in advance!


The information contained in this communication (including links and attachments) is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. Any review, use, copying, distribution, disclosure or taking action in reliance on the contents of this information by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. Whilst all reasonable steps are taken to ensure the accuracy and integrity of information and data transmitted electronically and to preserve the confidentiality thereof, no liability or responsibility whatsoever is accepted if information is, for whatever reason, corrupted or does not reach its intended destination.

[mpg123-users] mpg123 1.33.4 released

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

Dear all,

here is a little bit of mpg123 for you.

1.33.4
------
- mpg123: In terminal control, ignore 7-bit escape sequences to avoid spurious
  actions, e.g. when hitting cursor keys. Inspired by Peter Tirsek.
- ports/cmake: Avoid possibly conflicting use of SIZEOF_OFF_T CMake variable
  when embedding mpg123 with other projects using cmake and different off_t
  semantics. (bug 382)

Get it at the usual places …


Alrighty then,

Thomas

[mpg123-users] releasing mpg123 1.33.3

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

Hi folks,

a little code hygiene with mpg123 1.33.3:

1.33.3
------
- libmpg123:
-- Fix build with newer toolchain on Android by using __ANDROID__ macro (bug 380).
-- Consolidate and more consistently use .rodata switch in macro.


Get it at the usual places …

	https://sourceforge.net/projects/mpg123/files/mpg123/1.33.3/
	https://mpg123.org/download/


Alrighty then,

Thomas

Re: [mpg123-users] Out123 - not working on mint?

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

Am 8. August 2025 20:01:47 MESZ schrieb "Dominik Młynarczyk" <dom...@gm...>:

>[src/libout123/libout123.c:out123_open():484] error: Found no driver out of
>[oss] working with device <default>.
>

Did you build mpg123 yourself? It looks like you did not have development files present for more than OSS output. For alsa or pulse (and sdl, portaudio, whatnot), you need development files for those audio systems installed.

With the proper dependencies present, the list of tried drivers should be bigger. Also, you'd need to install your build of mpg123 so that libmpg123 finds the output modules (alternatively, there's an environment variable for that).

>Using mpg123-alsa also fails.

I am not sure which mpg123 you mean here. The default build with alsa on Ubuntu-like systems should be able to use e.g. the pulse server via compat layer.

>The workaround I've found for now is building the x86_64-cross version for
>Windows and then running under Wine. This fixes both the command line
>mpg123/out123 and the library, but is a very hacky solution.

Wow. This is a roundabout! Interesting option;-)

>Is this a bug or is there something I'm missing?

Just looks like an incomplete build lacking modules.


Alrighty then,

Thomas

[mpg123-users] releasing mpg123 1.33.2

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

Dear mpg123 folks,

there's a little bugfix release fixing a single bug:

1.33.2
------
- libmpg123:
-- Do not modify raw ID3v2 data while parsing (bug 379). This used to be fine
   before MPG123_STORE_RAW_ID3 got introduced. Not anymore.

Get it from the usual places …

This release also serves as a notice to anyone wanting to extract raw
ID3v2 frames with libmpg123 to disable the internal parsing with
MPG123_SKIP_ID3V2 or ensure that at least this bugfixed version of
libmpg123 is in use.


Alrighty then,

Thomas

[mpg123-users] releasing mpg123 1.33.1 (and 1.32.11, 11.4 to fix regression in signal handling)

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

Dear mpg123 folks,

there is a new mpg123 release with some urgency for me, as I botched up
signal handling for the terminal control mode (--ctrlusr1, --ctrlusr2)
in 1.31. Code cleanup triggered changed semantics of the signal()
library call, of which you are warned very clearly in the Linux/glibc
manpage of signal. It is rather embarassing that mpg123 got hit by that
in this age, so I prepared releases to fix the regression for all
affected minor series. Any distro shipping 1.31.x or 1.32.x: Please
update, also for LTS/stable.

Downloads are at the usual places on

	https://sourceforge.net/projects/mpg123/files/mpg123/

or

	https://mpg123.org/download/

Full changes for 1.33.1:

1.33.1
------
- INSTALL updated with hints for Windows, mainly.
- Finally formatted README. Maybe do it in Markdown sometime, as that's
  the fashion.
- build:
-- The ports/cmake only installs manpages for BUILD_PROGRAMS now.
-- The configure gives better hint if pkg-config was missing during generation
   (bug 378).
- mpg123:
-- Replace usage of signal() in terminal code with our sigaction() wrapper
   to fix repeated handling for --sigusr1 and --sigusr2, which got subtly
   broken on Linux + glibc by a feature test macro change in mpg123 1.31.


Alrighty then,

Thomas

[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
>