Playing to Emtec N200 (Realtek 1073 - AMP MOservices r13) fail with unknown - Updated

[batric]

Hello all, I'm filing an updated bug report (#238), I updated the application to the master version,

As previously tried, playing from my pc (Fedora 25 x64) to my Renderer, pulseaudio discovers it just fine and add a sink, however as soon as I try to send some audio (even the Speaker test) is fails and switch back to internal audio,

Sending auto to my android phone running BubbleuPnP works just fine, also my phone cano control the renderer successfully even playing the streams from a DLNA Media server NAS.

I tried also using the --fake-http10-content-length and --fake-http-content-length options with same identical results.

I attached a debug log of the entire process from starting pulseaudio-dlna --debug to testing the speakers on the audio control panel.

Do you still need the network capure?

Regards
Riccardo
debug.txt

[masmu]

Hello Riccardo,

Yes, indeed the capture is necessary. I did take a look at the old one but I couldn't find any related communication (I was searching for the string SetAVTransportURI) in there. Could you create a new one?

You also can try out current master which was merged 30 minutes ago.

[batric]

Hi massimo, I've updated the source code and no different result.
I made a run with --debug with the Emtec N200 and BubbleUPnP on my Android Phone, with the Emtec the connection get dropped before I try to start a stream, no problems with Android.
debug-bubble_upnp.txt
debug-n200.txt

I will try to make a new capture with wireshark but I'm struggling with the filters to reduce the noise, any clue?

Regards
Riccardo

[masmu]

I would disable as much services and running applications as possible. is the computer you are using for capturing connected via cable or wifi?

05-07 21:51:54 pulseaudio_dlna.pulseaudio                     ERROR    The device "Realtek Embedded UPnP Render(n200) (DLNA)" failed to play! (500) - "Realtek Embedded UPnP Render(n200) (DLNA)" : The command "SetAVTransportURI" timed out!

Did you try to increase the --request-timeout?

[masmu]

@batric I studied your log files again and I might found something. Your device specified the mime type audio/mpegurl before others and therefore it was used for later instructions. But since the concept of mpegurl is irrelevant for the streaming server I blacklisted them.

Could you please try out that branch to see if it fixes your problems?