Issues after latest spotify update

[jduust]

It seems that the latest spotify update created some issues, at least with monstercat visualizer. It won't fetch album cover, song name or album name.

Spotify version: 1.0.85.257.g0f8531bd Windows 10 64-bit Rainmeter 4.2.0 r3111 64-bit (Jul 8 2018) - Danish (1030)

[MZimmermann]

Looks like the local spotify-api the rainmeter-spotifyplugin relies on is no longer accessible: https://github.com/JohnnyCrazy/SpotifyAPI-NET/issues/254 The code in Parent.cs seems to make use of the web-api already, perhaps it's possible to rely on it completely. Although that sound's like a lot of web-traffic being generated for constantly updating rainmeter-scripts. :(

[ghost]

Can confirm that this issue is still persisting with the newest Spotify update:

Spotify version: 1.0.85.259.g4ab01679 Windows 10 64-bit Rainmeter 4.2.0 r3111 64-bit (Jul 8 2018) - English (1033)

[RobertFrydenlund]

@MZimmermann Thank you for finding the cause of the issue.

Ever since I started this patchwork of a plugin, I have been aware that the local API might stop functioning or change without notice (As it pretty much broke every other Spotify update). I have been in contact with Spotify regarding this plugin before, and I was warned that it was undocumented for a reason and I shouldn't expect it to keep working forever. I was also warned that a combined amount of 8000 token request per second was a little excessive, which is probably my favorite email ever 😄.

Even tho I would love to keep this plugin local to avoid unnecessary internet traffic, I think its about time we upgraded to using the WebAPI only. Expect an update soon.

[stevehoek]

