RobertFrydenlund
Issues after latest spotify update
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)
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. :(
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)
@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.
@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...
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.
Not to get everyone's hope up, but I'm pretty sure I'll upload a fix later today. No promises tho 🤞
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 you are a legend! Thanks for all the work to help make our desktops look beautiful!
Also experiencing frequent crashes, also the progress bar on the skin I'm using is no longer working
@dninja21 Got any logs or error messages I can look at? Works fine on my end so far.
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
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.
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.
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)
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).
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.
@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)
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();
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.
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. :)
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!
@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.