[GSoC] UPnP progress report week 6/7
nsm.nikhil at gmail.com
Sun Jul 4 07:47:02 CEST 2010
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
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
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
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
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.
More information about the Amarok-devel