Snip is updating files in middle of songs so if its in some source it makes them dissapear for few seconds #518
Comments
|
Yep, I'm having this issue too... |
Yeah its so annoying, its maybe on spotify side. |
|
Same here!!! I've reinstalled Snip and nothing... Let's give time to time! |
|
Hey Sk0ky, it looks like now it's working normal again! =D |
Damn.. mine is still broken |
Mine is still broken as well. Neither reinstalling Spotify nor Snip fixed the problem. |
|
Same issue here, been broken for a few days. I've noticed sometimes tabbing in/out of games/applications makes the text disappear for minutes at a time before it randomly comes back. |
|
I am having the same issue. It appears. disappears constantly. I tried reinstalling Snip to no avail. |
Yeah... reinstalling and trying older versions doesn't work. |
|
Seems like its on Spotify side and the polling rate update didn't help |
|
This is likely related to Snip being API rate limited by Spotify. I thought I had put in measures that if it hits the rate limit it won't interrupt what's currently showing unless it actually changes when it gets a successful return. I have a couple ideas to help mitigate this further. I think I'll bump the API poll from 2s up to 10s. At each poll I'll check the time remaining in the playing track. If there's only 3 seconds left then I'll make it poll again in 3s to get the track change info and then it will go back to 10s. This will lead to another problem. If you skip tracks repeatedly, or move to the next song before the next poll, there can be up to a 10s delay before it reflects that change. I could likely add something to the Snip hotkey for changing tracks that will force a poll on track change, but if you change it via media keys on your keyboard or within Spotify itself then it won't poll sooner. The API itself is severely limiting to developers in this regard. There is nothing in the Spotify API that can be used to notify Snip when a track is changed. If there were that capability then Snip wouldn't need to poll at all. |
|
I've implemented what I mentioned. It works but I just don't like the solution. Set the initial track poll to 1s so on first launch it will get the track information quickly. This is only useful if you already have Spotify playing something when you start Snip. Otherwise it defaults to the 10s timer and the next poll will be 10s from launch of Snip. On each 10s update I get the track duration and the track progress. I subtract the track progress from the duration. If there is <= 9s left I update the next poll interval to be whatever time was left + 1s (to allow time for the track itself to change). As you listen to a song and it gets close to the end, with the next 10s poll it might show only 3s left in the track, in which case it automatically updates the interval to 4s. This allows for natural track changes to update right away on song change. I also added it to each hotkey that when you pause/play/next/prev a track it sets the poll to 1s so it updates quickly after manipulating tracks with hotkeys. The big downside is that if you pause a track, or you quit Spotify, or if you change a track manually, it can take up to 10s for the change to reflect. This substantially cuts back on the API calls and will help mitigate rate limiting, but that delay is just a bit much. I've dropped it to 5s for now, which is still a huge increase over 2s, and it feels a little more responsive, but man is the Spotify API lacking. I will test more and see about pushing a release this weekend possibly. I want to do a few other things before pushing a release. |
|
5s may be doable. It doesn't feel too long. During my testing I was able to confirm rate limiting was happening for sure as the timer would sometimes go as high as 21s (whenever Snip hits a rate limit it sets the next update for the time for next attempt from the rate limit error itself, so it's always variable). With a push this weekend for a new release and everyone being on a 5s interval it should alleviate rate limiting for the most part. It's not an ideal solution but it should allow it to work better while I look into more ways to mitigate this. |
Gotta ask since I'm no tech-wiz :) |
|
I'm sorry, @murko69. I didn't even see your update on Dec 4. The duplicates are going to be related to this for sure. I thought I had put something in place to mitigate that but it didn't work obviously. I'll be taking another look at that and double-checking it before the next release. When I do release the next version of Snip I may acquire a new key for it so that statistics start over fresh and the rate limits don't clash with older versions. This will be more stable and allow it to operate more smoothly until everyone switches over, which I'm hoping when they do that the changes I've made will help mitigate it. I'll make sure to make note that the old one is deprecated and I may retire that key after so many months to allow people to switch over. |
|
This is taking slightly longer than anticipated as I'm re-doing the authentication code too. |
|
We can wait ;) but I appreciate the heads-up |
It randomly creates a new artwork file and snip.txt so if it's in OBS it makes it go away for a few seconds.
There is a video to see what happens. It happened in the middle of the songs and I was watching the files and the date and time of the last changes when it happened so
2023-01-13.19-21-47.mov
The text was updated successfully, but these errors were encountered: