I have the same issue again. With B1643, it fixed itself after some restarts, which is why I marked the old thread as solved, but now I have it again with B1644, and so far it has not changed back (I restarted ROCK and client twice)
It’s back to normal again, but it’s a bit weird.
Hi, @Suedkiez, thank you for your report. Could you please confirm if I am correct that the following happens:
- After update several items lose their position in the Albums browser when sorted by “most played”
- Reboot of the RoonServer resolves this and things go back to normal
My questions are:
- Does it happen across all of your remotes?
- Are there any commonalities between albums affected by this? For example, multiple version present in the library, etc
Thanks!
—
Ivan
At least one, but maybe it was only one that I noticed because it is the most played one, hence normally at the top of the list, and it has lots of plays in each of two different grouped versions - I don’t have such a situation in many albums, usually the significant number of plays is just in one version.
The first time in B1643, it fixed itself after several server reboots (and client restarts, I don’t know which one was relelvant), but not after the first one. The second time in B1644, several reboots/restarts didn’t seem to change anything, which was why I posted the issue again, but then it seemed to had fixed itself when I looked again on the next day or so.
Yes, it was the same on all remotes.
The one I noticed has 3 grouped versions. Two of them are local and each has many plays, the third one is from Qobuz but has zero plays. Hence I don’t think that it’s related to the current Qobuz CDN issues (plus, I am in Germany and have not experienced this issue at all).
This is the (local) primary version:
and its track plays (there are 21 tracks and the play count is between 30 and 14 or so)
This is the other local version:
And its 20 tracks, with counts between 28 and 16:
And the 3rd version from Qobuz, also in the library but 0 plays:
So across the 2 local versions there are between 58 and 30 plays per track, or something like this, and combined this is normally my top album in sorting by play count (I have “Show hidden tracks and album” = No, i.e., version grouping enabled.)
In the instances when sorting was weird, this album was sorted further down, around other albums where the play count is approx. 25, i.e. it seems as if during this time only the play count of one of the (local) versions may have been counted.
@ivan This had been OK-ish for a while as described above: i.e., after a restart, the Purge & Slouch album, which is my most played, was initially sorted a bit further down in Most Played order, but it fixed itself after a while and sorted itself back to the top.
However, in the last two or three builds, it does not fix itself anymore and the album stays further down in the sort order. It seems as if it uses the play count from only one of the versions.
I think this new behavior may have started with B1674, was definitely the case with B1675, and it’s still the same now with the new B1676. Same on all remotes: Mac, iPad, iPhone.
As a reminder, this album has its plays quite evenly distributed across two versions (with track play counts from ~30 to ~15, in each of the two versions), but taken both versions together it has the most plays. (I have Show Hidden Tracks And Albums set to No). I don’t have this situation of lots of plays being spread across two versions in other albums, so my guess is that this is the reason why only this album in my library is affected.
Hi, @Suedkiez, thank you for the post. I created a ticket for the QA team to take a closer look at this problem. Let’s see what they find out.
Thanks!
–
Ivan
Well, today the album is back at the top, but it’s weird that this took so long