Amarok 1.4 collection and artwork importing

[Pedro de Carvalho Gomes]

I've understood that metadata from A1 isn't useful to import my
collection to A2. But that's not my point. The fact is that, if I use
the importation tool and my collection is empty (i.e. using A2 for the
first time), it still populates my A2 collection with files from the
SQL query that have a valid URL, which are just a subset from my A1
collection. For example, check this log when then importation tool
tries to import a song from A1 collection.

amarok:    [CUEFILE]:  "/dados/mp3/B/Badfinger/Day After Day.cue"  -
Shoot blindly and missed, searching for other cue files.
amarok:    [CUEFILE]: - Didn't find any matching cue file.
amarok:    possible encoding:  "UTF-8"
amarok:    encoding decoded as UTF-8
amarok:    "Read metadata from file for: Day After Day"
amarok:    185  found track by URL:  "/dados/mp3/B/Badfinger/Day After Day.mp3"
amarok:    185  inserting track:
KUrl("file:///dados/mp3/B/Badfinger/Day After Day.mp3")
amarok:    not a track no match

The line below finds a file in the collection that wasn't there
(remember that A2 db was empty):

Line 182: Meta::TrackPtr track =
CollectionManager::instance()->trackForUrl( KUrl( url ) );

This file will be added to the A2 Local Collection when the method
reaches the line below:

Line 318: location->insertTracks( tracksForInsert );

The consequence is that only a subset of the files from my A1
collection would be imported to the A2 collection. Together with the
"Import Collection" mistake, that's why I first though it would be a
bug and have suggested to change the SQL query, so that I could import
my entire A1 collection.

Pedro

On Wed, Oct 28, 2009 at 9:49 PM, Jeff Mitchell <mitchell at kde.org> wrote:
> Jeff Mitchell wrote:
>> Pedro de Carvalho Gomes wrote:
>>> I don't really agree with the use of the collection import for
>>> statistics only. I can enumerate some reasons:
>>
>> It doesn't matter if you agree with it or not. The schema has changed in
>> many fundamental ways and there is not a good way to map everything 1:1.
>
> By the by. One of the ways it has changed is in the unique identifiers
> used to, err, uniquely identify each track.
>
> To figure out the appropriate A2 identifier each track would need to be
> scanned, since it's based upon contents of the file and the algorithm
> has changed since A1. There is no way to upconvert.
>
> Therefore every file *must* be scanned with the A2 collection scanner
> regardless of whether you've imported every detail of every track or not
> from the A1 database, at which time the scanner can (and should) also
> read fresh details of all the other tags. Therefore there is no point in
> converting all these throwaway details over, no effort will be made to
> convert these, and any patch that implements such behavior will be
> discarded as useless.
>
> QED.
>
> P.S.: You could make a case that whatever dialog is shown when Import
> Collection is selected should detail what will actually be imported, so
> that the user is aware of this.
>
>
>
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>
>