artemgordinskiy / Spotifree

An OS X app that automatically mutes ads on Spotify [DISCONTINUED]
http://spotifree.gordinskiy.com
MIT License
1.05k stars 70 forks source link

Adjustable polling setting #64

Open TASSDevon opened 8 years ago

TASSDevon commented 8 years ago

Not so much a bug but a feature suggestion. I notice Spotifree takes up about .6 to 1.4% CPU on my 2010 macbook pro. I'd be fine with hearing the start of an ad if it reduces the polling to let's say 1s or so.

Maybe add an option to set the polling in ms.

enellis commented 8 years ago

You can now set your own polling rate. You just have to set SFPollingRate in the User Defaults. For example in Terminal you would type: defaults write de.eneas.Spotifree SFPollingRate -float 0.6

artemgordinskiy commented 8 years ago

@simonbromberg We need the polling to know when an ad comes on. Spotify won't tell us that, unfortunately.

jb510 commented 8 years ago

@ArtemGordinsky Could you get the track duration and then pause polling for the remainder of time the track is supposed to play (remaining - 2s)?

Like others, I'd be totally fine hearing the occasional ad (ex. if mid-way through a song I skipped to the end and Spotifree polling was still paused for another minute) or hearing the first second of an ad if it meant better battery life / less power consumption.

artemgordinskiy commented 8 years ago

@jb510 I'm afraid this approach would break the moment you skip a song or put Spotify on pause. Then Spotifree would miss much more than an occasional ad. Regarding the battery life concerns — how much does Spotifree affect yours? I don't think it should cause any major battery drain.

jb510 commented 8 years ago

Artem - I'm not really sure what the energy impact is (haven't closely monitored it yet). I do see CPU cycles at about 3% which is the same as Spotify. It seems crazy that spotifree needs the same CPU cycles are Spotify, but I could be misinterpreting something.

As for breakage, I'm not suggesting you pause polling until the very last second. Just that if upon polling a song had 3 minutes remaining, you could pausing polling for 30 seconds. If the time remaining was less that 60 seconds then switch to .3 seconds to detect the end of the song. If someone manually skipped ahead a commercial might play, or might not. If not then when the poll occurred again you'd pickup the new song and new time remaining.

Maybe it's just way to complicated and wouldn't make a big difference in energy use. I don't know it was just an idea based on what seems like comparatively high CPU use.

scribabble commented 8 years ago

Is this enhancement/feature actually implemented in the current release? I've changed the SFPollingRate to many different values (and read them back), and the functionality of Spotifree doesn't seem to change. I would expect that a 5 second polling rate would at some point play a few seconds of the ad, yet the ad still gets muted immediately when the ad starts. It seems like regardless of the SFPollingRate, Spotifree still polls at its 0.3 second default.

jb510 commented 8 years ago

I wanted to wait until I had more than anecdotal data, but I don't see Spotifree using excessive power. It looks like it would based on CPU usage (but that's never very accurate). It's about 1/10th the energy use of Spotify.

simonmeusel commented 6 years ago

What about file access? Spotify takes note when a track is over, gets skipped or whatever...

Try: (https://apple.stackexchange.com/questions/14409/how-to-monitor-file-access-for-an-os-x-application/)

$ sudo opensnoop -n Spotify

Which produces something like (after skip):

  501   8289 Spotify       69 /Users/simonmeusel/Library/Application Support/Spotify/Users/simonmeusel-user/ad-state-storage.bnk.tmp
  501   8289 Spotify       69 /Users/simonmeusel/Library/Application Support/Spotify/Users/simonmeusel-user/log-tracked.tmp
  501   8289 Spotify       69 /Users/simonmeusel/Library/Application Support/Spotify/Users/simonmeusel-user/log-tracked.tmp
  501   8289 Spotify       69 /Users/simonmeusel/Library/Caches/com.spotify.client/Data/b4/******************.file
  501   8289 Spotify       99 /Users/simonmeusel/Library/Application Support/Spotify/Users/simonmeusel-user/recently_played.bnk.tmp
  501   8289 Spotify       99 /Users/simonmeusel/Library/Application Support/Spotify/Users/simonmeusel-user/recently_played.bnk.tmp
  501   8289 Spotify       99 /Users/simonmeusel/Library/Application Support/Spotify/Users/simonmeusel-user/pending-messages.tmp
  501   8289 Spotify       99 /Users/simonmeusel/Library/Application Support/Spotify/Users/simonmeusel-user/pending-messages_seq_nr.tmp
  501   8289 Spotify      116 /dev/urandom
  501   8289 Spotify      116 /Users/simonmeusel/Library/Caches/com.spotify.client/Data/30/******************.file
  501   8289 Spotify      116 /Users/simonmeusel/Library/Application Support/Spotify/Users/simonmeusel-user/pending-messages.tmp
  501   8289 Spotify      116 /Users/simonmeusel/Library/Application Support/Spotify/Users/simonmeusel-user/pending-messages.tmp

We could just watch a file, for example /Users/simonmeusel/Library/Application Support/Spotify/Users/$SPOTIFY_USERNAME-user/recently_played.bnk.tmp

If the username is not known, just look into /Users/simonmeusel/Library/Application Support/Spotify/Users/

simonmeusel commented 6 years ago

On how to watch a file: https://duckduckgo.com/?q=fsevents+swift

https://github.com/Eonil/FileSystemEvents

simonmeusel commented 6 years ago

Since this projects seems to be unmaintained, I have implemented this: https://github.com/simonmeusel/MuteSpotifyAds

artemgordinskiy commented 6 years ago

@simonmeusel That's pretty cool! What's the CPU usage with your approach?

simonmeusel commented 6 years ago

It's in the README.md:

Using those techniques, it uses only 0.4% CPU when the track changes (rate: 5 seconds), and 0% in idle. It has a energy impact of less than one tenth of spotify when the track changes, and a energy impact of 0.0 - 0.1 in idle.

Those measurements might not be the most accurate one's. They are just what i saw on my machine, when looking at the Activity Monitor.

Since the application doesn't do anything in idle, it makes sense that it uses 0%. But there could be some CPU usage, because MacOS has to manage the process etc.