Bug 311078 - Removed tracks remain visible in the collection browser under some circumstances
Summary: Removed tracks remain visible in the collection browser under some circumstances
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Unclassified
Component: Collection Browser (show other bugs)
Version: 2.7-git
Platform: openSUSE RPMs Linux
: NOR normal with 3 votes (vote)
Target Milestone: 2.8
Assignee: Amarok Developers
URL:
Keywords: regression
: 311234 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-12-03 13:01 UTC by Silver Salonen
Modified: 2013-07-02 11:54 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.8


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Silver Salonen 2012-12-03 13:01:54 UTC
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
Comment 1 Myriam Schweingruber 2012-12-03 13:04:58 UTC
I suspect the AFT to cause that, as the track is still in Trash and has been followed there.
Comment 2 Silver Salonen 2012-12-03 13:07:56 UTC
Which Trash do you mean? I'm not aware of any Trash (when deleting files I always do shift+delete) :)
Comment 3 Myriam Schweingruber 2012-12-03 15:06:49 UTC
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.
Comment 4 Matěj Laitl 2012-12-03 18:50:13 UTC
(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`)
Comment 5 Myriam Schweingruber 2012-12-06 15:52:51 UTC
*** Bug 311234 has been marked as a duplicate of this bug. ***
Comment 6 Myriam Schweingruber 2012-12-06 15:53:16 UTC
Confirmed by duplicate.
Comment 7 EMR_Kde 2012-12-06 15:56:37 UTC
Thanks for pointing me to this bug report. To follow up, update, and rescan doesn't help
Comment 8 Silver Salonen 2012-12-06 19:09:34 UTC
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.
Comment 9 Matěj Laitl 2012-12-06 19:13:21 UTC
(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.
Comment 10 Myriam Schweingruber 2013-01-11 13:13:39 UTC
Still waiting for feedback...
Comment 11 Silver Salonen 2013-01-11 13:16:19 UTC
Well, haven't seen it any more. If I see it again, I'll reopen the bug.
Comment 12 karaluh 2013-01-29 19:50:03 UTC
I can confirm that for 2.7, please reopen.
Comment 13 Matěj Laitl 2013-01-29 19:59:18 UTC
(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?
Comment 14 karaluh 2013-02-01 16:01:38 UTC
(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.
Comment 15 Silver Salonen 2013-02-06 07:39:13 UTC
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.
Comment 16 Matěj Laitl 2013-02-21 00:01:36 UTC
(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?
Comment 17 Silver Salonen 2013-02-25 13:19:08 UTC
I now hit this again.

Did not help:
  - making another search/filter
  - restarting Amarok

Did help:
  - updating collection
Comment 18 Myriam Schweingruber 2013-03-02 11:42:20 UTC
(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...
Comment 19 Matěj Laitl 2013-03-02 11:48:15 UTC
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.
Comment 20 Matěj Laitl 2013-05-23 14:05:18 UTC
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.
Comment 21 karaluh 2013-05-27 16:29:16 UTC
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.
Comment 22 Myriam Schweingruber 2013-06-18 17:12:09 UTC
Setting status correctly, not a caching issue
Comment 23 Matěj Laitl 2013-07-02 11:54:15 UTC
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