UPnP integration: progress report, week 4 and 5

[Nikhil Marathe]

Hi all,

( Note: this is partly a note to myself, so it rambles a bit )

Here is what I've been upto:

kioslave
----------
The slave was threaded in the beginning of the last week so that it
continuously monitors the device for updates, and the blocking event
loop was scrapped. All signals/slots in the slave now run in a
thread's event loop in a completely non-blocking manner. Quite a few
attributes were added to the meta-data reported by the slave to allow
the Amarok Collection to work better.

The most important change was iterative browsing. Bart reported that
some devices tend to crash with this. Rather than ask a device for all
the entries at once, they are done in small segments. This makes the
slave more responsive since the device can give results much faster
and we keep emitting them as they come.

All cache management was moved into ObjectCache, error handling was
improved, and most importantly, PersistentAction was introduced. A lot
of UPnP servers have a tendency to fail when actions are invoked too
quickly on them. The persistent action tries upto 3 times with
increasing intervals between the attempts, before it accepts that the
action has truly failed. With this, the collection scan actually
completed for the first time with a folder of ~2200 songs.

This week, I began exploring search options, so the slave can now
report a device's search capabilities and pass on search queries to
the slave. With persistent action and other existing code, basic
search didn't require much extra code at all. In the coming weeks I
expect to:

 - fix a few nitpicks in the slave like update path resolution of
paths not visited before
 - be able to specify the full path for a searched item so that even
if it is located many directories below, clicking on it should take
the user to the right place.
 - run valgrind against the kio code, see if I'm leaking too much memory.\
 - improve search validation.

I also realised a flaw in the slave when multiple devices are
simultaneously browsed, due to the way the KIO system works. Fixing
that will be a not-so-minor task, but the reasons are too big for this
already large mail.


In the Amarok Collection
-------------------------------
the original browsing collection is feature complete, reporting album
art and so on. It has issues with duplicate tracks which are to be
fixed using refId. It is capable of detecting updates to a directory
and *incrementally* updating the collection.

The deal is that when servers support Search(), prefer it since it
takes the load of us. So this week the collection was split. The
factory now queries the capabilities of the server and creates either
a UpnpSearchCollection or a fallback UpnpBrowseCollection. So that is
the state of the collection part. The Search based collection is
currently more of a playing ground while I try to map QueryMaker
queries to the UPnP counterparts.

Regards,
Nikhil