Nepomuk Collection

Bart Cerneels bart.cerneels at kde.org
Tue Nov 13 09:58:44 UTC 2012


On Fri, Nov 9, 2012 at 4:35 PM, Matěj Laitl <matej at laitl.cz> wrote:
> On 9. 11. 2012 Phalgun Guduthur wrote:
>> Hello all
>
> Hi,
>
>> After a period of inactivity, I want to continue working on the Nepomuk
>> plugin for Amarok and implement a few more features before it is shipped.
>
> Good!
>
>> These are the major problems of the plugin currently -
>>
>>    - The collection takes some time to load  (10s for 2000 tracks). This is
>>    because of the use of MemoryCollection.
>>    To write my own QueryMaker, I need considerable amout of time as I'm
>>    completely clueless about it. Any help on how to go about this would be
>>    great.
>>    Stecchino once mentioned to have a look at UPnP collections
>>    implementation.
>
> Yes, and also the SqlQueryMaker. The idea is to build the SPARQL query in the
> calls like addMatch(), addFilder() etc, and to run it asynchronously in the
> run method. You'll probably need a cache of "live" NepomukMeta entities (a map
> from Nepomuk URIS to Meta::* instances), something like SqlRegistry, although
> hopefully not that complicated.
>
>>    - After a restart of Amarok, the tracks in the playlist view get fetched
>>    from the Local Collection instead of Nepomuk collection. This is because
>>    the Nepomuk collection slow loading of tracks.
>>
>>    Is there a way to delay the fetching of meta data for tracks in the
>>    playlist view until the Nepomuk collection is fully loaded?
>>    The function Playlist::Model::metadataChanged(Meta::TrackPtr) must be
>>    delayed.
>
> Probably not. There are more flaws in our restore-tracks-from-urls code, so it
> maybe needs to be reworked. On the other hand, after you have your own
> QueryMaker, only thing a Nepomuk::Tracks needs to store will be the Nepomuk
> URI, other fields would be fetched using Nepomuk on demand. (perhaps with
> caching?)
>
> Then you can create Nepomuk::Tracks really quickly in trackForUirUrl() and the
> problem goes away.

Some more details: Tracks in the playlist are proxy loaded. This means
the tag values are filled in from data in current.xspf already and at
the same time a job is started looking for the actual track in
collections. If a new collection is added it also attempts to resolve
the track. So if your nepomuk collection starts late, it should still
work.
All this is theoretical architecture though and it's likely bug or
missing implementation break this behaviour, like Matêj mentions.

>
>>    - Implementing Nepomuk::ResourceWatcher, so that tracks when changed by
>>    other applications are reflected immediately in Amarok. This includes
>>    addition of new tracks, deletion, change in metadata etc.
>>    But this needs the code to be ported to Nepomuk2 ( The newer, sleeker
>>    API of Nepomuk ). I'm finding it tough to get Nepomuk2 work on my
>> machine.
>
> Yes, please do the porting ASAP, reportedly it is mainly just a namespace
> change. Connecting Nepomuk::ResourceWatcher to Track::metadataChanged() should
> be trivial.
>
>>    - Write back support - let the user edit meta data of his tracks through
>>    Amarok. Right now the edit fields are all grayed out.
>
> Yep. I suggest you assign this a lower priority than the NepomukQueryMaker
> though. Not strictly needed for Amarok 2.7, where we can label Nepomuk
> collection as "technology preview" if it lacks iportant features.
>
>>    - Support for creating playlists
>
> Nice, again lower priority than QueryMaker IMO, not needed for Amaork 2.7.
>
>>    - Support for storing scores of tracks - needs ontology support which is
>>    a whole different thing.
>
> Score is IMO much less used than rating, first & last play, so low prio from my
> PoV.
>
>> I write this seeking any sort of feedback on the above problems either on
>> how to tackle them or their importance.
>>
>> What do you think is the most important feature that should be implemented
>> before the plugin is shipped?
>
> QueryMaker and related refactor, if you think you can manage it by the end of
> November.
>
> Cheers, high five and good luck,
>         Matěj
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel


More information about the Amarok-devel mailing list