Hi *,
I wonder if anyone have seen this particular compile error (My Vala
knowledge is non-existent and Google's apparently too):
./configure --prefix=/usr --enable-uninstalled
--with-media-engine=gstreamer \
--without-ui --enable-gst-launch-plugin --disable-tracker-plugin \
--enable-vala
...
checking for gupnp-dlna-2.0 gstreamer-1.0 gstreamer-pbutils-1.0 vala
bindings... configure: error: Package requirements were not met:
gupnp-dlna-2.0 gstreamer-1.0
gstreamer-pbutils-1.0
error: Package `gupnp-dlna-2.0' not found in specified Vala API directories
or GObject-Introspection GIR directories
(Vala 0.18.1)
However, not a single gupnp-dlna-2.0 package from :
http://ftp.acc.umu.se/pub/GNOME/sources/gupnp-dlna/
contains (or makes) gupnp-dlna-2.0.vapi.
I found a message about 'fixing vapi generation':
https://mail.gnome.org/archives/commits-list/2012-November/msg08034.html
.... but not a working code - all Makefiles in vapi/ dir have
gupnp-dlna-2.0.vapi target commented out....
Anyone knows of a solution?
Alternatively, if anyone has a generated rygel-http-time-seek.c with
Krzesimir Nowak's patch (
https://bugzilla.gnome.org/attachment.cgi?id=201807&action=diff) applied, I
would appreciate it enormously, since that patch was the only reason I am
in Vala hell :-(
Thanks,
Andrej Falout
On Sat, Mar 9, 2013 at 1:58 PM, Andrej Falout <[email protected]> wrote:
> Thanks Jens,
>
> > Ah, sorry: Can you try to set my-dlnaprofile=MP3 and see if that helps?
> > I forgot that without that there are no flags generated.
>
> Unfortunately no difference that I can observe.
>
> > Now I see that my Samsung TV has the same issue. Both my TV and Onkio
>> > receivers are DLNA certified, so I wonder.... how did they pass DLNA
>> > test 7.3.33.4 ?
>>
>> For Samsung: There's a reason their implementation is called AllShare.
>>
>
> Samsung AllShare is an marketing name / family of products, that includes
> products such as Allshare Play, Allshare Cast Hub, and others. Some of them
> use DLNA, some dont. Primary focus of this product group / marketing name
> is transparently sharing media between devices regardless of location, as
> described here: http://www.samsung.com/nz/support/usefulsoftware/ASPS/JSP
>
> Samsung DLNA capable devices are all Digital Living Network Alliance
> certified, and advertised and marked as such on the device, packaging, and
> marketing material:
>
> www.*samsung*.com/us/pdf/*dlna*_guide.pdf
>
>
>> For Onkio: Don't know.
>>
>
> As far as I can see, there are only two answers possible:
>
> 1) requirement of the functionality exercised in test 7.3.33.4 is
> ambiguous, and allow non-specified/undocumented behaviors to satisfy the
> test, and/or
>
> 2) the test 7.3.33.4 implemented in Rygel testing suite is not exactly the
> same test that was used to obtain certification for Samsung and Onkyo
> devices, for whatever reason that may be.
>
> I would expect the goal of Digital Living Network Alliance to be
> interoperability between devices. Passing or failing a test has very little
> value for the end user trying to use two devices together. Having them work
> together, has a value.
>
> As any human endeavor, specific implementations of any stated goal will
> have flaws, even if the goal is achieved. As an example, Microsoft Media
> Player has no problem achieving this functionality (Streaming) with both
> devices, as much as this observation makes me wonder about the methods they
> used to achieve it.As a developer, I question them, and where I can, try to
> avoid them. As a user, I have little choice but to applaud them.
>
> As an comparison, I wonder how many computers on this planet would
> actually work, if they refused to boot on any computer with non-compliant
> ACPI implementation...
>
> I also note that devices known for exhibiting this behavior (Samsung,
> Onkyo and Sharp - that I personally know about) represent more then 50% of
> the DLNA devices on the planet, and therefore more then 50% of the
> potential user base of Rygel will be affected by this issue.
>
> The thing is this is mostly with GstLaunch which is a debugging/"rapid
>> stream prototyping" tool.
>>
>
> So is there another way to achieve this in non-debugging / non-rapid
> stream prototyping way? I so far failed to find user-level alternative to
> Rygel for creating a UPnP audio stream...?
>
> > Is there any chance for a workaround/fix, or do I need to look for
> > another solution?
>
> If the device has a proper user-agent, then yes. Samsungs sucked at that
>> until recently.
>>
>
> Please forgive my ignorance, is "user-agent" some king of software I can
> add or configure? If it refers to the software component in Samsung/Onkyo
> firmware, then this is never going to happen, because as far as this
> companies are concerned, they are fully DLNA compliant, and have
> certification to prove it....
>
> I don't mind begging, if that's going to make my Onkyo and Samsung work
> with Rygel ;-)
>
> Any chance for a workaround or any kind?
>
> This patch is still marked as Committed - did it not fix the issue or was
> it not really committed because of your comment about breaking the test?
> https://bugzilla.gnome.org/attachment.cgi?id=201807&action=diff
>
>
> Your work, and your help, are very much appreciated!
>
> Thanks,
> Andrej Falout
>
>
_______________________________________________
rygel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/rygel-list
