Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[wondroushippo]

So I'm using JRiver to control a Raspberry Pi 3 running DietPi Allo with GMediaRender, with a Khadas Tone 2 Pro outputting to my headphone amp at my desk. Now, it streams fine to the RPi, but the problem is that it when it reaches the end of the queue, it doesn't seem to send a 'stop' command and release the USB DAC. Using another DLNA controller app, MConnect on my iPhone, it works fine when doing so, sending a stop command and releasing the USB DAC signal.

Now, this is important because my DAC can automatically switch back to its SPDIF input when there's no signal on the USB DAC, so using JRiver to control this DLNA renderer means that I have to start playing again and hit Stop to properly release the USB DAC signal.

Is there something I need to enable to force a Stop signal to be properly sent to my DLNA renderer when controlling with JRiver?

[JimH]

Can you be more specific about "using JRiver to control"?  Which program?  Version?  On what OS?

Stop and Pause are different.

AndrewFG has a DMRA program.  Google Whitebear DMRA.  You can test the Renderer.

[AndrewFG]

AndrewFG has a DMRA program.  Google Whitebear DMRA.  You can test the Renderer.

Indeed. (See links below..)

[AndrewFG]

PS you are probably right that MC does not send a Stop at the end of a playlist. The UPNP spec is that Control Points would only send commands when the user wants the renderer to do something new. The renderer ought to be clever enough to stop itself when it has finished playing the last sent track.

.. IMHO the real oddity here is that a) you happen to have a renderer that needs an external Stop command, and b) you happen to have a CP that sends one.

[wondroushippo]

JRiver 28, Windows 10, using it to play music on this DLNA renderer, which works fine other than something with the way that the "renderer stopping itself" is going wrong. The problem is that I have one app that handles this process perfectly fine (MConnect) but JRiver and BubbleUPnP (just tested) behave the same way - the only way to release the signal is to start playing again and then manually stop. It could be that they're behaving properly and I have a renderer and one control app that are both messed up in a way that makes them work right.

Here's the data for this renderer, let me know if any other data would be helpful:

Device Description Url   http://192.168.0.112:49494/description.xml
HTTP Server Header   Linux/5.10.52-v7+, UPnP/1.0, Portable SDK for UPnP devices/1.8.4
Description   gmediarender 0.0.8
Friendly Name   DietPi
Manufacturer Name   Ivo Clarysse, Henner Zeller
Manufacturer Url   http://github.com/hzeller/gmrender-resurrect
Model Name   gmediarender
Model Number   0.0.8
Model Url   http://github.com/hzeller/gmrender-resurrect
Presentation Url   http://192.168.0.112:49494/
UPnP Device Type   urn:schemas-upnp-org:device:MediaRenderer:1
UPnP Media Renderer version   1
Unique Device Name   uuid:1f51d14c-a6f2-481a-af25-547df06a7f6d
Service Url for AVTransport   http://192.168.0.112:49494/upnp/rendertransportSCPD.xml
Service Url for ConnectionManager   http://192.168.0.112:49494/upnp/renderconnmgrSCPD.xml
Service Url for RenderingControl   http://192.168.0.112:49494/upnp/rendercontrolSCPD.xml
AVT:GetDeviceCapabilities action   Supported
AVT:GetMediaInfo action   Supported
AVT:GetPositionInfo action   Supported
AVT:GetTransportInfo action   Supported
AVT:GetTransportSettings action   Supported
AVT:SetNextAVTransportURI (gapless play)   Supported
AVT:SyncPlay (synchronous play)   NOT Supported
RC:GetVolume action   Supported
RC:SetVolume action   Supported
AVT:Event Subscription   Succeeded
RC:Event Subscription   Succeeded
HTTP User Agent (client)   GStreamer souphttpsrc 1.14.4 libsoup/2.64.2
Play test file result   Play success => Start Ok / Stop Ok

[AndrewFG]

It could be that they're behaving properly and I have a renderer and one control app that are both messed up in a way that makes them work right.

I rather fear that that is indeed the case

[wondroushippo]

I rather fear that that is indeed the case

Sounds like it, is there any data from your tool that could help diagnose why that happens, by the way?

[AndrewFG]

.. is there any data from your tool that could help diagnose why that happens, by the way?

Nope. The DMRA only tests functionality that is in the UPNP and DLNA specifications. And sending a Stop after playing, is not in them..

[wondroushippo]

BTW if anyone cares, the solution was to use Moode Audio instead, which apparently has a way better DLNA implementation than DietPi+Allo does. Works well.