When I remove any files, Amarok does detect that these have been deleted (in playlist), but collection browser still shows them. It does not happen if a file gets renamed (eg. after completing download and renaming it to final filename). Reproducible: Always Steps to Reproduce: 1. Put some files into collection's folder 2. Wait for the track to appear in collection browser 3. Delete file from disk Actual Results: The track is still shown in collection browser Expected Results: The track should be gone from collection browser
I suspect the AFT to cause that, as the track is still in Trash and has been followed there.
Which Trash do you mean? I'm not aware of any Trash (when deleting files I always do shift+delete) :)
Well, the trash the files go to if you use the right-click option "Move Tracks to Trash" :) But if you did Shift+Del then indeed those should not show up anymore, so again a caching problem of the Collection Browser, likely the same as already reported.
(In reply to comment #0) > When I remove any files, Amarok does detect that these have been deleted (in > playlist), but collection browser still shows them. What if you hit Tools -> Update Collection? What if you hit Rescan Collection in Amarok config. You say use use git, please post exact commit you're at. (output of `git describe`)
*** Bug 311234 has been marked as a duplicate of this bug. ***
Confirmed by duplicate.
Thanks for pointing me to this bug report. To follow up, update, and rescan doesn't help
I tried to reproduce it once, but then it worked OK. So "Reproducible" should be "sometimes", not "always". I'll also try update/rescan when I see this again.
(In reply to comment #8) > I tried to reproduce it once, but then it worked OK. So "Reproducible" > should be "sometimes", not "always". > I'll also try update/rescan when I see this again. After updating to Amarok 2.6, it may be needed to perform Full Rescan of the collection so that it "sanitizes" the database with fixes that went to it. Waiting on info whether this could be reproduces after full rescan.
Still waiting for feedback...
Well, haven't seen it any more. If I see it again, I'll reopen the bug.
I can confirm that for 2.7, please reopen.
(In reply to comment #12) > I can confirm that for 2.7, please reopen. Since you are not the original reporter, please provide exact and detailed steps to reproduce this with Amarok 2.7. Does it happen every time you try? Are you aware of the "Watch Folders for Changes" Amarok config option?
(In reply to comment #13) > (In reply to comment #12) > > I can confirm that for 2.7, please reopen. > Since you are not the original reporter, please provide exact and detailed > steps to reproduce this with Amarok 2.7. It is hard to provide exact steps to reproduce. I just had some files in my collection, removed them in Dolphin but they stayed visible in the collection browser despite multiple restarts and full rescans. I don't know if that matters, but those removed files had # in their name. > Does it happen every time you try? This is the first time I encountered this issue. > Are you aware of the "Watch Folders for Changes" Amarok config option? Yes, it's enabled.
I just experienced it again. 1) I had some new folders in my collection 2) I set collection's filter to "added:<1w playcount:0" 3) I listened to 3 tracks of one of these these new folders 4) I deleted one folder 5) I'm used to the behavior that filter is not refreshed on-line (that's another bug and another story), so I cleared the filter 6) Tracks of the deleted folder still remain in collection, but only those that I did not play (the 1st 3 are gone) Amarok is at version 2.7.0 at the moment.
(In reply to comment #15) > I just experienced it again. > 1) I had some new folders in my collection > 2) I set collection's filter to "added:<1w playcount:0" Perhaps this bug doesn't depend on you using the collection filer at all? (when you clear it right away in step 5) > 3) I listened to 3 tracks of one of these these new folders > 4) I deleted one folder > 5) I'm used to the behavior that filter is not refreshed on-line (that's > another bug and another story), so I cleared the filter > 6) Tracks of the deleted folder still remain in collection, but only those > that I did not play (the 1st 3 are gone) After you restart Amarok, do the deleted files go away? Anything else makes these go away w/out restarting Amarok? Perhaps making another search, or plugging in a USB Stick that shows as another collection?
I now hit this again. Did not help: - making another search/filter - restarting Amarok Did help: - updating collection
(In reply to comment #17) > I now hit this again. > > Did not help: > - making another search/filter > - restarting Amarok > > Did help: > - updating collection Sounds like the longstanding caching issue of the Collection Browser...
I think it is rather a bug in SqlCollection handling of "blocking updated() signal". IpodCollection seems to do it right and using a simpler algorithm, so I might as well pick it up from IpodCollection to SqlCollection.
As Myriam said, this may as well be the famous caching bug with Collection View, i.e. bug 262504. There is an easy test for it: if you see collection browser not being consistent with your expectation, clear the playlist and drag the whole collection to the playlist. Study the tracks in the playlist - are they correctly updated? Removed files removed and added files added? If a) yes (when dragged to playlist, the files look up-to-date) -> then this is a definitely another symptom of bug 262504. b) no, tracks aren't updated even when dragged to playlist -> then this is a bug in particular collections not updating themselves correctly. Someone who can reproduce this bug please perform the test. In case of a), please mark this as a duplicate of bug 262504.
It's b). The deleted track is placed into the play queue, but it's gray. I've found out, that the filename of not-removed tracks starts with #, you may try to reproduce with such files. Workaround: uncheck the folder with such files in settings. Chceck it again after rescan.
Setting status correctly, not a caching issue
Git commit ca88c8d303a7cda56f3890237d4a1adced736215 by Matěj Laitl. Committed on 02/07/2013 at 10:32. Pushed by laitl into branch 'master'. ScanResultProcessors: handle whole directories being removed in PartialUpdateScan This gets a bit complicated, but hopefully the code is commented enough that is it actually understandable by someone else than me. BUGFIXES: * When you remove whole directories from the Local Collection and have Watch Folders for Changes enabled, the tracks now disappear from Collection Browser. FIXED-IN: 2.8 M +2 -0 ChangeLog M +3 -3 src/core-impl/collections/db/sql/SqlRegistry.cpp M +72 -3 src/core-impl/collections/db/sql/SqlScanResultProcessor.cpp M +24 -5 src/core-impl/collections/db/sql/SqlScanResultProcessor.h M +3 -4 src/scanner/AbstractScanResultProcessor.cpp M +12 -2 src/scanner/AbstractScanResultProcessor.h http://commits.kde.org/amarok/ca88c8d303a7cda56f3890237d4a1adced736215