You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I build librespot with discovery support both for my x64 Linux desktop as well as for an ARMv5 embedded device. Both instances run and I get the log message [("action", "getInfo")]. However, only the desktop is discovered by the Spotify app whereas the embedded device does not show up. I compared the packets with wireshark, but I cannot see any difference.
I finally traced the communication with tcpdump. Both logs dumps show in- and outgoing traffic. However, only the desktop device is listed in the Spotify app.
What I've noticed so far is that the HTTP response send by librespot differs: the embedded device has no date string and the "status" field in the JSON string is 100 instead of 101.
The text was updated successfully, but these errors were encountered:
It turned out that this has nothing to do with librespot at all. The issue is with a wrong data-alignment in the custom ARMv5 target description. This has been fixed: rust-lang/rust#31796. librespot now runs on my ARMv5 target, although audio output is stuttering like hell. But this is another issue related to libvorbis being an decoder for floating point targets...
I build librespot with discovery support both for my x64 Linux desktop as well as for an ARMv5 embedded device. Both instances run and I get the log message
[("action", "getInfo")]
. However, only the desktop is discovered by the Spotify app whereas the embedded device does not show up. I compared the packets with wireshark, but I cannot see any difference.I finally traced the communication with tcpdump. Both logs dumps show in- and outgoing traffic. However, only the desktop device is listed in the Spotify app.
What I've noticed so far is that the HTTP response send by librespot differs: the embedded device has no date string and the "status" field in the JSON string is 100 instead of 101.
The text was updated successfully, but these errors were encountered: