Songs only play for 30 seconds

[Rojuinex]

Subject of the issue

Only ~30 seconds of a song plays, and then a new song starts playing.

Your environment

• version of pianobar: 2022.04.01_3
• macOS Sonoma Version 14.5 (23F79)

~/.config/pianobar/config

user = <redacted>
password_command = security find-internet-password -a '<redacted>' -s 'www.pandora.com' -t 'form' -w

Steps to reproduce

1. Install pianobar from homebrew
2. Play a song

Expected behaviour

The song should play from beginning to end.

Actual behaviour

The playback ends about 30 seconds into the song and a new song starts playing.

[PromyLOPh]

Can you build pianobar without -DNDEBUG and then run PIANOBAR_DEBUG=2 ./pianobar and post the logs?

[Rojuinex]

Under that configuration the bug no longer exists. I'm able to fully play songs to the end now.

The logs are filled with pretty much just these two lines repeated over and over:

ao play signalled it needs more data health 6 minHealth 5
decoding buffer filled health 6 minHealth 5

[PromyLOPh]

The log spam is expected, but not the change in behavior. Is the issue generally fixed with your own build or only when you activate the debug logs via PIANOBAR_DEBUG?

[Rojuinex]

It seems to be fixed only by building without -DNDEBUG. If I build it with that flag set then the issue occurs when building from master.

[PromyLOPh]

That’s weird. Is this an ARM-based Mac? Does increasing the setting buffer_seconds with the bad build change anything? Do you know which CFLAGS the bad build uses?

[Rojuinex]

Yes it's an ARM-based mac. M3 Pro specifically.

I increased buffer_seconds to 30 and this seemingly has fixed the issue.

There are actually 2 bad builds I've been working with:

1. From brew
2. Building from main

Homebrew

In trying to find the CFLAGS homebrew was using to build, I discovered it's actually bottled, and I was unable to discover if the build logs are publicly available or not.

From source

When building from main I do have to modify the make file in order to get it to find libgcrypt

Makefile.diff

diff --git a/Makefile b/Makefile
index 4e8fd0a..f3a725f 100644
--- a/Makefile
+++ b/Makefile
@@ -52,8 +52,9 @@ LIBAV_LDFLAGS:=$(shell $(PKG_CONFIG) --libs libavcodec libavformat libavutil lib
 LIBCURL_CFLAGS:=$(shell $(PKG_CONFIG) --cflags libcurl)
 LIBCURL_LDFLAGS:=$(shell $(PKG_CONFIG) --libs libcurl)
 
-LIBGCRYPT_CFLAGS:=
-LIBGCRYPT_LDFLAGS:=-lgcrypt
+LIBGCRYPT_CFLAGS:=$(shell $(PKG_CONFIG) --cflags libgcrypt)
+LIBGCRYPT_LDFLAGS:=$(shell $(PKG_CONFIG) --libs libgcrypt)
 
 LIBJSONC_CFLAGS:=$(shell $(PKG_CONFIG) --cflags json-c 2>/dev/null || $(PKG_CONFIG) --cflags json)
 LIBJSONC_LDFLAGS:=$(shell $(PKG_CONFIG) --libs json-c 2>/dev/null || $(PKG_CONFIG) --libs json)

ALL_CFLAGS

-O2
-DNDEBUG
-I src/libpiano
-I/opt/homebrew/Cellar/ffmpeg/7.0.1/include
-I/opt/homebrew/Cellar/libgcrypt/1.10.3/include
-I/opt/homebrew/opt/libgpg-error/include
-I/opt/homebrew/Cellar/json-c/0.17/include
-I/opt/homebrew/Cellar/json-c/0.17/include/json-c
-I/opt/homebrew/Cellar/libao/1.2.2/include

[PromyLOPh]

Good idea regarding using pkg-config to detect libgcrypt in the Makefile. I applied your patch. Thanks :)

Since increasing the buffer size fixes your issue there might be a race condition somewhere in the player code. Can you try compiling and running (without the buffer size increase) with the thread sanitizer? Should work with both, gcc and clang: make CFLAGS='-fsanitize=thread -O2 -g' LDFLAGS='-fsanitize=thread -O2 -g'. I see a data race, but it’s inside pulseaudio, so not much I can do I believe.

[Rojuinex]

Well, in my attempts to try your most recent suggestion I've discovered that I can't reproduce the original error when building from source or when installed by brew.

When trying to figure out what changed I noticed that brew had upgraded ffmpeg to 7.0.2. Doesn't look like they update change logs for patch version changes, and I'm too lazy to install 7.0.1 manually to test; so I'm considering this issue resolved.

Thanks for all your help in stepping through this!