Questions about using rygel with a DBus data source

[Dominic Jacobssen <dominic jacobssen gmail com>]

Hi all.

I'm currently using minidlna as a DLNA server with a Western Digital
TV Live as the renderer. Minidlna works well, but it's a little bit
limited, and various features that I want tend to float around forever
as patches rather than getting incorporated into the actual code.

I've been looking at Rygel as a potential replacement for several
reasons. Firstly, it's written in Vala, and I've recently become very
enthusiastic about Vala, and secondly because it uses GStreamer, and
I've recently taken the time to kinda-sorta understand GStreamer, and
I've been very impressed by the whole unix-like approach it uses.

The thing that I detest most in nearly all existing DLNA servers is
the time taken to scan and rebuild a media database. I want a database
that *I* rebuild on demand, not one that constantly gets corrupted and
needs rebuilding (which I found was the case with Twonky, and
sometimes with minidlna). I would also love to be able to use a
"proper" data store like postgres, or maybe Mongo.

Here are my (possibly wrong) preconceptions and assumptions; please
could someone jump in and correct me if and or all of these are wrong:

- Rygel allows me to separate out the (difficult) boilerplate
nitty-gritty of doing all the UPNP/DLNA/SSDP, etc, from the (easier)
generation and transmission of media metadata;

- All I have to do is to write a separate out-of-process "metadata
server" which registers itself using DBus and which serves up
information about the available media;

- This "metadata server" is language-independent, as long as it "talks" DBus;

- The "heavy lifting" (e.g. streaming) of the media itself to the
client is taken care of by Rygel;

- I can have several such "metadata servers" simultaneously connected
over DBus (all of which presumably identify themselves uniquely), and
only need a single Rygel server to make the media available;

- The "metadata path" does not have to correspond at all to any
physical path in the filesystem; in other words, I could have
something like "Movies -> By IMDB Rating -> 4/5/6/7/8/9+ -> By
Resolution -> SD/HD -> By Genre -> Action/Comedy/Drama/...", and have
this huge combinatorial metadata space generated on-the-fly by the
metadata server;

Assuming these preconceptions and assumptions are broadly correct,
then I do have one question.

On the page:

    https://live.gnome.org/Rygel/MediaServer2Spec

it says:

"""
as org.gnome.UPnP.MediaItem2.URLs

The 'URLs' property should list the URLs available. There could be
more than one URL, for instance, if both http and rtsp are supported.
'MIMEType' should be the mime-type of the stream.

In the 'URLs' array a special string wild card @ADDRESS@ can be used.
In a URL, if the string immediately following the protocol
specification and the :// is @ADDRESS@ (uppercase) it will be replaced
by the server address used for communication with the client when the
URL is passed to the client. If the string @ADDRESS@ is used in any
other part of the URL passed it will be left unmodified.
"""

I initially took this to mean that this is the URL that the "metadata
server" needs to hand back to Rygel (over DBus) in order for Rygel to
be able to access the media. However, if this URL is ALSO handed to
the DLNA client (the MediaRenderer), then I'm confused, because the
client would need an http:// (or rtsp://) URL, whereas Rygel would
need a file:// URL in order to open/read/stream the file to the
client, no?

Put another way, the http:// URL handed back to the client might not
(or, probably won't) bear any correlation to an actual file path on
the server. For example, the URL handed to the client might be
something as abstract as:

    http://192.168.1.1/media/123456.mp4

whereas internally it might be something like:

    /media/lvm/Media/Video/Movies/foo.mp4

What crucial insight am I missing?

Thanks!

Dominic