Playback hiccups after scrubbing through MP3s

Bug #1281654 reported by Smashuu on 2014-02-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Uwe Klotz

Bug Description

I am experiencing constant hiccuping after scrubbing through most (but not all) of my MP3s. Usually it will sound clear on an initial playthrough, but after I scrub around on the overview waveform, subsequent playback is unusably choppy!

M4A/AAC/WAV files seem unaffected. I've tried dialing down my latency, etc., but that hasn't made a difference.

OSX 10.9.1, Mixxx 1.11.0

Smashuu (smashuu) wrote :

Interestingly, this also seems to persist. If I load one MP3, scrub to make it start hiccuping, then eject it and load another MP3 susceptible to the problem, that one starts hiccuping right away without having scrubbed over it.

Smashuu (smashuu) wrote :

Also, unlike both CBR and VBR files alike are affected.

RJ Skerry-Ryan (rryan) wrote :

Can you post a log? I'm curious if there are any caching reader errors.

Changed in mixxx:
importance: Undecided → High
importance: High → Critical
jus (jus) wrote :
Smashuu (smashuu) wrote :

Log attached.

Smashuu (smashuu) wrote :

Update: I removed the ~/Library/Application Support/Mixxx/ directory, AND did a fresh reinstall of the same version of Mixxx, and together this seems to have fixed the problem for me. With one or two MP3s I'm hearing a slight hiccup immediately after a scrub, but only for a fraction of a second. This isn't something I'd be doing live anyway, so this is perfectly acceptable to me.

I'm running through my library now and will post any further findings.

Smashuu (smashuu) wrote :

I spoke too soon, the problem's back.

Everything was fine until I dragged an MP3 from my Downloads folder directly to the deck, and then the stuttering was immediate and constant, and even persisted after relaunch and opening an MP3 from my Library.

Removing Mixxx's Application Support directory and relaunching seems to have fixed it again. I saved the directory in case it could be of any use diagnosing the issue.

Smashuu (smashuu) wrote :

It's been creeping up again. I've narrowed the problem down to mixxxdb.sqlite -- deleting that one file and rescanning the library clears up the problem completely.

Smashuu (smashuu) wrote :

I'd be happy to compare a newly generated DB against the "choppy" DB, but I don't know enough about the schema to know what I'm looking for. Any suggestions would be much appreciated.

RJ Skerry-Ryan (rryan) wrote :

Smashuu -- when you run into a corrupt DB issue could you post the mixxxdb.sqlite here along with the filename of the file?

Smashuu (smashuu) wrote :

DB is attached.

Here's a track that's doing it immediately: "Concentric Circles (ID: 164403)"
And one that never does it, if that helps: "Beyond the Standard model (ID: 171212)" -- both by "DJGenericname"

Please let me know if there's anything else I can help with.

Smashuu (smashuu) wrote :

Oops, you asked for filenames. Those would be "01 Concentric Circles (ID_ 164403).mp3" and "01 Beyond the Standard model (ID_ 171212).mp3", respectively.

RJ Skerry-Ryan (rryan) wrote :

Hm, Smashuu -- so I've tried in 1.11.0 and master and can't reproduce.

Looking at your database by hand everything looks normal too.

Could you send me those 2 MP3s? I downloaded them by following the link in the comment but I think the files might be different than the ones on your hard disk:

My launchpad username @

RJ Skerry-Ryan (rryan) wrote :

How do you scrub through the audio?

Here are the steps I'm trying to take to reproduce:

1) Drag file from file browser to big waveform.
2) Hit play with keyboard shortcut
3) Scrub through audio with keyboard (a/s keys) and mouse on waveform overview
4) Eject track
5) Repeat 1-4 with the 2 MP3s you mentioned.

It sounds like just steps 1-2 on the particular file reproduce it for you with a totally clean config (deleted Application Support/Mixxx folder). Is that right?

Smashuu (smashuu) wrote :

One thing I've discovered, after playing with this yesterday and today, is what it takes to trigger the hiccups is not always consistent across files. I decided to record two short videos so you can see exactly what's happening to me in a couple of different cases. This is coming off a fresh reboot, with no other programs running, and my old DB file.

Three Dog Night's Black and White demonstrates the problem more or less as originally described, as seen here. It plays back normally at first, but scrubbing anywhere in the track produces hiccups immediately. Even ejecting and reloading the track does not remove them.

Black and White:

Concentric Circles (which I mentioned above) is a bit different. It plays back fine, even after scrubbing around the file. But then after loading another track (it does not seem to matter which), and then loading Concentric Circles again, the hiccuping starts immediately.

Concentric Circles:

In either case, once the hiccuping behavior is triggered, it will carry over into other tracks that show the problem until restarting Mixxx.

In answer to your last question, the problem goes away entirely if I delete the Application Support/Mixxx directory (or just the DB file, actually). After that, I am completely unable to trigger hiccups using the above steps. For a while, that is. Then after a few minutes or hours, the behavior will suddenly appear again, and then I can reproduce it at will.

I can't tell what is changing or what I am doing that is suddenly throwing a switch and allowing the hiccups to happen again. I just know that if I use it long enough, the issue returns.

RJ Skerry-Ryan (rryan) wrote :

I'm still stumped on this. Ugh.

Could you attach your entire "Application Support/Mixxx" folder (not just mixxxdb.sqlite) when the problem happens?

I skimmed over the problem database you uploaded and couldn't find anything out of the ordinary.

RJ Skerry-Ryan (rryan) wrote :

Smashuu : could you also try our 1.12.0 pre-alpha?

It doesn't have many of the new features showing but it has a ton of internal improvements. I wonder if we fixed this bug already.

Smashuu (smashuu) wrote :

Attached is a reliably problematic version of the Application Support folder; whenever I restore this and launch Mixxx, I can trigger the specific cases above right away. Did you get the attachment I emailed as well?

I will stress-test the pre-alpha and let you know if/when the issue comes back.

Smashuu (smashuu) wrote :

So far so good on the main issues above while using the pre-alpha.

I have noticed one unrelated but similar hiccup issue, but it seems more related to track decoding. I recorded it here:

Basically, very rarely a hiccup will appear in a track at the same point each playback. But in this case, unloading and reloading the track clears it up.

Daniel Schürmann (daschuer) wrote :

Hi Smashuu,

We have recently fixed some issues have produced buffer underruns. The effect "sounds" different on my machine, but
it was very similar to you second video. So you may give the latest master build a try.
We have now a meter, that displays the latency usage (Below the clock in the Shade skin).
What does it look like when the hickups starts ?

Your hiccups "sounds" very similar to the issue we experience when cached samples does not fit to the current samples.
But the eject reload cycle clears the cache, so this can not be the original issue, but it is prety sure the issue from your latest post.

Uwe prepared a branch that is probably worth a try:
Are you able to build it from source?

@All: Who can help, to build a mac version from Uwes branch? Thank you.

Daniel Schürmann (daschuer) wrote :

@Smashuu: Any updates?

Aahz from IRC reports that on master r5275, the pop/click issue is fixed for him.

Owen Williams (ywwg) wrote :

this is won'tfix for 1.12, we can reopen if it comes back in master

Changed in mixxx:
status: New → Fix Committed
milestone: none → 2.1
Uwe Klotz (uklotzde) on 2017-10-30
Changed in mixxx:
assignee: nobody → Uwe Klotz (uklotzde)
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers