starred/librespot
1
0
Fork 0
mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 00:05:55 +03:00
Code Issues 95 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #281] Did spotify drop mdns support for spotify connect? #190

New issue
Closed
opened 2026-02-27 19:29:19 +03:00 by kerem · 17 comments
kerem commented 2026-02-27 19:29:19 +03:00
Owner
Copy link

Originally created by @agrenott on GitHub (Dec 10, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/281

Hi,

I've been trying for days now to use the self discovery of librespot on my local network (not specifying my user account in the configuration).
Librespot implements the local discovery via mDNS protocol. However, using wireshark on my windows PC running official spotify client, I see no traffic on port 5353 (except discovery of proxy viq WPAD, which can be disabled in spotify advanced settings).
Instead, I can see SSDP traffic, with M-SEARCH query.

I can't find anything confirming this on the web.
Does anyone here encounter the same issue, or is able to get some network trace with official spotify connect device to confirm it?

This would mean the whole mDNS part of librespot could be dropped, and should be replaced with SSDP equivalent...

Thanks,
Aurelien

Originally created by @agrenott on GitHub (Dec 10, 2018). Original GitHub issue: https://github.com/librespot-org/librespot/issues/281 Hi, I've been trying for days now to use the self discovery of librespot on my local network (not specifying my user account in the configuration). Librespot implements the local discovery via mDNS protocol. However, using wireshark on my windows PC running official spotify client, I see no traffic on port 5353 (except discovery of proxy viq WPAD, which can be disabled in spotify advanced settings). Instead, I can see SSDP traffic, with M-SEARCH query. I can't find anything confirming this on the web. Does anyone here encounter the same issue, or is able to get some network trace with official spotify connect device to confirm it? This would mean the whole mDNS part of librespot could be dropped, and should be replaced with SSDP equivalent... Thanks, Aurelien
kerem 2026-02-27 19:29:19 +03:00
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@devgianlu commented on GitHub (Dec 10, 2018):

Which version of the Spotify client are you running?

On Mon, Dec 10, 2018, 21:12 agrenott <notifications@github.com wrote:

Hi,

I've been trying for days now to use the self discovery of librespot on my
local network (not specifying my user account in the configuration).
Librespot implements the local discovery via mDNS protocol. However, using
wireshark on my windows PC running official spotify client, I see no
traffic on port 5353 (except discovery of proxy viq WPAD, which can be
disabled in spotify advanced settings).
Instead, I can see SSDP traffic, with M-SEARCH query.

I can't find anything confirming this on the web.
Does anyone here encounter the same issue, or is able to get some network
trace with official spotify connect device to confirm it?

This would mean the whole mDNS part of librespot could be dropped, and
should be replaced with SSDP equivalent...

Thanks,
Aurelien

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/librespot-org/librespot/issues/281, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AOI-8aP9FbVAL3R4XwG0MmdHB7398VV6ks5u3sBJgaJpZM4ZMGDl
.

<!-- gh-comment-id:445961355 --> @devgianlu commented on GitHub (Dec 10, 2018): Which version of the Spotify client are you running? On Mon, Dec 10, 2018, 21:12 agrenott <notifications@github.com wrote: > Hi, > > I've been trying for days now to use the self discovery of librespot on my > local network (not specifying my user account in the configuration). > Librespot implements the local discovery via mDNS protocol. However, using > wireshark on my windows PC running official spotify client, I see no > traffic on port 5353 (except discovery of proxy viq WPAD, which can be > disabled in spotify advanced settings). > Instead, I can see SSDP traffic, with M-SEARCH query. > > I can't find anything confirming this on the web. > Does anyone here encounter the same issue, or is able to get some network > trace with official spotify connect device to confirm it? > > This would mean the whole mDNS part of librespot could be dropped, and > should be replaced with SSDP equivalent... > > Thanks, > Aurelien > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/librespot-org/librespot/issues/281>, or mute the > thread > <https://github.com/notifications/unsubscribe-auth/AOI-8aP9FbVAL3R4XwG0MmdHB7398VV6ks5u3sBJgaJpZM4ZMGDl> > . >
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@agrenott commented on GitHub (Dec 10, 2018):

On windows: 1.0.95.289.g342899da.
And same with android client 8.4.83.625.

<!-- gh-comment-id:445995426 --> @agrenott commented on GitHub (Dec 10, 2018): On windows: 1.0.95.289.g342899da. And same with android client 8.4.83.625.
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@devgianlu commented on GitHub (Dec 11, 2018):

I've managed to updated the Android client and it doesn't detect librespot-java anymore, I am waiting for the Windows update. That was an issue on my side (librespot-org/librespot-java#32).

<!-- gh-comment-id:446208330 --> @devgianlu commented on GitHub (Dec 11, 2018): ~I've managed to updated the Android client and it doesn't detect `librespot-java` anymore, I am waiting for the Windows update.~ That was an issue on my side (librespot-org/librespot-java#32).
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@awiouy commented on GitHub (Dec 11, 2018):

Have you tried building librespot with with-dns-sd, see https://github.com/librespot-org/librespot/wiki/Compiling

<!-- gh-comment-id:446263481 --> @awiouy commented on GitHub (Dec 11, 2018): Have you tried building librespot with with-dns-sd, see https://github.com/librespot-org/librespot/wiki/Compiling
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@agrenott commented on GitHub (Dec 11, 2018):

Yes, but I'm still stuck on a libsystemd.so not found at link time (while it's there and I've added the path with ld -L argument) - using raspotify cross-compilation docker image tweaked a bit.
But anyway, as I can't even see any mDNS packet going out of the official client, I don't think it would make any difference. Or are you saying avahi-daemon would handle SSDP requests as well for librespot?

<!-- gh-comment-id:446291971 --> @agrenott commented on GitHub (Dec 11, 2018): Yes, but I'm still stuck on a libsystemd.so not found at link time (while it's there and I've added the path with ld -L argument) - using raspotify cross-compilation docker image tweaked a bit. But anyway, as I can't even see any mDNS packet going out of the official client, I don't think it would make any difference. Or are you saying avahi-daemon would handle SSDP requests as well for librespot?
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@sashahilton00 commented on GitHub (Dec 15, 2018):

I'm now running 1.0.95.289.g342899da on OS X, and librespot is still working fine. Looks like we'll have to wait for iOS/Android versions to update a few and watch for changes.

<!-- gh-comment-id:447576255 --> @sashahilton00 commented on GitHub (Dec 15, 2018): I'm now running `1.0.95.289.g342899da` on OS X, and librespot is still working fine. Looks like we'll have to wait for iOS/Android versions to update a few and watch for changes.
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@devgianlu commented on GitHub (Dec 20, 2018):

1.0.95.289.g342899da is also fine on Windows.

<!-- gh-comment-id:448996139 --> @devgianlu commented on GitHub (Dec 20, 2018): `1.0.95.289.g342899da` is also fine on Windows.
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@agrenott commented on GitHub (Dec 29, 2018):

What do you mean by "fine"? Do you see mDNS queries sent from the windows client? Are you able to use spotify connect without specifying user/password when starting librespot?

<!-- gh-comment-id:450486712 --> @agrenott commented on GitHub (Dec 29, 2018): What do you mean by "fine"? Do you see mDNS queries sent from the windows client? Are you able to use spotify connect without specifying user/password when starting librespot?
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@devgianlu commented on GitHub (Dec 29, 2018):

I've not checked the traffic between the clients, but Zeroconf works fine with librespot-java.

If you see some SSDP, maybe they are slowly switching to it, I'll check.

<!-- gh-comment-id:450486939 --> @devgianlu commented on GitHub (Dec 29, 2018): I've not checked the traffic between the clients, but Zeroconf works fine with `librespot-java`. If you see some SSDP, maybe they are slowly switching to it, I'll check.
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@devgianlu commented on GitHub (Dec 29, 2018):

@agrenott There are a lot of SSDP packets being sent on my network, but that's normal. I have not seen anything related to Spotify, could you point out which type of service (NT header in the NOTIFY request) is used?

<!-- gh-comment-id:450491539 --> @devgianlu commented on GitHub (Dec 29, 2018): @agrenott There are a lot of SSDP packets being sent on my network, but that's normal. I have not seen anything related to Spotify, could you point out which `type of service` (NT header in the NOTIFY request) is used?
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@agrenott commented on GitHub (Dec 29, 2018):

Here is the SSDP query from spotify client on windows (sent each time you display the list of available devices):

0000   01 00 5e 7f ff fa 70 85 c2 43 63 26 08 00 45 00   ..^.ÿúp.ÂCc&..E.
0010   00 99 26 4d 00 00 01 11 00 00 c0 a8 00 03 ef ff   ..&M......À¨..ïÿ
0020   ff fa df f0 07 6c 00 85 39 58 4d 2d 53 45 41 52   ÿúßð.l..9XM-SEAR
0030   43 48 20 2a 20 48 54 54 50 2f 31 2e 31 0d 0a 48   CH * HTTP/1.1..H
0040   4f 53 54 3a 20 32 33 39 2e 32 35 35 2e 32 35 35   OST: 239.255.255
0050   2e 32 35 30 3a 31 39 30 30 0d 0a 4d 41 4e 3a 20   .250:1900..MAN: 
0060   22 73 73 64 70 3a 64 69 73 63 6f 76 65 72 22 0d   "ssdp:discover".
0070   0a 4d 58 3a 20 31 0d 0a 53 54 3a 20 75 72 6e 3a   .MX: 1..ST: urn:
0080   64 69 61 6c 2d 6d 75 6c 74 69 73 63 72 65 65 6e   dial-multiscreen
0090   2d 6f 72 67 3a 73 65 72 76 69 63 65 3a 64 69 61   -org:service:dia
00a0   6c 3a 31 0d 0a 0d 0a                              l:1....

Or a bit more readable view (from wireshark):

Internet Protocol Version 4, Src: 192.168.0.3, Dst: 239.255.255.250
User Datagram Protocol, Src Port: 57328, Dst Port: 1900
Simple Service Discovery Protocol
    M-SEARCH * HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
        Request Method: M-SEARCH
        Request URI: *
        Request Version: HTTP/1.1
    HOST: 239.255.255.250:1900\r\n
    MAN: "ssdp:discover"\r\n
    MX: 1\r\n
    ST: urn:dial-multiscreen-org:service:dial:1\r\n
    \r\n
    [Full request URI: http://239.255.255.250:1900*]
    [HTTP request 2/2]
    [Prev request in frame: 40]
<!-- gh-comment-id:450506663 --> @agrenott commented on GitHub (Dec 29, 2018): Here is the SSDP query from spotify client on windows (sent each time you display the list of available devices): ``` 0000 01 00 5e 7f ff fa 70 85 c2 43 63 26 08 00 45 00 ..^.ÿúp.ÂCc&..E. 0010 00 99 26 4d 00 00 01 11 00 00 c0 a8 00 03 ef ff ..&M......À¨..ïÿ 0020 ff fa df f0 07 6c 00 85 39 58 4d 2d 53 45 41 52 ÿúßð.l..9XM-SEAR 0030 43 48 20 2a 20 48 54 54 50 2f 31 2e 31 0d 0a 48 CH * HTTP/1.1..H 0040 4f 53 54 3a 20 32 33 39 2e 32 35 35 2e 32 35 35 OST: 239.255.255 0050 2e 32 35 30 3a 31 39 30 30 0d 0a 4d 41 4e 3a 20 .250:1900..MAN: 0060 22 73 73 64 70 3a 64 69 73 63 6f 76 65 72 22 0d "ssdp:discover". 0070 0a 4d 58 3a 20 31 0d 0a 53 54 3a 20 75 72 6e 3a .MX: 1..ST: urn: 0080 64 69 61 6c 2d 6d 75 6c 74 69 73 63 72 65 65 6e dial-multiscreen 0090 2d 6f 72 67 3a 73 65 72 76 69 63 65 3a 64 69 61 -org:service:dia 00a0 6c 3a 31 0d 0a 0d 0a l:1.... ``` Or a bit more readable view (from wireshark): ``` Internet Protocol Version 4, Src: 192.168.0.3, Dst: 239.255.255.250 User Datagram Protocol, Src Port: 57328, Dst Port: 1900 Simple Service Discovery Protocol M-SEARCH * HTTP/1.1\r\n [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n] Request Method: M-SEARCH Request URI: * Request Version: HTTP/1.1 HOST: 239.255.255.250:1900\r\n MAN: "ssdp:discover"\r\n MX: 1\r\n ST: urn:dial-multiscreen-org:service:dial:1\r\n \r\n [Full request URI: http://239.255.255.250:1900*] [HTTP request 2/2] [Prev request in frame: 40] ```
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@devgianlu commented on GitHub (Dec 29, 2018):

dial-multiscreen-org doesn't belong to Spotify.

DIAL—for DIscovery And Launch—is a simple protocol that second-screen devices can use to discover and launch apps on first-screen devices.

<!-- gh-comment-id:450507571 --> @devgianlu commented on GitHub (Dec 29, 2018): `dial-multiscreen-org` doesn't belong to Spotify. > DIAL—for DIscovery And Launch—is a simple protocol that second-screen devices can use to discover and launch apps on first-screen devices.
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@agrenott commented on GitHub (Dec 30, 2018):

And still, I'm almost sure those come from spotify client, as I capture them only when it's started. And the string "ST: urn:dial-multiscreen-org:service:dial:1" appears inside the binary (looking with process explorer).

<!-- gh-comment-id:450531903 --> @agrenott commented on GitHub (Dec 30, 2018): And still, I'm almost sure those come from spotify client, as I capture them only when it's started. And the string "ST: urn:dial-multiscreen-org:service:dial:1" appears inside the binary (looking with process explorer).
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@agrenott commented on GitHub (Dec 30, 2018):

Arg, got it. Looks like my spotify client correctly sends the mDNS requests, but on an invalid network interface, so it never reaches the "real" network...

<!-- gh-comment-id:450532056 --> @agrenott commented on GitHub (Dec 30, 2018): Arg, got it. Looks like my spotify client correctly sends the mDNS requests, but on an invalid network interface, so it never reaches the "real" network...
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@devgianlu commented on GitHub (Dec 30, 2018):

That is indeed true, but I cannot force Spotify to use SSDP between two clients. This means that they are using both mDNS and SSDP. I'll try with my smart TV.

Update: My TV is indeed dispatching a service with type urn:dial-multiscreen-org:service:dial:1.

<!-- gh-comment-id:450552460 --> @devgianlu commented on GitHub (Dec 30, 2018): That is indeed true, but I cannot force Spotify to use SSDP between two clients. This means that they are using both mDNS and SSDP. I'll try with my smart TV. Update: My TV is indeed dispatching a service with type `urn:dial-multiscreen-org:service:dial:1`.
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@sashahilton00 commented on GitHub (Jan 4, 2019):

Those SSDP requests are likely to be from the Cast SDK that is integrated into the Spotify clients. Whilst I can't be certain, I would say that nothing has changed w/ regards to the mDNS discovery.

<!-- gh-comment-id:451572048 --> @sashahilton00 commented on GitHub (Jan 4, 2019): Those SSDP requests are likely to be from the Cast SDK that is integrated into the Spotify clients. Whilst I can't be certain, I would say that nothing has changed w/ regards to the mDNS discovery.
kerem commented 2026-02-27 19:29:20 +03:00
Author
Owner
Copy link

@agrenott commented on GitHub (Jan 5, 2019):

I guess we can close the issue, as mDNS support is not dropped, just mis-behaving when several network interfaces are available (in my case using Hyper-V internal interface).
BTW, seems the android spotify client isn't using mDNS (or has similar issue than the windows one).

<!-- gh-comment-id:451606832 --> @agrenott commented on GitHub (Jan 5, 2019): I guess we can close the issue, as mDNS support is not dropped, just mis-behaving when several network interfaces are available (in my case using Hyper-V internal interface). BTW, seems the android spotify client isn't using mDNS (or has similar issue than the windows one).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
dev
v0.8.0
v0.7.1
v0.7.0
v0.6.0
v0.5.0
v0.4.2
v0.4.1
v0.4.0
v0.3.1
v0.3.0
v0.2.0
v0.1.6
v0.1.5
v0.1.3
v0.1.2
v0.1.1
v0.1.0
Labels
Clear labels   
A-Alsa

   
SpotifyAPI

   
Tokio 1.0

   
audio

   
bug

   
can't reproduce

   
compilation

   
dependencies

   
duplicate

   
enhancement

   
good first issue

   
help wanted

   
high priority

   
imported

   
imported

   
invalid

   
new api

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
reverse engineering

   
wiki

   
wontfix
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/librespot#190
No description provided.