Support for local scrobbling (elaborated play count, skip count, last played)

[decarbonization]

We should add SongPlay and SongSkip models which track activity around song playback. A song will be considered played if:

• The song is 30 seconds or less and it has been played through to completion.
• The song is over 30 seconds and at least half of it has been played before being skipped.

A song will be considered skipped if:

• The song is 30 seconds or less and playback is interrupted after the 2 seconds.
• The song is more than 30 seconds and playback is interrupted before half of the song has been played.

These will be best effort criteria. Seeking within a song will not affect either rule.

As far as last played goes, any time a song is loaded up and played, the last played should be updated to 'now.'

[decarbonization]

This data could be used for in-app listening habit breakdowns but really is mostly for plugins (#14) which upload to services like last.fm or listenbrainz.

[jkantro]

For song skip duration, are we being opinionated or flexible to supporting user set durations for when to scrobble?

Additionally other meta data that scrobble services seem to use are favorite/loved. I'm not quite sure of the value to supporting it let alone how that would be store in our local library file.

[decarbonization]

We could make the threshold duration a setting, we'd probably just want to include that in the records so that plugins can choose to omit data that doesn't fit their requirements. We could add love/dislike flags to songs for consumption by plugins. I don't think there's much the app could do with that data besides smart playlist population

[jkantro]

This did get me thinking about auto queue/auto playlist generation if we ever decide to build a default plugin or built in functionality using an llm. Just food for thought to capture here. Aside from play count, skip count, favorite, bpm, duration, last listen, genre, etc.

[decarbonization]

Now that we have more fully feature playback infrastructure, I think that we could actually accurately track playback time. We'll need a separate object which tracks all of the play/pause/seek events which occur while an item is played, and then aggregate those into a total played time. This can then be used by API extensions to decide whether to report a play.