Print

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

[eho]

I use JRiver to control a PSAudio DirectStream DAC via its Bridge II interface.  I have had a stable setup using Win10 on a Surface Book 1 (MC19) streaming FLAC files from a NAS.  I'm switching over to a Surface Book 2 and set up MC19 on it and it is working fine.  I have a third Surface Book I am testing which has an eval copy of MC25.  It is set up identically.  It will not stream to the Bridge II.  "There was a problem controlling the selected DLNA device.  Double-check" etc.  followed by "Something went wrong with your playback".  Looks identical to what happens when you have bad firewall rules (I wrote this topic for PS Audio:  https://www.psaudio.com/ps_how/how-to-get-through-firewalls-for-bridge-streaming/).  But I checked the firewall rules and they are fine. 

One weird thing is if I start playback using one of the two working configs, the non-working MC25 setup can see the Bridge, it shows the playback that is going on there, track info, progress on the playback, etc.  But it can't stream to the Bridge II.   

I loaded the uPnP developer tools which has an AV Wizard, a basic DLNA controller.  It boots up and recognizes the Bridge II interface immediately.  I point it to an MP3 file (it doesn't support FLAC) and hit play and it immediately starts streaming.  And, MC25 can see the playback and is "following along".  I was kind of figuring it might be a computer-specific problem but another (very simple) program can stream to the Bridge II fine on this computer. 

It does seem like the problem is specific to MC25 in some way.  The log (attached) says:

0010047: 20760: Reader: CWinINetReader::Open: Start
0010047: 20760: Reader: CWinINetReader::Open: Opening http://192.168.0.8:41481/service/AVTransport_control
0010047: 31448: Reader: CWinINetReader::Thread: Start
0010047: 31448: Reader: CWinINetReader::Thread: url: http://192.168.0.8:41481/service/AVTransport_control
0010047: 31448: Reader: CWinINetReader::Connect: Start
0010047: 31448: Reader: CWinINetReader::Connect: Finish (0 ms)
0010047: 31448: Reader: CWinINetReader::DownloadFromHTTPURL: Start
0010047: 31448: Reader: CWinINetReader::DownloadFromHTTPURL: HttpOpenRequest successful
0010047: 31448: Reader: CWinINetReader::DownloadFromHTTPURL: HttpSendRequest successful
0010047: 31448: Reader: CWinINetReader::DownloadFromHTTPURL: Failed (header status code: 500)
0010047: 31448: Reader: CWinINetReader::DownloadFromHTTPURL: Success
0010047: 31448: Reader: CWinINetReader::DownloadFromHTTPURL: Finish (0 ms)
0010047: 31448: Reader: CWinINetReader::Thread: Finish (0 ms)
0010047: 20760: Reader: CWinINetReader::Open: Finish (0 ms)
0010047: 20760: Reader: CWinINetReader::Close: Start
0010047: 20760: Reader: CWinINetReader::Close: Finish (0 ms)
0010047: 20760: General: CDLNADeviceServiceCaller::CallServiceFunction: DLNA function call failed or timeout! url = http://192.168.0.8:41481/service/AVTransport_control function = SetAVTransportURI execution time = 11 ms of 6000 ms.
0010047: 20760: Sharing Plugins: CDLNADeviceConnectionStatus::NotifyCommunicatedWithDevice: Error communicating with device: BridgeII

So the DLNA SetAVTransportURI request on port 41481 (AVTransport/control) fails almost immediately (11ms).  On the working config, that same command finishes successfully in 15ms.  Let me know if you want me to attach the log of the working config. 

What else should I try? 

[RoderickGI]

You could try selecting the "Ignore Transport Events (Use polling mode)" setting for the Bridge II Zone.

The setting is under the "DLNA Controller Options" shown in the attached image.

[RoderickGI]

 You could also try using AndrewFG's DMRA software to check what the Bridge is capable of.

AndrewFG's Digital Media Renderer Analyser by Whitebear software

[eho]

Roderick, thanks for the response and link.  I played with all manner of combinations of those 4 options before I posted but neglected to say that in the original post. 

[AndrewFG]

The  "Something went wrong with playback" message is often because you are trying to push a media format that the renderer does not support.

So check your MC server settings whether you are pushing Original, or Always Converting to another format. You can use the DMRA from my sig to tell you which media formats the renderer supports.

[eho]

Andrew, this is clearly not the problem, two other computers with MC19 can push those exact same FLAC files to the Bridge II just fine.  Another program on the failing computer (uPnP AV Wizard) can push those same files successfully and play them. I'm back from my trip, I can run other diagnostics but I'm out of ideas.  I was one of the people who helped PS Audio work through the JRiver streaming issues on Windows when the DirectStream / Bridge came out.

The working configs have "Specified output format", not "Original".  I hadn't been aware of that setting recently, original seems like a more precise/definitive setting.  But it doesn't change the outcome, still get "Something went wrong with playback" with "Original" on MC25.  Does that html callback failure indicate format incompatibility?  That seems like a bug in MC25, because everything else I try with the exact same media file (NAS-hosted FLAC 44.1/16, CD rip by MC19) works fine. 

Finally, on one of the working MC19 configs, Whitebear media analyzer can't even see the Bridge II, but MC19 can.  So that tool isn't super helpful.  And it doesn't see the Bridge II on the MC25 machine either.  But MC19/25 can. :-)

[AndrewFG]

.. this is clearly not the problem, two other computers with MC19 can push those exact same FLAC files to the Bridge II just fine.  Another program on the failing computer (uPnP AV Wizard) can push those same files successfully and play them.

Yeah, well the question is (also) whether the instance of MC that is failing, is pushing those files as Flacs (Original) or converting them to some other format (eg. PCM or L16) that the renderer cannot play..

[RoderickGI]

Finally, on one of the working MC19 configs, Whitebear media analyzer can't even see the Bridge II, but MC19 can.  So that tool isn't super helpful.  And it doesn't see the Bridge II on the MC25 machine either.  But MC19/25 can. :-)

If DMRA can't see the Bridge II from a computer, check the "Use Windows Discovery" in the top right corner. Also note the message about turning on Network Discovery in Windows and firewall settings to make that work. See image.

Sidenote: I just ran DRMA and got a Firewall warning, even though it has been run on this PC before with no issue. Security software (Norton in this case) may be essential, but is annoying.

Do you have an Android phone? If so, maybe get BubbleUPnP on the phone and try playing to it from the MC25 installation. That has always been a simple, reliable test for DLNA issues for me. Or perhaps you have another DLNA Renderer you can play to from the MC25 installation, just to confirm the MC25 end is working.

Have you discovered the "Services & Plug-ins > Media Network" logging functionality? Taking a look at that as you try you play to can highlight issues, particularly if you compare to playing to a working DLNA Renderer.

[eho]

Andrew, I tried Original and Specified Output Format, both failed.  The DAC screen will show the format (which is almost always 44.1/16) but the stream never gets that far, it fails "instantly" (10-15ms) and the Bridge II never sees it. 

Should I take another log, does it have that info?

RoderickGI, thanks for the tip, that did work.  I'm playing with it to see if I can get it to render (but I haven't figured out how to point it at FLAC files, either on the NAS, Twonky Media Server, or local file. 

I'll report back. 

[eho]

OK, with Windows Discovery turned on, Whitebear can find the Bridge II, query it, and stream to it, including a polar bear for album art. Report attached. 

On the working config: I see several of these:

1023   5:01 pm   Finished   192.168.0.7   POST: http://192.168.0.31:52100/AVTransport/control   555 bytes   0:00.001

followed by an http GET for either WAVE or FLAC depending on whether I have Original or Specific Output Format selected that keeps increasing in size as the file is streamed to the Bridge II. 

On the non-working config, I see only a single

1023   5:01 pm   Finished   192.168.0.7   POST: http://192.168.0.31:52100/AVTransport/control   555 bytes   0:00.001

and then nothing streams. 

This is consistent with the JRiver log which shows that the transport control POST gets a bad response back from the DLNA http server in the Bridge II. 

Is it possible to get the contents of the AVTransport/control POST packet without installing a network sniffer?

[AndrewFG]

Thanks for the DMRA report. It tells me that the renderer is UPNP compliant, but is NOT DLNA compliant. Reason being that it does not support the DLNA mandatory L16 (PCM no header) format.

So if your failing instance of MC were trying to push L16 format then it would fail. And since the default setting of new MC server installations is to push L16, this still seems to me to be the most likely cause of your failure. So I suggest again to check the MC DLNA Server settings concerning audio conversion. (Note that MC can have more than one server configured, so you need to check the conversion settings for the exact MC server being used).

Note: In the DMRA there are a couple of check boxes to enable HTTP logging, so if you do a push from the DMRA, you can log the POST and GET commands. However if you want to log the POSTs and GETs when MC is trying to do the push, you will need to install a network sniffer like WireShark.