The community for ongoing Spotify Connect research and the librespot-org/librespot project.
roderickvd on dev
Update raspotify description Merge pull request #1043 from J… (compare)
2nd point is problematic indeed. I get why you wouldn't want to make everything optional, as there is also stuff where I think it can always be assumed to be present like for example Track::{name, duration}
. The problem imo is to figure out what is actually missing in some cases.
After looking through the code again I think most critical would be Track::{number, disc_number
as I don't think all tracks need to be tagged with disc / track number. Since you can't determin if disc_number== 0
is actually disc-0 or not present, maybe those should be explicitely optional. With something like Track::version_title
it would default to an empty string which could easily be checked.
But on the other hand if you need to check is_empty()
anyways before using it, you can also use an optional value instead. At least that way it forces you to write working code.
I'll postpone the optional stuff and think about it a bit more, but I'll be sure to make a proposal if I come up with something sensible.
Another point: Should the wrapper types (like Tracks
) implement DerefMut
in addition to Deref
? I think that would be consistent and allow for basically full transparency of the types, even with mutable functions. If there is no reason against it, I'll make a PR for it
Deref
and DerefMut
at the same time. This would further slim down the boilerplate for those wrapper types
Could you elaborate on the part of the comment about the playlist: https://github.com/librespot-org/librespot/pull/1036#issuecomment-1201639830
In playlist/list.rs you see that the Playlist struct is decorated on top of an inner SelectedListContent. Maybe that can serve as an example for having inner structs.
I have to admit that I generally don't quite understand the difference between Playlist
and RootPlaylist
. As far as I can tell they contain mostly the same data (RootPlaylist
just wrapping the SelectedListContent
). Compared RootPlaylist
is missing the id
and Playlist
is missing the owner_username
ACCEPT
header specifically to application/x-protobuf
or application/json
or something else may be wrong, like the brand new client-token
header. Honestly I am assuming this thing in librespot-java
is working, I did not test that either.
I took the opportunity of the playlist mercury -> http switch did some very basic testing. In my tests the mercury endpoint was on average more than 4 times faster then the http endpoint for querying a playlist. The time for http from call to data was 0.6 to 0.7 seconds and for mercury it was only 0.13 to 0.3 with the average hovering around 0.6 and 0.15 .
From a technical standpoint (with me knowing literally nothing about mercury) it would also make sense that http with totally separate requests and a very large per-request overhead (headers, tls, ...) would be slower than using an already open channel
Just putting this information out there for now
spotify:playlist:37i9dQZF1DWZeKCadgRdKQ
with 180 tracks the difference is very noticable.Client
compared to building a new one on each request. The only problem is how to store that client, considering the (in cases like this really annoying) way how it's generic over connector and body (Client<C, B>
). The fact that there are two different connectors (normal Https and Proxy<Https>) makes it pretty hard
new-api
discussion. Great first optimization this, let’s continue from here!
i686
myself nor do I have a host running that.
/me/player/devices
to get a list of connected devices, I'd get an empty list back. If I replaced the KEYMASTER_CLIENT_ID
with what is being used on https://developer.spotify.com/console/get-users-available-devices/, I'd get the correct list of devices. I tried two of my own client IDs, and they would work, too. Has the one we're using by default been burnt?
playlist-read
.
cargo run --example get_token <user> <password> | fgrep access_token | export TOKEN=$(cut -d '"' -f2) && curl -X "GET" "https://api.spotify.com/v1/me/player/devices" -H "Accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN"
{
"devices" : [ ]
}
KEYMASTER_CLIENT_ID
with my own client ID, I get the expected result:{
"devices" : [ {
"id" : "...",
"is_active" : false,
"is_private_session" : false,
"is_restricted" : false,
"name" : "My Librespot Player",
"type" : "Speaker",
"volume_percent" : 49
} ]
}
dev
code. It has been used by thousands of users, incl. myself since then. Yesterday my server suddenly started to behave oddly, until I figured out that rsyslogd was filling up my system with logs coming from librespot (my application is launching librespot from Perl, therefore the "perl" in the log):Aug 8 14:10:20 musicpi perl[5569]: thread 'main' panicked at 'Spotify servers returned an error. Restart librespot.', core/src/mercury/mod.rs:205:13
Aug 8 14:10:20 musicpi perl[5569]: stack backtrace:
Aug 8 14:10:20 musicpi perl[5569]: 0: 0x75c958 - <unknown>
Aug 8 14:10:20 musicpi perl[5569]: 1: 0x49c258 - <unknown>
Aug 8 14:10:20 musicpi perl[5569]: 2: 0x75bec0 - <unknown>
Aug 8 14:10:20 musicpi perl[5569]: 3: 0x75b8dc - <unknown>
Aug 8 14:10:20 musicpi perl[5569]: 4: 0x75ad34 - <unknown>
Aug 8 14:10:20 musicpi perl[5569]: 5: 0x51c810 - <unknown>
Aug 8 14:10:20 musicpi perl[5569]: 6: 0x51c810 - <unknown>
Aug 8 14:10:20 musicpi perl[5569]: 7: 0x51c810 - <unknown>
...
Aug 8 15:26:46 musicpi perl[5569]: 64354566: 0x51c810 - <unknown>
Aug 8 15:26:46 musicpi perl[5569]: 64354567: 0x51c810 - <unknown>
Aug 8 15:26:46 musicpi perl[5569]: 64354568: 0x51c810 - <unknown>
Aug 8 15:26:46 musicpi perl[5569]: 64354569: 0x51c810 - <unknown>
abort
also exits without any sort of cleanup, as in it dies without releasing it's allocated memory leaving that up to the OS. (0x51c810
is a memory address) There could be some funkyness going on because of that? I personally would not distribute stripped or abort
binaries, because although they will be very tiny they're basically useless for debugging so you end up preventing the user from help you help them if that makes sense? A log full of 0: 0x75c958 - <unknown>
is pretty useless.
abort
would not give a backtrace at all. But that probably was a misunderstanding. The reason why I opted for the stripped version is that I provide binaries for multiple platforms (Mac Intel/ARM, Win, Linux ARM/686/x86_64...). Even compressed this makes for a lot of data. I'm now using a CDN, so this is not that much of a problem any more (my hosting service didn't like it). But OTOH I've been doing this for 5+ years without any regret - until a week ago.