@RobertFrydenlund thanks for all you do on this plugin... you should consider refactoring it to use SpotifyAPI.NET project (https://johnnycrazy.github.io/SpotifyAPI-NET/) so that you benefit from that community's work and not have to debug Spotify's API issues yourself. My $0.02...

[RobertFrydenlund]

@stevehoek We already are, they are having the same issue.

[MZimmermann]

For now I built a workaround involving an opened tab in a browser with the spotify-queue, a chrome-webextension which parses the document in intervals to scrape the information from the html-elements and pushes it to a locally running http-server-process in java, which then writes this data into a file, which is then parsed by a lua-script for rainmeter (based on a script intended for "google-play-music-desktop-player"). The album-art looks a bit fuzzy, because the only image available is the thumbnail on the lower-left. Web-extensions aren't allowed to save to files, so I build the http-server-relay. A god-awful hack which will break as soon as spotify decides to re-arrange their design, I'm really looking forward to a real solution.

[RobertFrydenlund]

Not to get everyone's hope up, but I'm pretty sure I'll upload a fix later today. No promises tho 🤞

[RobertFrydenlund]

If you are feeling adventurous, you can try the 2.1.6-Beta.

[jduust]

If you are feeling adventurous, you can try the 2.1.6-Beta.

It works for me

[MZimmermann]

It works in principle, although some values are now only returned as string (track length for example) and the playing-measure always returns zero.

[RobertFrydenlund]

@MZimmermann Should be fixed with 2.1.6-Beta.2.

[ghost]

@RobertFrydenlund you are a legend! Thanks for all the work to help make our desktops look beautiful!

[ghost]

@RobertFrydenlund beta crashes randomly, like once every 10 minutes.

[RashadAhmed1]

Also experiencing frequent crashes, also the progress bar on the skin I'm using is no longer working

[ghost]

Progress bar works fine for me. Your skin is broken lol.

[RobertFrydenlund]

@dninja21 Got any logs or error messages I can look at? Works fine on my end so far.

[RashadAhmed1]

This is the skin I'm using: https://github.com/tjmarkham/win10widgets/blob/master/Win10%20Widgets/Spotify/Spotify-Medium-Thin.ini

It hasn't been updated in a while but it was working fine a couple days ago. There's nothing in the log related to the progress bar

[ghost]

^^ Me too

[MZimmermann]

Left the pc alone for a couple of hours and found, that the plugin became non-responsive (i.e. didn't provide updated values to the skin anymore). Refreshing the skin didn't help, only a complete rainmeter-restart. Log showed only one error:

22:16:05 21 July 2018
SpotifyPlugin version 2.1.6.0
Culture: en-GB
OSVersion: Microsoft Windows NT 10.0.17134.0
----
 The remote server returned an error: (404) Not Found.
----
    at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
   at System.Net.WebClient.DownloadString(Uri address)
   at SpotifyPlugin.AlbumArt.GetAlbumImage(Int32 resolution, String filePath)

I was still using the first version of the 2.1.6-Beta and this error was probably not be responsible for the crash, as the exception was properly caught.

[MZimmermann]

Tried the new version 2.1.6-Beta.2, after about half an hour it stopped updating. Refreshing the skin crashed rainmeter, the windows-event-log captured an event with id 1026 from .NET Runtime:

Application: Rainmeter.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
   at SpotifyPlugin.Measure.Update()
   at SpotifyPlugin.Plugin.Update(IntPtr)

So at least one of the fixed double-measures must lack a proper check for null-references. You don't seem to have pushed the code for the second beta yet, so there's no telling which one it might've been, but it should be easy enough to find.

EDIT: by the way, I think the stalling happened about an hour after the last restart. Sound suspiciosly like the 3600 seconds "expires_in" parameter I saw in a url which opened in my browser after I started rainmeter.

[ghost]

Same error for me.

Application: Rainmeter.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
   at SpotifyPlugin.Measure.Update()
   at SpotifyPlugin.Plugin.Update(IntPtr)

[RobertFrydenlund]

Left it running overnight with a hacky debugger attached. Turns out the NullReferenceException just hides the fact that it's losing the connection to the WebAPI, because I missed a null-reference check. Will get right on it (And also remember to commit this time).

[RobertFrydenlund]

New beta release, hope it at least solves some of the issues we are having 🤞.

[RashadAhmed1]

Crashing seems to be fixed, but now song data switches between working and showing an error message every couple seconds. Also the progress bar is still not working on the skin I'm using.

[MZimmermann]

@ryraansh That's because the progress-measure still returns zero. If the skin derives the progress by dividing the position by the length, it works. The error seems to be located here, in Measure.Update:

int? progressMs = this.parent.Status?.get_ProgressMs();
int? durationMs = this.parent.Status?.get_Item()?.get_DurationMs();
return (progressMs.HasValue & durationMs.HasValue ? new double?((double) (progressMs.GetValueOrDefault() / durationMs.GetValueOrDefault())) : new double?()).GetValueOrDefault();

The double-typecast for the ints is outside of the bracket, thus typecasting the result of two ints being divided. You'll probably want something like:

int? progressMs = this.parent.Status?.get_ProgressMs();
int? durationMs = this.parent.Status?.get_Item()?.get_DurationMs();
return (progressMs.HasValue & durationMs.HasValue ? new double? ((double)progressMs.GetValueOrDefault() / durationMs.GetValueOrDefault()) : new double?()).GetValueOrDefault();

(btw: this is the code as found in the dll of beta3, it doesn't seem to have been pushed to the repository yet. The code in the repo doesn't have a typecast at all)

[RobertFrydenlund]

The repository is up to date. Beta 3 was built from d85c9fa. The actual code is this:

double? o = parent.Status?.ProgressMs / parent.Status?.Item?.DurationMs;
return o.GetValueOrDefault();

and should probably be

double? o = 1.0 * parent.Status?.ProgressMs / parent.Status?.Item?.DurationMs;
return o.GetValueOrDefault();

[RobertFrydenlund]

The good news is at the bottom. As much fun as this have been I have decided to stop development on this plugin. It has been an uphill battle for quite some time now, and I feel the final nail in the coffin has been set. The LocalApi has been shut down, and I am currently rate-limited from using the WebApi (So it wouldnt be able to handle the amount of traffic we need for real-time info). To be perfectly honest I haven't used Rainmeter actively in a few years, so continuing the development has been 100% for you guys (which I have truly enjoyed 😄).

As i have considered other implementations pretty much every time something has broken, I finally decided to dive into the Chromium Embedded Framework that Spotify is built on. Turns out I'm not the first guy to get that idea, and this is where the good news comes in. There is already a working plugin for this. Worked for me with the Monstercat visualizer out of the box. Download at https://github.com/khanhas/Spicetify.

Thank you for your feedback and help all this time, hope I see you around.

[MZimmermann]

Thx for the great plugin, it really worked well until they shut down the local API. I switched to Spicetify and after some initial speedbumps it seems to be working very stable. And most importantly I don't have to blast some poor web-api every second just to find out the current position in the track. :)

[Bungeetaco]

Thank you for maintaining and building this plugin for such a long amount of time. My desktop is ever grateful! Spicetify seems to work well with the WebNowPlaying extension as of now. Haven't noticed any significant difference, so that's what I'll start using from now on. Appreciate the recommendation!

[RobertFrydenlund]

@MZimmermann @Bungeetaco Thank you for the kind words! I'm glad it seems to be working out, that was the most important thing after all.

[marcopixel]

@RobertFrydenlund Thank you for all your continuous support and work on this plugin 👍 It really changed a lot in the recent years and it was surely one of the most used plugins in the recent years, so you can be proud of that. 😄

I'll hope that all your future projects work out for you and wish you the best 👋

[dasbekir]

Thank you for all your work!

[jduust]

@RobertFrydenlund Yea implementing API's is a never ending nightmare, thank you for your hard work.

Edit: I just forgot to backup first which explains why i couldn't click apply in spicetify

[redsaph]

Thank you for the years of hard work you've poured into this project @RobertFrydenlund! I've always appreciated this and it's bittersweet to see this discontinued but it's really a difficult battle to fight.

I wish you all the best of luck in your future endeavors :)

[T44D]

@RobertFrydenlund . I don't understand about Rainmeter Code, but the latest Beta Release u made is working so well with my Skin. I used Spotify from Microsoft Store and it worked. All I can say is Thank You So Much for u Hard Work.

Sorry for my bad English :(

[tjhrulz]

If there is a demand for it I could make a custom fork of the plugin where you have the ability to define your own secret key so that we do not have to worry about old skins stopping working, either that or I may turn the WebNowPlaying integration into its own standalone plugin that would be the same as this one for backwards compatibility reason.

[takochako]

I'm having the same issue on Spotify version 1.0.85.259.g4ab01679. I'm using Spotify Plugin 2.1.6-Beta 3. When I first start Spotify the song info skin I'm using (monstercat song info) works for a few seconds, then it flickers in and out, and finally just stops working. Looking forward to a fix!

[RobertFrydenlund]

@jduust @redsaph It is quite bittersweet indeed, but I'm sure there is some other project i can get into!

@T44D I'm glad its working for now, but it will stop showing info after a while. I would use the alternative if i was you.

@takochako Scroll up...

@tjhrulz There are some severe issues with this plugin that can't just be solved without an API change from Spotify or sacrificing a lot of functionality. I do strongly recommend using Spicetify and WebNowPlaying. Of course I'm not going to stop anyone from continuing to use this plugin, I just don't see any reason whatsoever why you would want to.

[takochako]

@RobertFrydenlund Oh, I didn't see that. Sucks to hear that the project is getting shut down. Hopefully Spotify decides to not be jerks and reimplements the local API!

[RobertFrydenlund]

@takochako Well if they do, I'll probably come right back. It's hard to just disband a project like this.

[anastasia-v-r]

Thank you so much for your contributions to this community despite the fruits of your labor not going to yourself in the slightest. I'll try your suggestion.

[Merrylittelama]

Hi there @RobertFrydenlund so you recommend Spicetify and WebNowPlaying right? I got them both and it seems that it works, but only with the web spotify. Is there a way to get the info from just the app? Thanks

[RobertFrydenlund]

@Daunzo Some better instructions than I could give over at the SpotifyPlugin thread.

[tjhrulz]

@RobertFrydenlund Yeah I also highly agree with using Spicetify for the time being if your skin supports WebNowPlaying but not all skins do and Khanas' installer is a bit clunky.

That is why I am working on a short term solution of reusing some of the multithreaded caching code from my UsageMonitor plugin to help significantly reduce the number of requests per sec per user and a more long term solution of building the injector for custom scripts into a plugin itself that can be easily installed, then it would be as simple as taking my WebNowPlaying script and plugin and modifying it to use a different port.

Also what about is your daily active users that way I know worst case about how much I need to improve the caching for the stop gap (Because right now the plugin averages 60,000 requests per day per user from my testing with a few skin devs). Also Spotify stupidly does its rate limit per app and not per developer so if you had two registered apps you could have twice the rate limit :P

[RobertFrydenlund]

@tjhrulz

Also Spotify stupidly does its rate limit per app and not per developer so if you had two registered apps you could have twice the rate limit :P

Wait, really? That's actually really silly. Right now it seems to average 2500 users, 13.3 million requests to me/player each day. Seems like it only keeps data for the past month, so I doubt that these numbers are very accurate. Apparently less than 100 requests to me/player/next a day, so not too many users of the latest version.

I'm not sure exactly how you intend to bypass the API limit by caching. If all you need is for the plugin to request results less often, there is a timer for that in the plugin already. You could set it to 10 seconds if that is what you wanted, but the skin would feel really laggy. Implementing a progress meter that gave the result as last result+time passed was on the horizon anyway. You could probably make it update after switching song too, as long as this happens from the plugin (or media buttons on the keyboard). It just seems like a lot of work for an inefficient result at this point.

I have considered making a plugin that implements the webserver from Spicetify and just sets it up without prompting the user, but decided against it, as it would just copy the code off Spicetify anyway. If the goal is to not bother the user with additional setup steps, I think that would be the solution. I would have done it myself if i could wrap my head around it 😄

[tjhrulz]

Ah I had not looked at it since you had refactored for the new update to see that you were not requesting all the data on every skin update but were already using a timer based method. So caching would not have any effect since you already are. I also was thinking about having users be able to generate their own keys and put them in their Rainmeter.data file as another potential way to just keep the plugin working for old skins.