INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: wondroushippo on August 09, 2021, 07:38:46 pm
-
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?
-
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 has a DMRA program. Google Whitebear DMRA. You can test the Renderer.
Indeed. (See links below..)
-
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. ;)
-
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
-
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 :(
-
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?
-
.. 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..
-
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.