Amarok 1.4 collection and artwork importing

[Pedro de Carvalho Gomes]

Here goes my fix for the "partial population" issue. I've tested it
with my Amarok 1.4 db and it has worked fine. I've made the same
changes for the iTunes importation, but I didn't have a valid database
to test it.

Basically I've fixed the erroneous test to check if
CollectionManager::instance()->trackForUrl( KUrl( url ) ) return zero.
This means that the URL is invalid, not that the URL is about a song
that is not at the collection. Now, to import statistics for a song
the URL must both be valid and the song should be at collection. Also
I've removed the store and insertion of valid URLs with the
CollectionLocation::insertStatistics and
CollectionLocation::insertTracks methods. Such call were present at
both Amarok and iTunes importation code.

Finally, I've seen this code at collection/CollectionLocation.h:
191:        /**
192:         * Inserts a set of TrackPtrs directly into the database
without needing to actuall move any files
193:         * This is a hack required by the DatabaseImporter
194:         */
195:        virtual void insertTracks( const QMap<Meta::TrackPtr,
QString> &trackMap ) { Q_UNUSED( trackMap ); }
196:       virtual void insertStatistics( const QMap<Meta::TrackPtr,
QString> &trackMap ) { Q_UNUSED( trackMap ); }

I guess it would be that case to remove both methods. They are
implemented only at
collection/sqlcollection/SqlCollectionLocation.cpp. But I'm not 100%
confident, because both methods are called only once, at
SqlCollectionLocation::slotJobFinished( KJob *job ).

I'd appreciate any comments on this.

Pedro
On Thu, Oct 29, 2009 at 7:26 PM, Jeff Mitchell <mitchell at kde.org> wrote:
> Pedro de Carvalho Gomes wrote:
>> One way to do this it to import the [Collection Folders] section from
>> A1's ~/.kde/share/config/amarokrc.
>
> It would be a nice thing to add the ability to the importer to import
> the collection folders from a given 1.4 amarokrc. Note that you can't
> rely on ~/.kde vs. ~/.kde4 as it's distribution-dependent, so you'd need
> to have the user specify the location of their 1.4 amarokrc. (Although
> this won't achieve your original objective, it will at least make it
> nicer for the 1.4->2.2 user to get started.)
>
> If you do this, take a look at what the code from the settings dialog
> does when you select directories, and imitate that behavior.
>
>> But I agree that it would take some
>> work. I wasn't suggesting you to implement it. All I've asked was what
>> would the be the consequences. Thank you for the opinion, I'll sure
>> take into account when I decide if I am going to implement it or not.
>
> Please keep in mind what I've said before: that if you attempt to modify
> the import behavior to remove the need for scanning the files, your
> patch is likely to be rejected. There are other things that go on during
> scanning besides just populating the database, and most of these have
> changed their behavior in A2, and need a rescan to get things sane
> again. Things like compilation/various artists detection, file tracking
> updates, and so on.
>
> It's not really a worthwhile goal, especially since rescanning is
> something that will have to be done periodically anyways (for instance,
> the upcoming 2.2.1 will require a full rescan upon first startup). It's
> not that we want to force the user to do full rescans over and over, but
> sometimes it's necessary -- for instance, when the db schema changes in
> a major way. If we sometimes find it necessary to force full rescans on
> even minor updates, I don't see why anyone should have a serious problem
> with it when there is a major update.
>
> Better to just change the text to not claim to import tracks, fix the
> importer to not try to (incorrectly) import tracks, and be done with it.
>
> --Jeff
>
>
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_database_import_files_from_Amarok14_iTunes.diff
Type: application/octet-stream
Size: 4046 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20091030/360afca7/attachment.obj>