Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: [development suspended] Spotify Integration (foo_spotify) (Read 52821 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Spotify Integration (foo_spotify)

Reply #25 –
Sorry to ask but what is the point of this extension? I need to look up the spotify uri copy it into fb2k. Why not playing it directly from the spotify client. What are the use cases?

Re: Spotify Integration (foo_spotify)

Reply #26 –
To avoid confusion for anyone who've read the post above: `foo_spotify` DOES NOT require the usage of URI's. In fact, URI won't work for anything other than single tracks.
The intended usage scenario is copying tracks/albums/playlists by URL: https://theqwertiest.github.io/foo_spotify/docs/faq/#how-to-actually-play-music-from-spotify
 

Re: Spotify Integration (foo_spotify)

Reply #27 –
Quote from: wcs13 on
@all : FYI, both of these two advanced prefs must be set to 0, or foo_spotify won't play music no matter what you try :
- Advanced > Playback > Buffering > Read-ahead for local files
- Advanced > Playback > Buffering > Full file buffering up to
Source : https://hydrogenaud.io/index.php?topic=119973.msg988798#msg988798

This helped. Thanks!

TheQwertiest, thank you for this plugin!

1. Is it theoretically possible to implement Spotify library navigation in foobar2000? Or search at least, like in Youtube Source plugin.

2. Is it possible to pass calculated gain from Spotify to foobar2000 to use normalization like in default app?

3. Current bitrate (in status bar) is not displayed. Is this a bug or limitation?
🇺🇦 Glory to Ukraine!

Re: Spotify Integration (foo_spotify)

Reply #28 –
Quote from: Chris Norman on
Sorry to ask but what is the point of this extension? I need to look up the spotify uri copy it into fb2k. Why not playing it directly from the spotify client. What are the use cases?

foobar2000 is a powerful tool. You take control of audio playback: ability to use DSPs, custom output interfaces.
🇺🇦 Glory to Ukraine!

Re: Spotify Integration (foo_spotify)

Reply #29 –
Quote from: Steve Forte Rio on
1. Is it theoretically possible to implement Spotify library navigation in foobar2000?
Yes, I've put it on the TODO list, but I don't think I will get to it any time soon.

Quote from: Steve Forte Rio on
Or search at least, like in Youtube Source plugin.
 
This is planned for the feature release after the next one.

Quote from: Steve Forte Rio on
2. Is it possible to pass calculated gain from Spotify to foobar2000 to use normalization like in default app?
No, I don't think so. There is `normalization` option (https://github.com/TheQwertiest/foo_spotify/issues/12) though.

Quote from: Steve Forte Rio on
3. Current bitrate (in status bar) is not displayed. Is this a bug or limitation?
Probably a bug, I'll look into it.

Re: Spotify Integration (foo_spotify)

Reply #30 –
Quote from: Steve Forte Rio on
3. Current bitrate (in status bar) is not displayed. Is this a bug or limitation?
Could not reproduce this bug: displays fine for me:


Re: Spotify Integration (foo_spotify)

Reply #31 –
@wcs13 @GeSomeone  , FYI, I've made a workaround (in the nightly build) that allows to play Spotify tracks with buffering enabled. All tracks need to be re-imported via `Add Location...` for the workaround to work though.

Re: Spotify Integration (foo_spotify)

Reply #32 –
Thank you, will try it soon :)

Re: Spotify Integration (foo_spotify)

Reply #33 –
I noticed that %APPDATA%\foobar2000\foo_spotify\ls\cache grows when playing from Spotify. It can become rather large, and doesn't become smaller when you remove Spotify tracks.
Will it be cleaned up at any time?

