Bug 262504 - Collection Browser doesn't update properly when metadata are changed sometimes
Summary: Collection Browser doesn't update properly when metadata are changed sometimes
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Collections/Local (show other bugs)
Version: 2.7-git
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: 2.8
Assignee: Amarok Developers
URL:
Keywords:
: 172542 269535 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-01-08 10:50 UTC by Dennis Schridde
Modified: 2013-07-21 23:33 UTC (History)
7 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 Dennis Schridde 2011-01-08 10:50:58 UTC
Version:           2.3.90 (2.4 beta 1) (using KDE 4.5.4) 
OS:                Linux

I edited the metadata of several files (swapped artist and title), now the collectionview shows both versions of the file (the artist=real-artist and the artist=title variant). Updating the collection from the extras menu does not get rid of either variant.

Reproducible: Always
Comment 1 Dennis Schridde 2011-01-08 11:30:55 UTC
All files are Ogg/Vorbis (libogg-1.2.2, libvorbis-1.3.2)
Comment 2 Myriam Schweingruber 2011-01-08 19:04:39 UTC
Sounds like a known caching issue. Did you restart Amarok after the collection rescan?
Comment 3 Myriam Schweingruber 2011-05-04 12:38:24 UTC
Closing for lack of feedback. Feel free to reopen if you can reproduce this with Amarok 2.4.1 or later.
Comment 4 maxime.haselbauer 2012-03-04 10:14:09 UTC
I re-open because I have a similar bug and precision to give:
When I edit followings metadata:
artist name /album name 

in a view where I have 
1st filter : artist name
2nd filter: album name
3rd filter nothing

The changes do not necessary ( in fact rarly appear in real time) Sometime it does but often it does not without that I can isolate a particular reason. 
When it does not, the track just stay as is, but when right click on it and metadata, no metadata editor. It looks like the track is just a ghost anymore. (Similar to what is mentionned by Dennis Schridde)

It is to notice that the change are actually written in the database, and if I change the view in Album/Interpret, then back to Interpre/Album, it seems to give the up to date view of the collection.
You also have the up to date view if you stop and then relaunch amarok

To me it just looks like the view of the collection ist not being updated
Comment 5 maxime.haselbauer 2012-03-04 10:17:29 UTC
Just about the version I am using:
KDE 4.8.0
Amarok 2.5.0
Kubuntu 11.10 (Oneiric 32 bit)
Comment 6 Dennis Schridde 2012-03-04 10:24:34 UTC
Reopening according to comment #4
Comment 7 Martin Droessler 2012-08-31 09:28:01 UTC
I can confirm the behaviour described in comment #4

I'm using: 
Kubuntu 12.04 (64bit)
KDE 4.8.4
Amarok 2.5.0
Comment 8 Mayank Madan 2012-12-01 04:37:08 UTC
Can reproduce in 2.6 - GIT as of today
Comment 9 Mayank Madan 2012-12-19 16:16:27 UTC
I edited the metadata of the tracks but i dont get any duplicate entries.
Using v2.6.90-26-gbcdd84c
Comment 10 Myriam Schweingruber 2012-12-21 11:02:08 UTC
(In reply to comment #9)
> I edited the metadata of the tracks but i dont get any duplicate entries.
> Using v2.6.90-26-gbcdd84c

It actually still happens, this is the old caching problem again, hard to get rid of. There are several bugs reported for that problem with the Collection Browser, hard to reproduce, as it doesn't happen on each try.
Comment 11 Matěj Laitl 2013-05-23 14:11:44 UTC
I have an idea how to fix this, fixing bug 300557 and bug 188074 along the way. Hopefully I'll be able to take a look at it before 2.8.
Comment 12 Myriam Schweingruber 2013-06-18 09:56:52 UTC
*** Bug 172542 has been marked as a duplicate of this bug. ***
Comment 13 Matěj Laitl 2013-06-26 13:53:10 UTC
Git commit d0bd4c4318684b62f8cb7bfef57fd3f180366345 by Matěj Laitl.
Committed on 26/06/2013 at 13:15.
Pushed by laitl into branch 'master'.

[Single]CollectionTreeItemModel[Base]: first look at cleanups/corrections

This is the first part of much-needed revisiting of the Collection Browser
and associated models. The final goal is to get rid of the unfortunate
expanding/scrolling behaviour and of the caching bug. That will involve
more code floating around this commit just brings some fixes,
deduplications and corrections.

This should fix bug 262504, but needs confirmation from folks that were
able to reproduce this bug. Reporters, please reopen if you can reproduce
this with recent git or 2.8 Beta (to be released really soon)
FIXED-IN: 2.8

M  +1    -0    ChangeLog
M  +5    -70   src/browsers/CollectionTreeItemModel.cpp
M  +1    -7    src/browsers/CollectionTreeItemModel.h
M  +126  -111  src/browsers/CollectionTreeItemModelBase.cpp
M  +2    -6    src/browsers/CollectionTreeItemModelBase.h
M  +5    -26   src/browsers/SingleCollectionTreeItemModel.cpp
M  +0    -1    src/browsers/SingleCollectionTreeItemModel.h

http://commits.kde.org/amarok/d0bd4c4318684b62f8cb7bfef57fd3f180366345
Comment 14 Myriam Schweingruber 2013-06-26 14:43:36 UTC
(In reply to comment #13)

> This should fix bug 262504, but needs confirmation from folks that were
> able to reproduce this bug. Reporters, please reopen if you can reproduce
> this with recent git or 2.8 Beta (to be released really soon)

Just tested several times with current git 2.7.0-420: the caching bug is not fixed, still happens here.
Comment 15 Matěj Laitl 2013-06-26 17:43:10 UTC
(In reply to comment #14)
> Just tested several times with current git 2.7.0-420: the caching bug is not
> fixed, still happens here.

Right. Now I know for sure the root is in the Local Collection. Gimme a couple of minutes. ;-)
Comment 16 Matěj Laitl 2013-06-26 17:48:49 UTC
Git commit 82bf0a85f9e71adf06b053589706a1810efd97b4 by Matěj Laitl.
Committed on 26/06/2013 at 17:45.
Pushed by laitl into branch 'master'.

Definitely fix the caching bug (mis-attributed to Collection Browser)

Local Collection wasn't simply emitting updated() enough.

Fix docs when at it to prevent such bugs in future.
FIXED-IN: 2.8

M  +1    -1    ChangeLog
M  +15   -8    src/core-impl/collections/db/DatabaseCollection.h
M  +8    -0    src/core-impl/collections/db/sql/SqlRegistry.cpp
M  +3    -3    src/core-impl/collections/ipodcollection/IpodCollection.h
M  +1    -0    src/core-impl/collections/mediadevicecollection/MediaDeviceCollection.h
M  +3    -3    src/core-impl/collections/umscollection/UmsCollection.h
M  +25   -9    src/core/collections/Collection.h

http://commits.kde.org/amarok/82bf0a85f9e71adf06b053589706a1810efd97b4
Comment 17 Myriam Schweingruber 2013-07-14 14:04:08 UTC
(In reply to comment #16)
> Git commit 82bf0a85f9e71adf06b053589706a1810efd97b4 by Matěj Laitl.
> Committed on 26/06/2013 at 17:45.
> Pushed by laitl into branch 'master'.
> 
> Definitely fix the caching bug (mis-attributed to Collection Browser)

@Matěj: See bug 322185. Should I reopen this one?
Comment 18 Myriam Schweingruber 2013-07-21 23:33:02 UTC
*** Bug 269535 has been marked as a duplicate of this bug. ***