Related songs recommendations improvements on PlexAmp

Hi all, happy Friday!

I searched for similar topics but it seems I’m the one who posts about related songs the most :sweat_smile: Unsure if that’s a good thing or a bad thing, but at least it shows I use it a lot :slight_smile:

Context: I have started to rate songs in Plex a lot more for the last year, to the point where I have some artists where most songs are rated, from 1-5 stars (well, sometimes from 1-10, as I’m using the half-star rating on PlexAmp). What I have started to notice is that the related song recommendations for those artists started to be somewhat suboptimal in this case, but were different when you were playing a song by the artist.

I narrowed it down to the two following queries:

  • Poor recommendations on a rated library: When you are listening to a song from a related artist, the query will ask for songs rated >= 4 out of 10, sorted by last played. For a highly rated artist library, this consistently yields poor choices. My recommendations end up being songs that are 2-3 stars songs that I haven’t listened to the longest. Since I don’t select any of them (well, for clear reasons), these end up being the ones that are always recommended. This is the query that gets the related songs for the current track:
/library/sections/1/all?sort=lastViewedAt&type=10&track.userRating>=4&artist.id=[redacted1],[redacted2],[redacted3],[redacted4]&excludeFields=summary&excludeElements=Mood,Similar,Genre,Style,Country,Media&includeFields=thumbBlurHash
  • Good recommendations, but will repeat recommendations unless they’re in the queue: If you’re listening to a song from the artist, the query is now different, and will ask for artist songs sorted by user rating, in descending order, and trims the list at 10 I believe. This ignores when you last heard the song, but yields good recommendations. When those 10 end, it will recommend songs that I believe relate to the artist’s most popular songs. When you exhaust those, no more artist recommendations will be presented when you’re playing a song from that artist. :slight_smile: Here’s the query for the top user rated:
/library/sections/1/all?artist.id=[Redacted]&type=10&group=guid&sort=userRating:desc&userRating%3E=5&limit=10&excludeFields=summary&excludeElements=Mood,Similar,Genre,Style,Country,Media&includeFields=thumbBlurHash

and here’s the one for the most popular songs:

/library/sections/1/all?artist.id=[Redacted]&type=10&sort=ratingCount:desc&group=guid&limit=10&excludeFields=summary&excludeElements=Mood,Similar,Genre,Style,Country,Media&includeFields=thumbBlurHash

So, now that I’ve been playing a bit with this, I have a couple of questions if I may:

  • Is there an easy way to do combined sorts in these requests? When I add a second sort parameter, the last one overrides the first one. I’d like to try out a few combinations to see if it can improve the related songs - such as sort by top rated and last played, rather than just last played, to see if it improves things.
  • Alternatively - or in addition - could we not just add a window to the “last played”, say, anything that was played over a week ago is fair to recommend again? The SQL query would be easy to create, but we likely can’t do that without knowing the database [NOW] timestamp. But adding a lastViewedAt <= [one week ago/whatever threshold makes sense] could alleviate this.
  • If not, can we increase the ratings threshold for the last played (can be user set if it’s too convoluted). In my case, with a highly curated library for those artists, I should probably only want recommendations of 4 and 5 star songs (or even 5 star songs only, though I can understand that if there aren’t many we’ll always repeat the same so that’s not ideal). Also, unsure how this would affect unrated items being recommended.
  • Last but not least, could we be able to mark a suggestion as “skipped”, and simply not show it anymore in that session - or for a period of time, depending if you’d store that info client-side or server-side? We would need to increase the “limit” from the queries to get more songs, though, so that we get more songs.

Just a few thoughts and feedback in this regard, but would love to hear your thoughts. Also, and again, if we can do combined joins let me know the syntax and I’ll happily play with things.

Above all, keep up the great work. :slight_smile:

Regards, and have a great weekend.

2 Likes

awesome post, and thanks for the ideas and suggestions. i’m traveling at the moment and will reply more fully when i’m back, but just wanted to let you know you can use multiple sorts like: sort=field1,field2 instead of sort=field1&sort=field2

1 Like

