Currently, it only sets bit 0, but we should really set bits 0 to 4, to indicate that we would like to be able to create new child containers and delete and update items, etc.

At the moment I believe you can compile the dLeyna-server-service without this component installed on your system. dLeyna-server-service is unusable without this component but this is not obvious from the documentation. So perhaps for the time being we should add a check for this connector if --enable-lib-only is false or if the connector name is dbus.

Create new components on top of dLeyna-core/server/renderer to access dleyna features through WebSocket API

Setup:

Laptop Dell Latitude E5420:
    Ubuntu 12.04 64 bit
    Intel Core i5 2540M
    4GiB memory
    integrated graphics controller (Intel)
dLeyna and its components:
    gupnp: 21fccb6
    gupnp-av: a48bbd0
    gupnp-dlna: fed5da3
    Rygel 0.17.7.17-d26cc: d26cc76

Pre-conditions:

Rygel and GUPnP AV Control Point are launched on Ubuntu laptop
GoldenDMS is launched
GoldenDMS is provisioned with mandatory audio files

Steps:

On GUPnP AV Control Point, select goldenDMS and Browse Picture folder
Select "B-JPEG_L-20"
Select Rygel as renderer
Select [Play]

Actual result:

Image is rendered all green

Expected result:

Image is rendered without problem

Other Infos:

There are similar problems with all the pictures files. Some of them are partially rendered

Setup:

Laptop Dell Latitude E5420:
    Ubuntu 12.04 64 bit
    Intel Core i5 2540M
    4GiB memory
    integrated graphics controller (Intel)
dLeyna and its components:
    gupnp: 21fccb6
    gupnp-av: a48bbd0
    gupnp-dlna: fed5da3
    Rygel 0.17.7.17-d26cc: d26cc76

Pre-conditions:

Rygel, GUPnP AV Control Point and GoldenDMS are launched on Ubuntu laptop
GoldenDMS is provisioned with mandatory audio files

Steps:

On GUPnP AV Control Point, select goldenDMS and Browse Music folder
Select "B-LCPM-2" (in My Music->Certification only mandatory files->Audio->LPCM)
Select Rygel as renderer
Select [Play]

Actual result:

Audio is heard several seconds and is cut

Expected result:

Audio is played without problem

Other Infos:

There are similar problems with all B-LCPM files except B-LCPM-1

Option with-ua-prefix should be described in README

