Pianobar freezing after several songs

Question

Pianobar freezing after several songs

zoof opened this issue 3 years ago · 16 comments

Subject of the issue

Pianobar freezing after several song

Your environment

2020.11.28 from Debian repo
Debian Bullseye
your config file

user = user@example.com
password = ******

Steps to reproduce

Start pianobar.

Expected behaviour

Play songs until quit.

Actual behaviour

Freezes after several songs. Cannot quit out of pianobar. ^Z and kill %1 before I can restart.

I am a longtime user of pianobar and this is something that started happening this morning. Maybe Pandora made some changes?

Answer 1 · 2021-10-18T15:35:30.000Z

When it freezes, it maxes out CPU for two pianobar processes.

Answer 2 · 2021-10-20T07:50:39.000Z

I’ve seen this too, but I’m not quite sure why it happens. Can you compile pianobar from source without the -DNDEBUG flag and then run PIANOBAR_DEBUG=7 ./pianobar 2> /tmp/log and have a look at /tmp/log?

Answer 3 · 2021-10-20T16:25:41.000Z

Will do. It seems to be working fine now but I will plan to run it this way from now on in the hopes of seeing this again.

Answer 4 · 2021-10-22T20:13:00.000Z

Currently, it is freezing as soon as I start it. The requested log is at: https://controlc.com/e652fd5f6

Answer 5 · 2021-10-22T20:35:24.000Z

It's happening frequently again so I can provide more examples of logs if that would be helpful.

Answer 6 · 2021-10-27T19:47:19.000Z

Sorry for the delay. The log is inconclusive unfortunately. Could you obtain a backtrace in gdb please? Here’s a guide: https://wiki.ubuntu.com/Backtrace
Please remove your auth tokens from it before you post it.

Answer 7 · 2021-10-27T21:02:52.000Z

It does not seem to be having these problems at the moment. Just to be sure I get the right information once it happens again, should I be first setting the environment variable PIANOBAR_DEBUG=7?

Answer 8 · 2021-10-28T07:47:43.000Z

No, that should not be necessary. The log does not have enough information to track down what is going wrong unfortunately.

Answer 9 · 2021-12-01T14:52:19.000Z

It finally seems to have happened again. Maybe you can make something of the gdb output here. If there are any auth tokens, I'm not sure what they are.

I used the script form at the bottom of the wiki page but I also have a manually started one if it would provide better information.

Answer 10 · 2021-12-05T10:17:08.000Z

That log unfortunately does not have any backtraces for running threads. Could you try to apply the section “Already running programs” without step four and five when pianobar is stuck?

Answer 11 · 2021-12-06T15:43:27.000Z

Here you go. Hopefully this one will have what you need.

Answer 12 · 2021-12-11T12:54:45.000Z

Thread 2 looks like it’s waiting for some condition, but I can’t see where, because your pianobar executable does not have debug symbols. Usually I use make CFLAGS="-ggdb -O0". Could you try that please?

Answer 13 · 2021-12-13T15:40:27.000Z

I've recompiled it but I will have to wait for another bad day -- working fine today.

One thing which may or may not be apparent from the logs that I've supplied so far is that the freezing always happens at song transitions, I believe when a new song has been queued up but will confirm when the opportunity arises.

Answer 14 · 2022-01-12T17:55:09.000Z

Finally! I had to skip "(gdb) continue" because it was simply frozen and ctrl-c would not break out of it. The output is here. Hopefully, this time there will be enough information for you.

Answer 15 · 2022-01-20T20:43:58.000Z

Can you try using libao’s pulse backend directly instead of through alsa?

Answer 16 · 2022-05-04T19:32:58.000Z

That seems to have done the trick. Haven't had any freezes for several months now.