quitting mixxx without canceling coverart scan causes sql errors

[Owen Williams]

coverart scanner needs to detect program exit.

Debug [LibraryScanner 1]: src/library/dao/trackdao.cpp 1709 FAILED QUERY [ "UPDATE library SET coverart_type=?, coverart_source=?, coverart_hash=?, coverart_location=? WHERE id=?" ] QSqlError(5, "Unable to fetch row", "database is locked") failed to write metadata cover
Debug [LibraryScanner 1]: src/library/dao/trackdao.cpp 1709 FAILED QUERY [ "UPDATE library SET coverart_type=?, coverart_source=?, coverart_hash=?, coverart_location=? WHERE id=?" ] QSqlError(5, "Unable to fetch row", "database is locked") failed to write metadata cover
Debug [LibraryScanner 1]: src/library/dao/trackdao.cpp 1735 FAILED QUERY [ "UPDATE library SET coverart_type=?, coverart_source=?, coverart_hash=?, coverart_location=? WHERE id=?" ] QSqlError(5, "Unable to fetch row", "database is locked") failed to write file or none cover
Debug [LibraryScanner 1]: src/library/dao/trackdao.cpp 1735 FAILED QUERY [ "UPDATE library SET coverart_type=?, coverart_source=?, coverart_hash=?, coverart_location=? WHERE id=?" ] QSqlError(5, "Unable to fetch row", "database is locked") failed to write file or none cover
Debug [LibraryScanner 1]: src/library/dao/trackdao.cpp 1735 FAILED QUERY [ "UPDATE library SET coverart_type=?, coverart_source=?, coverart_hash=?, coverart_location=? WHERE id=?" ] QSqlError(5, "Unable to fetch row", "database is locked") failed to write file or none cover

[RJ Skerry-Ryan (rryan)]

Hm, I don't think this is a problem with the cover-art phase of the scanner. It checks if the scan is cancelled on every iteration of its loop. This means the scan wasn't canceled when you were seeing these messages and that means the LibraryScanner hadn't been deleted yet (since it cancels and waits for the thread to terminate in its destructor).

Since these are locked errors -- it looks like some other thread is starting a transaction while the scanner is writing the covers. I'm not sure which that would be since TrackDAO::finish doesn't get called until after LibraryScanner is totally destroyed. It's possible that destroying the UI released a bunch of TrackPointer references which triggered some saveTracks.

[Owen Williams (ywwg)]

This is trivially reproduceable for me:

1. restore mixxx db backup from before coverart support
2. launch mixxx
3. quit while scan is in progress

[RJ Skerry-Ryan (rryan)]

Does this block Mixxx from exiting or do you see a few of these messages in the log?

[Owen Williams (ywwg)]

it prevents mixxx from exiting. It looks like it wants to keep scanning and scanning but I haven't let it go very long

[RJ Skerry-Ryan (rryan)]

Huh. Maybe the cancel check is hoisted out of the loop by the compiler since the cancel check is a const method.

[RJ Skerry-Ryan (rryan)]

Could you try changing this method to volatile instead of const?
https://github.com/mixxxdj/mixxx/blob/master/src/library/scanner/scannerglobal.h#L72

On Thu, Dec 11, 2014 at 10:08 AM, RJ Ryan <email address hidden>
wrote:

> Huh. Maybe the cancel check is hoisted out of the loop by the compiler
> since the cancel check is a const method.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1399981
>
> Title:
> quitting mixxx without canceling coverart scan causes sql errors
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1399981/+subscriptions
>

[Owen Williams (ywwg)]

no difference. It looks like it enters the WTrackTableView destructor right before the errors start. Also note that the cover scan dialog remains up

[Owen Williams (ywwg)]

Here's a full log. I added a debug line in the shouldCancel call -- it's not getting called.

[Owen Williams (ywwg)]

moar log

[RJ Skerry-Ryan (rryan)]

Ah, got it. Thanks for the help. I believe the problem is that the active select blocks the database entirely while it is active. We should be careful about iterating through results of a QSqlQuery and doing something slow in the loop (file access, etc.) since the longer the query is active the longer we are blocking the database.

[Owen Williams (ywwg)]

Is there an easy workaround to copy the result into an object for processing, rather than using the query result object?

[RJ Skerry-Ryan (rryan)]

Yep :). Fixed in https://github.com/mixxxdj/mixxx/commit/fc7bfe6b3c32779f2b3381f3b6284237ec0e28ab

[Owen Williams (ywwg)]

fix verified!

[Swiftb0y (swiftb0y)]

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