Version 8 info vanishing after a while of play of a song

[daameerstone]

Seems it works a bit faster, but it makes snip artwork and snip text blank after a little time of listening (checked in the folder when it goes away in OBS). Usually after 50 seconds of play after a few tests, but not consistent (40-65seconds, sometime faster).

I do have enabled option Empty file if no track playing enabled but it should work if track wasn't playing :)

I've tried to have Cache Spotify Metadata on and off, same behavior.

[dlrudie]

Can you provide some more details?

Does it do it while you are actively listening to a song?

It should only clear those files if you pause/stop a track, or if there’s any kind of hiccup with the network I guess.

The cache metadata option just means it saves the json output it receives, and uses it in the future if you play the song again. I do need to revisit some of that code though.

Does it do it if you listen to Spotify on a different device than where Snip is running?

[daameerstone]

Initially i did just overwrite the folder, and afterwards deleted the folder and extracted new version there. It was played from PC app, tried different combinations and in the end restarted PC... after restart it seems stable, It wasn't private listening mode which i toggled later on (then nothing is shown) :)

Maybe it was a kink on first authorization after update (it prompted same as when it asked for the first time before with notification what is being authorized, not like when it was re-authorizing with message "Snip successfully authorized with Spotify. You may close this window now.").

I will keep testing tomorrow and update/close.

[daameerstone]

Managed to recreate and saw why it was stable... So turning on Cache Spotify Metadata seems to be the culprit. When ON it works as described (works then stop working, then work again on intervals as i wrote). When option is toggled off it works fine.

[dlrudie]

Thanks for narrowing it down! I’ll try to duplicate this and fix it after work.

[dlrudie]

Snip-v8.0.0.zip

Please try this version out and let me know if the problem persists.

[murko69]

Changed to this version and re-enabled caching of metadata!
Testing during the day, but can't check reguarly before evening - so I'll get back :)

Edit: Three songs in to the playlist the info got blank on my website (also after ctrl+F5), but I'm not 100% sure it was Snip. There´'s a chance it was 'GoodSync'. Will check this more closely tonight

Edit 2: After 6 songs I closed Spotify. Snip still shows as if playing song though (2 minutes after) and that option is checked.
I didn't push 'stop' on the song though - I just closed the app down, if that would make a diffrence?!

[daameerstone]

It reacts a little bit slower on song pause/spotify exit but seems more stable and no vanishing info.

I tested it today with only 15 songs since it's late over here.

[murko69]

Yes, much more stable and the issue I had above was caused by another app and not Snip.
Pressing pause/stop in the app works fine. The huge delay in reaction is if I close the app or it crasches/restarts without stopping the music. I can live with that :)

[dlrudie]

Thanks for the information. The only thing I changed was just not loading the cached metadata. It's really completely unneeded now. Before I would get the player status and trackid directly from the Spotify app. This allowed me to check if a cached file existed based on the track ID, and if it did, it would load all of the data from that file rather than requesting it from the Spotify API on every refresh.

With the way Snip works now it doesn't rely on or even check if Spotify is running on your machine. It gets all of that information from the API. When checking if anything is playing it automatically provides all of the track information in the same request so there's zero point to loading any cached data. I basically changed it so with the option on it will still download/store the metadata but it won't load anything from it.

The reason it may show the song as still playing after you close it, or if it crashes, is because I do get that data from the Spotify API. In the event that Spotify crashes it may take a few moments for Spotify's system to determine that your player is no longer alive before it reports that nothing is playing. I imagine if you close the app regularly that the app should tell Spotify that you're closing the app and it's no longer playing, but I don't know how that works on the backend. I guess if it's something you need to rely on it reporting quickly when you need to stop playing then it would be best to pause/stop whatever's playing before exiting.

[murko69]

So... I just checked the history file!
Just showing my last few songs... I don't wanna spam :)
I think this vanishing issue still happens, and this was the first time I checked my history file after the new versions

