Bug 214980 - Various artists settings are not stored permanently
Summary: Various artists settings are not stored permanently
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Collections/Local (show other bugs)
Version: 2.3.1-GIT
Platform: Compiled Sources Linux
: NOR major
Target Milestone: 2.4.0
Assignee: Amarok Developers
URL:
Keywords:
: 244472 245310 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-11-17 15:30 UTC by Ray Harrison
Modified: 2011-06-16 16:48 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.4.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ray Harrison 2009-11-17 15:30:19 UTC
The following problem: I mark "Various Artists". This marker is stored only as long until I again "Fully Rescan Collection".

In German: Verschiedene Interpreten fehlen nach Fully Rescan Collection.
Folgendes Problem: Ich markiere Verschiedene Interpreten. Diese Markierung wird nur solange gespeichert bis ich wieder ein Fully Rescan Collection mache.
Comment 1 Myriam Schweingruber 2009-11-17 19:02:22 UTC
Are these gone even after an Amarok restart?
Comment 2 Ray Harrison 2009-11-17 19:34:21 UTC
(In reply to comment #1)
> Are these gone even after an Amarok restart?

No, only when i make a Fully Rescan Collection...
Comment 3 Myriam Schweingruber 2009-11-17 19:52:11 UTC
Sorry, I might have formulated badly:
do these changes disappear permanently when you do a full rescan and then restart Amarok?

There is a known bug with the collection browser view that can be worked around for now with that procedure.
Comment 4 Ray Harrison 2009-11-18 00:09:16 UTC
Yes, the changes disappear permanently! When i mark a album/artist as a "Various Artist" and by the next full rescan no artist under "Various Artist". A restart of Amarok changes nothing.
Comment 5 Myriam Schweingruber 2009-11-18 01:03:40 UTC
OK, thanks for your fast reply.
Comment 6 Jens Westemeier 2010-01-13 10:51:32 UTC
I have the same problem, on 2.2.1 and actual 2.2.2, both from OpenSUSE repositories. If I remove one song permanently, a partial rescan is triggered, which also leads to "forgetting" the "Show under Various Artists" flag.
Comment 7 Myriam Schweingruber 2010-01-13 14:25:39 UTC
Changing to confirmed.
Comment 8 Basti 2010-03-01 11:46:32 UTC
I can confirm Jens Westemeier’s reported behaviour of Amarok. Really annoying if you try to clean up your library.
Comment 9 Jens Westemeier 2010-03-28 13:27:11 UTC
The problem is still existing in 2.3.0. I have some directories with hundreds of songs, which all shows up in the regular album list after a re-scan was done due to some editing. Moving all of them back under "Various Artists" is very annoying - multiple selection for "Move to Various Artists" is not existing. You have to move the songs one by one!
Comment 10 Daniel S. 2010-05-01 19:28:43 UTC
(In reply to comment #9)
> multiple selection for "Move to Various Artists" is not existing.
> You have to move the songs one by one!

Yes, it exists – in the Cover Manager you can select multiple albums. It’s not perfect, but works.
But still an annoying bug.
Comment 11 Myriam Schweingruber 2010-07-13 11:41:09 UTC
*** Bug 244472 has been marked as a duplicate of this bug. ***
Comment 12 Jeff Mitchell 2010-07-13 15:01:33 UTC
Hi,

I just want you to know that is a problem that is slowly being worked on. The issue is that when you do a full rescan the information for all of the albums and artists is lost (purposefully), as opposed to an incremental scan. So there's nothing to correlate in various artists. This is a difficult problem for most all media players.

As a preview of how this should be able to be fixed, I've been working for a long while on the Free Music Player Specifications, a standardized method of storing certain metadata in files. (You can see a near-complete version here: http://gitorious.org/xdg-specs/xdg-specs/blobs/master/specifications/FMPSpecs/specification.txt )

Near the bottom you'll see the Compilation Identifier. That is intended to solve this problem.

What should end up happening is that when you mark an album as Various Artists, it sets a compilation identifier. When the tracks are then next scanned, the matching compilation identifier will allow Amarok to automatically figure out that those tracks are part of the same Various Artists compilation. In fact, the benefit of the approach in there is that you could build up a compilation from its pieces by having the tracks share compilation identifiers, so if you have some tracks from a compilation, and then finally acquire the missing tracks, you can easily correlate the two.

I really thank you for your continued patience.
Comment 13 Jens Westemeier 2010-07-14 18:39:56 UTC
Hi Jeff,

thanks for working on that issue with continued patience. I was not aware 
about such a fundamental problem, since I have the impression, that there was 
a solution in Amarok 1.4 (but I might be wrong since the scan was not working 
the way as in 2.x).
As far as I understood, you are extending the meta information to enable 
compilations. How is assured interoperability with other players? Are there 
some Amarok specific fields, or might these fields be overwritten by other 
applications?
Do you have any idea about timelines, when this might be available in an 
Amarok release?

Thanks again for your work.

Greetings, Jens.


Am Dienstag, 13. Juli 2010, 15:01:36 schrieb Jeff Mitchell:
> https://bugs.kde.org/show_bug.cgi?id=214980
> 
> 
> 
> 
> 
> --- Comment #12 from Jeff Mitchell <mitchell kde org>  2010-07-13 15:01:33
> --- Hi,
> 
> I just want you to know that is a problem that is slowly being worked on.
> The issue is that when you do a full rescan the information for all of the
> albums and artists is lost (purposefully), as opposed to an incremental
> scan. So there's nothing to correlate in various artists. This is a
> difficult problem for most all media players.
> 
> As a preview of how this should be able to be fixed, I've been working for
> a long while on the Free Music Player Specifications, a standardized
> method of storing certain metadata in files. (You can see a near-complete
> version here:
> http://gitorious.org/xdg-specs/xdg-specs/blobs/master/specifications/FMPSp
> ecs/specification.txt )
> 
> Near the bottom you'll see the Compilation Identifier. That is intended to
> solve this problem.
> 
> What should end up happening is that when you mark an album as Various
> Artists, it sets a compilation identifier. When the tracks are then next
> scanned, the matching compilation identifier will allow Amarok to
> automatically figure out that those tracks are part of the same Various
> Artists compilation. In fact, the benefit of the approach in there is that
> you could build up a compilation from its pieces by having the tracks
> share compilation identifiers, so if you have some tracks from a
> compilation, and then finally acquire the missing tracks, you can easily
> correlate the two.
> 
> I really thank you for your continued patience.
Comment 14 Jeff Mitchell 2010-07-14 21:45:35 UTC
(In reply to comment #13)
> Hi Jeff,
> 
> thanks for working on that issue with continued patience. I was not aware 
> about such a fundamental problem, since I have the impression, that there was 
> a solution in Amarok 1.4 (but I might be wrong since the scan was not working 
> the way as in 2.x).

Both 1.4 and 2.0 have had various heuristics to automatically detect Various Artists that are performed when scanning. They're far from foolproof, which is why you may have to mark items as Various Artists yourself.

> As far as I understood, you are extending the meta information to enable 
> compilations. How is assured interoperability with other players?

That's the point of an open specification. But, specifically: discussion of the spec has been on the XDG list; it's hosted in the xdg-specs repo on Gitorious and will soon be moving to the same repo on freedesktop.org; the specification will be hosted on freedesktop.org; and most importantly, several other media players (including Banshee, Quod Libet, and VLC) have promised to support the specification when complete. Whether or not they follow through, they have pledged their support in the past.

> Are there 
> some Amarok specific fields, or might these fields be overwritten by other 
> applications?

That depends on which part of the spec, so I encourage you to take a look.

> Do you have any idea about timelines, when this might be available in an 
> Amarok release?

I hope version 1.0 of the spec will be released RSN; as for how long it takes to get that support in Amarok, I'm not sure yet. Note that because these are in file tags, you will have to actually mark items as belong to some compilation or another -- either in Amarok or via a helper program -- in order for those tags to get in the files.

Thanks,
Jeff
Comment 15 Myriam Schweingruber 2010-07-21 18:35:39 UTC
*** Bug 245310 has been marked as a duplicate of this bug. ***
Comment 16 Patrick 2010-11-27 04:49:58 UTC
(In reply to comment #12)
> I just want you to know that is a problem that is slowly being worked on. The
> issue is that when you do a full rescan the information for all of the albums
> and artists is lost (purposefully), as opposed to an incremental scan. So
> there's nothing to correlate in various artists. This is a difficult problem
> for most all media players.

That's very interesting, and good to know. Hope this spec (in its completeness!) will become a 'standard' soon, and get implemented in Amarok. It would probably render the 'collection' (as it is now, stored in a MySQL database) a simple cache for the metadata, which is completely stored in the audio files, and that's actually the way it should be :)
Comment 17 Ralf Engels 2011-02-23 01:14:18 UTC
Fixed in 2.4 with the new collection scanner.

We are using the compilation tag that itunes is using too.
Comment 18 Jeff Mitchell 2011-02-23 15:08:07 UTC
Why aren't you using the FMPS spec?
Comment 19 Myriam Schweingruber 2011-02-25 10:20:28 UTC
Why is using a different specification a reason to reopen this bug if it works? Please take this discussion out of the bug tracker into amarok-devel@kde.org, where it belongs.
Comment 20 Jeff Mitchell 2011-02-25 17:41:27 UTC
If you were to actually look at the thread, you would see that the proposed fix was to use the FMPS spec, which both Jens and Patrick commented on as being a good idea. Hence the "resolution" of this bug as proposed was to use that spec.

When it was closed by Ralf he said it's using a different method than what the bug thread said was going to be used. It makes total sense to ask why a different method is being used than what the bug reporters were told was going to be used, as it means that the bug may or may not be fixed in the eyes of the reporters.
Comment 21 Jeff Mitchell 2011-02-25 17:42:42 UTC
What's more, since Ralf didn't resolve it according to what was told to the reporters, and since he told me personally that he was integrating the full FMPS spec, the better question is: why didn't *Ralf* bring his proposed change to amarok-devel@kde.org?
Comment 22 Myriam Schweingruber 2011-06-04 11:47:56 UTC
This is an automated message from the triager:

Amarok 2.4.1 has been released on May 8 already. Could you please upgrade and test if you can still reproduce this bug?

Without feedback within a month we will close this bug as resolved.

Thank you for your understanding.
Comment 23 Myriam Schweingruber 2011-06-16 16:48:51 UTC
Closing as this is fixed since quite some time.