[vlc-devel] [vlc-commits] UPNP: Add Austin's comment on how to really fix the "duplicating" bug

[Pierre d'Herbemont]

On Tue, Apr 19, 2011 at 3:18 PM, Konstantin Pavlov <git at videolan.org> wrote:
> vlc | branch: master | Konstantin Pavlov <thresh at videolan.org> | Tue Apr 19 16:59:01 2011 +0400| [506a4fc4cc516d1462d2e829f113d4be27cd93c1] | committer: Konstantin Pavlov
>
> UPNP: Add Austin's comment on how to really fix the "duplicating" bug
>
>> http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=506a4fc4cc516d1462d2e829f113d4be27cd93c1
> ---
>
>  modules/services_discovery/upnp.cpp |   33 +++++++++++++++++++++++++++++++++
>  1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/modules/services_discovery/upnp.cpp b/modules/services_discovery/upnp.cpp
> index 9b79d6c..2ade5be 100644
> --- a/modules/services_discovery/upnp.cpp
> +++ b/modules/services_discovery/upnp.cpp
> @@ -776,6 +776,39 @@ bool MediaServer::_fetchContents( Container* p_parent )
>     return true;
>  }
>
> +// TODO: Create a permanent fix for the item duplication bug. The current fix
> +// is essentially only a small hack. Although it fixes the problem, it introduces
> +// annoying cosmetic issues with the playlist. For example, when the UPnP Server
> +// rebroadcasts it's directory structure, the VLC Client deletes the old directory
> +// structure, causing the user to go back to the root node of the directory. The
> +// directory is then rebuilt, and the user is forced to traverse through the directory
> +// to find the item they were looking for. Some servers may not push the directory
> +// structure too often, but we cannot rely on this fix.
> +//
> +// I have thought up another fix, but this would require certain features to
> +// be present within the VLC services discovery. Currently, services_discovery_AddItem
> +// does not allow the programmer to nest items. It only allows a "2 deep" scope.
> +// An example of the limitation is below:
> +//
> +// Root Directory
> +// + Item 1
> +// + Item 2
> +//
> +// services_discovery_AddItem will not let the programmer specify a child-node to
> +// insert items into, so we would not be able to do the following:
> +//
> +// Root Directory
> +// + Item 1
> +//   + Sub Item 1
> +// + Item 2
> +//   + Sub Item 1 of Item 2
> +//     + Sub-Sub Item 1 of Sub Item 1

That's not exactly right:

You can achieve this with the current API:

(pseudo code)
services_discovery_AddItem(myItem1)
input_item_PostSubItem(myItem1, subItem1)
services_discovery_AddItem(myItem2)
input_item_PostSubItem(myItem2, subItem1ofItem2)
input_item_PostSubItem(subItem1ofItem2, subItem1ofSubItem1)

Pierre.