Comment 5 for bug 1641359

The backup is running with lowest io prio, but probably loads the disk
(it is writing to) so much, that mixxx can't get the audio files from
that disk.

Do you have test data to verify this assumption? I think Mixxx will log
something if it suffers cache missed. (I need to verify it.)

Mixxx isn't caching the playing tracks in memory, but getting the audio
from disk on demand?

Mixxx does not cache the entire track, but enough to avoid such "HD in
used" issues. Maybe it can be improved for your use case though.

Are the tracks on the same pysical disk of you backup? What kind of disk do
you use and how is it connected?

Is the buffer underrun counter counting in Mixxx hardware preferences? Is
there a hint hat you are not running at Real Time Priority?

If yes, you issue is probably not related to the Mixxx read ahead cache. In
this case it is a common overload issue, or you suffer the known
concurrency issue when the track is analysed. Do you suffer dropouts, if no
analysis is running?