One album won't scrub

This is a bit weird. Was playing an album this morning that’s been saved as 48kHz, ~192kbps MP3s. I noticed that when I tried to scrub forwards on a track by clicking at various positions along the track bar at the bottom of the screen it’s didn’t jump to the corresponding position within the track. Instead it would start playing the track from the beginning even though the red position marker was somewhere else. Then when the track position marker got to the end of the track, the track would just keep playing and the marker would then just animate across the track duration text and off to the right until it disappeared off the UI.

At first I thought this was a UI/playback glitch so I restarted the roon client. That didn’t fix it. So I restarted the roon server on the NAS. Still didn’t fix it. Then I tried some other albums and they played just fine.

Came back to the original album and again it would not scrub. So it’s something about the MP3’s in this album that are causing roon to missbehave. Symptoms:

  • Clicking on the track starts playing from the start of the track instead of the clicking position within the track.
  • Red track marker keeps animating across the duration text and off the right side of the display until the track actually ends playing. How far depending on where in the track is clicked.
  • Only occurs on this one album of 48kHz, ~192kbps MP3s. If there are others I have not found them yet.
  • Restarting roon client (Mac) and server (Synology NAS) has no effect.

Interesting. I have a question. Have you tried this with different remote clients? Also, could you list the remotes you have tried, e.g. iOS or Windows.

My guess is that there’s something off with the frame info in files themselves. You could try something like this: to validate them.

This was occurring on the Mac client. I’ll take a look at the frames you suggested. Thanks.

I couldn’t get checkmate to compile on my Mac but I found some other mp3 checkers and they didn’t find anything wrong with the files. I also downloaded the iOS client and it exhibited the same behaviour. ie. would starting playing from the beginning of the track no matter where you scrubbed to and would keep playing the track even after the progress bar had reached the end. For example the display was saying the track was 8:23 long at the current progress was showing 9:15 and still playing.

So I’m stumped as to why this album won’t behave.

Does it play and scrub with VLC or fission?

Can you encode it to another format with dbpoweramp or xld and see if it still has the same behavior?

The files play fine in VLC, I then did a quick convert of one of the tracks to WAV and loaded back into Roon and it worked fine. So everything I can see indicates there’s something about the encoding that Roon isn’t correctly handling, but the checker I ran says the files are ok. As does VLC.


I think there is an obscure issue with the files that checker isn’t looking for. Can you re-download or re-rip the files again? It is possible that something went wrong when the original files were encoded.

What is the affected album, I’ll try it here if I can.

Quite likely :slight_smile: I’ve had the files for some time and don’t remember where it came from. I’ll have to dig around and see if I can find it. The album is called Smash Da House Volume II (Virgin records) and had Respect (Adeva), Good Life (Magic Juan’s Mix, Inner City), etc. Probably pretty obscure as there are a bazillion albums and down in here Australia we often get albums that don’t appear in discogs.

I’d suggest bit rot but I don’t believe anything but redundancy would be able to fix it if it was bit rot, so encoding to a different format would definitely not produce a successful result.

:thinking: hmm.

Released 1996 one or two used copies on Discogs, “bit rot” maybe the issue but I’d put my money on a ripping/encoding error…we’ll never know :thinking:

I’ve since found a number of other tracks in my library that also had the same problem. They all came from the same ripper so I’m guessing it’s something about how that ripper worked. I’ve since tried using ffmpeg to record as aac and now they all work just fine.

ffmpeg is about the best tool available for that kind of thing. Glad to know you’ve sorted it.

I’m not sure I would gone with aac, a lossy codec to a lossy codec just makes more loss. I would’ve probably gone to flac which at least has some internal compression built into the format, you’d have a bigger file than the mp3 but at least It wouldn’t be worse, you would just preserve what was in the mp3 at the cost of some space.

Glad to read you sorted it out though. :grinning: