Summary: | After collection is scanned, Amarok loses collection and stats | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Eric Mesa <ericsbinaryworld> |
Component: | Collections/Local | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | auxsvr, matej, ralf-engels, s7mon |
Priority: | NOR | Keywords: | release_blocker |
Version: | 2.5.0 | ||
Target Milestone: | 2.6 | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
URL: | https://git.reviewboard.kde.org/r/105488/ | ||
Latest Commit: | http://commits.kde.org/amarok/5a0d3d39f6a0f588b6419c6c27e0227b512712e6 | Version Fixed In: | 2.6 |
Sentry Crash Report: |
Description
Eric Mesa
2012-04-17 04:44:13 UTC
Do you have the option "watch folders for change" enabled? Then Amarok will scan the collection on startup and update it, that is a normal behavior, not a bug. Sorry, I completely misread your first sentence and read "I will scan and erase all files but one". Please disregard my comment. It just lost my collection again. this is very annoying. Let me know what I need to provide to fix this. Where is your collection located? Please make sure the location is mounted and accessible when you start Amarok. FWIW, I can't reproduce this on Amarok 2.5-git of today Music is on my /home partition so it's definition mounted. Is this a known issue if Amarok crashes in 2.5? That's one thing that happened before the second time the music disappeared. The next time I started it all the music was gone after the collection scan as described above Did you try erasing the amarok* configuration files in $HOME/.kde/share/config/ (might be in $HOME/.kde4/share/config/ depending on the distribution)? A known issue? That really depends on the backtrace, else this is rather a wild guess. You didn't talk about a crash in this report before, is the db loss happening after a crash? A crash in the database can of course lead to a corrupted table, but you would also get a message on the console. Could you please provide a backtrace? Just happened again yesterday. I was playing music on Amarok. Then I noticed it kept playing the same song over and over. Then I noticed that all the music in the playlist had lost its album cover. Exited Amarok. Started it again and my collection was gone. Here's a neat little fact that might help pinpoint what is happening. All of my collection was gone EXCEPT the songs I'd added this week. You'd think it'd be all or nothing, right? Weird. I mark it as a release blocker, as this needs to be sorted out before we release 2.6. Thank you for your feedback. Ralf, Matej: any ideas? Eric, I have an idea what causes it. I've found out that Amarok's collection doesn't survive when you toggle "Local Files and USB Mass Storage Backend" in Configuration -> Plugins. Can you confirm this is the cause? Please do the following: A1. Enable the plugin, quit Amarok. 2. Restore Amarok db from backup 3. Poke around, trigger "Update Collection" if everything okay do even a Full Rescan. Tracks _and_ statistics (e.g. play counts) should not disappear. And they try with B1. Disable the plugin, quit Amaork; rest of the steps is the same. Reporters, please apply the patch from https://git.reviewboard.kde.org/r/105488/ on top of the current git and report back. It's worth to read the review request comments. Alternatively, the code is available in my personal repo clone branch: http://quickgit.kde.org/index.php?p=clones/amarok/laitl/amarok.git&a=shortlog&h=refs/heads/scanresultprocessor-bugfix *** Bug 273278 has been marked as a duplicate of this bug. *** I haven't messed with that plugin at all. Usually the songs just disappear after something has happened (don't know what). It's also often accompanied by some crashes. But I just read your blog post about your SoC and it appears you've tackled a bunch of collection data loss issues so maybe you've fixed the issue? I could toggle that plugin to test what you've done, but I never toggled it before so I doubt that's what was going on with me. (In reply to comment #12) > I haven't messed with that plugin at all. Eric, just please do what I instructed you in comment #9, note whether bug is reproducible, then apply path from comment #10, redo testing from comment #9, report back whether the bug is fixed by patch. I had the same problem, described in bug 290344. I fixed it by opening the mysql database directly and editing the path and device data stored in it. Git commit 5a0d3d39f6a0f588b6419c6c27e0227b512712e6 by Matěj Laitl. Committed on 09/07/2012 at 01:41. Pushed by laitl into branch 'master'. SqlScanResultProcessor: don't accidentally delete tracks, defensive rewrite This fixes data-loss that I can trigger every time by toggling "Local Files & USB Mass Storage Backend" in Config -> Plugins, restarting Amarok and triggering collection update / rescan. In theory, more things such as cloning changing disk could trigger this problem, from SqlScanResultProcessor::deleteDeletedDirectories() comment: We need to match directories by their (absolute) path, otherwise following scenario triggers statistics loss (bug 298275): 1. user relocates collection to different filesystem, but clones path structure or toggles MassStorageDeviceHandler enabled in Config -> plugins. 2. collectionscanner knows nothings about directory ids, so it doesn't detect any track changes and emits a bunch of skipped (unchanged) dirs with no tracks. 3. SqlRegistry::getDirectory() called there from returns different directory id then in past. 4. deleteDeletedDirectories() is called, and if it operates on directory ids, it happily removes _all_ directories, taking tracks with it. 5. Tracks disappear from the UI until full rescan, stats, lyrics, labels are lost forever. Also add a handful of asserts, ScanResultProcessor is very complicated and small error or corner-case in logic may result in horrible data losses. Reporters of linked bugs, please try to reproduce your data-loss with this patch applied and report back in both cases. In negative case, please reopen and attach full updated amarok --debug log. After this patch, only (statistics, lyrics and labels)-loss operations should be: a) moving track out of mounted collection folders [by design] b) changing both metadata and url from outside of a track not tagged by amarok_afttagger [we can do nothing about this] FIXED-IN: 2.6 M +4 -0 ChangeLog M +199 -75 src/core-impl/collections/db/sql/SqlScanResultProcessor.cpp M +36 -16 src/core-impl/collections/db/sql/SqlScanResultProcessor.h http://commits.kde.org/amarok/5a0d3d39f6a0f588b6419c6c27e0227b512712e6 apologies, but I can't do the testing. I've tried for the past two weeks but haven't been able to find time. Your patches sound pretty all-encompassing. If it still happens post-2.6 I'll reopen a ticket and hopefully will be able to find time for testing patches at that time. Thanks for your awesome help in this important issue |