MediaConsole
by Mark D Ryan
Hi All,
There is a python file in the test directory of media-service-upnp. It
contains some python classes that make it easy to invoke the various
media-service-upnp methods from python. The primary purpose of these
classes is to provide a crude sort of command line interface for testing
media-service-upnp and for manipulating media servers.
To use, you simply need to download, compile and install
media-service-upnp and then start python. Please find below some examples commands.
First, start python and import mediaconsole
cd test
python
>>> from mediaconsole import *
>>>
Create a manager object
>>> manager = UPNP()
Get a list of DMSs. The second column contains the d-Bus path of
the server.
>>> manager.servers()
XBMC (mryan6dev) /com/intel/MediaServiceUPnP/server/0
MediaTomb /com/intel/MediaServiceUPnP/server/1
My Media /com/intel/MediaServiceUPnP/server/2
Create a Container object for the server "My Media". This Container
object represents the server's root directory.
>>> root = Container("/com/intel/MediaServiceUPnP/server/2")
>>>
Print the root object's properties. Note this object has multiple
interfaces.
>>> root.print_props()
ManufacturerUrl http://live.gnome.org/Rygel
ModelName Rygel
DisplayName My Media
Searchable 1
Parent /com/intel/MediaServiceUPnP/server/2
Type container
SerialNumber 0000001
IconURL http://127.0.0.1:39622/MediaExport-48x48x24.jpg
ModelNumber 0.1
DeviceType urn:schemas-upnp-org:device:MediaServer:2
Location
http://127.0.0.1:39622/f1021319-8d2d-470b-843c-c3656bc26a94.xml
FriendlyName My Media
Path /com/intel/MediaServiceUPnP/server/2
UDN uuid:f1021319-8d2d-470b-843c-c3656bc26a94
ChildCount 4
Manufacturer Rygel Developers.
List the type and name of each child of the root folder.
>>> root.list_children(0,0,["DisplayName","Type"])
Type container
DisplayName Files & Folders
Type container
DisplayName Music
Type container
DisplayName Pictures
Type container
DisplayName Videos
Search the root folder and its sub-folders for images, print the Name,
d-Bus path and URL of each image found. The search is limited to 5
items and the images are sorted by DisplayName in descending order.
>>> root.search('Type derivedfrom "image"', 0, 5, ["DisplayName",
"Path", "URLs"], "-DisplayName")
Total Items: 16
Path /com/intel/MediaServiceUPnP/server/2/3365323432376438363962393431626332393630393731643736393864386136
DisplayName EU.jpg
URLs
dbus.Array([dbus.String(u'http://127.0.0.1:39622/MediaExport/i/M2UyNDI3ZDg2OWI5NDFiYzI5NjA5NzFkNzY5...')], signature=dbus.Signature('s'), variant_level=1)
Path /com/intel/MediaServiceUPnP/server/2/3132643265303865363661666437353438313138396139613166656532636238
DisplayName Eton Mess.jpg
URLs
dbus.Array([dbus.String(u'http://127.0.0.1:39622/MediaExport/i/MTJkMmUwOGU2NmFmZDc1NDgxMTg5YTlhMWZl...')], signature=dbus.Signature('s'), variant_level=1)
Path /com/intel/MediaServiceUPnP/server/2/6465316531663566613033633930633730646631373663666565303335353938
DisplayName Collioure.jpg
URLs
dbus.Array([dbus.String(u'http://127.0.0.1:39622/MediaExport/i/ZGUxZTFmNWZhMDNjOTBjNzBkZjE3NmNmZWUw...')], signature=dbus.Signature('s'), variant_level=1)
Path /com/intel/MediaServiceUPnP/server/2/6661633532656530616266613763646366303263663530626237623439666435
DisplayName Cherry Tree.jpg
URLs
dbus.Array([dbus.String(u'http://127.0.0.1:39622/MediaExport/i/ZmFjNTJlZTBhYmZhN2NkY2YwMmNmNTBiYjdi...')], signature=dbus.Signature('s'), variant_level=1)
Path /com/intel/MediaServiceUPnP/server/2/6138616662396333356264336665656365353436343437353934666530636565
DisplayName Ceidhe Fields.jpg
URLs
dbus.Array([dbus.String(u'http://127.0.0.1:39622/MediaExport/i/YThhZmI5YzM1YmQzZmVlY2U1NDY0NDc1OTRm...')], signature=dbus.Signature('s'), variant_level=1)
Create a MediaObject object for the last image so we can inspect it
further.
>>> item =
MediaObject("/com/intel/MediaServiceUPnP/server/2/6138616662396333356264336665656365353436343437353934666530636565")
>>>
>>> item.print_props()
MIMEType image/jpeg
DisplayName Ceidhe Fields.jpg
Parent /com/intel/MediaServiceUPnP/server/2/3766313934373030326436306666613036326631613838316232376538353139
DLNAProfile JPEG_LRG
Height 1448
Width 2576
URLs
dbus.Array([dbus.String(u'http://127.0.0.1:39622/MediaExport/i/YThhZmI5YzM1YmQzZmVlY2U1NDY0NDc1OTRm...')], signature=dbus.Signature('s'), variant_level=1)
Date 2010-05-18T10:09:40Z
Path /com/intel/MediaServiceUPnP/server/2/6138616662396333356264336665656365353436343437353934666530636565
ColorDepth 0
Type image.photo
Size 792454
Resource 0
MIMEType image/jpeg
URL
http://127.0.0.1:39622/MediaExport/i/YThhZmI5YzM1YmQzZmVlY2U1NDY0NDc1OTRm...
DLNAProfile JPEG_LRG
Height 1448
Width 2576
ColorDepth 0
Size 792454
Resource 1
MIMEType image/png
URL
http://127.0.0.1:39622/MediaExport/i/YThhZmI5YzM1YmQzZmVlY2U1NDY0NDc1OTRm...
DLNAProfile PNG_TN
Height 128
Width 128
ColorDepth 32
Size 15673
Resource 2
MIMEType image/jpeg
URL file:///home/mryan/Pictures/Ceidhe%
20Fields.jpg
DLNAProfile JPEG_LRG
Height 1448
Width 2576
ColorDepth 0
Size 792454
Resource 3
MIMEType image/png
URL
file:///home/mryan/.thumbnails/normal/a8afb9c35bd3feece546447594fe0cee.png
DLNAProfile PNG_TN
Height 128
Width 128
ColorDepth 32
Size 15673
>>>
Regards,
Mark
8 years, 8 months
MediaServer2 spec
by Jens Georg
Hi,
from https://01.org/dleyna/documentation/item-objects I see that you
found an issue with the org.gnome.UPnP.MediaItem2 interface.
How are the semantics of the Resources property? Should you duplicate
the URLs in the item's URLs property, or does Resources only have the
additional meta-data and no URLs?
Just wanted to say that this spec is not set in stone, and especially
adding optional properties "upstream" isn't a problem.
For more deeper issues that can't be solved in a backwards-compatible
way, we can always discuss about version 3 :)
8 years, 8 months
Upload API
by Mark D Ryan
Hi All,
I've been working on an API extension for media-service-upnp that will
allow clients to easily upload files to a DMS. I have a working
implementation on my fork but I thought it might be a good idea to
discuss the API changes here before sending my pull request. The plan
is as follows:
Add four new methods to the com.intel.UPnP.MediaDevice interface.
1) Upload(s DisplayName, s FilePath, o ContainerPath) -> (i TransferID,
o ObjectPath)
This command would initiate the upload of the local file specified by
FilePath to the Container specified by ContainerPath. The file will be
assigned the Friendly Name DisplayName. This method creates a new empty
object on the server and instructs the server to begin to upload the
local file from the client. The Upload method returns as soon as the
server has begun to upload the file and not when the server has finished
uploading the file. Upload returns two output parameters: a TransferID
that can be used to monitor the upload and to cancel it, and ObjectPath
which contains the path of the newly created object.
An example of invoking this function with mediaconsole would be
upnp = UPNP()
upnp.servers()
MediaTomb /com/intel/MediaServiceUPnP/server/0
My Media /com/intel/MediaServiceUPnP/server/1
device = Device("/com/intel/MediaServiceUPnP/server/1")
device.upload("Test", "/home/user/Pictures/Cherry Tree.jpg",
"/com/intel/MediaServiceUPnP/server/1/3766313934373030326436306666613036326631613838316232376538353139")
Transfer ID: 3
Path: /com/intel/MediaServiceUPnP/server/1/6535653665373662663837663938346135633063643761373236623663346239
2) GetTransferStatus(i TransferID) -> (s TransferStatus, i
TransferLength, i TransferTotal)
Retrieves information on the status of an upload operation. TransferID
is the ID returned by a call to Upload. The method returns a
TransferStatus which can be set to 1 of 4 values, "IN_PROGRESS",
"STOPPED", "ERROR", "COMPLETED", and two integers which indicate the
total length of the transfer and the amount of bytes transferred so far.
GetTransferStatus will return valid results for up to 30 seconds after
the transfer has finished.
3) CancelTransfer(i TransferID)
Cancels an ongoing transfer.
4) GetCurrentTransfers() -> (ai)
Returns an array of transfer IDs of the transfers currently in progress.
This is my proposal. I'm wondering whether to provide a notification to
indicate whether the transfer has completed or failed. Currently, I'm
not planning to do this but I'd like to hear your thoughts. My feeling
is that upload clients will need to call GetTransferStatus periodically
to determine how the transfer is progressing, and so will not need this
extra signal.
On the other hand, if we want to implement an upload manager that
monitors all the uploads being made to the server, regardless of their
initiators, we would need some signals.
Alternative Proposal
-----------------------
Also, I did consider an alternative API, where the Upload method is
invoked on the Container object of target folder of the uploaded file.
The return value of Upload would be a newly created d-Bus object
representing the upload. The CancelTransfer method would belong to this
new object and the progress of the transfer would be published in
properties of the transfer object. The GetCurrentTransfers would remain
on the com.intel.UPnP.MediaDevice interface but would return an array of
object paths of the transfer objects rather than an array of transfer
IDs.
This would probably be a cleaner interface, and would do away with the
TransferID variable. However, I decided not to do this as it would be
more work for both the client and media-service-upnp. The clients would
need to create and maintain a new d-Bus object and media-service-upnp
would need to maintain a new virtual tree of d-bus transfer objects.
Also, the lifecyle of the transferObjects would be tricky. Who should
delete them? Should media-service-upnp create transfer objects on start
up to reflect transfers on going on each DMS before media-service-upnp
was started? My feeling is that the initial proposal is the simpler
one, but again, I'd like to get your thoughts on this.
Mark
8 years, 8 months
Making the About page clearer
by Murray Cumming
Hi, I just discovered this project and I'm taking a look.
I'd like to suggest a small edit on the About page?
https://01.org/dleyna/about
Currently it says:
"Media-service-upnp can be used to implement a Digital Media Player or
to implement the DLNA Download System Use Case. "
But that's a little misleading to non-experts (such as me) and DLNA can
be confusing enough already. I suggest this:
"Media-service-upnp can be used to implement the browsing capabilities
of a Digital Media Player, though it does not provide the rendering
capabilities. It can also be used to implement the DLNA Download System
Use Case."
Your other pages make this clear, but it would be nice to avoid the
confusion at the start. I think the media-service-upnp and
renderer-service-upnp names are themselves confusing, but I guess it's
too late to change them.
--
Murray Cumming
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
8 years, 8 months
Announcing the dLeyna Project
by Mark D Ryan
Hi All,
We are pleased to announce the creation of a new open-source project
called “dLeyna”. The “dLeyna” project hosts a number of middle-ware
components designed to make it easy for developers to integrate DLNA
functionality into their applications.
Currently, two components make up the dLeyna project. These are
“Media-service-upnp” and “Renderer-service-upnp”.
Media-service-upnp is a high level media content API that allows client
applications to discover, browse and search UPNP and DLNA media servers.
It is designed to be used by media applications such as Digital Media
Players (DMPs) or Digital Media Controllers (DMCs).
Renderer-service-upnp is a high level media content API that allows
client applications to discover and manipulate UPNP and DLNA media
renderers. It is designed to facilitate the creation of Digital Media
Controllers (DMCs), in conjunction with media-service-upnp, and to
implement the DLNA 2-box push use case.
Both components are d-Bus services implemented on top of the GUPnP
libraries. They provide easy to use, language and toolkit independent
APIs that isolate applications from the complexity of the DLNA and UPnP
specifications and that eliminate redundant network traffic when
multiple DLNA applications are running simultaneously.
We plan to contribute more components and services soon, including
feature enhancements, sample applications and Web API extensions
enabling developers to write HTML5/JS applications with DLNA
capabilities. We are also planning a sustained effort of quality,
robustness and interoperability testing, to ensure that the dLeyna
components can be integrated into real world products with the minimum
of difficulty.
For more information about the dLeyna project please see the dLeyna home
page ( https://01.org/dleyna ).
The dLeyna project encourages and welcomes contributions from the
open-source community. Please see our community page to find out how
you can get involved ( https://01.org/dleyna/community ).
The "dLeyna" project team.
8 years, 8 months
