Normalise album playcount sorting by amount of tracks

[metalheim]

Is your feature request related to a problem? Please describe.

When I query the Subsonic getAlbumList2 by type=frequent, I am supposed to get returned my albums with the most plays.
In reality, I get returned the longest Albums that I ever heard (usually Audiobooks).

An Audiobook i listened to once with 120 tracks will show before a 10-track Album that I listened to 10 times. So IMHO, its biased falsely to long Albums.

Describe the solution you'd like

I'd like the sorting at this endpoint to be normalized/weighted by songCount This way the

• Audiobook with songCount=120 and playcount=121 would get a new "playcount" of 121/120 = 1.01
• Album with songCount=10 and playcount=100 would get a new "playcount" of 100/10 = 10

To be fair, I listened to that audiobook for more, so technically the current implementation is correct. But from a user perspective, I want to find Albums that I actually listened to multiple times (because they were good and I want to find them again).

That is of course a change up for discussion, maybe there is a good reason to prefer the current implementation

[certuna]

Another approach is to multiply plays by song length, i.e. "total time spent listening to album X"

[metalheim]

Another approach is to multiply plays by song length, i.e. "total time spent listening to album X"

Yes, that's also viable. A property called playcount in an album object should reflect "how often has this album been played" better than just the sum of it song plays.
It would help with my issue, since the Audiobooks are usually 1-2h maximum, so my regular Albums that are played often will overtake them in "total time listened to".

It would be a bit of a compromise, because I don't want the annoying audiobooks in there at all.. But maybe this requires another solution (multiple libraries/musicfolders f.e.)

[certuna]

Arguably that would still benefit long albums (a 240-minute 3CD album played 10 times would be higher than a 35-minute album played 68 times), but at least it would show correctly how you have actually spent your time listening.

I do like the concept of configurable "library sections", which would essentially be smart playlists/filters: Release Type is not "audiobook". But we'll have to wait for the smart playlist foundation (i.e., the ability to build queries client-side that are stored/processed server-side) to work on something like that.

[deluan]

This gets complicated if for example I listen to three songs in a row:

1. Queen - A Night At The Opera - Bohemian Rhapsody
2. David Bowie - Low - Sound & Vision
3. Queen - A Night At The Opera - Love of My Life

How many plays should the Queen's album playCount be increased by? In my opinion it should be 2 and not one.

I think this logic should be a bit smarter, by not incrementing an album's playCount if you listen to the album songs in sequence (shuffled or not). Once you interrupt the album and listen to something else, it "resets" this behaviour. Thoughts?

Another approach is to multiply plays by song length, i.e. "total time spent listening to album X"

I like this idea, but should be a different attribute, not playCount as it is not a counter.

[certuna]

How many plays should the Queen's album playCount be increased by? In my opinion it should be 2 and not one.

I think that @metalheim 's suggestion is that the album playCount should increase by 2/12 = 0.167

We would get "half" playcounts (ie playCount in the album table won't be an integer), but intuitively that makes sense - if you listen to half the songs of an album, the play count should be 0.5.

[metalheim]

Yes, that's my suggestion. It's questionable how subsonic clients would handle a non-integer play count though

But even doing this and applying rounding (read: cast to int) would already be better than whatvwe currently have imho

[deluan]

Just to be clear: I also don't like the current behaviour, but I'm not sure if what you are proposing is a good solution.

Picture this: I have the The Cure Disintegration Deluxe Edition, a triple album with rarities and a live show. I love that album and I frequently listen to the first disc (the original content), but rarely listen to the live show or the rarities. With the approach you are proposing I would have to listen to it three times for it to be count as one play.... I personally don't like it.

I think you are trying to store two different informations into one field. My suggestion is to have two separated album fields:

1. playCount: it is increased by one when you listen to a song in the album. It will NOT be incremented if you continue to listen to the same album. This mimics the real life experience where you physically put a LP on the turntable (or CD in the tray) and listen to one song or the full album. For me this is one listening, one play, and should increment the playCount by one.
   It will also alleviate your issue with audiobooks: Every time you listen to an audiobook (in its entirety or not), it will be counted as one play.
2. playLength: This is the total time spent listening to that album, as proposed by @certuna. This gives you a sense of how much you like the album, and spent your time with it.

These metadata will of course be available for Smart Playlists. And having Multiple Music Folders in the (hopefully) near future, or even with smart playlists, you will be able to separate your audiobooks from music, AFAICS the main motivation for you to open this issue.

[metalheim]

Yes, overnight I thought about that same problem, I have a lot of "Deluxe Editions" with CD1 being the normal album and CD2 being instrumentals, which I rarely listen to, causing the same issues as your "rareties".

Your solution 1. for playCount sounds better than mine, although a bit more complex to do (?beyond my capability to access).

And yes, my problem with audiobooks can be solved other ways eventually :)

[certuna]

With playlist and "radio" based listening, 1. will make album statistics pretty meaningless.

Playing one song from an album 10x (because it's in a playlist, smart playlist, last.fm-popularity-based "library radio") will increase the album count by 10, playing ten songs from the album will increase the count by 1. That doesn't seem right.

[rombat]

I'm more in favor of @metalheim initial solution (ratio of played album tracks count/album tracks count).
I've stumbled upon the exact same problem he's mentioning, except the fact that I don't listen to audiobook. But 70 tracks albums played once were considered more played than 10 tracks albums played 5 times, which feels wrong to me.
An album should be seen as a whole, so if there's some tracks you almost never play, well, this ratio is still, imho, the best representative to order "most played albums" (which is my initial purpose).

@deluan solution 1 is interesting, but let's say you create a playlist which randomize an artist albums. There's a probability that some albums will be played more than once, but not in a continuous way. Should you consider it another playCount every time ?

solution 2 is interesting too but I think it will favor long length album over smaller ones, which kind of fail (imho) the purpose of representing a "most played album".
Let's say I have an album A with 4 tracks, 10min each, played 3 times each (thus a total of 120min of playLength.
Let's say i have an album B with 10 tracks, 7 min each, played 2 times each (thus a total of 140min of playLength).
Navidrome would consider album B as most played, even if I think album A should be considered as most played, since it has been played one more time than album B.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Navidrome team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.