Closed tkem closed 10 years ago
This behavior is not always reproducable -- often/mostly, Mopidy will start up fine during a local scan, correctly reporting the number of local tracks already committed.
May be related to the size of the library.db-journal
, i.e. the number of tracks being updated. Could be observed with library.db-journal
> 1.5MB, or > 4000 tracks.
Performing each INSERT in a seperate transaction fixes this, but increases the total time for a local scan about a factor of 3. Addtionally, this will probably result in more disk writes, which may affect platforms running off SD cards, for example.
Another option would be to set local/scan_flush_threshold
to a lower value, e.g. 100 (the default 1000 seems a little bit excessive, anyway). Thus, the journal file seems to stay well beneath 500KB, and no database timeouts could be observed. So this should be added as a recommendation to the README.
When starting Mopidy while a local scan is running, it will most likely fail due to a connection timeout. Rethink transactions/locking/isolation levels, e.g. commit after every insert.