WSR 2013 08
by Keel, Thomas
*dLeyna*
Spent the week extending my Android native-lib-test app to handle multiple
tests, and then tried plugging in everything I could find that looked like
a GLib test -- any program from the Glib source tree that has "test" in its
name, and a main() function.
The Android tester app has a main Activity with a scrolling tty view and a
few buttons. The Settings button takes you to an Activity with a list of
checkboxes for enabling/disabling each test. The Start button runs the
selected tests, and displays progress in the tty view. Meanwhile, any
output written by the native code to stdout or stderr is visible in the log
associated with the emulated device.
Of the 31 native test programs I found, 2 of them fail to compile, 8 of
them fail to link, 8 of them fail at run time, and the remaining 13 passed.
I haven't spent any time at all yet looking into the build failures. At
first glance, the run time problems include failure of mkstemp() and
attempts to fork() which is a no-no in an Android app process. There may be
other problems though.
One tricky thing I ran into is that the test programs often include a
header file that is not built out to the distribution -- a source .h file
that's produced during the config stage and that differs according to the
target architecture. So I have to be careful about keeping a separate copy
of the configured source file for each architecture (x86/arm) and include
the right one when building the Android app.
So now I need to investigate all these failures, and see if I can fix any
of them. I also should try pretty soon to define the Java API that will be
presented to Android apps to get a better feel for the scope of this whole
endeavor.
-- Tom
7 years, 10 months
dLeyna re-organization
by Ludovic Ferrandis
Hi,
Currently, there are two main dLeyna repositories, renderer-service-upnp
and media-service-upnp, both of which contain d-Bus services for
discovering and manipulating DLNA devices. Unfortunately, the current
organization of the code is far from ideal and it's also an obstacle to
the evolution of our components.
1. The names of the repositories and services are meaningless and
cumbersome. They are derived from a long abandoned architecture and
do not appear to be connected with dLeyna.
2. There is a lot of code duplication between the two services.
3. The services are bound to d-Bus and we would like to support other
forms of IPC.
For these reasons we are planning to split the two existing dleyna
services into a number of new repositories.
Essentially, we plan to extract the common code from these two services
and place them in two separate repositories, dleyna-core for the common
code such as the logging, task handling, settings management etc, and
dleyna-conn-dbus for the d-bus code. Most of the remaining code in
media-service-upnp and renderer-service-upnp will be moved to two new
repositories, dleyna-renderer and dleyna-server. dleyna-renderer and
dleyna-server will actually be libraries. A small amount of code is
needed to create services out of them. This code for linux will be
stored in a fifth project, dleyna-linux. dleyna-linux will build the
d-Bus services but note that the names of these services will have
changed along with the project.
So to summarise, we are proposing to split the existing dLeyna code into
the following repositories:
* dleyna-core
* dleyna-renderer
* dleyna-server
* dleyna-conn-dbus
* dleyna-linux
All open issues in media-service-upnp and renderer-service-upnp will be
moved to the appropriate new repository. The old repositories will
still be available but they will no longer be updated.
In the future if we add a support for a new form of IPC, we will create
a new repository, e.g., dleyna-conn-websocket. If we support a new
class of DLNA or UPnP device we will also add a new project, e.g.,
dleyna-printer.
Finally, we will move the dleyna demo app, media-service-demo to a new
repository, called dleyna-control.
Does anybody see any problems or objections with this approach?
Regards,
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
7 years, 11 months
Feature "Content synchronization" test report (02/12/2013)
by Prigent, Christophe
Feature "Content synchronization" test report for dLeyna (02/12/2013)
Objective
The test is focused on "Content synchronization" functionalities.
All test cases are executed manually.
Quality summary
Some properties are not incremented as described in UPnP standards, not impeding to synchronize information.
We found it is not possible to update the display name of a media content when its title is "hard coded".
Regarding results "Content synchronization" works well.
Setup
* gssdp: 3a45f61
* gupnp: 21fccb6
* gupnp-av: bcb1e53
* gupnp-dlna: fed5da3
* media-service-demo: f4440e1
* media-service-upnp: 7a0b804
* Rygel 0.17.7.37-8f125b: 8f125be
Results
Passed
83%
Failed
10%
Blocked
7%
Run rate
100%
Bug status
New bugs:
#181<https://github.com/01org/media-service-upnp/issues/181> Some content's display name can't be changed
#182<https://github.com/01org/media-service-upnp/issues/182> updateCount property is not incremented when the content has changed
#693577<https://bugzilla.gnome.org/show_bug.cgi?id=693577> ObjectUpdateID and ContainerUpdateID are not incremented when adding a media in a container
Closed bugs:
None
Details
Results are shared via QA Reports:
http://otc-qa-reports.fr.intel.com/Upstream/Laptop/dLeyna/Laptop/708
Name
Result
Comment
Launch Download Synchronization Controller
PASS
Add a server to the tracked list
PASS
Start synchronization
PASS
Remove a server from the tracked list
PASS
List the tracked servers
PASS
Remove local contents and meta data for all the tracked servers
PASS
Remove all the tracked servers and sync again
PASS
Remove one A/V, audio, picture content and sync
PASS
Rename one A/V, audio, picture content and sync
PASS
Add one A/V, audio, picture content and sync
PASS
Check the LastChange request when deleting an object
PASS
Check the LastChange request when adding an object
PASS
Check the LastChange request when updating an object
PASS
Check the LastChange request when creating a new subfolder
PASS
Rename one A/V content shared by Rygel
FAIL
https://github.com/01org/media-service-upnp/issues/181
Rename one audio content shared by Rygel
PASS
Rename one picture content shared by Rygel
PASS
Delete one A/V content shared by Rygel
PASS
Delete one audio content shared by Rygel
PASS
Delete one picture content shared by Rygel
PASS
Add one A/V content shared by Rygel
PASS
Add one audio content shared by Rygel
PASS
Add one picture content shared by Rygel
PASS
Check totalDeletedChildCount is incremenented when deleting an A/V content
PASS
Check totalDeletedChildCount is incremenented when deleting an audio content
PASS
Check totalDeletedChildCount is incremenented when deleting a picture content
PASS
Check values of SystemUpdateID, ObjectUpdateID, ContainerUpdateID when adding a media content
FAIL
https://bugzilla.gnome.org/show_bug.cgi?id=693577
Check values of SystemUpdateID, ObjectUpdateID, ContainerUpdateID when deleting a media content
BLOCKED
https://bugzilla.gnome.org/show_bug.cgi?id=693577
Check values of SystemUpdateID, ObjectUpdateID, ContainerUpdateID when renaming a media content
BLOCKED
https://bugzilla.gnome.org/show_bug.cgi?id=693577
Modify an image resolution and check updateCount is incremented
FAIL
https://github.com/01org/media-service-upnp/issues/182
---------------------------------------------------------------------
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-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