Better error handling after zeroconf issues (and a request for help to debug the issue)

Describe the bug I’m experiencing issues with librespot-java zeroconf discovery, but only on one specific client, which is a raspberry 3 with a fresh raspbian install (but it also has pihole, homeasssistant and some other stuff installed on it which might interfere). Another Pi with the exact same version of librespot-java runs just fine, but this one raspberry is simply not showing up in spotify’s list of devices.

This is similar to #246, but a zeroconf /?action=getInfo GET request returns the same on both clients (except device ID and public key) , so it seems like a client-specific issue that the broken client never makes itself public for the Spotify clients.

As you can see in the below logs, the start of librespot-java is stalled after " Zeroconf HTTP server started successfully", whereas on the working raspberry it’ll say “Zeroconf:473 - Announced Service” shortly after starting the server.

Because I have absolutely no experience with zeroconf I couldn’t further debug the issue. Nevertheless I’d say that librespot-java should do some error handling when it fails to launch the zeroconf service properly.

To Reproduce Not sure unfortunately, which is why I’m looking for a way on how to debug this.

Expected behavior If there is an issue with the zeroconf discovery (announcement?) it should crash / show in the logs.

Screenshots/Stracktraces/Logs Log level for both raspberrys is TRACE

Log from the broken raspberry (it’s pretty short and nothing else will show up, even after a few minutes):

pi@raspi-server:~ $ java -jar librespot-player-1.5.1.jar
2020-08-10 23:32:41,309 INFO  Utils:84 - Cryptography restrictions removal not needed.
2020-08-10 23:32:41,438 INFO  ZeroconfServer:442 - Zeroconf HTTP server started successfully on port 21787!

In comparison, log from the working raspberry:

pi@raspi-zwei:~ $ java -jar librespot-player-1.5.1.jar
2020-08-10 23:32:54,607 INFO  Utils:84 - Cryptography restrictions removal not needed.
2020-08-10 23:32:54,926 INFO  ZeroconfServer:442 - Zeroconf HTTP server started successfully on port 17169!
2020-08-10 23:32:55,886 TRACE ZeroconfServer:506 - Handling request: GET /?action=getInfo HTTP/1.1, headers: {Connection=keep-alive, User-Agent=Spotify/113800558 Win32/0 (PC desktop), Host=192.168.0.107, Accept-Language=en, Accept-Encoding=gzip, deflate, Content-Type=application/x-www-form-urlencoded}
2020-08-10 23:32:56,527 INFO  Zeroconf:473 - Announced Service{alias='librespot-java', service='spotify-connect', port=17169, text={VERSION=1.0, CPath=/, Stack=SP}, addresses=[/192.168.0.107], domain='.local', protocol='tcp', host='raspi-thomas'}.
2020-08-10 23:34:34,851 TRACE ZeroconfServer:506 - Handling request: GET /?action=getInfo&version=2.7.1 HTTP/1.1, headers: {Connection=keep-alive, User-Agent=Spotify/113800558 Win32/0 (PC desktop), Host=192.168.0.107, Accept-Language=en, Accept-Encoding=gzip, deflate, Content-Type=application/x-www-form-urlencoded}

Version/Commit tested with both librespot-api-1.5.1.jar and librespot-player-1.5.1.jar

[devgianlu]

It seems to get stuck somewhere in between the gathering of the network interfaces and the dispatching of the service. Try this:

[zeroconf]
	listenAll = false
	interfaces = "eth0"
	listenPort = -1

If you can hook up a debugger you could try stepping trough this: https://github.com/librespot-org/librespot-java/blob/0be6da0b6dd26c92d448bf4aa5a88bd3d97a6a6f/lib/src/main/java/xyz/gianlu/librespot/ZeroconfServer.java#L110-L144

[devgianlu]

No problem, go ahead