Having had problems in the past with soft links in my ~/Music directory pointing to other partitions (see https://bugs.kde.org/show_bug.cgi?id=349783 ) I decided to sort things out and did the following: - In amarok settings->Local collection, I removed the soft link from directories to be scanned - I let the rescan of the collection (by ok'ing the settings dialog) run to completion (so ending up with around 600 fewer tracks in the collection as the soft link was no longer followed) - I then, in local collection, added the true path to the collection area in the other partition (rather than using the soft link), ok'ed the setting dialog and let that scan run to completion. - I noticed that the collection size was around 300 tracks short of the total before I started the process, thought it odd but ignored it. - I then removed the soft link - At some point after this I realised the collection count was back at the correct number (not sure what amarok did to get this right) - Then I realised that all the music files in ~/Music at the top level (eg ~/Music/item.flac ) were in the collection but were down as having never been played and there were around 300 of these tracks - this the bug So the statistics for these files at the top level of ~/Music have been lost, I've been back into settings and made the tick box for ~/Music fully ticked (it was marked as partially ticked after removing the soft link at step 1) but so far I've not managed to get the statistics for these tracks restored. I was expecting to lose the stats for the tracks pointed to by the soft link but to lose the stats for the files in ~/Music was unexpected. (sorry this is a bit discursive but I hope it's clear!) Reproducible: Always
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)