[vlc-devel] Patch/request for comment and testing - constructing the upNp playlist

[Mirsal Ennaime]

Hi Chris,

On Wed, 2013-10-09 at 12:34 +0100, Chris Clayton wrote:
> For a while now, I've wondered why vlc takes so long to build the
> initial playlist for
> UPnP servers. So I added some diagnostic fprintf()s to
> modules/services_discovery/upnp.cpp. The result of this work is the patch below.
> 
> What I found is that immediately after the playlist is built through
> the ->fetchcontents()
> call in MediaServer::parseDeviceDescription(), Callback() is called
> with event_type set to
> UPNP_EVENT_RECEIVED. I don't know, but I suspect that this event is the server's
> response to the call to ->subscribeToContentDirectory() earlier in
> ::ParseDeviceDescription(). Part of the processing for this event is to call
> ->fetchcontents() and this means that the playlist is constructed
> twice before it is
> presented to the user and clickable. In fact, roughly half way through
> the time the user
> has to wait, there is a quick "flicker" of the playlist, which is
> probably caused by the playlist
> being deleted in the second call to fetchcontents() before it is reconstructed.

Indeed, thank you very much for your analysis, I believe it is correct
and that you did a nice job uncovering this bug. However the fix which
you are proposing will probably break support for some media server
devices which do not send update events, see below.

> My patch to overcome the long wait is very simple, it just removes
> the call to ->fetchcontents() from ::ParseDeviceDescription() and
> relies on the UPNP_EVENT_RECEIVED event to construct the playlist.
>
> I've tested the patch against miniDLNA running on
> OpenWrt (hosted on a mini-server on my local LAN, BubbleUPnP running
> on my Samsung Galaxy S3 phone, the media server built into my 
> Panasonic Blu-Ray recorder (model DMR-BW880), and both miniDLNA and
> mediatomb hosted on the (linux)
> laptop that I am testing the patched vlc on.

I think the correct fix is rather to take the event type (and the
ContainerUpdateID properties if applicable) into account instead of
unconditionally fetching the whole smörgåsbord every time an update
event is received.

However, your hack is probably better than nothing in the meantime, so
could you resend your patch properly ?

 * Use git to format your patch and provide authorship information
 * Do not comment lines out, just remove them.
 * Read https://wiki.videolan.org/Sending_Patches/


Cheers,

-- 
mirsal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20131014/c26a357a/attachment.sig>