London Calling - Remastered ― The Clash
London Calling - Remastered ― The Clash
London Calling - Remastered ― The Clash
Lust For Life ― Iggy Pop
Lust For Life ― Iggy Pop
Lust For Life ― Iggy Pop
Lust For Life ― Iggy Pop
Lust For Life ― Iggy Pop
Kick Out The Jams (Original Uncensored Version) ― MC5
Kick Out The Jams (Original Uncensored Version) ― MC5
Kick Out The Jams (Original Uncensored Version) ― MC5
Blitzkrieg Bop - 2016 Remaster ― Ramones
Blitzkrieg Bop - 2016 Remaster ― Ramones
Don't Want to Know If You Are Lonely ― Hüsker Dü
Don't Want to Know If You Are Lonely ― Hüsker Dü

And yes, I did only play them one time each.
Checking Snip each time the text file updates it says 'nothing playing' for a few seconds before it seems to re-check and write to fie again.

I save the history files monthly and September did not look like this, and the begining of october didn't either so if I can guess this all happened around version 8.0.0 started, that's why I put this in the same thread and not a new issue!

[dlrudie]

Hmm. Interesting. I haven't had this happen to me at all.

The duplicates in the text file can likely be attributed to it saying no track is playing. Each time it refreshes (once per second) it checks the track ID of the current refresh against the track ID of the last refresh. If it determines it's different then it will download/update everything. However, if you pause/stop the track then that clears the previous track ID, and when you resume it it will update everything and write everything out again.

In your case it seems like Spotify may report nothing playing and so Snip resets and then writes the data out again once it resumes.

I've got a couple of ideas here I'll mess with later today.

[murko69]

Just to confirm: Yes this is non-stop-playing. No play and pause. I try to make a habit of clicking next song (forward button) after I either paused or stopped a song, just to try and avoid such duplicate rows in the history file
I got songs from a few days ago with as much as 9 duplicate lines when I check the history file

Edit: I also save all album covers and since I also get timestamps on them I can tell the issue started for me on October 10. I believe I installed the new version at that point (released Oct 9)

[dlrudie]

It could be that Snip is being rate-limited by the API and so it will show no track playing. It might not have been obvious before because it was only a small handful of people testing it, but now that it's released it may be triggering a rate limit.

Spotify doesn't specify the actual maximum amount of calls allowed in a time period are but it may be hitting it.

Their chart is somewhat useless because it cuts off text and if I highlight one of the points to the right on the chart the popup text appears cut off and I can't see it. It appears that there may be roughly 6m API calls per day currently. Also at the release of v8 you can see a huge spike in the endpoint calls. It looks like it's hitting upwards of 6m calls per day. Or roughly 70 calls/second.

Once per second for updates may be too high, especially when there are a lot of users of Snip.

I think a rework of the refresh time is in order. The Spotify API does not provide any real-time way of getting play status. There was a feature request thread for it on Github started over five years ago with no progress on Spotify's end. They actually locked the issue and I haven't found any other updates.

I can increase the refresh timer to 2 seconds. This will cut the API calls in half but it will definitely cause track updates to be delayed by up to 2 seconds.

I'm not sure if there's a clean way around this yet.

[murko69]

I think I can live with a 2 second delay. If it's that or the -dupli -multi -lines, I go with the extra second delay! :)

[dlrudie]

Given that it may be getting rate limited I've set up a local session with logging and have it playing in the background. If it gets rate limited at all I'll know for sure. I've added a couple extra steps.

There is pre-existing code for handling rate limiting so it should have triggered that if that were the case.

I was able to recreate the duplicate tracks in the history file though but I haven't been able to yet figure out why. Working on it.

[dlrudie]

Okay that didn't take too long. It's exactly that. It got rate limited and that causes it to add the duplicate entry.

I think I'll push out 8.0.1 shortly.

In testing 2 seconds isn't too bad. The track change isn't guaranteed to fall exactly on two seconds either. Basically it could reflect the change anywhere between 0 seconds and 2 seconds. (i.e. if the update interval is 2 seconds, and the track is changed half way into it, then the update will reflect in only 1 second).

[dlrudie]