Thank you @elan for the prompt and kind reply as always, that did give me a push in the right direction. :slight_smile:

So, for the query that gets the songs sorted by user rating, changing

sort=userRating:desc

to

sort=userRating:desc,lastViewedAt:asc

does alleviate some of the challenges there, but it may still result in other problems once again where you can end up having a static list of recommendations that the user never plays for whatever reason. So I’m not 100% thrilled with this option, but it could be an improvement to the current query - unless I’m forgetting something.

I tried to query for a condition on track.lastViewedAt and we can use the keyword now just like in the database, as it’s parsed correctly. I could not, however, query for track.lastViewedAt<=now-604800 (one week) as it returned an invalid server request. After thinking about this a bit, I’m not thrilled with this - for artists with a small library, you may risk never having suggestions if you ended up listening to those songs within that threshold.

Now, the query that requests all related songs doesn’t have a limit, actually - the

/library/sections/1/all?sort=lastViewedAt&type=10&track.userRating>=4&artist.id=[redacted1],[redacted2],[redacted3],[redacted4]&excludeFields=summary&excludeElements=Mood,Similar,Genre,Style,Country,Media&includeFields=thumbBlurHash

so, if we actually have all that info on the client side, I’m sure we could work some post-processing there to improve the recommendations we show and work through the songs we already recommended during the session X times and not suggest them, or just do some different sorting based on rating and lastViewedAt. For instance, if you get the list of songs sorted by lastViewedAt, you can, say, split the result set in half (or a reasonable size - I wasn’t going to use a fixed size as if the total result set is smaller than that size, you’ll always get the same results), and then sort the oldest half by rating, descending order. That way you’d sort the songs you haven’t heard the longest by your favorite ones.

Alternatively, unless there is a reasonable performance or memory constraint, adjusting the limits of the recommended songs per artist could alleviate some of this, though it’d still not be a full solution.

I don’t really know what’s best, to be honest, and I’m sure there are issues with all of these, but the fact that we already get all the data to PlexAmp suggests that we can do more things in a local cache to improve the recommendations - from storing suggestions that are swiped X times and not showing them again in that session, to even allowing the user to mark something as a bad suggestion for that session or for a small time period (probably skipping is already that “skip”, and we wouldn’t need to make things more complicated in the UI). I’m happy to help with it in any way I can.

Safe travels, and have a great weekend!

you can do relative times with e.g. -1w (one week ago)

1 Like

Nice!

In that case,

/library/sections/1/all?type=10&track.userRating>=4&track.lastViewedAt<=-1w&artist.id=[redacted]&excludeFields=summary&excludeElements=Mood,Similar,Genre,Style,Country,Media&includeFields=thumbBlurHash&sort=userRating:desc

can be an option, with the issue that if this returns zero results that’s kind of messed up. I believe there’s a separate query that gets other related songs when that’s the case - I know we get recommendations for unrated songs and popular songs as well?

Thanks - this is fun!

Have a great weekend.

Hi all and happy Monday.

Following up on this, as I dug into it, I recall suggesting something around album versions a while back which I don’t know if it ever got implemented, but at least the query for “Most popular” songs

/library/sections/1/all?artist.id=[redacted]&type=10&sort=ratingCount:desc&group=guid&limit=10&excludeFields=summary&excludeElements=Mood,Similar,Genre,Style,Country,Media&includeFields=thumbBlurHash

doesn’t consider that, so in fact it can end up only returning 2 or 3 different songs, each with several versions being suggested. Perhaps a good candidate for increased limit (if at all?) and then post-processing, as I’m not sure that there can’t be cases where a popular song is actually a live-only version.

Thanks.

Hi @elan and all. Apologies for the direct tagging, but I remembered this thread earlier today. You did suggest you wanted to follow up on this when you were back from traveling, so I was just pinging this here. :slight_smile:

Hope you’re all doing well!

So sorry, I have not yet had the chance to have a look into this, but it’s on the list!

1 Like

Not a bother, and definitely not urgent - just wanted to ping this in case it had completely fallen of the radar. :slight_smile:

Hope you’re all doing well. Have a great weekend!

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.