DEBUG_ASSERT when changing tree view item

[mixxxbot]

Reported by: daschuer
Date: 2019-07-21T10:12:58Z
Status: Fix Released
Importance: Medium
Launchpad Issue: lp1837315

---

This has happens during AutoDJ development derived from current master.

Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: Keys version/sub-version unchanged since previous analysis. Not analyzing.
Debug [AnalyzerThread 0 mixxxdj/mixxx#4910]: AnalyzerWaveform - Waveform generation for track 8 done 0 s
Debug [Main]: MixxxLibraryFeature::activate()
Debug [Main]: WTrackTableView::loadTrackModel() LibraryTableModel(0x3dd2620)
Debug [Main]: LibraryTableModel(0x3dd2620) select() took 2 ms 68
Critical [Main]: DEBUG ASSERT: "row < m_children.size()" in function TreeItem* TreeItem::child(int) const at src/library/treeitem.cpp:60
Fatal [Main]: ASSERT failure in QList<T>::operator[]: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 514

[mixxxbot]

Commented by: daschuer
Date: 2019-07-21T10:14:47Z

---

There is an issue during updating the bold state of a recently generated history playlist.
That was not already drawn by the GUI.

[mixxxbot]

Commented by: daschuer
Date: 2019-07-21T11:23:55Z

---

Strange. I can't reproduce the issue with the 2.2 branch but with plain master.

We can easily solve the crash by iterating over the rootItem->childs instead of m_playlistList, but unfortunately this does not solve the root issue.

The crash happens when I see in the tree a current history playlist (5) marked with a "->", but m_playlistList already has a invisible history playlist with prefix (6).

How can this situation happen?

[mixxxbot]

Commented by: daschuer
Date: 2019-07-21T12:35:48Z

---

I got it. It is an issue with running two Mixxx instances in parallel.
In this case a the new history playlist is silently created in the database without updating the GUI.
The next call to BasePlaylistFeature::updateChildModel() the fetches whole m_playlistList from the database but updates only the recently changed playlist inside the GUI and not the changes do to the other Mixxx instance.

I think the best solution is to refresh only the effected playlist in m_playlistList.
This fixes the crash and improves the performance.
Concurrent DB changes are not discovered as Mixxx is not designed for it.

[mixxxbot]

Commented by: daschuer
Date: 2019-07-21T18:13:20Z

---

A solution is here:
#2214

[mixxxbot]

Issue closed with status Fix Released.