replacing a track with a better version leads to the risk of the song being cut off abruptly during broadcast.

[mixxxbot]

Reported by: alpillesgp
Date: 2022-07-14T16:09:41Z
Status: Confirmed
Importance: Undecided
Launchpad Issue: lp1981726

---

The caching mechanism does not take into account the modification of a file which keeps its name (so as not to lose its insertion in multiple playlists) but is intrinsically different (better recording quality, or more danceable version)
If the replaced version is longer (is the end-of-track silence marker counted from the end?) the end-of-track marker is retained during playback and therefore the piece is cut off before the end, which is catastrophic for the dancers' experience.
The cache should check not only for the presence of the file but also compare sizes and dates to validate the relevance of the information used.
Very easy to reproduce: replace a file with a shorter one, use the auto DJ with the mute option to switch from one track to another and on replay the broadcast will be truncated.
Additional note: deleting the end marker does not solve the problem, the track is nevertheless interrupted at the same marker which is however no longer visible.
Re-scanning the tracks before playback should solve the problem, but the behaviour is certainly not intuitively understood by users.

[mixxxbot]

Commented by: pcantare
Date: 2022-08-09T07:23:50Z

---

Re-scanning the library won't do the job. You need to reset all the information (ot at least the waveform, I suppose) related to that file. In any case, if you change the file also the key, BPM and replay gain might be different, so I think it's safer to reset everything.

Anyway, I agree with you it would be nice that Mixxx detected the new file and reset everything which is stored in the database.

[mixxxbot]

Commented by: daschuer
Date: 2022-08-14T20:55:09Z

---

A first step is implemented here:
#4773

This detects, if the first sound is still on the same sample as expected.
This can easily be extended for the last sound to also verify changes at the end of the track.

Currently It only logs a warning to mixxx.log

How should Mixxx behave when such issue is detected?

[mixxxbot]

Commented by: pcantare
Date: 2022-08-22T11:49:23Z

---

For my use case, Mixxx doesn't need to check if the first sound is consistent. If the Date modified of the file is newer than Date added stored in the db, and maybe the size as well has changed, Mixxx should treat the file as newly addded: metadata, waveform, BPM, ReplayGain, maybe even cue points need to be reset and the file needs to be analyzed again.

[ronso0]

If the Date modified of the file is newer than Date added stored in the db, and maybe the size as well has changed

Both date modified and file size would change if metadata is edited outside Mixxx, so I think this (alone) is not enough to detect 'quality' change.
However, it is very likely the sample count is different. Though, like file size, that is currently not stored in the db.

I think, in order to reduce open bugs/feature requests, it's better to close this and continue in #8053
Feel free to reopen if you think this is a significantly different topic.