I've released v8.0.1. Please try it out.

Keep in mind that the rate limiting is per application. So it's a combination of not just one person requesting an update every 1s. It's every user of Snip requesting an update every 1s. Until everyone updates from v8.0.0 to v8.0.1 rate limiting will likely still be hit for a little while. However, I did change it so that if Snip hits a rate limit that it will just bypass that update so it shouldn't mark it as no track playing, clear the artwork, or have duplicates in the history. This may have unintended side effects but I honestly didn't put a whole lot of thought into it. :)

Also some insight on the rate limiting code. I've had code to handle rate limits already. The default interval was 1s. What it would do if it hit the rate limit is that the Spotify API would return a "retry-after" header with a specified amount of time. When that happens it changes the default interval from 1s to whatever retry time Spotify specified plus 1 second. After a successful update after the retry it would set it back to the default of 1s. When Spotify rate limits Snip it doesn't return any JSON at all, just http headers with the error. With the refactoring of code with v8.0.0 for Spotify I (likely) overlooked what would happen if the JSON was empty. Snip checks if the JSON is empty, and if it is, then it clears everything and resets back to a default state. Then on the next succesful update that's not rate limited it would get the track information all over again causing the duplicate.

[murko69]

I'll try it out directly and will keep an eye out for anything regarding the

This may have unintended side effects but I honestly didn't put a whole lot of thought into it. :)

;)

[dlrudie]

Thanks! :)

Making a note here for myself later:
When pausing a track keep the track ID stored. Then when playing again if the track ID is the same don't add a duplicate entry to the history file. If you pause a track and then play it it will add a duplicate entry.

On a side note relating to this, I may change the way history works completely. The API provides a way to retrieve the track history so I might be able to come up with a more reliable solution. This is low on my radar though.

So far I haven't had any duplicates in the history file from rate limiting (the one duplicate is me pausing/playing).

[daameerstone]

Can confirm that missing info still happens but very rare. Happened as i was streaming and talked about it being solved... Murphy :) Switching to 8.0.1 but will test it tomorrow and on Thursday.

[dlrudie]

Yeah, you'll have to test 8.0.1 since that includes the fixes. Thank you for checking!

[dlrudie]

In my own use 8.0.1 has been much better about displaying the track. I think more people have updated to 8.0.1 so it's no longer being rate-limited as far as I can tell.

[murko69]

Almost no duplicates here. The few I have after installing 8.0.1 is paus/play only so I think this is a non-issue.
Only thing happening a few more times has been that if I play Spotify from my phone and I don't stop the music, but rather just close the app mid song, Snip shows last played song 'for ever'. Last check was +30 minutes before I resumed playing again. It didn't empty the file.

I don't have cache metadata checked anymore if that makes a difference....?!

[dlrudie]

@murko69 Interesting on that one. Would you mind opening a separate issue? I'd like to keep track of that one on its own. Thank you.

@daameerstone Pending your result of testing I believe this issue is ready to be closed.

[murko69]

@murko69 Interesting on that one. Would you mind opening a separate issue? I'd like to keep track of that one on its own. Thank you.

Done #510

[murko69]

Quick comment on the duplicates in the history file again @dlrudie
It's still a pretty big issue here so I wanna ask if there is some way to tell how many of the users are using 8.0.1 comparing to the ones still using a version where this is not addressed?!

If needed, is there any way of creating a note of sorts saying 'there is a new version out'? I think I remember seeing something like that way back

Edit:
My last three songs
Maybeline ― Social Distortion
Maybeline ― Social Distortion
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
Here Come the Drums ― Jaya The Cat
New Girl ― The Suicide Machines
New Girl ― The Suicide Machines
New Girl ― The Suicide Machines
New Girl ― The Suicide Machines
New Girl ― The Suicide Machines
New Girl ― The Suicide Machines
New Girl ― The Suicide Machines

Thursday ~18:10-18:20 CET

I'm guessing that most my issues with this is late afternoon until early morning hours (CET), but I can't be 100% certain since I don't have timestamps. Maybe you have tools to see these spikes