Shaun Alexander

For some further examples, I'm seeing a similar thing in my setup which has been successfully long running, although I did reboot the machine yesterday, and add pulseaudio back to...

Mine never managed to reconnect but I did find [this issue](https://github.com/librespot-org/librespot/issues/1490) (https://github.com/librespot-org/librespot/issues/1490 added after my comment above) is exactly my problem.

Just adding another data point of this issue. I originally thought it was this https://github.com/librespot-org/librespot/issues/1481#issuecomment-2781062014 but I never got it to reconnect. Similar to povserok I had a primary DNS...

Ahh it seems debian [defaults to 5 seconds for the timeout](https://manpages.debian.org/bookworm/manpages/resolv.conf.5.en.html#timeout:). From the docs (emphasis mine): > [timeout:n](https://manpages.debian.org/bookworm/manpages/resolv.conf.5.en.html#timeout:) Sets the amount of time the resolver will wait for a response...

In my `resolv.conf` setting the following did indeed work (proving @kingosticks assumption that 5 seconds would be enough if the DNS timeout was 3s, and you only had the first...

Or perhaps it is actually a good idea to ([from the original PR](https://github.com/librespot-org/librespot/pull/1458#issuecomment-2618666133)): > Would it make sense to make the timeout customizable?

TLDR: 1. Code/config for `librespot` to support broken systems is undesirable, however this problem can occur for many reasons, not just a `librespot` servers config, but transient upstream DNS server...

Ahh sorry I missed that about the log above showing the 3s timeout. Okay that makes sense to me, so we have a situation where some library use cases need...