Re-Arch: Rename and split components
by Ferrandis, Ludovic
Discussion open: <https://github.com/01org/media-service-upnp/issues/156>
*Summary:*
We have currently 3 components, MSU, RSU and Media-Service-Deo (MSD)
To optimize code, to make dLeyna more modular and as much as possible techo
independent (like dbus) or easily integrated in other techo (like
websocket) we need to reorganize the source.
In the same time, we are going to rename the components as
media-service-upnp or renderer-service-upnp are not really relevant.
The project should be split in various components described below:
- dleyna-core (The dLeyna common library)
- dleyna-server (Current MSU libray, without dbus)
- dleyna-renderer (Current RSU, without dbus)
- dleyna-dbus-server (dbus dameon that publish the dbus interface and
rely on dleyna-server)
- dleyna-dbus-renderer (dbus dameon that publish the dbus interface and
rely on dleyna-renderer)
- dleyna-demo (We could add various applications in sub-folders, DMP,
DMC).
In near future, see other TODO:
- dleyna-websocket-server
- dleyna-websocket-renderer
We have 2 choices to implement this architecture change.
1 - Create a single *dleyna* repository on github and then each library
will be manged in a sub folder
2 - Create a github repository by library
--
Ludovic Ferrandis
Open Source Technology Center
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
7 years, 11 months
BAT report for dLeyna Drop 2 (01/30/2013)
by Prigent, Christophe
Basic Acceptance Test results report for dLeyna (01/30/2013)
Objective
The objective is to check we can build dLeyna and its components without problem from fresh sources, and give a global quality status by testing key functionalities.
All BAT test cases are executed manually.
Quality summary
Regarding BAT results, all alpha test cases can be executed.
Setup
* gssdp: 3a45f61
* gupnp: 21fccb6
* gupnp-av: a48bbd0
* gupnp-dlna: fed5da3
* gupnp-tools: 5cb391f
* gupnp-vala: 93008ec
* media-service-demo: f4440e1
* media-service-upnp: 7a0b804
* render-service-upnp: 2d986ed
* cloudeebus: be81b3b
* cloud-dleyna: 6a67b30
* Rygel 0.17.7.17-d26cc: d26cc76
* GoldenDMS 3.0.0.37582
Results
Passed
91%
Failed
9%
Blocked
0%
Run rate
100%
Bug status
New bugs:
BUG180<https://github.com/01org/media-service-upnp/issues/180> Green screen when Rygel renders images
Closed bugs:
None
Details
Results are shared via QA Reports:
http://otc-qa-reports.fr.intel.com/Upstream/Laptop/dLeyna/Laptop/662
Name
Result
Comment
Check all components are integrated
PASS
Check all services and components can be launched
PASS
Check the communicating endpoints establish communication
PASS
Check presence of dLeyna in dBus
PASS
Check functioning with Cloud Dleyna
PASS
Check DLNA capabilities and features are retrieved when a new device connects
PASS
Check DMS serves up media
PASS
Check DMP browse content and play the selected media
PASS
Check DMC controls the content selection and content rendering between networked devices
PASS
Check DMR renders content
FAIL
Unable to render images with Rygel as DMR
Check content can be uploaded
PASS
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
7 years, 11 months
Re: [dLeyna] Discovering
by Mark D Ryan
Hi Jens,
On Thu, 2013-01-24 at 17:42 +0100, Jens Georg wrote:
> On Do, 2013-01-24 at 12:52 +0100, Mark D Ryan wrote:
> > Hi Ludo,
> >
> > > 1 - Add a new API to perform a discovery. This will allow a DMP/DMC to refresh the list of devices/services without waiting the 30 min timeout for some cases.
> > >
> >
> > How will you implement this API? I could be wrong here, but I don't
> > think there is a GUPnP API that performs a rescan of the network? I
> > think you would need to destroy and re-create the context manager to
> > implement this. What would happen to outstanding tasks issued by other
> > clients if you did this?
>
> No, there's no API in GUPnP. What I did in Helium is to disable/enable
> the control point but that has the drawback of getting
> device_unavailable signals. [1]
>
I wonder if it would be possible/sensible to add a new method to GSSDP
that allows clients to force a rescan without clearing the cache. This
should prevent the device unavailable signals while allowing new devices
to be discovered. On the downside, it would not clear out old devices
which have disappeared from the network but are still present in the
GSSDP cache, so it wouldn't be a perfect solution. If you think this
might be a sensible thing to do I can enter a bug for this.
Regards,
Mark
7 years, 12 months
Discovering
by Ludovic Ferrandis
Hi,
after some use of our DMC/DMP I found a lack in our API. We cannot refresh the list of servers/renderers.
In the re-arch discussion we also talk about the fact services perform auto discovering at launch and that could be unnecessary.
We can fix all these issues this way:
1 - Add a new API to perform a discovery. This will allow a DMP/DMC to refresh the list of devices/services without waiting the 30 min timeout for some cases.
2 - Add settings for DMS/DMR to enable/disable auto discovering at launch
3 - If auto discovering is disabled, the call to GetServers() call first the new API defined in 1)
Reminder: We are on local networks. So discover is pretty fast.
So in case of single service for DMS/DMR, customers can choose to disable auto discover for one or both services and to perform the discover in their application manually when they want. They now their needs, they can tune it.
In case of general use, like on desktop, I think we can enable the auto discover for both, it won't be a problem. We can even make the service launch at boot time.
Ludo
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
7 years, 12 months
Re: [dLeyna] Re-Arch: Rename and split components
by Mark D Ryan
Hi Ludo,
> So, the questions are:
>
> - Do we want to be able to run multiple connectors on the same device?
Since it's not really clear to me what a connector is going to be yet,
let me say that we definitely want to be able to support more than one
IPC mechanism simultaneously on the same device. On linux this is
likely to be d-Bus and websockets. We will probably want to allow users
to enable and disable IPC mechanisms.
It's not clear to me yet whether we will be able to have a single
generic process for all OSs or whether it would be better to have a
linux specific process in which d-Bus is always available and websockets
can be optionally disabled. I suspect the latter would be the easiest
but this remains to be seen.
> - Do we want a service/server by connector or a single service/server
> that run all connectors?
As far as I can tell we cannot have two separate processes providing DMS
APIs over different IPC mechanisms as this will lead to redundant
network traffic.
> - Do we want a single service for DMS/DMR or 2 separate services?
>
For me, the simplest thing to do, with the least architectural and API
changes is to have one process for the DMS API and one process for the
DMR API, which is what we have today. The only change will be to
modifying the existing processes to support multiple IPC mechanisms. We
will change the APIs, but not for architectural reasons. They will
change merely because we are renaming everything to dleyna-*. These
changes will therefore be cosmetic.
Combining both APIs into one service would require big architectural and
API changes, and I can't really see any benefit in doing this.
Regards,
Mark
7 years, 12 months
Plugfest January 21-24 in Redmond
by Ferrandis, Ludovic
Hi,
we are going to the plugest next week (Christophe Prigent & me).
If you want to come and talk, you're welcome.
--
Ludovic Ferrandis
Open Source Technology Center
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
8 years
error rendererconsole.py
by Rémi Guichard
Hi,
I want compil rendererconsole
Traceback (most recent call last):
File
"/home/rguichar/Téléchargements/renderer-service-upnp/test/rendererconsole.py",
line 23, in <module>
import dbus
ImportError: No module named dbus
i have dbus-python
what is the problem ? or solution?
Thx
Best regards
Rem
8 years
Playlist URI issue with Rygel
by Ferrandis, Ludovic
Hi,
I've more information about URI in PlayList DIDL_S file.
About URI, there is a way to describe an URI without using IP/domain name
information.
There are 2 solutions, DLNA PlayContainer URI and DLNA PlaySingle URI.
Unfortunately, these solutions could not be used for DIDL_S playlist items.
We also thought the main advantage of IP URI is the possibility to create a
playlist with various items, from the server or on the net or on the local
storage.
Wrong, URI shall be from the same media collection.
About the URI format, in the DIDL_S description, it's said we should follow
various Guidelines:
guideline 7.4.1.3.10:
7.4.1.3.10 MM URI Rules
7.4.1.3.10.1
[GUIDELINE] If a content binary conforms to a DLNA media format profile,
then the URI value shall be an absolute URI, with the IP address in the
a.b.c.d IPv4 address format (i.e. quad-form network byte order).
NOTE: This guideline mandates that content URIs will use absolute URIs that
use IP addresses.
7.4.1.3.10.2
[GUIDELINE] URIs shall be properly URI-escaped in a UTF-8 encoded form.
NOTE: This guideline requires UPnP AV endpoints to provide URI values that
are URI-escaped in a UTF-8 encoded form. This guideline also allows a UPnP
AV MediaServer control point to assume that URIs obtained from a UPnP AV
MediaServer do not need any escaping.
-----
So, to resume, with DIDL_S we must provide IP URI.
With DIDL_V, we should provide PlaySingle URI.
We face 2 issues, one with the device, one with Rygel.
If a device is configured without a static IP/Port, when the device is
restarted and Rygel relaunched, we will have a new IP/Port.
All DIDL_S files previously created have now invalid IP URI for the
playlist items.
There is 1 hack that could be implemented in Rygel to fix these issue. As
we know all DIDL_S items reference an object in the media collection of the
DMS, we could replace all IP base address of each item with the new IP/Port.
It's evil. It's a hack. It's the only solution I think about to fix the
problem with DIDL_S file and dynamic IP.
There is a second solution that will be to use DIDL_V instead of DIDL_S
files.
With DIDL_V we could define DLNA PlaySingle URI that are not IP/Port
dependent.
But that imply to have a PlaySingle URI encoder/decoder and to update the
renderer to be able to use DIDL_V/Playsingle URI.
-----
I also found these information:
MM playcontainer-param (DLNA PlayContainer Flag)
7.4.1.3.31.1
[GUIDELINE] The playcontainer-param flag indicates support for a DLNA
PlayContainer URI operation. If the flag is true for a protocolInfo, then
it means that the UPnP AV MediaRenderer can play that type of content in a
DLNA PlayContainer URI operation.
The playcontainer-param flag shall be false when the context of the
protocolInfo involves a media collection binaries (e.g. DIDL_S and DIDL_V
playlist files). Furthermore, when performing a DLNA PlayContainer URI, the
MediaRenderer shall not render media collection binaries when traversing
the CDS hierarchy. Note that this restriction against playing media
collection binaries applies only to media collection binaries defined by
the DLNA guidelines.
So I need to set these flag to false when creating a Playlist.
It's not clear yet if I should set this info for each item, or for the
playlist item.
--
Ludovic Ferrandis
Open Source Technology Center
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
8 years
