Summary: | Tracks become 'never played' after modifying the root Music directory | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | robert marshall <robert> |
Component: | Collections/Local | Assignee: | Amarok Bugs <amarok-bugs-null> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | matej, ralf-engels, stschoettl, tuomas |
Priority: | NOR | ||
Version First Reported In: | 2.8-git | ||
Target Milestone: | 2.9 | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
robert marshall
2015-12-21 12:01:16 UTC
No problem, I think I understood the issue, this should indeed not happen. Assuming this is a database problem, Ralf, if you could have a look? I should have mentioned (but was probably implicit) that I have both 'scan folders recursively' and 'watch folders for changes' set to true. I think this is what happened: When you removed the link and did the rescanning Amarok deleted the old songs from the database. If you would instead have moved everything in place and then let Amarok rescan, then Amarok would have noticed that the files were just moved. The behaviour is a little bit up to interpretation, but I think forgetting about not longer used songs is the right thing to do. However you could add a "wish" that Amarok should not clean up deleted files until a restart. Allowing Amarok to save the playcount in the file will prevent this from happening again. Ralf That's not the problem, to give an explicit example: ~/Music/ contained (say) track1.flac and otherArea - otherArea is a soft link to /newPartition/Music and contains track2.flac I removed otherArea from the directories (within ~/Music) where are scanned (in amarok settings) and at that point track2.flac loses its stats (this I expected!). I then added /newPartition/Music (using the full path) as a directory containing part of my collection. track2.flac reappears in the collection with a never played status (also an expected outcome). I then removed the otherArea soft link. What I didn't expect was that track1.flac would suddenly also appear to be never played - and in my simple example at one point in the process (after adding /newPartition/Music and the consequent scan I only have one track in the collection) I hope this makes it clearer, maybe I should create a dummy user and check that the issue is easily repeatable. I managed to replicate this in a slightly simpler form on another machine: - without amarok running I added a subdirectory to ~/Music containing (new to the collection) music tracks - I ran amarok and rescanned that directory so the new tracks were there - I then told amarok not to scan that new directory and let it do another rescan - with amarok running I moved the new subdirectory of ~/Music elsewhere (outside the directories contained in the collection) - using the `mv` shell command Then I see that the tracks at the top level in ~/Music are all shown as having never been played (before I went through these steps those tracks had been played!) Ah, interesting. Reading the description and steps to reproduce, I got a feeling this might be related to a bug that was fixed yesterday in git master ( https://bugs.kde.org/show_bug.cgi?id=475528 ). I tried the steps and could reproduce this, but (in addition to the bug fixed yesterday?), this case involves another aspect: Seems that when some subdirectories of a directory are excluded from the collection, all files in the root of the directory are excluded, too (and only the specifically included subdirectories are included). I'm not completely sure if it should include the top level or not; maybe it should, but that's technically a bit complicated to implement. (Here seems to be also an additional small UI bug: when files in a top level of directory are not included, they are shown as checkable single files in collection directory setup. However, selecting them has no effect as collection scanner skips them as they are not directories) |