Does now show up on the network and compile errors

[rajgole]

I saw some updates today gmrender and compiled it on dockstar debian wheezy. I am still using gstreamer0.10. (I did not see gstreamer 1.0 in wheezy) Here are some warnings that I got on the compile. In file included from /usr/include/gstreamer-0.10/gst/gstpad.h:30:0, from /usr/include/gstreamer-0.10/gst/gstelement.h:57, from /usr/include/gstreamer-0.10/gst/gstbin.h:27, from /usr/include/gstreamer-0.10/gst/gst.h:35, from output_gstreamer.c:35: /usr/include/gstreamer-0.10/gst/gstbuffer.h: In function ‘gst_buffer_ref’: /usr/include/gstreamer-0.10/gst/gstbuffer.h:349:10: warning: cast increases required alignment of target type [-Wcast-align] /usr/include/gstreamer-0.10/gst/gstbuffer.h: In function ‘gst_buffer_copy’: /usr/include/gstreamer-0.10/gst/gstbuffer.h:387:10: warning: cast increases required alignment of target type [-Wcast-align] In file included from /usr/include/gstreamer-0.10/gst/gstpad.h:33:0, from /usr/include/gstreamer-0.10/gst/gstelement.h:57, from /usr/include/gstreamer-0.10/gst/gstbin.h:27, from /usr/include/gstreamer-0.10/gst/gst.h:35, from output_gstreamer.c:35: /usr/include/gstreamer-0.10/gst/gstevent.h: In function ‘gst_event_ref’: /usr/include/gstreamer-0.10/gst/gstevent.h:404:10: warning: cast increases required alignment of target type [-Wcast-align] /usr/include/gstreamer-0.10/gst/gstevent.h: In function ‘gst_event_copy’: /usr/include/gstreamer-0.10/gst/gstevent.h:439:10: warning: cast increases required alignment of target type [-Wcast-align] In file included from /usr/include/gstreamer-0.10/gst/gstbus.h:29:0, from /usr/include/gstreamer-0.10/gst/gstelement.h:58, from /usr/include/gstreamer-0.10/gst/gstbin.h:27, from /usr/include/gstreamer-0.10/gst/gst.h:35, from output_gstreamer.c:35: /usr/include/gstreamer-0.10/gst/gstmessage.h: In function ‘gst_message_ref’: /usr/include/gstreamer-0.10/gst/gstmessage.h:330:10: warning: cast increases required alignment of target type [-Wcast-align] /usr/include/gstreamer-0.10/gst/gstmessage.h: In function ‘gst_message_copy’: /usr/include/gstreamer-0.10/gst/gstmessage.h:368:10: warning: cast increases required alignment of target type [-Wcast-align] output_gstreamer.c: In function ‘output_gstreamer_init’: output_gstreamer.c:507:29: warning: cast increases required alignment of target type [-Wcast-align] mv -f .deps/output_gstreamer.Tpo .deps/output_gstreamer.Po

gcc -Wall -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -Wwrite-strings -o gmediarender main.o upnp.o upnp_control.o upnp_connmgr.o upnp_transport.o song-meta-data.o upnp_device.o upnp_renderer.o webserver.o output.o output_dummy.o xmldoc.o xmlescape.o output_gstreamer.o -pthread -lgthread-2.0 -lrt -lglib-2.0 -pthread -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lglib-2.0 -pthread -lupnp -lthreadutil -lixml -lm

When I run the program, I get following warnings and the DLNA devices on the network do not see gmrender. I am not running X11 on dockstar. (gmediarender:8306): GConf-WARNING _: Client failed to connect to the D-BUS daemon: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 GConf Error: No D-BUS daemon running (gmediarender:8306): GConf-WARNING : Client failed to connect to the D-BUS daemon: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 GConf Error: No D-BUS daemon running (gmediarender:8306): GConf-WARNING *: Client failed to connect to the D-BUS daemon: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 GConf Error: No D-BUS daemon running (gmediarender:8306): GConf-WARNING *_: Client failed to connect to the D-BUS daemon: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 GConf Error: No D-BUS daemon running

debug level two shows following errors

(gmediarender:2547): GStreamer-CRITICAL **: gst_pad_new_from_template: assertion `GST_IS_PAD_TEMPLATE (templ)' failed

(gmediarender:2547): GStreamer-CRITICAL **: gst_pad_template_get_caps: assertion `GST_IS_PAD_TEMPLATE (templ)' failed

(gmediarender:2547): GStreamer-CRITICAL **: gst_pad_set_caps: assertion `GST_IS_PAD (pad)' failed

(gmediarender:2547): GStreamer-CRITICAL **: gst_element_add_pad: assertion `GST_IS_PAD (pad)' failed

[hzeller]

The compile warnings are harmless - I get them on my Rasperry as well; they seem to be rooted in in that the gstreamer 0.10 developers did not anticipate the ARM arch; it still works for me.

If you use pulseaudio, I think that attempts to start some d-bus daemon; make sure to install all necessary pulseaudio libraries. (I usually use directly ALSA, see the init script).

