[GSoC] UPnP progress report week 6/7

[Maximilian Kossick]

Hi Nikhil,

I just had a look at the UpnpQueryMaker on gitorious and noted that it
is always creating new Meta objects instead of returning already
existing ones. This will break several parts of Amarok which rely on
ponter comparison to determine equality of Meta objects.

Please consider using a cache similar to SqlRegistry in SqlCollection.
There is a class PrivateMetaRegistry in meta/support, but I would not
recommend using that. It lacks garbage collection and has, for some
reason, a static instance variable and no locking.

Cheers,
Max

On Sun, Jul 4, 2010 at 7:47 AM, Nikhil Marathe <nsm.nikhil at gmail.com> wrote:
> Hi,
>
> This past few weeks due to some time constraints I haven't done as
> much as I would have liked to.
>
> The slave is quite mature now, and not leaking memory very much at
> all, except a few bytes somewhere 'upstream', but I'm not so much of a
> valgrind expert.
> I have improved search validation and fixed a few bugs.
> - dc:creator and upnp:artist are treated differently, as they should be.
> - some code to do with directory listings has been refactored.
> - ObjectCache is now capable of going from an ID to a human-readable
> directory path by querying the server. This is slow as hell due to the
> way UPnP works and is not recommended to use unless required. The Upnp
> Search() action has an extra option 'resolvePath' if you want
> resolutions to occur.
> - fixed an issue where Search() was never emitting listingDone() in
> certain cases.
>
> I have been patching the fuppes server too to improve its Search() so
> that I get a good test-bed for Amarok.
>
> In Amarok, the CollectionFactory now handles errors instead of blindly
> creating a collection. The track duration is interpreted properly
> according to the UPnP standard format, including fraction handling (
> no precision guarantees though for the fractions. I do not think that
> is mission critical ). This replaces the earlier naive
> QDateTime::fromString().
> refID support has been added in BrowseCollection to prevent duplicate
> entries, although no software server supports refID. This will be
> added to SearchCollection soon.
> possiblyContainsTrack() are now done by both collections.
> trackForUrl() is not yet handled by Search() since I have to code up
> the lazy handling as done by some other Collection using the MetaProxy
> classes.
>
> I now have correct collection tree browsing for the search server, but
> the QueryMaker is in a pretty bad state in terms of handling all the
> filters and so on.
>
> Since I'm at Akademy, I will be fixing this with the help of nhn. I
> also will try to fix some Cagibi bugs with Friedrich Kossebau.
>
> Nikhil
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>