Kind of a joke, really. Being able to track and revisit your listening history is a pretty basic use case, but an important one to a lot of people who are in this demographic. That this basic function, that so many other apps handle without issue, was reported 6+ years ago and is still broken today is absurd.
You can track and revisit the listening history, the problem seems just that not everyone agrees on how partial track plays shall be counted
I don’t agree with this. Roon’s behavior in this case is clearly a bug. Logically it doesn’t make sense that software errors lead to an increase in the play count (it once happened to me that a track listened to in full only once was counted 14 due to obvious communication errors)
There can be debate about when to consider a track actually listened to. Personally, this must only happen at the natural completion of listening or at an intentional skip by the user. And in case of skip, based on a default percentage (for me it should be at least 90%, but this is just my thought), Roon should update the play count or not
That’s what „not everyone agrees“ means.
I don’t understand. So this behavior wouldn’t be a bug for you?
I think it’s more complicated and have explained what I think further up in the thread. Clearly there are people who strongly think that the current behavior is incorrect and that’s your right. Maybe there is a need for a setting.
Yes, I had read your previous thought and if you mean that part then yes, I agree that we disagree 
But this was the second part of my previous post on when to consider +1 on the play count and if I understand correctly, you might be fine with the fact that a track is considered as +2 if you listen to part today and part tomorrow.
I believe what I am interested in personally is how often I wanted to hear a track, rather than abstract statistics on which bits were played. So if hit play twice on a track, then for me it’s OK that this is counted twice even if I only listen to one half of the track each time.
Maybe there’s a difference between playing a track and playing the album, and it happens to get paused in the middle of a track. When I later continue playing the album, this track probably should only be counted once for me as well.
So to me it seems more complex than it’s made out to be by some. I mean, it’s OK if some people have a clear preference that (the sum of all) partial track plays should always be counted as one play only. That’s their choice and they will have their reasons. I just don’t buy the „it’s very simple and I am right and everyone else it’s clearly wrong“ part.
Anyway, I just commented now in response to the statement that made it seem as if tracking plays and visiting the play history didn’t work at all, because that’s just not the case, whatever one’s preference is.
1 Like
I’m in full agreement with you on this. If I hit play on a track today and listen to it 50%+ and then tomorrow I deliberately hit play on the same track and listen to it 80% through, I do think that should count as 2 plays.
This is the one that I see as a bug and would like to see fixed. I don’t know of any other media player that counts this as 2 or more plays depending on how many times you pause and resume a single play through.
Right, agreed, but then other people wrote that they consider it incorrect that „If I pause and resume a song it often counts as 2+ plays“.
And that’s their right and they will have their reasons, but stuff like this is also why I think it’s not so simple to please everyone
Agreed, you can’t easily please everyone. That’s true everywhere in life. At a minimum, I think having behavior consistent with every other piece of software and that meets the expectations of the majority of users makes the most sense. Keeping it as is because not 100% of people agree on the solution is lazy.
It’s impossible to disagree with this as soon as we define „behavior consistent with every other piece of software and that meets the expectations of the majority of users“ 
While I personally don’t think that’s necessary, it should not take 6+ years to do it. Step 1 - evaluate the behavior of x number of media players. Step 2 - run a user poll. This should be a 1 week effort.
The vast majority of users isn’t on the forum though
I don’t think we should be making excuses for why something isn’t happening. Again, it’s lazy to suggest that not all users being on the forum means nothing can be done.
I believe I recall from another thread that you are involved in tech, not sure exactly what area but I work with Product Managers and Engineering leads every day who are asked to do incredibly hard things by the executive team who are guiding product direction. Just because something is hard doesn’t mean you don’t figure out a way to get it done (at least the best it can be done).
Agreed, but I also don’t think it helps to keep saying „well that’s easy because …“ if thinking about it for a second shows that it’s not all that easy.
Me too, and I also work with customers and users and things are rarely as easy as they claim
With respect, personally I do think figuring out what to do here is simple. I cannot excuse this lack of progress with the “well it’s hard to figure out” perspective. Now, the technical fix may indeed be difficult. I can acknowledge and understand that. I would also have more respect for a response from Roon saying, “We decided not to do anything about this because x, y and z”.
Has this been fixed in the latest update? I’ve been running some tests and it does seem that way. Haven’t tested it with ARC yet. Any other users have tested it?
Looks like I am still getting it in ARC. Though my ARC wasn’t updated in the latest release.