Keep track of song listening history / save timestamps for each song listen

[FriederHannenheim]

I would like to suggest a new feature that I believe could greatly enhance the user experience of mucke. We could add a listening history to keep track of when a track has been listened to last and which tracks haven't been listened to much.

While this change may seem small, it opens up the possibility for a number of new features. For example, with this data we could create widgets for the home screen that show users the songs, albums, and artists they've been listening to the most recently, or the ones they haven't listened to in a while. Additionally, the shuffle algorithm could be modified to give a higher probability to songs that haven't been played in a while, which would improve the fact that some songs are never played/played very rarely because random chance doesn't favor them.

What do you think about this?

[FriederHannenheim]

I just found out that history is already tracked. I'm opening new issues with the other improvements I mentionend

[moritz-weber]

Currently, this is not implemented for every individual song. It is implemented on a coarser level for so-called Playables, which are basically sets of songs, e.g. albums.

My reasoning was, that I didn't want to store every single song playback, but we can give it a try. I certainly like the additional opportunities that we would have with this data.

[FriederHannenheim]

Ahh yes I see that too now. How would the new System be implemented? Here are the options I thought of:

• completely replace the old history repositories with a new one that stores song playbacks (this would mean the last played widget couldn't show albums anymore)
• Have two seperate history repositories, one which tracks all Playables and another one which only tracks songs (too complicated imo)
• Have the current history repository record each song listened on top of Playables listened

I prefer the last solution but maybe you have a better idea. We could then add a playedReason to each history entry which indicates if the Playable has been played manually or if it was played in an Album / Artist shuffle. That way the last played widget could filter for Playables manually played and it would keep it's old functionality.

I hope this made sense, I'm typing this up in the tram on my way to school.

[moritz-weber]

I just realized that still owe you a response here. This is what I think:

• We should track the timestamp of the last playback directly in the song. We have a counter there anyway, so updating one more field should basically come free. This would allow easy sorting.
• Currently, songs and playables have a fundamentally different definition of "playback". For songs, it's after a certain amount of time has been played. For playables, it's when the user selects them for playback. I find this kind of intuitive, but it certainly isn't the only correct way to do it.
• I like the idea of storing the current playable together with a song playback. However, I think this is more in line with your first option. Effectively, this would be a new table and the creation of new entries would be triggered by other events than before.

The new history table would need 4 fields: timestamp, song (path), playable type, playable identifier. The song table would need an additional (nullable) timestamp field.