Mixxx

Dirty track ASSERT

Bug #680325 reported by Albert Santoni on 2010-11-23

This bug report is a duplicate of: Bug #733376: Track Cache does not Save to Database. Edit Remove

This bug affects 2 people

Affects		Status	Importance	Assigned to	Milestone
	Mixxx	Triaged	Low	RJ Skerry-Ryan	Mixxx 1.9.0

Bug Description

From IRC:

Debug: [Main]: Track Played: "Lady Gaga" - "Just Dance" Fatal: [Main]: ASSERT: "!m_dirtyTracks.contains(trackId)" in file src/library/dao/trackdao.cpp, line 124 ussycat Dolls Feat Snoop Dogg - Buttonz
Track Played:Lady Gaga - Just Dance
Aborted

From rryan:
there's a caching layer in the library
so that we dont save tracks to the database every time they're changed
because they get changed a lot so that would generate a lot of database traffic
but anyway.. the way we save stuff to the disk is via the DAO pattern, and those DAO's are not thread safe so when Qt signals/slots are hooked up to them they have to be proxied via the Qt event loop
so when a track is changed it phones home that its dirty
but the message might not get there until the next time through the event loop
thats the only way I can guess that that assertion would fire
it's a mostly harmless assertion too
or...

Revision history for this message

RJ Skerry-Ryan (rryan) wrote on 2010-12-01:

I can't reproduce this. theresajayne has not yet provided details on how to reproduce this either, so we're kind of stuck.

Changed in mixxx:
assignee:	nobody → RJ Ryan (rryan)

Revision history for this message

RJ Skerry-Ryan (rryan) wrote on 2010-12-02:

Tracked this down. After merging features_library there is a new feature that clears the track cache once the library scanner is finished running. It cleared the track-cache map, but not the dirty-tracks set.

Steps to reproduce:
1) Load a track and edit it (it becomes dirty)
2) Rescan the library
3) While library scan is in progress, load a track in place of the dirty track.
4) Library scan finishes, putting TrackDAO in an inconsistent state.
5) Reload the dirty track to the deck. Assertion fires.

Fixed in trunk.

Changed in mixxx:
status:	Confirmed → Fix Committed

Revision history for this message

RJ Skerry-Ryan (rryan) wrote on 2010-12-02:

OK this is not actually fixed. Genji confirmed it still happens in trunk. I'm going to change the assert to a check and take corrective action + warn when this happens, since it's certainly not worthy of making Mixxx bail b/c a crash would not follow if this was not asserted.

Changed in mixxx:
status:	Fix Committed → Triaged

Revision history for this message

RJ Skerry-Ryan (rryan) wrote on 2010-12-08:

Since this is no longer an assertion, I'm setting the priority as low.

Changed in mixxx:
importance:	High → Low

Revision history for this message

Owen Williams (ywwg) wrote on 2011-02-05:

I think I found one fix for this. It probably won't solve it completely but does fix some of the cases.

in TrackDAO::deleteTrack():

// Save dirty tracks.
pTrack->save();

should be
// Save dirty tracks.
if (pTrack->isDirty())
pTrack->save();

otherwise it will try to save tracks that aren't dirty and will trigger the assertion. This causes problems on exit because tracks try to save themselves after the DB is already closed

Revision history for this message

RJ Skerry-Ryan (rryan) wrote on 2011-03-20:

OK, this blew up into a super huge problem where we weren't saving tracks and losing data. I was very wrong about this being a harmless assert. That said, it should be fixed now. Marking as a dupe of the relevant bug.

Revision history for this message

Swiftb0y (swiftb0y) wrote on 2022-10-08:

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5675