mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 00:05:55 +03:00
[GH-ISSUE #876] Spotify does not detect Librespot as a device #436
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#436
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @itwasonlyabug on GitHub (Oct 30, 2021).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/876
Hi, I have been using Librespot for a few months now without any issues. Starting this month (October) though, none of my Librespot instances show up in Spotify.
I am running Librespot in Docker containers on a Raspberry Pi 4, but I also tried a direct
cargo install librespoton my laptop with no success.I have made no changes to my home network and I have tried with various combinations of Wi-Fi 2,ghz, Wi-Fi 5ghz and just everything wired together via Ethernet cable. I see no errors in Librespot's logs (besides ones about the Avahi demon when running inside a container).
Versions tried:
0.1.6 (this one was previously working)
0.2.0 (ditto)
0.3.1
Any tips on how to debug this?
@JasonLG1979 commented on GitHub (Oct 31, 2021):
I have basically zero experience with containers. Strange that it worked for months and now it stopped? Nothing else in your system has changed has it?
I would start by disabling
avahi-daemonif you're not using it for anything else. Librespot doesn't needavahi-daemonunless you compile it withwith-dns-sd. And in fact they may interfere with each other.If that doesn't work you can try disabling discovery with
--disable-discoveryand providing a--usernameand--passwordto see if it's even a mDNS problem.I would also run with the
--verboseflag to see if anything shows up in the logs.@roderickvd commented on GitHub (Oct 31, 2021):
Additionally:
I know you said you made no changes to your network, but please double-check multicast is working OK and not firewall in any way. Do other services like
shairplay-sync(AirPlay) show up?@itwasonlyabug commented on GitHub (Nov 1, 2021):
Thanks for the swift responses.
@JasonLG1979
Container-wise it's effectively running in Ubuntu 20.04 (focal) while the network is directly connected so no extra NAT or other networking hoops.
As I was unsure if this could be some random Docker / Container / RPI issue, I tried installing librespot directly on my laptop (Linux / Manjaro running 5.10 kernel).
In both cases, I'm installing Librespot through
cargoand not compilling / building it myself. It's running in verbose mode on both places and I see nothing wrong:from my laptop:
librespot -n "HelloWorld" -b 160 -v[2021-11-01T08:16:02Z INFO librespot] librespot 0.3.1 5049cd7 (Built on 2021-10-29, Build ID: vqN3o9BV, Profile: release) [2021-11-01T08:16:02Z DEBUG librespot_playback::mixer::mappings] Volume control is now Log(60.0) [2021-11-01T08:16:02Z DEBUG librespot_discovery::server] Zeroconf server listening on 0.0.0.0:40631from the container:
librespot -n "HELLO" -b 160 -v[2021-11-01T08:27:04Z INFO librespot] librespot 0.2.0 UNKNOWN (Built on 2021-09-20, Build ID: JrtOukg9) [2021-11-01T08:27:04Z DEBUG librespot_connect::discovery] Zeroconf server listening on 0.0.0.0:35093I'll try disabling
avahiand username + pass + no-discovery.@roderickvd I said it as in "I didn't explicitly make changes" but as we know - computers are magic :) I will check multicast operation. I have removed all firewalls on the RPI. I have not tried
shairplay-sync. Do you mean shairport-sync? I can try that one too.@roderickvd commented on GitHub (Nov 1, 2021):
Yes that's what I meant. Or any other zeroconf service.
@itwasonlyabug commented on GitHub (Nov 1, 2021):
I just tired
shairport-syncrunning in a docker container (https://hub.docker.com/r/mikebrady/shairport-sync) on the same RPI4 and I can see it in Spotify via AirPlay.@roderickvd commented on GitHub (Nov 2, 2021):
That puzzles me. I have no idea why one Zeroconf service is discoverable, and the other isn't.
Not sure if you've now also tried manually specifying a username and password, and disabling discovery?
@kingosticks commented on GitHub (Nov 2, 2021):
Maybe you guys already know this but that shairport-sync container also runs avahi. Maybe that's a piece of this puzzle. It's not clear to me which mDNS lib is used by the librespot binary from Cargo. Presumably it is using libmdns ? Did you disable avahi on the host?
@itwasonlyabug commented on GitHub (Nov 2, 2021):
I ran some tests on the laptop and here's the results:
--disable-discoverydoes not show up in spotify.--username, --password and --disable-discoveryworks and is visible in spotify!Here's some logs from the success (non-container):
librespot -n "HelloWorld" -b 160 -v --disable-discovery --username OMITTED --password OMITTED[2021-11-02T09:08:29Z INFO librespot] librespot 0.3.1
5049cd7(Built on 2021-10-29, Build ID: vqN3o9BV, Profile: release)[2021-11-02T09:08:29Z DEBUG librespot_playback::mixer::mappings] Volume control is now Log(60.0)
[2021-11-02T09:08:29Z INFO librespot_core::session] Connecting to AP "gew1-accesspoint-a-7qw9.ap.spotify.com:4070"
[2021-11-02T09:08:29Z INFO librespot_core::session] Authenticated as OMITTED !
[2021-11-02T09:08:29Z DEBUG librespot_core::session] new Session[0]
[2021-11-02T09:08:29Z INFO librespot_playback::mixer::softmixer] Mixing with softvol and volume control: Log(60.0)
[2021-11-02T09:08:29Z DEBUG librespot_connect::spirc] new Spirc[0]
[2021-11-02T09:08:29Z DEBUG librespot_connect::spirc] canonical_username: OMITTED
[2021-11-02T09:08:29Z DEBUG librespot_core::mercury] new MercuryManager
[2021-11-02T09:08:29Z DEBUG librespot_playback::player] new Player[0]
[2021-11-02T09:08:29Z INFO librespot_playback::convert] Converting with ditherer: tpdf
[2021-11-02T09:08:29Z INFO librespot_playback::audio_backend::rodio] Using Rodio sink with format S16 and cpal host: ALSA
[2021-11-02T09:08:29Z INFO librespot_playback::audio_backend::rodio] Using audio device: default
[2021-11-02T09:08:29Z DEBUG librespot_playback::mixer::mappings] Input volume 58958 mapped to: 49.99%
[2021-11-02T09:08:29Z DEBUG librespot_core::session] Session[0] strong=3 weak=2
[2021-11-02T09:08:29Z INFO librespot_core::session] Country: "OMITTED"
[2021-11-02T09:08:29Z DEBUG librespot_core::mercury] subscribed uri=hm://remote/user/OMITTED/ count=0
[2021-11-02T09:08:29Z DEBUG librespot_playback::audio_backend::rodio] Rodio sink was created
[2021-11-02T09:08:29Z DEBUG librespot_playback::player] command=AddEventSender
[2021-11-02T09:08:29Z DEBUG librespot_playback::player] command=VolumeSet(58958)
[2021-11-02T09:08:29Z DEBUG librespot_connect::spirc] kMessageTypeNotify "manjaro" and etc...
@kingosticks AVAHI has always failed for me but this didn't affect anything so far.
@roderickvd commented on GitHub (Nov 4, 2021):
Well, it must be something with Avahi or otherwise. Have you also tried compiling with
--features with-dns-sd?@itwasonlyabug commented on GitHub (Nov 10, 2021):
@roderickvd I tried installing with
--features-with-dns-sdand got multiple issues while installing / starting. See below:I heavily modified my Dockerfile to successfully install avahi and I can start it but this does not resolve the issue that LibreSpot is not visible in Spotify. Also, please keep in mind that I have been using the unmodified version for months with no issues.
I also reverted a backup of my router settings to verify there have been no changes and ran some zeroconf tests (avahi-daemon) but saw no issues.
For anyone interested, here's my old and used for a long time Dockerfile:
The relevant line in Snapserver conf -
source = spotify://librespot?name=Spotify&devicename=dockerize&volume=20&normalize=trueAnd here is my latest & greatest version, with Avahi working:
EDIT: Installing with
--features with-dns-sdworks on my laptop (manjaro) but there are no errors in the log and no devices shown in Spotify.@JasonLG1979 commented on GitHub (Nov 10, 2021):
Nothing in
librespothas changed as far as discovery in a very long time, 6 months or so from the looks of things. (https://github.com/librespot-org/librespot/tree/dev/discovery)If it worked forever but than stopped working clearly something has changed on your side that you have not found yet. Other devices can interfere with mdns. What new devices have you added to your network?
@itwasonlyabug commented on GitHub (Nov 10, 2021):
Can you give me some idea how to get some more logs out of Librespot or some breadcrumbs what the path fro Device A to Device B is so I can try to unwrap this?
All I can see is librespot starting and Zeroconf listening but no idea where the connection breaks. I can hit Zeroconf/Librespot on the port it picks, but this isn't logged in Librespot.
I am aware that this is almost entirely an issue with my setup, I just need some help with how to debug it :)
@JasonLG1979 commented on GitHub (Nov 10, 2021):
There would be no logs from
librespotas far as it's concerned it's advertised itself as a service. If there are no logs than no connection is being made.I believe that avahi has a GUI app. I have never used it but maybe that will help.
@JasonLG1979 commented on GitHub (Nov 10, 2021):
Eventually it would be nice to be able to use avahi's DBus interface for zeroconf on Linux.
@itwasonlyabug commented on GitHub (Nov 10, 2021):
This got me thinking - In all scenarios I have either A) No avahi working or B) Avahi working without DBus. Is DBus 100% required or is dbuss-less avahi fine?
@JasonLG1979 commented on GitHub (Nov 10, 2021):
I'm not sure? DBus is pretty much a requirement for a modern Linux system as just about everything uses it. I didn't even think you could run a DBus-less system? I've never thought about it or tried?
@dubo-dubon-duponey commented on GitHub (Nov 16, 2021):
@itwasonlyabug
I've been (and still am) running librespot in containers successfully (currently running 0.3.1).
can you copy the exact command you use to start your container? specifically, what networking mode you are using
also, personal opinion: just avoid avahi - it's messy in containers and definitely a source of issues when multiple instances share the same ip - you do not need avahi to use librespot
@itwasonlyabug commented on GitHub (Nov 16, 2021):
@dubo-dubon-duponey
0.24 is the "unmodified" dockerfile I sent in the coment above and 0.25.1 is the modified (with avahi) that I shared above.
@dubo-dubon-duponey commented on GitHub (Nov 16, 2021):
@itwasonlyabug network host is likely problematic if your host also has avahi installed. Multiple mDNS stacks on the same ip will compete / not play well with each other.
Can you try to use
macvlaninstead ofhost? (or make sure your host does not have any mDNS stack running - eg: avahi)And also make sure you use your version of librespot that does not use avahi (simplifies your problem).
For macvlan, if you are not familiar, see https://docs.docker.com/network/macvlan/ - something in the line of:
@dubo-dubon-duponey commented on GitHub (Nov 16, 2021):
Also, you may want to remove snap from the equation and start just librespot (for now).
@dubo-dubon-duponey commented on GitHub (Nov 16, 2021):
So, 0.24 appears to use librespot 0.1.6 which is quite old. I would just try with 0.3.1.
This one forces librespot to use avahi, which IIRC does require dbus (which you disabled).
Avahi works fine withOUT dbus if you are interested in resolution only - but (again IIRC) publishing with dnssd-dev does require dbus.
This is one of the reason avahi (in a container) is usually a bad idea. Just to annonce a single service, you have to spin up two different daemons (and the dbus one requires root IIRC).
Summarizing:
Let me know if it still does not work, there are more things we can try.
@dubo-dubon-duponey commented on GitHub (Nov 18, 2021):
@roderickvd I shared notes / experiences about these topics ^ on the wiki: https://github.com/librespot-org/librespot/wiki/librespot,-mDNS,-networking-and-containers in the hope that could help people who have issues related to containers / mDNS.
I hope this was the appropriate thing to do, but evidently feel free to do whatever you need with that page.
@itwasonlyabug ^
@itwasonlyabug commented on GitHub (Nov 19, 2021):
Thanks you very much @dubo-dubon-duponey for the support!
Here's my latest attempt:
I tried with:
--network host. ❌--features-with-dns-sdflag and the container running with--network host. ❌--network host. Tried with both thedns-sdflag and without it. ❌macvlaninstead - ❌--network hostand it is working flawlessly.✅I want to say that it's something on my side that's messing with the network, but I don't understand how Shairport works every time I try it if that is indeed the case.
@roderickvd If you prefer I can close the issue and re-open / open a new one if I manage to track this down, so I don't create noise. For the time being I can't say that it's a librespot issue.
@dubo-dubon-duponey commented on GitHub (Nov 19, 2021):
@itwasonlyabug
I'm lurking on gitter. Feel free to send me a PM over there if you want to continue this conversation out of band.
Nevertheless, the following should help figuring out what's wrong.
Can you follow these steps below exactly as written?
If you get a failure at step 1., you messed-up something with your macvlan config, so, try again until you get it right.
If step 1 is a success, but steps 2-4 fail, you have a network configuration issue.
To further diagnose it, you can try to first confirm that your RPI sees its own mDNS traffic.
On the RPI, with all the test containers from above still running:
If you get a success in that case while you get failures from a remote host, your network configuration / equipment is definitely the problem.
If you still get a failure in that case, then something is wrong with your RPI itself.
If step 1 is a success, and steps 2-4 are a mix of success & failures, then it's probably still a problem with your network configuration (though it hinders only certain mDNS implementations) <- I want to hear about it if that's the case.
Hope that helps...
@roderickvd commented on GitHub (Nov 19, 2021):
Great stuff @dubo-dubon-duponey, your input and documentation is highly appreciated.
@itwasonlyabug I'm fine with keeping this issue open. Although I have no idea what's going on, I do find it interesting that
shairplayworks andlibrespotdoesn't. So if there's a chance thatlibrespotcan be improved in this regard, then that's worth pursuing.@dubo-dubon-duponey commented on GitHub (Nov 19, 2021):
@roderickvd
From a cursory look & quick traffic sniffing, it seems to me that librespot uses aggressively short TTL (60 sec), and also does not appropriately set the cache flush bits on records.
For comparison, shairport sync uses a 75 minutes TTL, and does set the cache flush bit on all records but PTR.
So does Sonos (and also macOS).
Please take what I say with a grain of salt, as I'm not that familiar with the spec, but to me, very short TTLs like that are much more likely to trip multicast storm control with some gear, and lack of cache flush bit will very likely append multiple conflicting IN records for eg on restart (albeit given the short TTLs...).
I do not know if @itwasonlyabug problem is related to that ^ (we may get an answer when they will have run through my tests above ^, or if they can tcpdump), and again I'm not 100% comfortable with these topics, but I thought I would still point these two facts out.
@JasonLG1979 commented on GitHub (Nov 19, 2021):
I traced that back to our implementation:
https://github.com/librespot-org/libmdns/search?q=DEFAULT_TTL
And walked back though the git blames and it's been 60 since the initial commit with no explanation why?
@dubo-dubon-duponey zeroconf/mDNS is black magic voodoo to me. Apple is the king of zeroconf. I'm pretty sure they literally wrote the book. There are certainly worse things we could do than copy their implementation.
I'm sure PR's are welcome.
@dubo-dubon-duponey commented on GitHub (Nov 19, 2021):
@JasonLG1979 I usually sacrifice a chicken before touching mDNS...
Just fixing the ttl without also fixing the cache flush will likely cause more issues I think (right now the short TTL make it so these issues are at most taking 60 seconds to resolve AFAIK).
I'll look around into the codebase and issues (on the mdns lib) though I do not know rust, so... 🤪
@kingosticks commented on GitHub (Nov 19, 2021):
Is this not a problem with advertising on the wrong interface, because the default interface (which is used) is probably something weird in a container?
@dubo-dubon-duponey commented on GitHub (Nov 20, 2021):
My guess is "no" (at least in the exact set of examples I gave above (using macvlan) - iface is
eth0@if2, which works just fine with librespot for me - I've been using this with many different docker versions).From a cursory look, it looks like:
github.com/librespot-org/libmdns@acd405604d/src/fsm.rs (L187)- this simply enumerates all interfaces without trying anything "smart".Still an interesting point though. Could check with OP if the tests above still fail for them.
@JasonLG1979 commented on GitHub (Nov 20, 2021):
@dubo-dubon-duponey I'm fairly new to
rustbut I enjoy a challenge I'd be willing to give it a shot if you want to help me out?@dubo-dubon-duponey commented on GitHub (Nov 20, 2021):
@JasonLG1979 switching conversation to gitter if you want, so we can keep this issue centered on @itwasonlyabug problem.
@JasonLG1979 commented on GitHub (Nov 20, 2021):
Sure.
@itwasonlyabug commented on GitHub (Nov 26, 2021):
Just wanted to say I'm not dead - having some difficulties with the cabling, but will be able to test this in the next couple of days.
@roderickvd commented on GitHub (Nov 26, 2021):
Well that's always good to hear 😆
Thanks for the update.
@sdetweil commented on GitHub (Nov 30, 2021):
I have suddenly had to add user/pw info to my librespot instance to get it recognized as a valid receiver in my smart-mirror app
but I don't understand these words as it affects my app
I am using the node spotify -web-api library . it calls and gets registered receivers..
https://github.com/thelinmichael/spotify-web-api-node
until the librespot instance gets authenticated, the device it represents is not found.
my app doesn't know anything about what the receiver is and how it works internally.
so , all I have is username/pw, which shows on the commandline (ps -ef too) from starting librespot which is a terrible security exposure. I don't have any 'apps' that use zeroconf to discover anything.
@JasonLG1979 commented on GitHub (Nov 30, 2021):
Something has changed on your side networking wise then. The mDNS code in
librespothas not changed in a long time.At least that part could be solved with: https://github.com/librespot-org/librespot/pull/886
It's ready and just waiting to be merged.
librespotuses zeroconf by default so do the official Spotify apps and a whole lot of other apps and services. You'd be surprised. It's very widely used. If anything to do with your smart mirror depends onavahi-daemonit's using zeroconf.@itwasonlyabug commented on GitHub (Nov 30, 2021):
Alright, so I did some testing and I got it working! This is my Dockerfile that works:
As you can see, I've removed all the avahi stuff, so it looks like the initial container I had running, but with the newest version of Librespot. There is also no Avahi working anywhere atm (not on the PI, not on the laptop i'm using).
Now onto the steps:
gI don't see anything on _workstation._tcp -t but I see on _nvstream_dbd._tcp localdocker inspect mypy | jq -rc '.[0].NetworkSettings.Networks["my-macvlan"].IPAddress'-> results in <MACVALN_IP>avahi-browse _raop._tcp -t | grep TEST_shairport && echo "Success" || echo "Failure"-> results in+ enp0s3 IPv4 9391508A60DC@TEST_shairport AirTunes Remote Audio localSuccessavahi-browse _spotify-connect._tcp -t | grep TEST_goello && echo "Success" || echo "Failure"results in+ enp0s3 IPv4 TEST_goello _spotify-connect._tcp localSuccessdocker run -ti --rm --net my-macvlan --entrypoint librespot dubodubonduponey/spotify --name TEST_librespot -vLogs from the container
avahi-browse _spotify-connect._tcp -t | grep TEST_goello && echo "Success" || echo "Failure"FailureThis might be relevant to the IPV6 error https://github.com/librespot-org/librespot/issues/67#issuecomment-848225881 @roderickvd is it possible for librespot to fail if it tries to connect to IPV6?
Now for the final test with all the containers:
Caveats:
My results are contaminated 😭
Thanks to everyone involved, you've been grand! Especially @dubo-dubon-duponey, thanks for the in-depth support! :) If anyone wants to try something on my environment, please add it here otherwise I'm closing the ticket.
@dubo-dubon-duponey commented on GitHub (Nov 30, 2021):
@itwasonlyabug glad you got it working!
Step 4, I'm afraid you have typos in there. You are supposed to test for
TEST_librespotin step4 (and NOTTEST_goello).I think it's a red herring. My hunch is "no".
Take-away:
Thanks for the offer to test in your environment. Though, since it does work now, I don't think it's going to surface useful info.
@dubo-dubon-duponey commented on GitHub (Nov 30, 2021):
@sdetweil have you tried:
I believe this is true for any Spotify compatible speaker (inc. Sonos for example)... until it does authenticate with your user account, it will not be listed by your node app (the node module you are using clearly relies on https://developer.spotify.com/documentation/web-api/reference/#/operations/get-a-users-available-devices which can only list devices that are authenticated - either directly, or through the Spotify app).
Put otherwise, your node app is not able to discover existing speaker/endpoints. It only list the speakers/endpoints that are using your Spotify account.
In the case of librespot, that means you have to either:
Hope that helps.
@sdetweil commented on GitHub (Nov 30, 2021):
yes, helps a lot.. there still is no spotify connect for raspi OS. SO, thats raspotify (which wraps librespot) .. SO local authentication is the only choice..
makes no sense to force someone to PLAY on THIS device (from some other device) with some OTHER tool, so you can then play on this device..
@JasonLG1979 commented on GitHub (Nov 30, 2021):
I'm not sure how you would expect apps to show up in the node service your using, which only shows devices that are authenticated by your account to show up without credentials?
You're essentially asking "Why do I have to authenticate apps for them to show up in the list of authenticated apps?"
@sdetweil commented on GitHub (Nov 30, 2021):
I know everyone is protecting their assets, vigorously, now.. sure makes useful solutions harder and harder to implement
anyway, I've put the info in a file, and can read it into env variables for when the support comes in..
@JasonLG1979 commented on GitHub (Nov 30, 2021):
No, what I mean is what you're asking is nonsensical. It's not a matter of security.
In it's "natural" credential-less state
librespotoperates in zeroconf mode. In that mode it's visible to any and all other Spotify apps locally as a Spotify Connect endpoint. But since there are no creds it's not "owned" (authenticated) by any account. Only after you connect to it does it get authenticated.If you want
librespotto show up as authenticated or "owned" by your account before you connect you have to provide creds.@JasonLG1979 commented on GitHub (Nov 30, 2021):
It has to be authenticated one way or another for it to show up in your node app.
@JasonLG1979 commented on GitHub (Nov 30, 2021):
Yep I know. I'm the Raspotify maintainer.
@sdetweil commented on GitHub (Nov 30, 2021):
but it hasn't been required for years to do this. but anyway. times they are a changin
@JasonLG1979 commented on GitHub (Nov 30, 2021):
This has not changed in
librespotnor Raspotify. If something has changed in the way thatlibrespotoperates something has changed in your network or applications.@JasonLG1979 commented on GitHub (Nov 30, 2021):
That aspect of
librespothas not changed in a very long time.@sdetweil commented on GitHub (Nov 30, 2021):
hm. I have been running librespot on this machine for 3 years, without authentication, and up til last year without Spotify connect ( Ubuntu ) for development and fixes, and never had this issue til this spring. the code I am maintaining is older than that
@JasonLG1979 commented on GitHub (Nov 30, 2021):
Well something has changed and it wasn't
librespot.@dubo-dubon-duponey commented on GitHub (Dec 1, 2021):
@sdetweil so, I assume you have been playing music on that librespot instance, right?
Then that means you have been authenticating: whenever you do play music on that librespot instance, you effectively authenticate with your user account. Then, this librespot instance will show-up in the list of devices attached to your user account, which will be returned by your node module...
Maybe the question is actually: what do you want to achieve here? (beside technical details)
If what you want to do is: "list available speakers on my local network", then you are clearly using the wrong nodejs library, since that library can only list devices that have been playing music already, or have been manually authenticated.
@JasonLG1979 commented on GitHub (Dec 1, 2021):
If you enable caching
librespotwill use the cached auth token. You ofc have to connect at least once.@dubo-dubon-duponey commented on GitHub (Dec 1, 2021):
Yeah, that's my guess about what has happened for @sdetweil and why they think things have changed / they did not have to authenticate before.
@JasonLG1979 commented on GitHub (Dec 1, 2021):
Ofc if you disable caching you can't expect to use the cached auth token. And I honestly have no idea how long the tokens are good for?
@sdetweil commented on GitHub (Dec 1, 2021):
this smart-mirror is voice centered
so the command (after getting the oauth done) is
smart-mirror, ask/tell spotify to play ???? on [ this device | device name ]
and I can transfer play , etc..
and it would play. the code had a retry problem i fixed last year, not playing for a day, didn't find it on the first try,
but did on retry, thats when I found the spotify connect app but only used it once or twice. (why use a UI when voice works?!)
anyhow, it worked.. and then this year, spring ish I saw the it was looping in the background.. got the newer librespot code and all was well.. and then last week saw my cpu heat was up and found it looping again ..
then found this issue..
my command from before today
the voice user has always been oauth authenticated for spotify
@JasonLG1979 commented on GitHub (Dec 1, 2021):
-c2 ./cacheis not valid.@sdetweil commented on GitHub (Dec 1, 2021):
its running, no error messages..
found that on some google search years ago.. it worked..
@JasonLG1979 commented on GitHub (Dec 1, 2021):
Then by all means listen to Google and not the guy that wrote the code that parses the command line args in
librespot...@sdetweil commented on GitHub (Dec 1, 2021):
my point was, ok, so I am not a librespot commandline guy (and don't want to be).. I got enough on my plate..
the doc didn't help me.. terms I don't understand, so, I searched around til I found something that worked.
and stuck with it.
but , it didn't complain, or I would have found something else that didn't..
I don't play music often, I have a small hearing problem that i find is minimized with less surround sound content.
but my users don't have that problem, and also just want it to work.
I will gladly take your advice on how to change it.
@JasonLG1979 commented on GitHub (Dec 1, 2021):
-c2 ./cachecreates a cache folder called2(the./cachepart is ignored) inside the home of the user that startslibrespot. In the case of Raspotify it doesn't work because it uses a dynamic user that has no home. And even if that folder existed somewhere you wouldn't have permission to write to it. You should use/var/cache/raspotifyas documented since that's the ONLY place the Raspotify service has permission to write to.@sdetweil commented on GitHub (Dec 1, 2021):
ok, note that I am running on ubuntu now, using librespot, not raspotify
@JasonLG1979 commented on GitHub (Dec 1, 2021):
How do you run the service?
@sdetweil commented on GitHub (Dec 1, 2021):
I use pm2 to launch the binary under my user
@JasonLG1979 commented on GitHub (Dec 1, 2021):
Is that user privileged?
@JasonLG1979 commented on GitHub (Dec 1, 2021):
I have no experience with pm2 I personally would just use systemd since it's more native and allows you to sandbox services.
@sdetweil commented on GitHub (Dec 1, 2021):
i do not think so.. i am in sudoers
I had to make /var/cache/librespot 777 for my command to not get access denied on start (666 didn't work as I would have expected)
@JasonLG1979 commented on GitHub (Dec 1, 2021):
Oh, wow. running a network facing service as a sudoer with 777 cache... fully loaded foot guns.
@sdetweil commented on GitHub (Dec 1, 2021):
what the heck do you want me to do?
I just want the damn thing to RUN,.. u wanted cache, so I tried to set that up.. I TOLD you what i did, not hiding anything
@JasonLG1979 commented on GitHub (Dec 1, 2021):
No, what I mean is that above you were complaining about having your password and username in plain text and you're basically running naked though a corn field with that thing. Your Spotify creds are the least of your worries if that's your approach to security. It's actually kinda funny.
@sdetweil commented on GitHub (Dec 1, 2021):
ok, thanks.. I'm gonna go get some dinner.. running with /c2
@JasonLG1979 commented on GitHub (Dec 1, 2021):
I'm sorry. All kidding aside:
Never run system services as a privileged user if you can help it. And you can help it for sure in this case. Nothing about
librespotrequires privileges.700 should be fine for the cache. That means that only the user who owns the folder can read, write and execute.
Don't use 777 if you have to use 777 more than likely you're doing something wrong.
@sdetweil commented on GitHub (Dec 1, 2021):
the folder /var/cache/librespot did not exist
I had to use sudo to create it, so that set the user to root
so 600 won't work as I am not root
666 did not work but should have
@JasonLG1979 commented on GitHub (Dec 1, 2021):
I'm sorry the folder has to be 700 you want the files 600.
It would if you configured
librespotto start with systemd and configured the cache folder to be/var/cache/librespotin the unit file with:Systemd will create the folder for you if it does not exist. You still need to point librespot at
/var/cache/librespot. The above just takes care of creating the folder and setting the permissions.You can see a full example of a reasonably secure
librespotsystemd service unit file here.You're mileage may vary depending on what version of Ubuntu you're running. The sandbox settings target the version of systemd that comes with Raspberry Pi OS (based on Debian Bullseye) which is 247.
With that configuration
librespotwill more than likely be the most secure service on you system as reported bysystemd-analyze securityand still be fully functional.@JasonLG1979 commented on GitHub (Dec 1, 2021):
You can also clear the cache by stopping the service with
sudo systemctl stop librespotthensudo systemctl clean librespotand finallysudo systemctl restart librespotif you want to restart it. That's assuming you name the servicelibrespotofc.It would probably be easier for you to just use the Raspotify package if you have a recent enough version of systemd.
@JasonLG1979 commented on GitHub (Dec 1, 2021):
I feel like this has gone way off topic. I will stop now and say that yours is a problem of configuration and a lack of understanding @sdetweil if you'd like to continue we can move to a discussion. I'm done here as it's just noise for anyone who is actually having this legitimate issue.
@roderickvd commented on GitHub (Dec 1, 2021):
The
new-apibranch has a new caching token provider that automatically refreshes tokens 10 seconds before they expire. It also reveals when the expiry time is. This is something that Spotify sets and isn't guaranteed to be any set value in the future.