(a portable install doesn't use %APPDATA% but keeps everything in the install folder).
In theory, there is no difference between theory and practice. In practice there is.

Re: Spotify Integration (foo_spotify)

Reply #34 –
@GeSomeone , component uses the default setting of "libspotify automatically resizes the cache (10% of disk free space)".
I will expose the configuration though: https://github.com/TheQwertiest/foo_spotify/issues/23

Re: Spotify Integration (foo_spotify)

Reply #35 –
Thanks for the answer,
a related question however: Why is it in %APPDATA% and not in %LOCALAPPDATA%. For local it makes some sense to look at free disk space, but Roaming Profiles might have other limits than just disk space.
In theory, there is no difference between theory and practice. In practice there is.

Re: Spotify Integration (foo_spotify)

Reply #36 –
Quote from: GeSomeone on
Thanks for the answer,
a related question however: Why is it in %APPDATA% and not in %LOCALAPPDATA%. For local it makes some sense to look at free disk space, but Roaming Profiles might have other limits than just disk space.
Dunno, component uses the profile path that is returned by fb2k, so you'll have to ask fb2k devs =)

Re: Spotify Integration (foo_spotify)

Reply #37 –
Maybe none of the developers are nutty enough to use Roaming Profiles in their home environment?

Re: Spotify Integration (foo_spotify)

Reply #38 –
I get HTTP 429 errors when trying to play any Spotify track. Tried both the latest nightly build as well as release 1.0.2. Output from the console for a test track:
Code: [Select]
Opening track for playback: "spotify:track:6rkeaQRCWZxwkjhyqgxjXi"
Unable to open item for playback (429: unknown
Additional data: HTTP/1.1 429 unknown
access-control-allow-credentials: true
access-control-allow-headers: Accept, App-Platform, Authorization, Content-Type, Origin, Retry-After, Spotify-App-Version, X-Cloud-Trace-Context, client-token
access-control-allow-methods: GET, POST, OPTIONS, PUT, DELETE, PATCH
access-control-allow-origin: *
access-control-expose-headers: Retry-After
access-control-max-age: 604800
Alt-Svc: clear
Content-Length: 80
Date: Mon, 19 Oct 2020 18:35:47 GMT
Retry-After: 3453
Server: envoy
strict-transport-security: max-age=31536000
Vary: Accept-Encoding
Via: HTTP/2 edgeproxy, 1.1 google
x-content-type-options: nosniff


):
"spotify:track:6rkeaQRCWZxwkjhyqgxjXi"

Re: Spotify Integration (foo_spotify)

Reply #39 –
Like the previous posters issue, I am receiving the error 429 when adding songs to my library.

It was working this morning, I went out for a few hours and it's broken so I'm assuming Spotify changed something in their WebAPI.

[imghttps://imgur.com/a/7SLv0Ua[/img]

Here's the error I get when trying to play a newly added song:
"Unable to open item for playback (429: unknown
Additional data: null
):
"spotify:track:6YIHCgaDKTmyRH1yUXUKSE"."
After looking on Spotify's webAPI site it says: 429   Too Many Requests - Rate limiting has been applied.
Hope this helps you fix the issue, thank you so much for making this component!!! It saves me hours slaving away on r/riprequests

Re: Spotify Integration (foo_spotify)

Reply #40 –
Welp, f*ck.
It seems that Spotify applies rate-limiting per-app and not per-user. So, as component's user base was growing, so was the amount of requests. Till eventually we reached the global (as in per-app) rate limit (which is unknown and not disclosed to the public).

I don't know how to fix it. Or even if it's possible to. I will try to search around the WWW and will try to reach to Spotify support, but it looks really unpromising.

Worst comes to worst, I'll have to abandon this component :\

PS: And it's not like there were THAT many request, it peaked at 4k request a day. Which is like ~50 requests per active user :\

Re: Spotify Integration (foo_spotify)

Reply #41 –
Would it be possible to have users supply their own API keys?

Re: Spotify Integration (foo_spotify)

Reply #42 –
@sammoth, theoretically it's possible, but it will require a totally different authentication scheme and it will severely limit the user-base of this component.

Re: Spotify Integration (foo_spotify)

Reply #43 –
Not knowing this, I have played some tracks today, without problems. I added them to a playlist previously.
In the example below it says "Retry After 3453" seconds that is. That is almost 58 minutes, which make me think it will reset after one hour. It is suggested to wait an extra second cause it could still be counting down some milliseconds that you can't see.

It could become a problem in the long run though. The only advise from Spotify is to fetch multiple entities in one request.
 
In theory, there is no difference between theory and practice. In practice there is.

Re: Spotify Integration (foo_spotify)

Reply #44 –
Quote from: GeSomeone on
Not knowing this, I have played some tracks today, without problems. I added them to a playlist previously.
That's because I'm caching the data, so nothing is actually fetched =)

