Bugzilla – Bug 17609
Database is locked when accessing library while scanning
Last modified: 2011-12-12 10:13:29 UTC
It seems like you can start to get "database is locked" messages when accessing the library when performing a full rescan. I've stressed the system a bit during rescan by playing and browsing and I've seen this number of times. It's hard to describe exactly when it happens but it does happens if you play music and browse a bit. I've at least seen the following scenarios: - When TrackStat tries to write to persist.db because music is playing and it want to update play counts - When scanner reaches artwork scanning phase and tries to write artwork data - When iPeng starts up and tries to read contributors It happens with and without third party stuff but the easiest way I've found to reproduce it is as follows: 1. Start a full rescan 2. Start-up and shutdown iPeng for iPad a few times, so it refresh its local cache. You will get "database is locked" message in the server.log or scanner.log eventually, it might not happen the first time but it will happen if you stress the database a bit. It might not be critical if it's just a read operation that fails but I think it's random if it causes an error in main sbs process (which just disturbs music and cause non updated play counts in worst case) or if it crashes the scanner, I've seen both when experimenting with this. I haven't tried if this is unique to LMS or if it also happens in SBS 7.6.x and we just haven't found it yet. Some different logs follows below: [11-09-28 00:54:50.2205] Slim::Schema::Storage::throw_exception (122) Error: Carp::Clan::__ANON__(): DBI Exception: DBD::SQLite::st execute failed: database is locked [for Statement "UPDATE contributors SET name = ? WHERE ( id = ? )"] at /var/lib/sbssvn/squeezeboxserver/Slim/Schema/Storage.pm line 126 [11-09-28 00:54:50.2207] Slim::Schema::Storage::throw_exception (122) Backtrace: frame 0: Slim::Utils::Log::logBacktrace (/var/lib/sbssvn/squeezeboxserver/Slim/Schema/Storage.pm line 122) frame 1: Slim::Schema::Storage::throw_exception (/var/lib/sbssvn/squeezeboxserver/CPAN/DBIx/Class/Storage/DBI.pm line 598) frame 2: DBIx::Class::Storage::DBI::dbh_do (/var/lib/sbssvn/squeezeboxserver/CPAN/DBIx/Class/Storage/DBI.pm line 1297) frame 3: DBIx::Class::Storage::DBI::_execute (/var/lib/sbssvn/squeezeboxserver/CPAN/DBIx/Class/Storage/DBI.pm line 1419) frame 4: DBIx::Class::Storage::DBI::update (/var/lib/sbssvn/squeezeboxserver/CPAN/DBIx/Class/Row.pm line 490) frame 5: DBIx::Class::Row::update (/var/lib/sbssvn/squeezeboxserver/CPAN/DBIx/Class/Relationship/CascadeActions.pm line 35) frame 6: DBIx::Class::Relationship::CascadeActions::update (/var/lib/sbssvn/squeezeboxserver/Slim/Schema/DBI.pm line 32) frame 7: Slim::Schema::DBI::update (/var/lib/sbssvn/squeezeboxserver/Slim/Schema.pm line 1889) frame 8: Slim::Schema::variousArtistsObject (/var/lib/sbssvn/squeezeboxserver/Slim/Control/Queries.pm line 872) frame 9: Slim::Control::Queries::artistsQuery (/var/lib/sbssvn/squeezeboxserver/Slim/Control/Request.pm line 1884) frame 10: (eval) (/var/lib/sbssvn/squeezeboxserver/Slim/Control/Request.pm line 1884) frame 11: Slim::Control::Request::execute (/var/lib/sbssvn/squeezeboxserver/Slim/Web/Cometd.pm line 880) frame 12: Slim::Web::Cometd::handleRequest (/var/lib/sbssvn/squeezeboxserver/Slim/Web/Cometd.pm line 553) frame 13: Slim::Web::Cometd::handler (/var/lib/sbssvn/squeezeboxserver/Slim/Web/Cometd.pm line 112) frame 14: Slim::Web::Cometd::webHandler (/var/lib/sbssvn/squeezeboxserver/Slim/Web/HTTP.pm line 486) frame 15: Slim::Web::HTTP::processHTTP (/var/lib/sbssvn/squeezeboxserver/Slim/Networking/IO/Select.pm line 139) frame 16: (eval) (/var/lib/sbssvn/squeezeboxserver/Slim/Networking/IO/Select.pm line 123) frame 17: Slim::Networking::IO::Select::__ANON__ (/var/lib/sbssvn/squeezeboxserver/Slim/Networking/IO/Select.pm line 184) frame 18: (eval) (/var/lib/sbssvn/squeezeboxserver/Slim/Networking/IO/Select.pm line 184) frame 19: Slim::Networking::IO::Select::loop (/var/lib/sbssvn/squeezeboxserver/slimserver.pl line 695) frame 20: main::idle (/var/lib/sbssvn/squeezeboxserver/slimserver.pl line 645) frame 21: main::main (/var/lib/sbssvn/squeezeboxserver/slimserver.pl line 1158) [11-09-28 00:54:50.2210] Slim::Control::Request::execute (1889) Error: While trying to run function coderef [Slim::Control::Queries::artistsQuery]: [Carp::Clan::__ANON__(): Carp::Clan::__ANON__(): DBI Exception: DBD::SQLite::st execute failed: database is locked [for Statement "UPDATE contributors SET name = ? WHERE ( id = ? )"] at /var/lib/sbssvn/squeezeboxserver/Slim/Schema/Storage.pm line 126 ] [11-09-27 20:01:06.8534] Slim::Schema::Storage::throw_exception (122) Error: DBI Exception: DBD::SQLite::st execute failed: database is locked [for Statement "UPDATE track_statistics set playCount=1, lastPlayed=1317145805 where url = ?"] [11-09-27 20:01:06.8802] Slim::Schema::Storage::throw_exception (122) Backtrace: frame 0: Slim::Utils::Log::logBacktrace (/usr/local/bin/myperl/lib/site_perl/Slim/Schema/Storage.pm line 122) frame 1: Slim::Schema::Storage::throw_exception (/usr/share/squeezeboxserver/CPAN/DBIx/Class/Storage/DBI.pm line 1006) frame 2: DBIx::Class::Storage::DBI::__ANON__ (/var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/TrackStat/Storage.pm line 757) frame 3: (eval) (/var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/TrackStat/Storage.pm line 755) frame 4: Plugins::TrackStat::Storage::savePlayCountAndLastPlayed (/var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/TrackStat/Plugin.pm line 4212) frame 5: Plugins::TrackStat::Plugin::markedAsPlayed (/var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/TrackStat/Plugin.pm line 4095) frame 6: Plugins::TrackStat::Plugin::stopTimingSong (/var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/TrackStat/Plugin.pm line 3788) frame 7: Plugins::TrackStat::Plugin::openCommand (/var/lib/squeezeboxserver/cache/InstalledPlugins/Plugins/TrackStat/Plugin.pm line 3915) frame 8: Plugins::TrackStat::Plugin::commandCallback65 (/usr/local/bin/myperl/lib/site_perl/Slim/Control/Request.pm line 2082) frame 9: (eval) (/usr/local/bin/myperl/lib/site_perl/Slim/Control/Request.pm line 2082) frame 10: Slim::Control::Request::notify (/usr/local/bin/myperl/lib/site_perl/Slim/Control/Request.pm line 860) frame 11: Slim::Control::Request::checkNotifications (/usr/libexec/squeezeboxserver line 676) frame 12: main::idle (/usr/libexec/squeezeboxserver line 645) frame 13: main::main (/usr/libexec/squeezeboxserver line 1158) [11-09-27 20:01:06.8819] Plugins::TrackStat::Storage::savePlayCountAndLastPlayed (761) Database error: database is locked while executing: UPDATE track_statistics set playCount=1, lastPlayed=1317145805 where url = ?
igot it while doing a scan for new and changed . But i runned 3 players in sync . Another occurence here: http://forums.slimdevices.com/showpost.php?p=660466&postcount=31
Two reasons I could imagine causing this issue: - artists query is localizing the VA title to the client's language. If iPeng (or some other client) is using a different language than the server this might result in a write access we don't want - if we're playing some music and _some_ client (web, SP, iPeng etc.) is requesting artwork while the artwork scan is running, we again can run into such a lock Could one of these cases match what you're seeing?
yes iPeng and "controller app" in Swedish on my iPad , to change that i have to change the pads language. SBS/LMS in English.
Just for information, I've in the TrackStat 2.11.3591 and Dynamic Playlist 2.9.3590 releases implemented a temporary dirty workaround until this bug is solved. The workaround is that I keep all write operations in memory and queue them up and do the actual write after the rescan is finished. It's not something I plan to maintain on longer terms but it felt like a good idea to avoid some support issues in the 7.7.0 release. I still hope we can get a database that supports both read and writes to persist.db during rescans in 7.7.1 so I can safely remove this dirty workaround when 7.7.1 is released.
== Auto-comment from SVN commit #33728 to the slim repo by agrundman == == http://svn.slimdevices.com/slim?view=revision&revision=33728 == Bug 17609, do not update the global VA object if we are doing a per-request string in a different language
== Auto-comment from SVN commit #33729 to the slim repo by agrundman == == http://svn.slimdevices.com/slim?view=revision&revision=33729 == Bug 17609, avoid a possible locking issue by ensuring VA object is up to date at init time instead of waiting until the first time it's called, for example through artistsQuery
I fixed the case where the VA object update could fail. I am not quite sure yet how to fix the persistent table issue with TrackStat.
(In reply to comment #7) > I fixed the case where the VA object update could fail. I am not quite sure yet > how to fix the persistent table issue with TrackStat. Assuming the problem will be solved if adding the multi threaded scanner through Media::Scan module instead of using a separate scanner process, maybe it would be preferred to focus on that rather than trying to make it work with a separate scanning process ?