Doesn't accept streams at all

[towo]

Cheers,

I'm using "Stream What You Hear" from a Windows machine to send output across the network, but it doesn't seem to work... at all.

Upon connecting, gmediarender tries to pass the stream to gstreamer and just fails silently:

** (gmediarender:20567): WARNING **: cannot set NULL uri
ERROR [2016-01-22 20:53:49.703251 | gstreamer] setting play state failed (2)
ERROR [2016-01-22 20:53:49.703271 | upnp] upnp_set_error: Playing failed
INFO  [2016-01-22 20:53:49.705183 | transport] AVTransportURI: http://192.168.75.26:51343/stream/swyh.mp3
INFO  [2016-01-22 20:53:49.705201 | transport] NumberOfTracks: 1
INFO  [2016-01-22 20:53:49.705212 | gstreamer] Set uri to 'http://192.168.75.26:51343/stream/swyh.mp3'
INFO  [2016-01-22 20:53:49.705255 | transport] LastChange: <?xml version="1.0"?>
<Event xmlns="urn:schemas-upnp-org:metadata-1-0/AVT/">
<InstanceID val="0">
<AVTransportURI val="http://192.168.75.26:51343/stream/swyh.mp3"></AVTransportURI>
<NumberOfTracks val="1"></NumberOfTracks>
</InstanceID>
</Event>

[towo]

And yeah, piping the stream to mplayer sounds good, so that can't be it. ;)

[towo]

So far, this has only happened with SWYH, not pulseaudio-dlna.

[terrin2k]

I'm seeing a similar problem when sending an audio stream from the Allstream app on an android phone. I'll post the debug log output when I get a chance. (Allstream reports that it could not connect.)

[hzeller]

What version of gstreamer are you guys using ? 0.10 or 1.x ?

gmrender passes on the URI to the underlying gstreamer, and maybe the on-the-fly encoders in SWHY might not be properly processed by older versions of gstreamer.

[terrin2k]

In my case, it is gstreamer 1.x. If I can get some time to look at the system again, I'll post more detailed version info and also get the error output as I promised. :P

[sdfg2]

Any workaround for this?

[hzeller]

You need to look at the log file to figure out what is happening in your case.

[BruceOS]

4 years after: So with v 0.0.8 of gmrender-resurect it is "kinda working" with v 1.5.0 and a Raspberry Pi. But "Stream What you hear" and "swyh-rs" both have problems to connect to the headless servers. Connecting is not possible until v.0.0.8 because of the things written on top here.

Workarround (after letting the rpi-audio-receiver script do its magic) : Server Side

1. compile gmrender-resurect as written here (because in the rpi-audio-script it is v 0.0.7)
2. stop the gmediarender service $sudo systemctl stop gmediarender
3. backup /etc/init.d/gmediarender (e.g. $sudo mv /etc/gmediarender /home/pi/)
4. replace /etc/init.d/gmediarender with the example script from the src package (gmrender-resurect/scripts/init.d/gmediarender) 5. Adjust the settings close to the old init.d script
5. Reload services $sudo systemctl daemon-reload

Windows 10 Client Side

1. Be sure the sampling output of your soundcard is 48kHz and 16 Bit
2. Set SWYH to: 'send to device: mp3' ; Capture 48000Hz, 16 Bit, Stereo, MP3 Bitrate 256 (or whatever you think you have to set); Audio Source : The soundcard you want to caputure from; Then Press OK.
3. Start streaming to your device - it should show connected but stream nothing , disconnect from your device, now connect a second time and you should hear something. otherwise repeat that steps slowly. you can debug by watchign the traffic . Wait time is about 3 seconds, until you hear something
4. If the soudn is stuttering restart the gmediarender on your server and try again

I tried to analyze both sides. It is a kind of stuck in the initializing from SWYH. Kind of when you missed a CR on Serial Port / Telnet interaction.

Like written above `

`

And then a typo or information is missing to let gmrender-resurect do its magic. I could not analyze it properly by wireshark, because I am not used to the DLNA/UPNP protocol. But by testing the server with several working DLNA Clients properly and failing on SWYH it's clear that it is something in the initialize process of SWYH.

Tip: SWYH-rs is working sometimes better, sometimes it makes ore problems with the sampling rate (Test with switching 44.1kHz / 48kHz ) - you also have to switch it on the server alsa settings then as well.

At the moment it is a nice "debug project".

[mill1000]

I've discussed this in another issue thread but I believe the problem with SWYH is that it issues the Play action first, and then sets the AVTransportURI. Without a valid AVTransportURI the Play action fails. I'm not certain if this is a valid UPnP command sequence, other control points typically set AVTransportURI and then issue a Play action.

The workaround works because on the 2nd connection attempt, the AVTransportURI is already set from the SWYH's 1st connection attempt so the Play action can succeed.

As for the stuttering. Enabling buffering should help with that.

[BruceOS]

Haha nice :) 18 Days ago - thx for the tip. Yeah in your words it sounds like what i saw on Wireshark but were to unfirm in the protocol. Because on other "Players" the Play com,mand by the IDTag followed.

Anyways. Yeah swhy-rs is running good

I added the buffer-duration in the init.d script

---

Code On Pastebin

And it is workign like a charm with swyh-rs - problem hear is i have to open another instance of the normal SWYH for the Sonos speakers, because mine only accept mp3. - I maybe should ask on the swyh-rs project on GitHub if they can add for example a lamemp3 pipe to the programme

Anyways nice reply.

[hzeller]

I get the impression that we might need to add a configuration file, so that it is easier to have a documented set of options to change and not have to modify init scripts.

[mill1000]

I've also created an issue with SWYH for this. https://github.com/StreamWhatYouHear/SWYH/issues/42