error code 99 error sending packet

[iameru]

Description
Fresh installation of spotifyd does not function.
In my config its the bare minimum: User, password and backend are given.

See errors down below, I myself am a user and dont really understand why it is not working. It seems to be connecting though.

version:
spotifyd 0.3.2 (installed from repo)
OS:
5.13.13-1-MANJARO Linux

user@host$   spotifyd --no-daemon

Loading config from "/home/user/.config/spotifyd/spotifyd.conf"
No proxy specified
Using software volume controller.
error sending packet Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" }
Connecting to AP "gew1-accesspoint-a-z34n.ap.spotify.com:443"
Authenticated as "USER_ACCOUNT_INFO" !
Country: "DE"
Unhandled DBus message: (Signal, Some("/org/freedesktop/DBus"), Some("org.freedesktop.DBus"), Some("NameAcquired"))
Sep 25 16:25:51 host spotifyd[164523]: error sending packet Os { code: 99, kind>

linked to issue #532 which was closed by a bot

[nickray]

Running into this as well (regular Arch Linux, community package 0.3.2-1), couldn't locate the source of the error. The spotifyd works, but it logs the above code 99 error messages every two seconds (about 20 times, then it stops).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[iameru]

automated bot closing, yay.

[eladyn]

This error comes neither directly from spotifyd nor from librespot (which spotifyd uses). There are several issues in the librespot repository, which are about the problem: librespot-org/librespot#918, librespot-org/librespot#326.

In general, you can find a lot about this error by searching the internet since it isn't really specific to this application and often happens with somewhat special network setups.

Apparently, the error comes from this line in the libmdns crate, which is used here.
You could try and change this line to the following

diff --git a/Cargo.toml b/Cargo.toml
index b522886..21fa464 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -37,7 +37,7 @@ xdg = "2.2"
 librespot-audio = { version = "0.2.0", default-features=false, features = ["with-tremor"] }
 librespot-playback = { version = "0.2.0", default-features=false }
 librespot-core = { version = "0.2.0"}
-librespot-connect = { version = "0.2.0"}
+librespot-connect = { version = "0.2.0", features = ["with-dns-sd"]}
 toml = "0.5.8"
 color-eyre = "0.5"

and recompile spotifyd to see, if it works with the other available mdns library. Otherwise, it is probably a problem with your network setup.

Hope this helps.

[OJFord]

Thanks @eladyn, I have the same issue & tried that, unfortunately:

PANIC: Shutting down spotifyd. Error message: called Result::unwrap() on an Err value: DNSError(Unknown)

I haven't managed to get any more out of it with --verbose or RUST_BACKTRACE=1.

I'm not sure what 'a problem with your network setup' means, certainly I and presumably anyone reporting this issue have no problem with other devices on the network - or in my case, the official client & web-app on the same device too.

[eladyn]

@OJFord Thanks for trying! That new error is probably due to neither of avahi and bonjour running, as documented multiple times¹ in issues over at the librespot repository.

Apart from that, I no longer think that trying with-dns-sd would help us get further here. Something that might be worth trying, though, are the steps outlined here (second paragraph), to see, whether the problem is reproducible in libmdns and, if so, report the issue over there.

Another point of interest: How, if in any way, does this error influence your ability to use spotifyd and play music?

Footnotes

1. https://github.com/librespot-org/librespot/issues/824, https://github.com/librespot-org/librespot/issues/985, https://github.com/librespot-org/librespot/issues/819 ↩

[OJFord]

That new error is probably due to neither of avahi and bonjour running,

Ah yes probably then - there were warnings about that that I omitted.

Something that might be worth trying

I'll give that a go, thanks.

How, if in any way, does this error influence your ability to use spotifyd and play music

I haven't used it before, so I was just trying to get started; I haven't been able to as a result. I was trying to play something from another device because it seemed that should 'just work', and honestly I couldn't figure out how I was supposed to use it from the same device? That's why I went straight to 'Connect'.

[OJFord]

Yes - but it is only logged as a warning:

$ cargo run --example register
[2022-05-18T16:20:46Z TRACE libmdns::fsm] sending packet to [ff02::fb]:5353
[2022-05-18T16:20:46Z WARN  libmdns::fsm] error sending packet Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" }
[2022-05-18T16:20:46Z TRACE libmdns::fsm] received packet from 192.168.3.225:5353
[2022-05-18T16:20:46Z TRACE libmdns::fsm] received packet from 192.168.3.225:5353 with no query

I'm not sure if that's a problem or not, given it's a warning and then 'received packet'?

[OJFord]

If I start avahi-daemon.service by the way it does indeed get rid of that error and seem to start up fine - doesn't appear in available devices on others though.

[eladyn]

Thanks for reporting back, that is indeed valuable information! My guess is that that warning just indicates a problem with IPv6, but doesn't really influence libmdns' ability to work. Judging by those received packet messages, IPv4 seems to work fine though.

You could probably check with ss or netstat, whether spotifyd correctly listens on 5353 and some random high port. For me, that prints the following:

# ss -lnp | grep spotifyd
udp   UNCONN 0      0                                                  0.0.0.0:5353             0.0.0.0:*    users:(("spotifyd",pid=15822,fd=10))                                 
udp   UNCONN 0      0                                                        *:5353                   *:*    users:(("spotifyd",pid=15822,fd=11))                                 
tcp   LISTEN 0      128                                                0.0.0.0:45539            0.0.0.0:*    users:(("spotifyd",pid=15822,fd=9))                                  

Maybe it is also related to a firewall or anything else blocking the traffic? Of course, you can always just pass your credentials to spotifyd, and it would also work.

[OJFord]

Just the high TCP one for me:

tcp   LISTEN 0      0                                                                                     0.0.0.0:39819            0.0.0.0:*    users:(("spotifyd",pid=120846,fd=9))

No error though (this is with avahi-daemon running still):

May 19 16:11:12 spotifyd[120846]: Loading config from "~/.config/spotifyd/spotifyd.conf"
May 19 16:11:12 spotifyd[120846]: CliConfig { config_path: None, no_daemon: true, verbose: true, pid: None, shared_config: SharedConfigValues { username: Some("..."), username_cmd: None, password: None, password_cmd: Some("..."), use_keyring: false, use_mpris: None, on_song_change_hook: None, cache_path: None, no-audio-cache: false, backend: None, volume_controller: None, device: None, control: None, mixer: None, device_name: Some("..."), bitrate: None, initial_volume: None, volume_normalisation: false, normalisation_pregain: None, zeroconf_port: None, proxy: None, device_type: Some(Computer), autoplay: false } }
May 19 16:11:12 spotifyd[120846]: Found user shell: Some("/bin/bash")
May 19 16:11:12 spotifyd[120846]: No password specified. Checking password_cmd
May 19 16:11:12 spotifyd[120846]: Running "..." using "/bin/bash"
May 19 16:11:12 spotifyd[120846]: No proxy specified
May 19 16:11:12 spotifyd[120846]: registering event source with poller: token=Token(0), interests=READABLE | WRITABLE
May 19 16:11:12 spotifyd[120846]: Using software volume controller.
May 19 16:11:12 spotifyd[120846]: registering event source with poller: token=Token(1), interests=READABLE | WRITABLE
May 19 16:11:12 spotifyd[120846]: Zeroconf server listening on 0.0.0.0:39819
May 19 16:11:12 spotifyd[120846]: *** WARNING *** The program 'spotifyd' uses the Apple Bonjour compatibility layer of Avahi.
May 19 16:11:12 spotifyd[120846]: *** WARNING *** Please fix your application to use the native API of Avahi!
May 19 16:11:12 spotifyd[120846]: *** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
May 19 16:11:12 spotifyd[120846]: *** WARNING *** The program 'spotifyd' uses the Apple Bonjour compatibility layer of Avahi.
May 19 16:11:12 spotifyd[120846]: *** WARNING *** Please fix your application to use the native API of Avahi!
May 19 16:11:12 spotifyd[120846]: *** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
May 19 16:11:12 spotifyd[120846]: Connecting to AP "ap.spotify.com:443"
May 19 16:11:12 spotifyd[120846]: registering event source with poller: token=Token(2), interests=READABLE | WRITABLE
May 19 16:11:12 spotifyd[120846]: flushing framed transport
May 19 16:11:12 spotifyd[120846]: writing; remaining=253
May 19 16:11:12 spotifyd[120846]: framed transport flushed
May 19 16:11:12 spotifyd[120846]: attempting to decode a frame
May 19 16:11:12 spotifyd[120846]: frame decoded from buffer
May 19 16:11:12 spotifyd[120846]: deregistering event source from poller

Of course, you can always just pass your credentials to spotifyd, and it would also work.

Sorry, I don't follow that, as above I have configured username & password_cmd, I assumed that was necessary. Is there something else for some sort of more direct connection between devices you mean?

[OJFord]

Of course, you can always just pass your credentials to spotifyd, and it would also work.

Sorry, I don't follow that, as above I have configured username & password_cmd, I assumed that was necessary. Is there something else for some sort of more direct connection between devices you mean?

Oh I see now, via https://github.com/librespot-org/librespot/wiki/Authentication#zeroconf-based-authentication=, no I'm not trying to rely on it for auth - just trying to play something via my phone (say) as the client.

'Web player (Firefox)' shows up fine as a client; that's Firefox on the same computer I'm trying to run spotifyd.

[eladyn]

Just the high TCP one for me:

tcp   LISTEN 0      0                                                                                     0.0.0.0:39819            0.0.0.0:*    users:(("spotifyd",pid=120846,fd=9))

No error though (this is with avahi-daemon running still):

Sorry, should've been clearer about what I meant. My output was with libmdns, yours is indeed the expected output if you do it with avahi-daemon.

Sorry, I don't follow that, as above I have configured username & password_cmd, I assumed that was necessary. Is there something else for some sort of more direct connection between devices you mean?

In theory, you don't need to supply spotifyd with credentials, as it will just advertise itself on the network. I'm currently out of ideas, why this isn't working for you. Looking at your logs, I'm guessing that authentication was not successful.¹ A successful authentication should look something like this:

# spotifyd --no-daemon
...
Connecting to AP "ap.spotify.com:443"
Authenticated as "user" !
Country: "DE"
...

So maybe you can try debugging, why the authentication fails in your case.

Footnotes

1. Unfortunately, the situation with reporting authentication failures is currently not optimal. (see e.g., properly handle Session::connect() errors #1041) ↩

[OJFord]

.... Fixed it. username needs to be your email address, not your -er- username.

(Veering off-topic, but aside from the naming it'd be nice if it logged 'failed to authenticate' or whatever, I'd have tried that a lot sooner. It doesn't, even with --debug-credentials.)

[eladyn]

Great to hear that! For me, it actually works with my username as well. Regarding the better reporting of authentication failure: Yeah, that is definitely suboptimal, and you're not the first one to stumble over it. There are two PRs that would improve that situation, #1041 and #1059, hopefully one of them can be merged at some point.

---

I guess, this issue could be closed, since the “error” isn't really an error, but rather a warning that appears in some cases, but doesn't influence usability? And if it does, it would probably be better to report it over at the librespot-org/libmdns repo.

[tyskie]

Hello,

I have this error too. It occurs when I start spotifyd without credentials (username/password). If I start spotifyd with my credentials I am the only one that sees this device in the spotify app. When I start spotifyd without credentials I can use the device. The other members of my family also see the device and can use it. If it is already in use they can join the session, control the device and change the music. That is precisely what I need so I would be very pleased if the error could be cured or cirumvented.

Regards, Thijs

[tyskie]

Hi,

I have found that spotifyd.service is so kind to accept StandardOutput=null. As in

[Service]
ExecStart=/usr/bin/spotifyd --no-daemon
Restart=always
RestartSec=12
StandardOutput=null

That will do it for now. I'm not much of a reader of syslog anyway 😉 But I don't want it cluttered or flooded.

Regards, Thijs

[eladyn]

@tyskie Hi! As pointed out above, I'm not really sure what exactly causes the warning to be emitted, other than that it's coming from libmdns and probably doesn't influence usability.

If you're interested in seeing that error go away, maybe you can try reproducing it with the libmdns example (see here) and report a bug over there?

---

Apart from that, I'm going to close this, since this isn't really an issue with spotifyd. :)