Snip
Snip copied to clipboard
dlrudie
autostart and authorization questions
First of all, let me just say WELCOME BACK David. I have Snip back up and running again after over a year of despair. You and it have been really missed.
*Autostart (still an issue) - hasn't been working since prior to v 6,9,0 for me - It would be great if an option for this would be possible to add (by checking it along with the other options).
*The authorization window (browser) appears every time I start the app. First time with the actual authorization, the rest with a small "thank you note". I would prefer just a small sign in the menu if possible (see file)?
Thanks!
What do you mean by autostart?
As for the browser window it has to do with authorization process of Spotify being done over the web. I don't like it any more than anyone else will. I haven't had time to look into other ways of it. I might be able to open the browser via a form and then I can close that form when complete. It's something I'm going to research.
@dlrudie Are you using "my" implementation from the PR (#303)? If yes we might have to do a little more because we have to control the internal webserver.
Auto Start - as letting the app start on Windows startup. It used to work by adding it to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp or similar, but that was prior to 6.9.0. or 6.9.1 when it last worked for me.
See #317 for more info
No I did not. After finally having some time to sit down and go over Spotify's web API I just decided to write my own implementation. I really only wrote in the functionality needed.
Ah okay sounds equal to my implementation which results in the same behavior.
@murko69 Oh, I haven't tested that. I don't see why it wouldn't work. I'll look into that.
@MeikelLP It has to do with the actual authorization webpage that Spotify uses. It forces a browser redirect afterwards. I just haven't sat down to research ways to stop that or closing windows afterwards and whatnot. If you open a new browser window programmatically you should be able to close programmatically. The problem is with Process.Start(). It uses the default operation of your default browser. In my case it's Google Chrome and it opens a new tab automatically in a pre-existing window which means you can't close it afterwards. One might get around it by forcing use of a browser with arguments to open a new window instead of a tab. Or possibly with an integrated browser in a form that you can simply close when done. JavaScript doesn't seem to allow it to close either automatically.
I think I overlooked something. There's a lot of endpoint requests. So many that in the last 24 hours there have been 4.3 million requests.
I just checked out Snip and set up the Spotify keys. I came to the point where I received a 400 response from the Spotify API (called via UpdateSpotifyTrackInformation_Elapsed). This is called very frequently...
Sadly there is nothing like event-based API callbacks: https://github.com/spotify/web-api/issues/492
It should only call it once per second. I monitored it locally and it only did call once per second for me. That means if someone listens to an hour straight of music there should be 3600 calls. I bumped it to 3 seconds locally to see how it would perform and other than a slight delay in catching song changes (because 3 second overlap) it cut back on the calls quite a bit.
Maybe many people just tried out your app. Can you see how many different "sources" are calling your Spotify API?
I can see that as of this morning there were 285 users. And a little under 8 million API calls. The user count refreshes once per day and usually I won't see any new number until the following morning. The API calls updates about 2-4 times a day?
Previously no user had to log in so it only ever showed 1 user. At least now I can see how many people are using it and a breakdown on which countries people use it.
Should there be so many API calls? Just double checking that I'm not the bad guy here in getting that many API calls?
I use five files for my output with some Ajax and PHP using fopen/fread. Checking Snip_Track.txt (if that's empty I just stop there and show an offline sign), Snip_Artist.txt, Snip_Album.txt, Snip_TrackId.txt and finally the Snip.txt Then showing them in order track name, artist name, album name, spotify link and finally a search algorithm for lyrics via Musixmatch.com.
But I guess (hope) the API calls is only determined by start/stop/skip etc on Spotify. eg. what makes Snip change behavior?!
Edit: Typo
Nah. It's nothing you're doing specifically. 1 per second may just be too much with a lot of users.
I have an update I’ll be putting out this evening possibly. Will change API calls to every three seconds instead of every second. I also implemented a catch for if/when Snip hits a rate limit.
I’m also working on having it authorize in a different manner so browser windows are only opened when initial authorization is required. I just don’t know if I’m going to include that with the update I’ll put out today, or if I’ll push it to a later release.
Sounds good - Had a chance to look into the "run Snip at Windows startup" yet?
Just thinking. I could do a mixture of things to cut back on API calls.
One thought was that when you pull the track info it shows the length of the song and your current playing position. I could start a timer and have it count until the length of the song and only refresh then. The downside to this is if someone pauses a song or changes songs. Snip is not going to know that and the next update wouldn’t be until the timer expires.
The other method would be a hybrid of API calls and local checking. I could still monitor then window title for changes. If the window title changes then do a call. The upside would be that I’m not actually retrieving track information from the title so the code would be smaller.
Personally I think the timer would not suite my persona at all. I skip songs frequently, thus making the output 'out of date' for a long period. Depending on the length of songs it might even miss songs completely. The second choice sounds better to my 'non-programming' ears
@murko69 Are you on Windows 10? Apparently the way startup folders work changed with Windows 10. I may add a toggle checkbox in the right-click menu to let the user enable/disable launch on startup. It's just a registry key so it's nothing major.