dpmittal[m]: sorry, i didn't get the time to take a detailed look yet
dpmittal[m]: but a thing that came to my mind was that you should focus on adding support for entities one by one
instead of doing all the db stuff at once and then adding the ui support
this would make it much easier to keep track of work.
Leo_Verto: re your user agent question, LB currently saves everything passed to it in the `additional_info` field of the listen, BUT you should probably open a ticket for this so we can think about adding explicit support for it.
Mineo
Leo_Verto: you can easily get spotify ids via the mpris interface exposed by spotify on dbus (on linux)
I suppose querying this API point every 30 minutes for each user who wants to scrobble from spotify wouldn't be a good idea? :P
also probably a great way to run into rate limits
iliekcomputers
Leo_Verto: alastairp wrote up some code for exactly this during the summit
though I think it never got done
Leo_Verto
huh, I must've missed that
I'm wondering about how to get listens from say the mobile Spotify app into LB
1) Editing the host file is only possible on rooted devices so probably out of the question
iliekcomputers
dpmittal[m]: and more implementation details would be welcome tbh, it is kinda sparse right now. You should add what changes we'll need to make to the db etc.
Leo_Verto
2) The API endpoint is practically designed to be unusable with only the last 50 songs listened to available
iliekcomputers
Leo_Verto: if you're on Android, Simple Last.FM scrobbler should probably work?
not sure
Leo_Verto
hmm, does that use Android intents or something?
dpmittal[m]
iliekcomputers: Thanks :), I will definitely work on this and update soon
iliekcomputers
Leo_Verto: no idea
dpmittal[m]: no prob :)
Vrishank97 has quit
Im_Amartya[m] has quit
Leo_Verto
iliekcomputers: unfortunately SLS does neither submit the spotify id nor the MBID, i remember hearing that those weren't being passed by Android properly :/
I have not yet added debounced query part, here's a rough demo commit.
The debounced query function (which has to be debounced), from what I understand has to be such that _.debounce(function) lies in scope for each call. This means making it a debounced function for the component.
From what I understand, that would mean making the present stateless function to a class, adding the debounced function as member function, some where along the lines `query = debounce((...) => {})`
Then in thunk, we can access it using getState. It will most likely return a promise (assuming we don't pass dispatch to it, doing which I think would be anti-pattern).
If we can use the return part of the function (in this case, a promise) without worrying about debounce thing (like we do normally), then it will simply be a case of dispatching using .then
LordSputnik: But first, I am unable to dispatch two actions simultaneously :/