The problem is now what happens if 30 seconds into the song I started playing at 12:00:01 I pause the track for exactly 10 minutes while I'm on a phone call, then I unpause and continue listening to the whole thing. Still, that'd probably be somewhat easy to try and filter out most duplicates. At some point relatively early on I started adding 60seconds to the timestamps I received from last.fm so that they would hopefully be very close, but if you pull up the properties page of a song you'll see that very often last.fm last played will be 12:01:01 and foobar's will be 12:01:02. At the 2 minute mark (50% through) your song is scrobbled to last.fm with a timestamp of when the song STARTED playing. After 60 seconds, foobar records a play time stamp at 12:01:01.342 (it's down to the microsecond at least). Let's say you start playing a 4 minute long song at 12:00:01. The reason the lists are different and can contain duplicates is because it's impossible to be 100% accurate with them. %lastfm_played_times_js% ONLY includes scrobbles from last.fm, and doesn't know or care where those scrobbles came from and some or all of them could have been from foobar.įoo_enhanced_playcount originally didn't retrieve scrobbles, and it was added a little later on. It doesn't know or care about last.fm scrobbles, although some or all of these plays could have also been scrobbled. %played_times_js% ONLY includes plays from foobar. In any case, what's the reasoning of having duplicate data at all? Why are they not being filtered using the SDK? Or why not exposing a global variable having all without duplicates? Quote from: regor on 09:04:36 A) %played_times_js% contains both, foobar (1) and lastfm statistics (2+3), and %lastfm_played_times_js% contains only lastfm statistics but with some temp offset (2+3).ī) %played_times_js% contains both, foobar (1) and lastfm scrobbles (3), done within foobar and %lastfm_played_times_js% contains lastfm statistics (2+3) (with some temp offset).
0 Comments
Leave a Reply. |