lastfm_extension
lastfm_extension copied to clipboard
asermax
get playcount in the background
Currently, this extension gets a track's playcount only when playing it. I think it would be nice if it'll have an option to "playcount all tracks", which might take some time of course. Then, it'll save the date of the last time it checked with last.fm for playcounts, and get all tracks playcount that the user listened to since the last sync.
This way, the playcount will keep up to date, without the need to play a track to check its playcount sync.
I'll think about it, but you have to take into account the strain to the LastFM API that this feature signifies. You'll be doing tons of requests in a short amount of time; I'm not sure what their policy is about that, but is my API account what's on the line d: Plus, there isn't an easy way to get the playcount of a track after a given date. It would have to be a full sync every time.
If I implement it, it'll be and extra feature alongside the current 'on track reproduction sync'; let me check if this feature would be a problem with LastFM API rules and I'll get back at you.
The whole-library sync should be a one time thing. You can make a delay between each track, or between every X tracks. After you have the whole library synced the first time, the idea is to ask "which tracks were scrobbled since yyyy-mm-dd?" and then - get the playcount for each of those. Or, if you could get a playcount since yyyy-mm-dd, that'll work also.
Bottom line is to get the library synced. Currently, I can scrobble a track 100 times on my smartphone, and its playcount will keep showing "never" on Rhythmbox, until I listen to it using Rhythmbox.
I understand what you mean, but the previous problems stand:
- If many user with a big library do a full sync, that's a lot of requests. The current way do a lot of request too, but they are sporadic.
- There isn't an easy way to get the playcount for a track past a given date. Retrieving and counting all the tracks scrobbled past a date would mean querying a lot of data (depending on the interval between syncs and the user scrobbling rate, of course) and doing the count manually. Even more, how do the algorithm differentiates between scrobbles from Rhythmbox itself?
Anyway, I did some digging and there seems to be no problem with doing a lots of requests, the libary I use automatically separates request by the defined interval in the API policy; so, for starters, I'll implement the full sync feature in the future. The partial sync I don't think it's viable tho, I'll see what I can do.
Ok, I made an initial implementation of the full sync feature. Something to note: it's slow. It depends on your network connection, but the API imposes a limit of 5 request per-second per-ip, so that's a limit I can't bend. If you have a big library (like me) it would take a good while to do the full sync.
As for now, it doesn't support resuming if you close Rhythmbox or cancel the sync (idk if there should be neither), and I haven't came up with a mechanism to implement the 'incremental' sync (syncing from a given date).
As for the 'incremental' sync - which method are you currently using? I see that you can use "from" & to parameters in methods like user.getWeeklyTrackChart & user.getRecentTracks. Isn't that enough?
Saving locally the last date used in an API call should allow closing Rhythmbox or stopping the sync. No?
Currently there's no incremental update, i didn't get around that.
For what I can read in the documentation, none of those give back a differential playcount. You could use those to limit the tracks to update tho. And for a full playcount, there isn't any order in which the playcount are retrieved, so saving the date wouldn't change much.
Anyway, I'm not using rhythmbox anymore, so I'm not updating any of the plugins I developed for now. Feel free to work on it and send a pull request!