Print

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

[Mikhail]

I want to divide my topic into 2 questions, both of them about the oddities of jriver working in my home network as an UPNP controller.

• After the release of JRiver versions newer than 25, I lost the ability to output audio via MC to my UPNP render (a separate computer with a player running in UPNP render mode).
  This happened because JRiver sends a link to my player containing extra information at the end ( ...?Reader=1.2.3.4... )
  
  I tried to disable the transmission of this information through the DLNA server setting, set the values recommended by the DMRA, but to no avail.
  I will be happy to receive any recommendations from the community.
  
  
• I also have a problem that they tried to solve here, it is related to the fact that with a certain configuration of the home LAN, the JRiver server sometimes loses connection with the render device for a short time, as a result, playback is interrupted after the track in which the render disappeared from the list.
  According to my observations, this problem manifests itself when a very simple switch is used in the home network after the main router with the Internet to combine all the equipment. Moreover, I tried to use a whole bunch of different switches, and only a few did not create problems. These were mostly L3 managed switches with IGMP snooping support and a bunch of bells and whistles..
  IMHO the simplest switch models-such as Dlink DGS-108, do not pass certain UDP multicast packets, which is why JRiver stops seeing the upnp render, and this happens at unpredictable moments. My render just disappears from the JRiver list and reappears after a few seconds, it finishes playing the track, but the new track doesn't start...
  Actually, the question is, what network functions should all network devices support between JRiver and Upnp render, and what other conditions should be met? For example: Dlink DGS-108 has support for IGMP snooping, but its presence in the network leads to loss of communication between the render and JRiver...
  I Hope I explained my problem clearly.
  I want to note that the problem is not related to one specific UPNP render, I see it on different devices.
  

In the attachment, I posted a screenshot of the error for the first question and a DMR report about my render.

[AndrewFG]

.. JRiver sends a link to my player containing extra information at the end ( ...?Reader=1.2.3.4... )

Sorry but I have no idea what you are talking about. Can you please explain?

[AndrewFG]

Actually, the question is, what network functions should all network devices support between JRiver and Upnp render, and what other conditions should be met?

I suggest the following:

- All the devices should get their IP addresses via DHCP from the same DHCP server on your router. Which means that they will all be on the same subnet that the router can route.

- In your router, make sure that once the devices have got an IP address, that address is “reserved” (meaning that the next time the device asks for an IP address it will get the same one).

And no, IGMP is not necessary, and will not help you.

[Mikhail]

Thanks for the answer.

1. Renderer and the server are on the same subnet, the IP4 parameters for the server with JRiver software and for the renderer device are set manually, of course the IP addresses of the renderer and the server are different, but they have a common Gateway, subnet mask, and DNS server (although it is not needed).
2. The problem with JRiver

.. sends a link to my player containing extra information at the end ( ...?Reader=1.2.3.4...)

the screenshot shows that the player gives an error message when trying to play a WAV file that jriver passes to it.
The player cannot read the file at the path specified in the URL. Starting with JRiver version 26, I see this error, so I do not purchase the following licenses, all new versions are useless for me, since I see this error with them.
It seems to me that the error is due to the fact that the URL contains additional information that is not related to the file location.as you can see in the screenshot, there is additional data after the file name, which my render most likely interprets as a continuation of the path to the file. I think this information in the old versions of JRiver just wasn't there, so apparently everything worked for me.
I tried different settings of the DLNA server in JRiver, but they did not help in the new versions, starting from 26.

[RoderickGI]

Well, it looks like the Renderer is the problem. This is reported in the DMRA report:
Play test file result=Play failed => Command "SetAVTransportURI" failed

I think it is kind of important for the SetAVTransportURI command to work.

Normally, a Controller tells a Renderer what files to play, and gives the Renderer a URL to get it.
In the Wireshark traces I have, that URL is in the form "http://192.168.1.109:52100/Music/F561325.flac?Reader=2". (Example, and yes it works. Even with a third party Renderer.)
Then the Renderer requests the file using the URL.
As MC told the controller to use the URL "http://192.168.1.21:52100/Music/F69749.wav?Reader=9", the Renderer should use that URL, and MC would understand it.

It is possible that PM123 isn't forming the GET command correctly. A correct value, as shown in Wireshark, would look like:

GET /Music/F69749.wav?Reader=9 HTTP/1.1\r\n

So what is shown in your image as a failing URL looks correct.



Do you have the latest version of PM123 installed? It is up to version 1.41 now, and the DMRA report just says you have version 1.
Anyway, it seems you need to ask Dmitry about the problem, not JRiver. http://www.5nets.ru/pm123.html

[Mikhail]

Thank you for your detailed response.
Yes, I use the latest version of PM123, as I am a tester of this project under ArcaOS.
I will definitely send Dmitry your comments on working with SetAVTransportURI command.

[Mikhail]

So, the problem with playing files on new versions of JRiver was solved, the author of PM123 made changes to the algorithm for exchanging requests with the server.

There is still a problem with the UPnP render disappearing from the jriver menu (the problem is not specifically related to PM123 and is observed on other devices, for example on Soundaware D300REF) if it is connected not directly to the router, but via an additional LAN switch.
The render is visible most of the time in the JRiver menu, but sometimes it disappears and reappears. If you start playing, most often the player will play 1-2 tracks and stop. In the interface, you will notice how at some point the render disappears from the list, then appears with an empty playlist, then the only track that it is currently playing appears in the playlist.

[RoderickGI]

It seems Dmitry fixed the issue. 

Alas, I can't help with the second problem. I've had ongoing issues with DLNA Renderers not showing up, showing up very slowly, and disappearing at random. While I suspect my router is the issue, I've not been able to isolate the problem.

[Mikhail]

In my experience of dealing with this problem, it helps to select equipment that can work with multicast and support IGMP snooping. The problem itself seems to be related to SSDP (Simple Service Discovery Protocol) and probably caused by hardware attempts to stop Multicast storm https://help.airtame.com/en/articles/1661401-troubleshooting-discovery-multicast-and-ssdp
Unfortunately, the settings for Storm control in SOHO/home segment devices are often not provided.