Quote from: GeSomeone on
In the example below it says "Retry After 3453" seconds that is. That is almost 58 minutes, which make me think it will reset after one hour. It is suggested to wait an extra second cause it could still be counting down some milliseconds that you can't see.
This value is actually in milliseconds (not seconds like usually), so it's not *that* bad =). The problem is that this still still doesn't help (I've implemented the proper handling in the latest nightly): every consequent request still returns 429 even after the required wait :\

Quote from: GeSomeone on
The only advise from Spotify is to fetch multiple entities in one request.
I'm already batching all requests that are possible to batch...

Quote from: GeSomeone on
It could become a problem in the long run though. The only advise from Spotify is to fetch multiple entities in one request.
It's a huge problem even in short-term, since it rendered the component effectively useless. I'm trying to find if there as any way to increase the rate-limit (apart from going commercial, since it's impossible for me), but no luck so far...

Re: Spotify Integration (foo_spotify)

Reply #45 –
I would like to support this idea :

Quote from: sammoth on
Would it be possible to have users supply their own API keys?
I understand it will make things different. But how many people want to play Spotify through foobar anyway ? Not so much, given that there was barely a working component until now. And those who really want it will surely make the effort to get a Spotify account, go to the developers page, accept the terms of service and get an API key (I guess that's the process).

I remember having a similar problem with TMDB and a script that was provided with the developer's API key. Getting my own TMDB account and a personal API key solved the issue.

Re: Spotify Integration (foo_spotify)

Reply #46 –
It seems that my current app key was banned (soft-ban via 429 on every request). Since the number of requests per day has fallen significantly (less than a half of requests during the first release day), but every requests still fails.
I will implement some measures to limit the amount of requests (in addition to proper 429 response handling) and then will release the component with the new app key (that is not banned).
If my measures don't help and the component still gets a `429-ban`, then I will most likely abandon it's development.

Re: Spotify Integration (foo_spotify)

Reply #47 –
Maybe API keys aren't designed for making a player replacement, since it seems these awful delay errors would seem to indicate that they count delay across ALL USERS of the API key, globally. Which kind of sucks.

Re: Spotify Integration (foo_spotify)

Reply #48 –
Quote from: TheQwertiest on
If my measures don't help and the component still gets a `429-ban`, then I will most likely abandon it's development.
Please don't give up when you could at least give users the OPTION to replace your API Key with theirs...

Re: Spotify Integration (foo_spotify)

Reply #49 –
@kode54 , playback is a separate API from the one that is getting 429-banned.
As I've mentioned, the current amount of daily request is MUCH smaller than it was on the first days of the component.
That could mean one or more of the following:
- Request limit are not per day, but per week or per month. The component might have exceeded that quota.
- There were a few instances when a user somehow performed more than 1k request in a day. This might have caused the throttle/429-ban.
- There was no 429 response handling implemented. This might have caused the throttle/429-ban.

But yes, rps limits are per-app and not per-user. Spotify guides have mentioned though, that it's not static. And I've seen a few popular non-commercial apps that do not require user to create a separate app key. So, I'm hoping that implementing RPS limits and 429 handling (coupled with a new app key to avoid the 429-ban) will be enough.

@wcs13 , the problem is that I will have to rewrite the authentication scheme to do that. And I currently don't have enough motivation for that.