Frequent hangs with ALSA as default_driver in /etc/libao.conf #623
Comments
|
Sure, you can attach a debugger and grab a backtrace, see #610 (comment)
Make sure debugging symbols are installed/available.
|
|
@RichiH: Out of curiosity, are you on an IPV6 connection? I'm having similar (though perhaps not related) problems, and that's all that's changed for me. |
|
I am. I can't debug for two more weeks, though :/
Richard
Sent by mobile; excuse my brevity and the wall of text Gmail appends by
default.
…On May 22, 2017 13:37, "jellisii" ***@***.***> wrote:
@RichiH <https://github.com/richih>: Out of curiosity, are you on an IPV6
connection? I'm having similar (though perhaps not related) problems, and
that's all that's changed for me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#623 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAuEIy7hWkFq4XkAyq8YO5Rx0GyN2aWXks5r8XOWgaJpZM4Na5Yb>
.
|
|
I'll say that the debugger didn't net anything that appeared interesting when I ran it myself. When fetching a new playlist, it just takes something on the order of 10 minutes. |
|
For me, it sometimes simply stops at the beginning of a new song and
does nothing.
This would not be too much of an issue if the ui didn't freeze. Being
able to select a station (again) or quit would be enough, already. But
as it locks up, I need to kill it from the outside.
|
|
This seems to be a race condition. I can reliably make pianobar hang within 0-15 minutes by simply listening to music, doing nothing else. Running within gdb, I am unable to reproduce a single hang after countless hours of always-on listening, even leaving the stream run over night. |
|
Since I’m unable to reproduce the issue myself I really need more
information from you. If you’re unable to reproduce the issue while
running gdb you can enable coredumps with `ulimit -c unlimited` (depends
on your shell) and force a coredump by sending SIGQUIT to the process as
soon as you experience the problem. Then load the dump with `gdb -c
<file>` and proceed with step 5
(https://wiki.ubuntu.com/Backtrace#Generation).
Are you using an eventcmd script, by the way?
|
|
Will do ASAP, and yes, I am using eventcmd: |
|
I don't have symbols and there's not dgbsym package, I assume this is useless, correct? |
|
Yeah, you’ll need symbols. Isn’t
https://packages.debian.org/stretch/pianobar-dbg the symbols package?
|
|
I had that, but was confused (or overheated, given this weather) |
|
Just in case a second one helps |
|
So at least those two hangs are in the same codepath. |
|
First of all, change your password for pandora.com. I usually warn
people that a coredump contains their password, but missed it this time
– sorry about that.
I see you’re using pulseaudio. Can you try
#433 (comment)
please?
|
|
No worries, I anticipated this, didn't see it at a glance and decided I don't really care about the account enough to delay pasting. I can't try that before Monday, but would argue that no matter what the audio does or does not do, the UI should not freeze, in the meantime. |
|
Intermediate data point: No more hangs during the last ~3 hours. This is looking good, but I wouldn't want to confirm yet. Assuming this is a workaround, this raises two questions
|
|
1) Can the UI not lock up, no matter what sound engine is used?
I’m not entirely sure why the UI locks up in the first place. The stack
trace looks fine, thread 1 is waiting inside BarReadline/select for new
input. So either I’m missing something or the call to ao_play (thread 2)
locks up everything else too, which would be weird.
2) Can you warn when alsa is used?
No, alsa is perfectly fine for those not using pulseaudio.
|
|
I too am experiencing random lockups of the UI. Sometimes Ctrl-C will kick it free. I haven't been able to narrow it down, but I think it happens when the internet connection drops. Let me know what you need from me. I am running it on a oPi PC. |
|
@USAFPride Did you try using pulseaudio? @PromyLOPh The underlying issue still exists, though. |
|
Sometimes Ctrl-C will kick it free. I haven't been able to narrow it
down, but I think it happens when the internet connection drops.
^C aborts the current action and thus may indeed fix issues caused by
a dropped connection.
@PromyLOPh The underlying issue still exists, though.
But there were no UI lockups any more after switching to libao’s
pulseaudio driver, right?
|
|
@RichiH, I've changed to Pulse, but I will need to wait to see what happens. |
Correct; but the actual issue of UI lockup when the backend is unhappy still exists. |
Closed
|
Starting long-term test. |
|
Not so long after all. pianobar is currently hanging after anything between 3 and 7 hours; I wasn't wearing my headphones so I can't tell for sure. |
RichiH
changed the title
|
Well, I’m puzzled – no idea why this is still happening.
|
|
I’ve been using the updated version and have had no issues since this patch. I’ve discovered that any repeated internet connection issues caused most of the problems initially and this has fixed it. |
|
Let me reconfirm once more tomorrow. |
Hangs after a few hours. |
|
With pulse, it has been running for three days in a row, now. |
|
I'm getting this occasionally on a Debian Buster system using alsa. Version 2020.04.05 running from $HOME/bin. I can compile the git version if you think that might help. |
|
Does it work with pulse, @zoof? |
|
So far so good. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I regularly experience hangs of both the UI and sound playing with 2016.06.02 on Debian testing. Q, ^C, etc do not work, I have to kill the process from the outside.
I am fully aware of how thin this report is; if there's anything I can do to help debug, please tell me.
The text was updated successfully, but these errors were encountered: