Bug in play queue while setting stars/fav on tracks via context menu

Issue description:

First, I don’t think this is a subsonic issue (I’m using navidrome).

While you are playing a queued list of songs, sometimes I like to start/favorite a previous played song. What I do:

  1. Open the queue list
  2. Long press the prev song (or any other).
  3. Select “More Actions” [1]
  4. Then select “Add to favorites” [1] or “Change stars” [1].
  5. After the action, the app goes back to the queue.

Then there is a the following bug:

The new values are not reflected immediately in the queue list (if you do on the current playing track it works, but not for others), so I think it is missing a refresh after the update. As a programmer myself, I think is just a matter of refreshing the UI. I’m not sure if this will result into a roundtrip to the server, most probably the update is already cached in sqlite/memory so I think this is a cheap operation.

[1] I don’t know the official English translations for these as I use the app in Spanish, but you get the idea.

Logs:

Upload description: kraptor

Additional information:

 

 

Reproduction steps:

 
I can provide a quick video I recorded from the screen, should you need it (40MB, let me know where to upload).
 

Media provider:

Subsonic

Screenshots:

     

This is mostly expected, the queue is not really tied to full media and so not updated on changes, they are resolved at play time.
This is what allows to have queues of 200 000 songs and everything still works smoothly.

I understand that, but when updating the current song in the mediaplayer, the queue is updated instantly with stars in the queue list, so I’m not sure this is not possible at all or I’m not understanding.

In any case, this is just a minor annoyance that I’d like to report.

Thank you for the great work you are doing on the player.

If the song play then it was obviously resolved :wink:

If you have the same song queued again later it won’t be updated.

If you have a 200 000 song queue that you need to resolve and update on any media item property change I let you imagine the CPU and so battery for that.

Uhm… so it should work for a song that just played? I’m just trying to understand.

Ok, I’m not sure we are on the same page. I’m not expecting that an event is sent from the server to the player so the player has to listen for 200k songs events whatever. What I mean is, if I have the following queue:

* A → B → C → D (bold represents the current playing song).

Then if during it’s being played, I set the stars in the very same player (I have stars enabled for current playing song) then in the list itself it’s updated (it shows the current stars that I set). If I do the same for prev songs (in this example B, which was just played, not skipped) then the song was already resolved as per your words, but it’s not updated. I understand as per what you say, that this could happen to D, but not to B.

The thing is, I was somehow expecting some kind of UID/FQDN for each song, and when updating via the app any item, them all items in all views that are currently being shown would update (as it does for currently being played song). I have no idea how this is currently set up in the app/sources and how views are updated from the datamodel or how different parts of the app handle events between views, obviously.

In any case, not a big issue, just a minor annoyance.

Again, let me emphatize the great work you are doing on the application, it’s a hidden gem that I keep recommending everyone.

Just understand that they are different items, you update tracks but play playlist entries.