The problem is well documented on the dLeyna mailing lists (https://lists.01.org/pipermail/dleyna/2013-January/000054.html ) but in summary the current APIs create playlists containing URLs that point to files on a DMS. The problem is that DMSs are not obliged to maintain persistent URLs and typically that cannot do so as they do not control their IP address. Therefore, it's possible, in fact likely, that playlists created with the existing methods, CreatePlaylist and CreatePlaylistInAnyContainer will become useless after the DMS is rebooted.

This methods should be modified to receive a list of URLs as parameters and not DMS object paths. Typically, these URLs will need to point to external content not hosted on a DMS.

Alternatively, we could simply get rid of them.

Source files are becoming too large. We should split files, especially the ones related to protocol, in one file by "function".

Ex: msu/device.c
->device_playlist.c/h
->device_upload.c/h
...
device.c will contain the common/utils funcs.

The dLeyna-server API documentation is missing. It should be probably placed under docs/server/dbus.

This function is always called in a g_idle_add
Check if needed, and move g_idle_add inside the function
If not needed, remove all g_idle_add

Setup:

• gssdp: 4851be5
• gupnp: 361052b
• gupnp-av: 171cfa2
• gupnp-dlna: fed5da3
• media-service-upnp 0.5.0: b043aae
• render-service-upnp 0.3.1: a756e3b
• cloudeebus: 1ed7b8b
• cloud-dleyna: a849976
• Rygel 0.17.8.8-9cc1: 9cc1f96

Pre-conditions:

Launch Rygel, Cloud-dleyna
Use Television Sony Bravia kdl-26ex320 (certified as DMP and DMR)
Both are connected to DLNA network
Rygel DMS shares Video folder containing a mp4

Steps:

DMR: Television Sony Bravia
DMS: Rygel
DMC: Cloud-dleyna

Using the DMC (Cloud-dleyna), select the DMS (Rygel) and browse through the contents of the DMS, select the video
Using the DMC, select the DMR (Sony Bravia)
Select [Play]

Actual result:

Error "Operation failed: Action SetAVTransportURI failed" is displayed.
You can't press [play] button

Expected result:

Video is rendered by Sony Bravia TV

Info:

Reproduced with DMC: GUPnP AV CP
Not reproduced with DMC: Skifta running on Samsung Galaxy tab 2

This issue is linked to intel/dleyna-renderer#25

The property will be used for example by DMC when they will call renderer service OpenURIEx, to fill the metadata parameter.

The com.intel.dLeynaServer.MediaDevice.LastChange return a dict with four entries, listing the object path of the ADDed, DELeted, MODified entries, and of the root container for subtree updates that are now DONE.

The receiver would then need to fetch all the other metadata for each entry, as not even the type is known at this point (ie. container vs. media file).

Adding a new Changed(Added:aa{sv}, Deleted:aa{sv}, Modified:aa{sv}, Done:aa{sv}) signal (with the aa{sv} parameters formatted as the ListChildren() return value) to deprecate the LastChange would make life far easier for clients and provide for better extensibility.

If the amount of data transferred over the bus is of concern it could even return a subset of the properties, eg. DisplayName, Path, Parent, Type, TypeEx, ObjectUpdateID.

gupnp_context_get_host_ip is a deprecated API, used in upnp.c function prv_server_available_cb.

Check other deprecated APIs.

Hi,
I cross compiled the dleyna library, and when I trie to launch the dleyna-server-service on the target I have a Floating point exception immediately. Same with dleyna-renderer-service.

Do you have an idea ?
Thanks,

See issue description here: https://github.com/01org/media-service-upnp/issues/85

--with_connector-name

should be

--with-connector-name

Pre-conditions:

media-service-upnp, renderer-service-upnp, rygel, GUPnP AV Control Point are launched on Ubuntu laptop
Golden DMS is provisioned with mandatory files

Setup:
Laptop Dell Latitude E5420:

• Ubuntu 12.04 64 bit
• Intel Core i5 2540M
• 4GiB memory
• integrated graphics controller (Intel)
  dLeyna and its components:
• gssdp: 9d66868
• gupnp: 5550411
• gupnp-av: 278db7d
• gupnp-dlna: a5c174f
• gupnp-tools: 3e52033
• gupnp-vala: 93008ec
• media-service-demo: f4440e1
• media-service-upnp: 4d29707
• render-service-upnp: 5152517
• cloudeebus: cc94088
• Rygel: 7ed1545a1de8948720e590ab3d6b36b545778f11

Steps:

1. On GUPnP AV Control Point, browse Video->My Videos->Certification Only mandatory conten->Video->WMVHIGH_FULL
2. Select file "O-WVH_F-01_CBR_12M_320_44_2"
3. In Renderer picklist, select Rygel
4. Select [Play]

Actual result:
4. Video is launched. There is no sound

Expected result:
4. Video is played with sound

Note:
Not reproduced if BubbleUPnP is used as the renderer

Path record in server/com.intel.dleyna-server.service.in points to @Prefix@/libexec , although the dleyna-server-service is being installed into @libexecdir@, which causes problem on sytems, which do not use /usr/libexec for installation.

Overview:

Each file exposed by a DLNA server specifies a protocolInfo value, e.g.,

'''
http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC;DLNA.ORG_OP=10;DLNA.ORG_CI=1;DLNA.ORG_FLAGS=01500000000000000000000000000000"
'''

There is lots of information in this protocolInfo. Currently we only expose the DLNA profile via the DLNAProfile property. However, this information is not sufficient if you are writing DMCs. Ideally you want to retrieve the entire protocolInfo string and pass this string to the Renderer. So let's expose this property verbatim. We don't need to split this up as the DMC wants to pass the string to the DMR directly.

This is needed so that clients can populate playlist containers with references to media items that exist elsewhere on the server.

AvTransport/PrepareForConnection could be used in DMP? (Between dleyna-server<->DMS)
if yes, how? what for?

Setup

Description: Ubuntu 12.10
Codename: quantal
Distributor ID: Ubuntu
Release: 12.10

Mozilla Firefox 18.0.2

::: PACKAGES LIST

gssdp-1.0 v0.14.2
gupnp-1.0 v0.20.1
gupnp-av-1.0 v0.12.1
gupnp-dlna-2.0 v0.10.0
dleyna-core-1.0 v0.0.2
dleyna-renderer-1.0 v0.0.2
dleyna-server-1.0 v0.0.2
dleyna-server-service-1.0 v0.0.2
dleyna-renderer-service-1.0 v0.0.2
Cloudeebus version 0.3.0

::: REPOSITORIES

• COMPONENT: gssdp
• REPOSITORY: git://git.gnome.org/
• TAG: HEAD

- COMMIT ID: a39de89d45d957d7531b66c4b7e3ed3b8430415d

• COMPONENT: gupnp
• REPOSITORY: git://git.gnome.org/
• TAG: HEAD

- COMMIT ID: 77c728ea7a5997ef10b469de2ac5d83cd304b02f

• COMPONENT: gupnp-av
• REPOSITORY: git://git.gnome.org/
• TAG: HEAD

- COMMIT ID: 6f3a016df59c5b827a0f2bbd72e4ca6b49674325

• COMPONENT: gupnp-dlna
• REPOSITORY: git://git.gnome.org/
• TAG: HEAD

- COMMIT ID: a245d9498d3f723c364405a292c8e3941fb0ca4d

• COMPONENT: dleyna-core
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: b3cd1f7f0d81adce2e6b9232c42d55bce9b69b9e

• COMPONENT: dleyna-renderer
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: 1fbb7baa1066720fb9782900bf70c0de55e0f944

• COMPONENT: dleyna-server
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: 4c19ed2

• COMPONENT: dleyna-connector-dbus
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: 1fb9213fc5e063f406db3363588a0734b5828178

• COMPONENT: cloud-dleyna
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: ffebb623fdacb95e571684cbac44b7b2acb906c5

• COMPONENT: cloudeebus
• REPOSITORY: git://github.com/01org/
• TAG: HEAD
• COMMIT ID: f855abb982e2f224ea9cf887144c4e7c2c6dd14e

Pre-conditions

•Device Under Test (Cloud-dleyna) and CTT are both connected via WiFi to a router witth DHCP server (see DLNA test setup from TestDocumentation.pdf page 5)
•Launch Cloudeebus and cloud-dleyna
•Launch CTT DLNA

Requirement level is: "Must support"

Steps:

1 Launch test 7.2.5.5,6 DDC UPnP HTTP Support and General Rules: HTTP Version
2 Wait result

Actual result:

2 Test result is WARNING: The HTTP version was not HTTP/1.1

Expected result:

2 Test result is Pass

Setup

Description: Ubuntu 12.10
Codename: quantal
Distributor ID: Ubuntu
Release: 12.10

Mozilla Firefox 18.0.2

PACKAGES LIST

gssdp-1.0 v0.14.2
gupnp-1.0 v0.20.1
gupnp-av-1.0 v0.12.1
gupnp-dlna-2.0 v0.10.0
dleyna-core-1.0 v0.0.2
dleyna-renderer-1.0 v0.0.2
dleyna-server-1.0 v0.0.2
dleyna-server-service-1.0 v0.0.2
dleyna-renderer-service-1.0 v0.0.2
Cloudeebus version 0.3.0

REPOSITORIES

• COMPONENT: gssdp
• REPOSITORY: git://git.gnome.org/
• TAG: HEAD

- COMMIT ID: a39de89d45d957d7531b66c4b7e3ed3b8430415d

• COMPONENT: gupnp
• REPOSITORY: git://git.gnome.org/
• TAG: HEAD

- COMMIT ID: 77c728ea7a5997ef10b469de2ac5d83cd304b02f

• COMPONENT: gupnp-av
• REPOSITORY: git://git.gnome.org/
• TAG: HEAD

- COMMIT ID: 6f3a016df59c5b827a0f2bbd72e4ca6b49674325

• COMPONENT: gupnp-dlna
• REPOSITORY: git://git.gnome.org/
• TAG: HEAD

- COMMIT ID: a245d9498d3f723c364405a292c8e3941fb0ca4d

• COMPONENT: dleyna-core
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: b3cd1f7f0d81adce2e6b9232c42d55bce9b69b9e

• COMPONENT: dleyna-renderer
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: 1fbb7baa1066720fb9782900bf70c0de55e0f944

• COMPONENT: dleyna-server
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: 4c19ed2

• COMPONENT: dleyna-connector-dbus
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: 1fb9213fc5e063f406db3363588a0734b5828178

• COMPONENT: cloud-dleyna
• REPOSITORY: git://github.com/01org/
• TAG: HEAD

- COMMIT ID: ffebb623fdacb95e571684cbac44b7b2acb906c5

• COMPONENT: cloudeebus
• REPOSITORY: git://github.com/01org/
• TAG: HEAD
• COMMIT ID: f855abb982e2f224ea9cf887144c4e7c2c6dd14e

Pre-conditions

•Device Under Test (Cloud-dleyna) and CTT are both connected via WiFi to a router witth DHCP server (see DLNA test setup from TestDocumentation.pdf page 5)
•Device profile is configured with HTTP Options: HTTP 1.1 and ConsistentConnection (both options are necessary to run the test)
•Launch Cloudeebus and cloud-dleyna
•Launch CTT DLNA

Requirement level is: "Must support"

Steps:

1 Launch test 7.2.8.4,6 DDC UPnP Persistent Connections: Non-Pipelining Fallback
2 Wait result

Actual result:

2 Test result is Not Applicable: The DUT did not use persistent connections.

Expected result:

2 Test result is Pass

This happens even if the server does not support tracking changes or the containers themselves are not tracked. For example, all containers exposed by XBMC are reported to have a ContainerUpdateID of 0 by dLeyna. I think this property should simply not exist.

object.container.playlistContainer and object.container.storageFolder classe are converted to 'container' instead of 'playlist' & 'storage'

=> Function dls_props_upnp_class_to_media_spec: In the switch case, test of gUPnPPlaylist & gUPnPStorage should be done before gUPnPContainer as we don't do full string comparaison.

When searching a matching resource url, we should not return the first that match the supported format, but we should return in priority the non transcoded URL, then any matching url.

We should also ensure to return in priority the same base mime type.
An object could have 2 audio URLs and 2 image URLs (cover). If we don't support the audio, we should not return the cover instead.

Support GUPnP introspection in our component

But we need to update the current GUPnP introspection implementation. The current API doesn't allow to cancel the action.

1 - Update GUPnP introspection API
2 - Update our components.

At least this seems to be the case from looking at the code. I haven't actually tried this. The point is that a server can specify the wildcard string '*' for SortCaps and SearchCaps. If this wildcard is specified then the server indicates that it can search or sort on any properties. If I understand the code correctly, dLeyna-server will translate a wildcard UPnP SearchCaps or SortCaps string into an empty array indicating that searching and sorting are not supported, when in fact the inverse is true.

I've never actually seen a server that uses a wildcard in SortCaps or SearchCaps but we should fix this and update our documentation.

libdleyna-server-1.0 is just an implementation and it is not meant for public consumption: I think that shipping a .pc file which should not be used only adds confusion and we should stop to do that. (See intel/dleyna-renderer#108)

The return signature of SearchObjectsEx is (aa{sv}u), the 2nd output parameter being the total count. This count is always 0 when max input parameter is nonzero. Setting a nonzero offset but max to 0 works.

Test log below:

def search_children(server_path):
... bus = dbus.SessionBus()
... container = dbus.Interface(bus.get_object(
... 'com.intel.dleyna-server', server_path),
... 'org.gnome.UPnP.MediaContainer2')
... (objects, count) = container.SearchObjectsEx("DisplayName contains "arthur"", 0, 0, ['DisplayName'], "-DisplayName")
... print 'count:'
... print count
... for item in objects:
... for key, value in item.iteritems():
... print '{0:<30}{1:<30}'.format(key, value)
...
search_children("/com/intel/dLeynaServer/server/0")
count:
15
DisplayName Livret_Famille_Arthur.jpg
DisplayName Arthur.jpg
DisplayName Arthur.jpg
DisplayName arthur_gaspard.jpg
DisplayName arthur_gaspard.jpg
DisplayName Livret_Famille_Arthur.jpg
DisplayName arthur_gaspard.jpg
DisplayName arthur_gaspard.jpg
DisplayName Arthur.jpg
DisplayName Arthur.jpg
DisplayName arthur_gaspard.jpg
DisplayName arthur_gaspard.jpg
DisplayName Livret_Famille_Arthur.jpg
DisplayName Arthur.jpg
DisplayName Arthur.jpg

def search_children(server_path):
... bus = dbus.SessionBus()
... container = dbus.Interface(bus.get_object(
... 'com.intel.dleyna-server', server_path),
... 'org.gnome.UPnP.MediaContainer2')
... (objects, count) = container.SearchObjectsEx("DisplayName contains "arthur"", 4, 5, ['DisplayName'], "-DisplayName")
... print 'count:'
... print count
... for item in objects:
... for key, value in item.iteritems():
... print '{0:<30}{1:<30}'.format(key, value)
...

search_children("/com/intel/dLeynaServer/server/0")
count:
0
DisplayName arthur_gaspard.jpg
DisplayName Livret_Famille_Arthur.jpg
DisplayName arthur_gaspard.jpg
DisplayName arthur_gaspard.jpg
DisplayName Arthur.jpg

def search_children(server_path):
... bus = dbus.SessionBus()
... container = dbus.Interface(bus.get_object(
... 'com.intel.dleyna-server', server_path),
... 'org.gnome.UPnP.MediaContainer2')
... (objects, count) = container.SearchObjectsEx("DisplayName contains "arthur"", 10, 0, ['DisplayName'], "-DisplayName")
... print 'count:'
... print count
... for item in objects:
... for key, value in item.iteritems():
... print '{0:<30}{1:<30}'.format(key, value)
...
search_children("/com/intel/dLeynaServer/server/0")
count:
15
DisplayName arthur_gaspard.jpg
DisplayName arthur_gaspard.jpg
DisplayName Livret_Famille_Arthur.jpg
DisplayName Arthur.jpg
DisplayName Arthur.jpg

It does this by sending a totally invalid response to a UPnP Search query.

POST /photolibrary/contentDirectory/control HTTP/1.1
Host: 192.168.1.134:9080
SOAPAction: "urn:schemas-upnp-org:service:ContentDirectory:1#Search"
Accept-Encoding: gzip
Content-Type: text/xml; charset="utf-8"
User-Agent: dLeyna/0.0.2 GUPnP/0.20.1 DLNADOC/1.50
Connection: Keep-Alive
Content-Length: 672

<?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Search xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1"><RequestedCount>50</RequestedCount><StartingIndex>0</StartingIndex><SortCriteria>-dc:title</SortCriteria><SearchCriteria> ( upnp:class derivedfrom &quot;object.item.imageItem&quot;  or upnp:class derivedfrom &quot;object.item.videoItem&quot;  or upnp:class derivedfrom &quot;object.item.audioItem&quot;  ) and ( @refID exists false )</SearchCriteria><Filter>res,dc:date,upnp:artist</Filter><ContainerID>0</ContainerID></u:Search></s:Body></s:Envelope>HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 249
Cache-Control: max-age=1800
Server: iPhoneOS/6.1.3, UPnP/1.0, MediaConnect/2.0
Content-Type: text/xml; charset="utf-8"
Date: ven., 29 mars 2013 13:11:31 GMT

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:SearchResponse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1"></u:SearchResponse></s:Body></s:Envelope>

Note that it returns success but it doesn't fill in any of the output parameters.

This causes the following crash in dLeyna-server

#0  __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:39
#1  0x00007ffff5e998b7 in gupnp_didl_lite_parser_parse_didl_recursive (parser=0x676ce0, didl=0x0, recursive=0, error=0x7fffffffe100) at gupnp-didl-lite-parser.c:237
#2  0x00007ffff76bfaf7 in prv_search_cb (proxy=0x64cbf0, action=0x8b90d0, user_data=0x68c480) at device.c:2600

The reason that we are crashing is that gupnp returns true when we call gupnp_service_proxy_end_action. We assume that this means that all the output parameters have been correctly filled and so we do not test them. Unfortunately, as they are not filled the result parameter is NULL. dLeyna assumes it is not NULL and merrily deferences it. it's not clear to me where this should be fixed, GUPnP or dLeyna. I'm thinking GUPnP as it knows which output parameters are missing and it can fail the request. dLeyna can detect when string parameters are not initialised but it can't really tell when ints are not correctly initialised.

Basically, I reproduced this by selecting a MediaConnect server that was sharing no media.

Quoting the MediaServer2 Spec:

'Type' tells what kind of object we are dealing with and its value must be 'container' in case of container or either of 'video', 'video.movie', 'audio', 'audio.music' 'music', 'image' or 'image.photo' in case of item.

Navigating by album some mp3 files served by Rygel I noticed that the Type returned by dleyna-server for the object.container.album.musicAlbum containers is album.music: the fact that it does not starts with container makes rather cumbersome to properly handle them since I was just checking for the container prefix, and it seems in violation with the portion of the spec quoted above.

It exposes UPnP types and not MediaServer2Spec types.

Here's an example of the CreateClasses property for a playlist container.

 play.print_props()
{
    "ChildCount": 2, 
    "CreateClasses": [
        [
            "object.item.imageItem", 
            0
        ], 
        [
            "object.item.imageItem.photo", 
            0
        ], 
        [
            "object.item.videoItem", 
            0
        ], 
        [
            "object.item.audioItem", 
            0
        ], 
        [
            "object.item.audioItem.musicTrack", 
            0
        ]
    ], 

The types should be "image", "image.photo", "video", etc.

Currently, the format of the version string is x.y.z and it's provided by the autotools.

We can change the format in debug and/or release to add the commit sha1 on which the component is builded: x.y.z-sha1

We should use the short sha1 format, not the long one.

This is a weird one and it actually causes problems for dLeyna-control.

To Reproduce

1. Start dLeyna control.
2. Select XBMC
3. Select the Browse Tag.

Expected Result

There is no ".." entry as we are in the root directory.

Actual result

The '..' is there. Clicking on it causes an exception.

Analysis:

This seems to be a bug in the implementation of MediaObject2.get_prop. Have a look at this log from mediaconsole.

>>> root = Device("/com/intel/dLeynaServer/server/1")
>>> root.print_props()
{
    "ChildCount": 2, 
    "ContainerUpdateID": 0, 
    "CreateClasses": [], 
    "Creator": "Unknown", 
    "DLNAManaged": {
        "ChangeMeta": 0, 
        "CreateContainer": 0, 
        "Delete": 0, 
        "Upload": 0, 
        "UploadDelete": 0
    }, 
    "DeviceType": "urn:schemas-upnp-org:device:MediaServer:1", 
    "DisplayName": "Root", 
    "FriendlyName": "XBMC (mryan6dev)", 
    "IconURL": "http://192.168.1.143:60639/images/platinum-48x48.png", 
    "Location": "http://192.168.1.143:60639/DeviceDescription.xml", 
    "Manufacturer": "Team XBMC", 
    "ManufacturerUrl": "http://www.xbmc.org/", 
    "ModelDescription": "XBMC Media Center - Media Server", 
    "ModelName": "XBMC Media Center", 
    "ModelNumber": "1.0", 
    "ModelURL": "http://www.xbmc.org/", 
    "ObjectUpdateID": 0, 
    "Parent": "/com/intel/dLeynaServer/server/1", 
    "Path": "/com/intel/dLeynaServer/server/1", 
    "PresentationURL": "http://192.168.1.143:8080/", 
    "Restricted": 1, 
    "SearchCaps": [], 
    "Searchable": 1, 
    "SerialNumber": "", 
    "SortCaps": [], 
    "SystemUpdateID": 0, 
    "TotalDeletedChildCount": 0, 
    "Type": "container", 
    "UDN": "uuid:9b96484f-13b7-f0fe-e492-7aff83c28c51"
}
>>> root.get_prop("Parent")
dbus.String(u'/com/intel/dLeynaServer/server/1/', variant_level=1)
>>> root.get_prop("Path")
dbus.String(u'/com/intel/dLeynaServer/server/1', variant_level=1)

Note that the parent path reported by root.get_prop("Parent") is incorrect. It has a trailing '/'. This '/' is not present when you do a root.print_props. Also, it is only present for XBMC. It is not present for Rygel. I haven't explored why this is the case. The creates problems for dLeyna-control which performs a comparison between Parent and Path to determine whether the user is browsing the root directory.

This bug is described in the old media-service-upnp issues database.

https://github.com/01org/media-service-upnp/issues/183

It has already been fixed in media-service-upnp

https://github.com/01org/media-service-upnp/commit/97351d7963aa2b6bf3f72a1c45f8bae9f195ed7f

The fix needs to be forward ported to dLeyna server.

DMSs are encouraged to include resources in certain types of container, such as albums, that point to a playlist. The playlist contains a list of all the files in the container in the order in which they should be played. Unfortunately, dleyna-server does not expose container resources through a org.gnome.UPnP.MediaContainer2 property. It needs to do this.

The intention here is to initiate a rescan to discover new DMSs on the network or to determine that existing DMSs are no longer available. Strictly speaking this shouldn't be necessary but I guess it's possible that SSDP packets can get lost or not processed and some misbehaving servers don't always send BYE events.

The good news is that as of version 0.14.0, GSSDP has a rescan method so it should be trivial to implement this.

Pre-conditions:

media-service-upnp, renderer-service-upnp, rygel, GUPnP AV Control Point are launched on Ubuntu laptop
GoldenDMS is provisioned with mandatory audio files

Setup:
Laptop Dell Latitude E5420:

• Ubuntu 12.04 64 bit
• Intel Core i5 2540M
• 4GiB memory
• integrated graphics controller (Intel)
  dLeyna and its components:
• gssdp: 9d66868
• gupnp: 5550411
• gupnp-av: 278db7d
• gupnp-dlna: a5c174f
• gupnp-tools: 3e52033
• gupnp-vala: 93008ec
• media-service-demo: f4440e1
• media-service-upnp: 4d29707
• render-service-upnp: 5152517
• cloudeebus: cc94088
• Rygel: 7ed1545a1de8948720e590ab3d6b36b545778f11

Steps:

1. On GUPnP AV Control Point, Browse Video folder
2. Select ''B-MP2PS_N-8'' (in My Videos->Certification only mandatory files->Video->MPEG_PS_NTSC)
3. Select rygel as renderer
4. Select [Play]
5. Select [Stop]
6. Select "B-MP2PS_P-11" (in MPEG_PS_PAL)
7. Select [Play]

Actual result:
4 and 7. Only sound is played

Expected result:
4 and 7. Sound and video are played

Note:
Not reproduced if BubbleUPnP is used as the renderer

The code to add and manage properties is becoming huge and repetitive.

Define and create a static table that will include all information needed to create and manage properties easily. So a customer will be able to customize MSU without changing code or at least as less as possible.

Update code to loop on this table to:

declare properties
return Object/Item/Container/device properties

For instance, we only manage 'context-available' notification.

We rely on 'device-proxy-available' & 'device-proxy-unavailable' to manage devices and the list of context for each devices. It's in this notification we manage

We could make code more simple and more clear by splitting the current in 2 pieces, and probably faster, as we could manage the drop of a context in a single notification, rather than to wait a device-proxy-unavailable notification by device avaible on this context.

This enhancement will probably not introduce too much change in the code. It's seems it's more a reorg of the current code, plus some new code for the new notification context-unavailable.

The code for context-available should remain the same.

The code for context-unavailable should parse all devices to find the one that belong to the context and remove it from the list (device->context). If the list is empty, the device is deleted. If the deviec has subscribed for event notification on that context, try to register on another context. All this code already exists.

The code for device-proxy-available should remain the same.

The code for device-proxy-unavailable should be remain almost the same. Just removing things that belong to context, like re-registering for event notification.

This will also clarify the code in notification. When we will receive device-proxy-unavailable it will be for a server that has shutdown, not because a context has dropped. So we will be able to clear immediately a device.

1. Start dLeyna-server-service with valgrind
2. G_SLICE=always-malloc G_DEBUG=gc-friendly libtool --mode=execute valgrind --num-callers=40 server/dleyna-server-service
3. In another console start mediaconsole
4. Then type

>>> upnp = UPNP()
>>> upnp.servers()
Mark Ryan's media             /com/intel/dLeynaServer/server/0
>>> root = Device("/com/intel/dLeynaServer/server/0")
>>> root.print_props()

Exit python. You will see the following error in valgrind as dLeyna-server-service shuts down.

==15582== Invalid write of size 8
==15582== at 0x50B0835: g_nullify_pointer (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x5EA2081: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5EA3013: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x533CE77: prv_context_delete (device.c:190)
==15582== by 0x5058D41: g_ptr_array_remove_index (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x534EA27: prv_server_unavailable_cb (upnp.c:248)
==15582== by 0x5EA15C3: g_cclosure_marshal_VOID__OBJECTv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5E9E406: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5EB6DF5: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5EB7641: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x62EDA83: gupnp_control_point_resource_unavailable (gupnp-control-point.c:828)
==15582== by 0x5EA0F76: g_cclosure_marshal_VOID__STRINGv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5E9E406: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5EB6DF5: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5EB7641: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x695400C: clear_cache_helper (gssdp-resource-browser.c:1017)
==15582== by 0x5072240: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x69551ED: gssdp_resource_browser_set_active (gssdp-resource-browser.c:1032)
==15582== by 0x62EDEF3: gupnp_control_point_dispose (gupnp-control-point.c:152)
==15582== by 0x5EA3013: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x62ECC5C: on_context_unavailable (gupnp-context-manager.c:107)
==15582== by 0x5EA15C3: g_cclosure_marshal_VOID__OBJECTv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5E9E406: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5EB6DF5: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x5EB7B4F: g_signal_emit_by_name (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x62FC6A5: network_device_free (gupnp-linux-context-manager.c:257)
==15582== by 0x5071FB2: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x5072E30: g_hash_table_remove_all (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x5072E9D: g_hash_table_destroy (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x62FD22B: gupnp_linux_context_manager_dispose (gupnp-linux-context-manager.c:777)
==15582== by 0x5EA3013: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3400.1)
==15582== by 0x534EDCA: dls_upnp_delete (upnp.c:334)
==15582== by 0x533C893: prv_control_point_stop_service (server.c:1158)
==15582== by 0x4E35329: prv_context_quit_cb (main-loop.c:61)
==15582== by 0x5082AB4: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x5082DE7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x50831E1: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x4E355D0: dleyna_main_loop_start (main-loop.c:153)
==15582== by 0x400EAA: main (daemon.c:93)
==15582== Address 0xae1cf50 is 144 bytes inside a block of size 216 free'd
==15582== at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15582== by 0x534D5DB: prv_delete (task.c:122)
==15582== by 0x534E2D2: dls_task_delete (task.c:620)
==15582== by 0x533B97C: prv_delete_task (server.c:650)
==15582== by 0x4E37685: dleyna_task_queue_task_completed (task-processor.c:430)
==15582== by 0x533B60F: prv_async_task_complete (server.c:552)
==15582== by 0x533CBC2: dls_async_task_complete (async.c:75)
==15582== by 0x5082AB4: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x5082DE7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x50831E1: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3400.1)
==15582== by 0x4E355D0: dleyna_main_loop_start (main-loop.c:153)
==15582== by 0x400EAA: main (daemon.c:93)
==15582==

Split the file API.txt. File is too large.

Create a file by interface.

This issue is described in the old media-service-upnp issues database:

https://github.com/01org/media-service-upnp/issues/187

It is fixed in two separate commits

https://github.com/01org/media-service-upnp/commit/0c2e169e82aedf468763b017b62b3c9327cf79aa

and

https://github.com/01org/media-service-upnp/commit/0dbc74a79aa07a8f8c7d32e1d2de6c4d3a0f95bc

The fixes just need to be forward ported.

upstream is for development process.
Create a branch that will tag the code used for certification.

Setup:

• gssdp: 3a45f61ee50a1d30574da48f6b2bbbfb9b6574b6
• gupnp: 21fccb67689e717828c2fba44aa72d63d2321cd0
• gupnp-av: bcb1e53b5239e77cd2333f3ab471cdb95bfc4584
• gupnp-dlna: fed5da3d1b79a2775e0d7ebaa8b03c4f349ee0dd
• media-service-upnp: 7a0b804f6c3573c774262a39b0d4e9a9fecd0b0b
• Rygel 0.17.7.37-8f125b: 8f125bedbfb444e59db81fac76fd400bb13c20b1

Pre-conditions:

• Launch: Rygel, Media Service UPnP, Gimp, media console
• Rygel (DMS) shares one jpg (I used 62.jpg 480x480 px)

Steps:

1 . In media console, print properties of the jpg
2 . Open the jpeg with Gimp, modify the resolution (Right clic, Image->Scale Image) and save it (File->Overwrite).
3 . In media console, print again properties of the jpg
Actual result:

1 . Properties indicate: "UpdateCount": 0, "Width": 480
3 . Properties indicate: "UpdateCount": 0, "Width": 470
Expected result:

3 . updateCount property MUST be incremented by one (“1”)

This issue is described in the old media-service-upnp issues database

https://github.com/01org/media-service-upnp/issues/185

It has already been fixed in media-service-upnp.

https://github.com/01org/media-service-upnp/commit/97351d7963aa2b6bf3f72a1c45f8bae9f195ed7f

The fix just needs to be forward ported.

This will avoid to duplicate the servers in memory when multiple users are logged on system where MSU is running.

Add a new property called TypeEx that behaves as our current Type behaves and then change Type so that it conforms to MediaService2Spec.
This might be better for search queries and would make things simpler for applications. Otherwise applications that want to take advantage of the advanced Type information would need to inspect two properties.