The GST errors could indicate that not all plugins are installed - did you install all the plugins mentioned in the INSTALL.md ?

To test with controllers, I would first start by checking with some UPnP controller (such as BubbleUPnP which I use on my phone); DLNA is somewhat a subset of UPnP, so I would first try with that first - if that works, it is possible to drill down what is happening with DLNA.

[rajgole]

1. Got rid of pulseaudio
2. Made sure that all the plugins are installed. (Copy and paste)
3. Recompile
4. Installed bubbleUPnP on a phone (I had skifta and few others)
5. Verified that other DLNA devices do show up

Started app from console I see following lines after load.

gstreamer, got mute 0 registering '/upnp/rendertransportSCPD.xml' registering '/upnp/renderconnmgrSCPD.xml' registering '/upnp/rendercontrolSCPD.xml' Got fraction 1.000000 Setting volume-db to 0.00db == #100 Ready for rendering..

I still see GStreamer-CRITICAL errors while loading up the application and I do not see mediarender on the network. I do have MPD running on the same machine. Is there any conflict? BTW How do I disable registering image and video services? This is headless installation.

[hzeller]

The CRITICAL gstreamer errors and X11 errors I get as well, these are a red herring (they probably show up for plug-ins at register time that don't really work, but that is fine).

After the output 'Ready for rendering': if you see that and then start BubbleUPnP, you should see the output continue something like this

---

webserver_get_info:(filename='/upnp/rendertransportSCPD.xml',info=0xad3c2570) webserver_get_info:(filename='/upnp/renderconnmgrSCPD.xml',info=0xad3c2570) webserver_get_info:(filename='/upnp/rendercontrolSCPD.xml',info=0xad3c2570) event subscription request Subscription request uuid: urn:schemas-upnp-org:service:RenderingControl 1 evented variables

....

Which shows that the controller registered. Do you ever see something like that, or does it stop at 'Ready for rendering.' ?

If you never see this, then BubbleUPnP does not 'get through'. The way the UPnP advertises itself requires, that the controller and the renderer are in the same network segment; but I assume you already have that set up if DLNA works ?

I don't think that MPD is interfering with the registration process. I can imagine that it might interfere later when both systems attempt to grab the audio device, but even that is unlikely as ALSA allows multiple audio devices. But I would suggest, while debugging, to stop MPD to have the 'simplest' environment.

I have to check in the sources if this is handled properly, but one thing that comes to mind is the network interface; if you have two interfaces (the regular ethernet and some WiFi USB dongle). Though by default, it should listen on 0.0.0.0; but something to try: if you have this set-up, can you try to connect it via ethernet and see if that works ? That could narrow down things.

Regarding registering non-audio - I once had some experimental code in there that only registered plugins that offered audio/ mime-types. However it turned out that some plugins didn't advertise the right mime-types and were actually able to handle some streams even though they didn't advertise it when presented. So I choose to leave it with 'register all plugins found'.

[rajgole]

Problem solved. It was the wireless network interface binding.

I do have USB wireless connection on the device that I am using to connect. I am not using ifplugd or wicd so eth0 is getting 169.x.x.x address.

The solution is to use -I switch with a static IP address of the device. The messages that you described were not showing up earlier but started showing up after adding the static IP.

BubleUPnP works fine. MPD works fine too. I am going to close this issue. BTW I ended reinstalling pulseaudio as there was some issue switching audio. I am not sure if this is related to gmrender-resurrect. (Before pulse audio, gmrender was saying something about jack audio, It is not installed).

[kgha]

When I run dlna control point ,apear this error.how to solve it ? INFO [2011-09-08 17:40:18.370567 | webserver] webserver_get_info:(filename='/upnp/rendercontrolSCPD.xml',info=0x7662d970) INFO [2011-09-08 17:40:18.371036 | webserver] webserver_get_info:(filename='/upnp/rendercontrolSCPD.xml/index.html',info=0x7662d970) ERROR [2011-09-08 17:40:18.371343 | webserver] Not found. INFO [2011-09-08 17:40:18.374866 | webserver] webserver_get_info:(filename='/upnp/rendercontrolSCPD.xml',info=0x74a2d970) INFO [2011-09-08 17:40:18.375902 | webserver] webserver_get_info:(filename='/upnp/rendercontrolSCPD.xml/index.html',info=0x74a2d970) ERROR [2011-09-08 17:40:18.376217 | webserver] Not found.

[hzeller]

kgha: this looks like some unrealted problem, so it would be better to open a separate issue.

You haven't written what DNLA control point software/device you're trying, this would be interesting to reproduce the trouble. Also, the version of gmediarender would be good to know (the first line of the log-file) and the version of the libupnp library.

What you're seeing is, that the control point attempts to access non-existent files, such as "/upnp/rendercontrolSCPD.xml/index.html", while there is only a "/upnp/rendercontrolSCPD.xml" available. This points to some unnecessary and broken behavior of the DNLA controller, but it is not necessarily a problem if the rest works alright. Does it otherwise play music, or is it stuck at this stage ?

[hzeller]

(since you opened a separate bug #27, let's continue the discussion there.