8:20 p.m.
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 :)
10:49 p.m.
Hi,
On Wed, 2012-06-20 at 12:20 +0200, Jens Georg wrote:
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?
The way things currently work is that the item's URL property only ever
contains a single URL. By default this is the first URL returned by the
DMS, but it is configurable, by a call to
com.intel.MediaServiceUPnP.Manager.SetProtocolInfo. The other item
properties that are transcoding dependent, e.g., the MIMEType, all have
the correct values for this URL.
Each element in the resource array contains separate copies of all the
item's properties that can change with transcoding, including the URL.
Here's an example,
MIMEType image/jpeg
DisplayName Collioure.jpg
Parent
/com/intel/MediaServiceUPnP/server/1/3766313934373030326436306666613036326631613838316232376538353139
DLNAProfile JPEG_LRG
Height 1536
Width 2048
URLs
dbus.Array([dbus.String(u'http://127.0.0.1:48002/MediaExport/i/ZGUxZTFmNWZhMDNjOTBjNzBkZjE3NmNmZWUwMzU1OTg%3D.jpg')],
signature=dbus.Signature('s'), variant_level=1)
Date 2011-04-09T15:53:56Z
Path
/com/intel/MediaServiceUPnP/server/1/6465316531663566613033633930633730646631373663666565303335353938
ColorDepth 0
Type image.photo
Size 595850
Resource 0
MIMEType image/jpeg
URL
http://127.0.0.1:48002/MediaExport/i/ZGUxZTFmNWZhMDNjOTBjNzBkZjE3NmNmZWUw...
DLNAProfile JPEG_LRG
Height 1536
Width 2048
ColorDepth 0
Size 595850
Resource 1
MIMEType image/png
URL
http://127.0.0.1:48002/MediaExport/i/ZGUxZTFmNWZhMDNjOTBjNzBkZjE3NmNmZWUw...
DLNAProfile PNG_TN
Height 128
Width 128
ColorDepth 32
Size 18819
Resource 2
MIMEType image/jpeg
URL file:///home/mryan/Pictures/Collioure.jpg
DLNAProfile JPEG_LRG
Height 1536
Width 2048
ColorDepth 0
Size 595850
Resource 3
MIMEType image/png
URL
file:///home/mryan/.thumbnails/normal/de1e1f5fa03c90c70df176cfee035598.png
DLNAProfile PNG_TN
Height 128
Width 128
ColorDepth 32
Size 18819
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 :)
Great. That's good to hear. I guess the best place to discuss this
would be on the Rygel mailing list, right?
Regards,
Mark
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
8:55 p.m.
On Mi, 2012-06-20 at 14:49 +0200, Mark D Ryan wrote:
Hi,
On Wed, 2012-06-20 at 12:20 +0200, Jens Georg wrote:
> 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?
>
The way things currently work is that the item's URL property only ever
contains a single URL. By default this is the first URL returned by the
DMS, but it is configurable, by a call to
com.intel.MediaServiceUPnP.Manager.SetProtocolInfo. The other item
properties that are transcoding dependent, e.g., the MIMEType, all have
the correct values for this URL.
Ok, so you'd suggest to keep the "preferred" item in the global
meta-data + url (e.g. by default the non-transcoded original resource)?
Btw, the support for several URLs was never meant for different
resources but different transport layers like HTTP and RTSP
Each element in the resource array contains separate copies of all the
item's properties that can change with transcoding, including the URL.
Here's an example,
That makes sense.
[example]
> 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 :)
>
Great. That's good to hear. I guess the best place to discuss this
would be on the Rygel mailing list, right?
Yes, I'd say so. CCing there.
I also noticed the *Ex() functions in
https://01.org/dleyna/documentation/server-objects. This is also
interesting in Rygel for future versions in conjunction with the fixing
of the whole "sorting in plugins" bugs (see
https://live.gnome.org/Rygel/Roadmap/OSixteen, "Sorting in plugins"
section)
11:45 p.m.
On Thu, 2012-06-21 at 12:55 +0200, Jens Georg wrote:
On Mi, 2012-06-20 at 14:49 +0200, Mark D Ryan wrote:
> Hi,
>
> On Wed, 2012-06-20 at 12:20 +0200, Jens Georg wrote:
> > 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?
> >
> The way things currently work is that the item's URL property only ever
> contains a single URL. By default this is the first URL returned by the
> DMS, but it is configurable, by a call to
> com.intel.MediaServiceUPnP.Manager.SetProtocolInfo. The other item
> properties that are transcoding dependent, e.g., the MIMEType, all have
> the correct values for this URL.
Ok, so you'd suggest to keep the "preferred" item in the global
meta-data + url (e.g. by default the non-transcoded original resource)?
Yes. This way we can maintain backward compatibility. Also, if the
client is only interested in the preferred resource he can filter out
the Resources property in a call to Search or ListChildren.
In our implementation the properties of the preferred resource are
currently duplicated in the Resources array, but we could remove them.
I guess the only downside of doing so is that it would make it slightly
more difficult for clients who genuinely want to retrieve the properties
for all resources. The upside is that there would be no data
duplication.
Btw, the support for several URLs was never meant for different
resources but different transport layers like HTTP and RTSP
>
> Each element in the resource array contains separate copies of all the
> item's properties that can change with transcoding, including the URL.
> Here's an example,
That makes sense.
[example]
>
> > 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 :)
> >
>
> Great. That's good to hear. I guess the best place to discuss this
> would be on the Rygel mailing list, right?
Yes, I'd say so. CCing there.
I also noticed the *Ex() functions in
https://01.org/dleyna/documentation/server-objects. This is also
interesting in Rygel for future versions in conjunction with the fixing
of the whole "sorting in plugins" bugs (see
https://live.gnome.org/Rygel/Roadmap/OSixteen, "Sorting in plugins"
section)
Right, so the two main things we added to the existing MediaServer2Spec
interfaces were the Resources array and the Ex functions. As you point
out, the Ex functions allow clients to specify a sort order. We also
added an extra return value to SearchEx that indicates the total number
of items matching a search query. This is useful if you use the Offset
and Max parameters to limit the number of items returned.
Mark
3741
days inactive
3742
days old
3 comments
2 participants
participants (2)
-
Jens Georg -
Mark D Ryan