Problems with sqlite support with 1.4.8: no such table: uniqueid_temp

[Jeff Mitchell]

Colin Guthrie wrote:
> I've done some more testing and I don't think it's that call that's
> getting it, but rather the PlaylistFile::loadM3u()....
>
> I put in some debug (see attached patch) into the loadM3u() and
> triggered the error with my known test case. I got my debug output
> immediatelly before the errors started. See debug.1.txt.
>
> It clearly shows a new sqlite connection being created immediately
> before the error. This makes sense as this connection will not be able
> to access the temporary tables.
>   
But that doesn't affect anything.  At least not over here.  I just 
managed to brute-force it so that I get the "no such table 
uniqueid_temp" errors, but they in no way cause horrendous CPU usage or 
lockups, and it just falls through to the second case as intended.

Note that originally (AFAIR) those errors weren't shown in the debug 
output, so as originally implemented you wouldn't see any output if the 
table didn't exist, it'd just fall through.

> So I guess the PlaylistLoader is in a different thread and apparently
> creates it's own CollectionDb instance but shares the ScanController
> instance.
>   
Actually I don't think it shares the ScanController instance.  If it did 
it'd be able to access the temporary tables.

> Still the query will fail for every file in every playlist found and
> thus that's a fair few pointless queries in my case which probably
> accounts for the slowdown.
>   
No, it doesn't.  There are many queries being made for every file 
scanned.  A single extra query isn't causing huge slowdown for you.  The 
only thing it would do is cause the scanning to go slower, either 
imperceptibly or almost imperceptibly (the slowest part of the scanning 
is the file parsing itself).

> I really appreciate the time you're spending on this. I hope it does
> turn out to be a bug and not just user support ;)
>   
Unfortunately at this point it's still the latter.  I still can't 
reproduce this.  We have X number of Amarok installs out there that 
include AFT, Y percentage of which are using sqlite (both probably 
fairly large numbers) and you're the only one that seems to be having 
this issue (not with seeing the uniqueid_temp errors -- that's just 
normal debug output -- but with the huge long scan times seeming to be 
caused by a simple sqlite query).  So I still tend to think that this is 
something on your system.

Have you tried using an external, more recent version of sqlite and 
seeing if that helps?  The most recent release is 3.5.6...you could just 
grab the source (the "amalgam" source) and overwrite what's in the 
Amarok tree with the sqlite.h and sqlite.c files if you want to keep it 
internal but want to try a newer version.  Make sure if you are using an 
external package outside the tree that sqlite is built with 
threadsafety.  Generally it is enabled by default.

I know this is frustrating for you, but as I can't reproduce this (on 
two separate computers...one x86 and one x86_64) I still can't hack at 
it to figure out what's going on.  So I need you to keep trying things 
out on your side.

Trying a recent sqlite version would be a help, because if that fixes 
things, I'll bump it up in our tree.

--Jeff