Version: 2.3.90 (2.4 beta 1) (using KDE 4.5.4)
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.
All files are Ogg/Vorbis (libogg-1.2.2, libvorbis-1.3.2)
Sounds like a known caching issue. Did you restart Amarok after the collection rescan?
Closing for lack of feedback. Feel free to reopen if you can reproduce this with Amarok 2.4.1 or later.
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
Just about the version I am using:
Kubuntu 11.10 (Oneiric 32 bit)
Reopening according to comment #4
I can confirm the behaviour described in comment #4
Kubuntu 12.04 (64bit)
Can reproduce in 2.6 - GIT as of today
I edited the metadata of the tracks but i dont get any duplicate entries.
(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.
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.
*** Bug 172542 has been marked as a duplicate of this bug. ***
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)
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
(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.
(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. ;-)
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.
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
(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?
*** Bug 269535 has been marked as a duplicate of this bug. ***