Play count not updating as expected

Will this ever be fixed? I mean it’s nitpicking but at the same odd that a known bug has persisted since 2016. This also messes scrobbling. If I pause and resume a song it often counts as 2 plays / double scrobbling.


This caught my attention today because it also happens in Roon ARC.

Hi @Bruno_Mello ,

I split your post off since the thread was very old and outdated.

When it happens in Roon, where do you see the multiple plays, in the History browser? Does the issue only impact ARC or both Roon and ARC?

Does the issue happen only with a particular kind of content - TIDAL / Qobuz / Local? Are you able to share any screenshots of how the issue looks on your end? Thanks!

@noris I’m also experiencing this in both Roon and ARC w/ Qobuz and local file playback. My play counts are increasing whenever I pause and resume playback and I’m also getting duplicate scrobbles. I posted about this a week or so ago here.

Edit: While I am loving the updates (especially ARC) this issue rather annoying.
Edit 2: Btw, last week I provided my thoughts on ARC (here) and how it brought me back to Roon after a year or so away. Really hoping this duplicate play count/scrobble issue can be addressed.

  1. play count, in Roon, increases when you pause then resume playback of a track (any track!)
  2. for those who have linked their account to Roon this also reflects in’s playback history as the same track being played twice (… or more)

can’t believe support still didn’t get it years later! :roll_eyes:

1 Like

Perfect summary. @noris it seems this issue has been going on for a long time and impacting many of us. What can we do to get some traction on it?

thank you @pl_svn for putting it as clear as I ever could. This has happened for a long time indeed, but I am finding it even more annoying now using ARC a lot (something that despite this I am loving).

I have been noticing this too. I’m pretty OCD about my play counts and when I have to leave the room I pause the music but that is skewing my counts.

Hi All,

Thanks for the additional information. I have been attempting to reproduce this issue on my end but have yet to succeed. Are there any details that may help us reproduce this behavior? Which screen in Roon do you notice the play count increase on?

I tried to pause/unpause both TIDAL and Qobuz tracks that were in and out of my library without success in reproducing.

If you temporarily disable/log out of Last.FM do you still notice the issue occurring?

… in which Roon’s screen does play count show?

Along the lines of view in my tracks, album details, playlist plays, etc. Where do you notice this increase?

in Album view: that’s what I use!

My play count shows elevated plays on the tracks page.

Hi everyone,

The crucial missing component here is whether or not you see duplicate plays reflected in the Play History.

If you pause a track and notice a duplication in the Track Count from any Track, Album, or Playlist page, do you also see that track listed twice in your play history when you click on the Queue and scroll up?

Sometimes these tracks may be nested under “X skipped items,” so be sure to unfold that menu.

I understand some of you are quite frustrated and have waited some time for a resolution here. We’re working with QA to reproduce, and we’re investigating the scrobbling in ARC as a separate, but potentially related issue. The tech support team will provide an update as soon as we have one, but any clarify you can provide around the above question will be immensely helpful in supporting our efforts.

1 Like

Hi Connor,

Looks like I prematurely reported this being resolved in my other thread on this issue here. The good news is, I think I’ve been able to narrow down a specific sequence of event that causes it reliably.

In this screenshot, you’ll notice two tracks that have a play count of 2. I didn’t listen to these tracks twice. However, I did pause them at somewhere around 50% to 70% progress for an extended period of time. In the case of “Nothing at All”, I paused playback for roughly 2-3 hours. When I resumed listening after that 2-3 hour period I noticed two things. First, the playback progress was right where I left it. Also, the play counter had incremented to 1 even though it was at 0 when I paused playback. After resuming playback and completing the track, the play count incremented to 2. Again, despite the pause I only played the track from start to finish one time.

I found something else very interesting when I went to check my play history. I wanted to check if there were duplicate plays listed there per your request, @connor. What I found is that the two tracks with duplicate play counts were only listed once BUT they were showing completion percentages equal only to the track duration after the pause. Despite the pause, these tracks were played through to 100%. See screenshot below.

One other thing that I’ll note, although I’m not sure if it is relevant, is that my Mac (where I did this testing) went to sleep during the extended playback pauses. My Roon core is on an Ubuntu Server elsewhere on the network. Again, I don’t know if this is an important detail but there would have been an interruption between the Roon app on my Mac and the Roon core during this time. Anyway, hope this helps the team make some progress! Please keep us posted.


1 Like

Here’s another example. This afternoon I was listening w/ my Astell & Kern SP3000 DAP via Roon Ready and paused playback about 15% into the first track of the Earthling album by Eddie Vedder. I powered off the DAP and turned it back on about 4 hours later to continue listening. Sure enough, the track that I was only 15% into showed a play count of 1 and upon completion (after unpausing) it incremented to 2. Just as before, the track’s completion percentage displayed in play history is equal to the remaining portion after unpausing. This behavior seems to be pretty consistent from what I can tell.

1 Like

Hey guys, we’ve discussed this and have some ideas about how to address it, but the fix is not simple. We do plan to fix this.


Thanks, @brian. Does this mean you’ve found the cause and can reproduce the issue?

1 Like

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