Sqlite3 problems in Amarok 2

[Nikolaj Hald Nielsen]

What you are seeing is caused by this part of Amarok2 simply not being
done yet. We are moving to a completely new collection backend, and as
you noticed, this work is not yet completed. Amarok2 is currently in a
pre alpha state, so there is really no point in running it unless it
is to help code it! :-)

We are not at a point where we even accept bug reports yet (hence no
bugs on bko), as there are still more things that are broken than
things that work.

- Nikolaj

On Dec 15, 2007 2:31 PM, Ryan Bitanga <ephebiphobic at gmail.com> wrote:
> Hey everyone,
>
> I was just wondering if anyone else is having problems with Sqlite3 in
> Amarok 2. I get a lot of sqlite3_compile errors, with errors about the
> unavailability of the tags and tags_labels tables.
>
> Updating tracks results in this:
> amarok: BEGIN: void ScanResultProcessor::processScanResult(const
> QMap<QString, QHash<QString, QString> >&)
> amarok:      Processing  16  tracks
> amarok: BEGIN: void DatabaseUpdater::copyToPermanentTables()
> amarok:        [ERROR!] sqlite_step error.
>
> amarok:        [ERROR!] PRIMARY KEY must be unique
> amarok:        [ERROR!] on insert:  "INSERT INTO directories SELECT *
> FROM directories_temp;"
> amarok:        [ERROR!] sqlite_step error.
>
> amarok:        [ERROR!] PRIMARY KEY must be unique
> amarok:        [ERROR!] on insert:  "INSERT INTO tracks SELECT * FROM
> tracks_temp;"
> amarok: END__: void DatabaseUpdater::copyToPermanentTables() - Took 0.22s
> amarok: BEGIN: void DatabaseUpdater::removeTemporaryTables()
> amarok: END__: void DatabaseUpdater::removeTemporaryTables() - Took 0.0042s
> amarok: END__: void ScanResultProcessor::processScanResult(const
> QMap<QString, QHash<QString, QString> >&) - Took 0.23s
>
> I also get sqlite3_compile errors when the temporary tables are
> created (DatabaseUpdater::createTemporaryTables()). The first time
> temp tables are created, there are no error messages, however, it
> seems like removeTemporaryTables() isn't always called after the temp
> tables are created. I haven't investigated this much, but obviously if
> the temporary tables are not empty, it's possible for entries with
> identical primary keys to exist leading to the failure of the query
> attempting to insert the duplicate entries.
>
> I'm using Kubuntu and apparently libamarok_collection-sqlcollection
> links to the stock libsqlite instead of the sqlite bundled with
> amarok. I haven't tested if this is the cause but I don't think the
> above errors are caused by using the stock libsqlite.
>
> Is anyone working on this? I rather not waste my time looking for the
> real reason if this is caused by the configuration of Kubuntu or
> someone else is working on it and close to finding fix. I see all the
> other database engines have been commented out in
> SqlCollectionFactory::init(). I didn't see any amarok 2 sqlite 3 bugs
> in bko so I was wondering if this was a singular event. If you need
> help, I'm willing to go bug hunting and fix it as soon as I finish the
> last bunch of krunner stuff I'm working on.
>
> Cheers,
> Ryan
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>