Print

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

[jmone]

I've lost the ability to control two DLNA Speakers (my Axiom Audio) from MC on my new PC Build and I'm scratching my head a bit as it has always "just worked".  Here are some details:
- MC Sees the Axiom DLNA Speakers as a Zone just fine
- If you try to play anything to them you get the "There was a problem controlling the selected DLNA Device"
- Whitebear can see all my DLNA devices (but only when "Use Windows Discovery" is checked)
- Whitebear can play test files to the Axiom & the MC GUI shows the details of the File Being Played
- MC Sees the Pioneer DLNA Speakers as a Zone and can play to them just fine.

No luck fiddled with:
- a few of the MC DLNA Settings
- Windows Firewall (on/off, checked MC and Whitebear are on the exclusion list)

I've attached the Whitebear Renderer Report.

[jmone]

Also tested from a MC 22 (32-Bit) install on a Laptop and it can see and play to the Axioms just fine. 

Interestingly on the PC with the issues, I can see what is being played to the Axiom and also have some control such as Pause/Play and Stop to the Axiom all works but can not recommence playback of the track once stopped. 

Edit - here is the renderer report from the Laptop (Whitebear runs without needing the "User Windows Discovery" option.

[AndrewFG]

I don’t see anything bad in the DMRA report. (The only thing is that they apparently support neither L16 PCM which is the “minimum must support” format of DLNA, nor MP3. But this would not prevent you playing other formats in Original format.)

I find it interesting that the DMRA only finds the speakers when using Windows Discovery. This makes me suspect a firewall issue on the PC concerned. Perhaps you are using Windows 10 (?) fall creators update (?), perhaps an issue with Windows Defender (?)..

[jmone]

Checking the details of the two PCs:
- Main (with issue): MC23.0.64 64Bit / Win 10 Pro for Workstations build 1709
- Laptop (no issue): MC22.0.108 32Bit / Win 10 Home build 1703

I'm guessing that as Whitebear DMRA works on the Laptop without needed to "Use Windows Discovery" it is something about the Main PC's network or firewall setup.

[jmone]

Thanks as always Andrew for your help - I've also added a report from the laptop

[jmone]

Found when it broke.  Working in V69, broken in V70.

Logs attached of it working in V69 and not working in V70

[JimH]

Try toggling SetNext on the Renderer.

[AndrewFG]

I think bob made some recent “improvements” that probably broke your renderers.

Notwithstanding this, this is the second time this week that I have seen a case where the DMRA’s native discovery process seemed to get banjaxed by Windows 10, and it had to fall back to Windows discovery. There is evidently something firewally going on here, that’s not entirely obvious. Please keep an eye on this. We may need to find out more..

[jmone]

Try toggling SetNext on the Renderer.

No Difference

[jmone]

I think bob made some recent “improvements” that probably broke your renderers.

Notwithstanding this, this is the second time this week that I have seen a case where the DMRA’s native discovery process seemed to get banjaxed by Windows 10, and it had to fall back to Windows discovery. There is evidently something firewally going on here, that’s not entirely obvious. Please keep an eye on this. We may need to find out more..

It may be a per instance thing as well.  I up graded the laptop to the same Windows build and DMRA still works fine on that one ... but when upgradeding MC to more than V69 playback DLNA control stops working for these speakers.

[bob]

generating a pair of wireshark traces of 69 and one not working >69 would be the most useful in this situation. Since it’s really a simple repeatable failure it should be straightforward to do.
Install wireshark on the windows pc
Setup a capture filter on the Ethernet interface, host 1.2.3.4 where 1.2.3.4 is your renderer.
Get ready to play a track
Start the capture
Play the track
Stop the transfer as soon as playback starts or fails.
Save the captures and email them to bob (at) JRiver.com
Thanks

[jmone]

Thanks - Captures sent...

[petekowalsky]

Same issue here with DLNA on MC23 but on MacOS 10.13. Trying to play to BubbleUPnP -> Chromecast Audio, and was getting the same error messages. Re-installed MC22, and it worked with no issues. Now to find what build of MC23 it works on...

Great software - always gonna be bugs - happy to help chase them down where needed. Thanks in advance for your fixes and hard work!

UPDATE!

[AndrewFG]

Thanks - Captures sent...

Just to be on the safe side could you please do the same with the DMRA on both machines? i.e. turn on HTTP logging, select the renderer, and send the log file.

[jmone]

Well that is Odd.  DMRA just worked without needing to "Use Windows Discovery" - Log attached...

[AndrewFG]

Thanks for sending the log. This log is about as perfect a test behavior as you could imagine. It indicates that the renderer is doing absolutely everything that it ought to.

You mentioned it working on one version of MC and not on another. But I can’t see anything on the DMRA log that might indicate such an issue is likely. But let’s wait to see what bob has to say on that.

Therefore I think your issue has to be something to do with your network of your firewall. As it appears on one PC but not on another, then I would tend to suspect a firewall thing on that PC. The DMRA Windows discovery issue supports that suspicion. But I have no idea why it would suddenly start working again. Modern firewalls do smart heuristics so it may have learned about the DMRA in the meantime. Or it may have looked up the DMRAs fingerprint online and found that other users had scored it good. It’s possible that the same issue might apply to MC — perhaps the earlier version of MC had earned a good score, but the later version is still too new to be trusted?? Or something like that??

[jmone]

I think 2 different issues. 
- DMRA:  I've had more of a play and it can take a of few times pressing "Select a Media Renderer" to display DLNA Devices when "Use Windows Discovery" is not checked.  It will work, sometimes the first time, sometimes the Nth Time.
- MC: Always sees the DLNA Devices and will show control information about what is playing on the devices and can control playback (Pause/Play etc) but from V70 onwards can not commence playback on just SOME of my devices (the Axiom Airs).

[bob]

I think 2 different issues. 
- DMRA:  I've had more of a play and it can take a of few times pressing "Select a Media Renderer" to display DLNA Devices when "Use Windows Discovery" is not checked.  It will work, sometimes the first time, sometimes the Nth Time.
- MC: Always sees the DLNA Devices and will show control information about what is playing on the devices and can control playback (Pause/Play etc) but from V70 onwards can not commence playback on just SOME of my devices (the Axiom Airs).

Ok, the obvious difference is that .69 is sending the file as a mp3 and .70 is sending it as flac. I'm guessing your axiom can't play flac.
If you have the DLNA server set to "Specified format when necessary" on both .69 and .70 (and newer) you can specify WHICH formats the device needs converted under the DLNA server Audio->Advanced section. It's possible the defaults were wrong. It should by default have been set to convert everything that's not .mp3 or .l16 (very unusual) to .mp3.

I did also notice that there seems to be more chatter than necessary between the MC and the Axiom. Looking into that.

[jmone]

Thanks.  I'll retest when I'm back.  When doing the captures I did not change any setting between versions.  Just installed and captured (laptop).  I'm pretty sure that the Axiom plays FLAC and on my Main PC I had tested various output formats including mp3 and L16 without luck.  It may be a few days before I can retest.

[AndrewFG]

The Axiom reports in GetProtocolInfo that it can support both audio/flac and audio/x-flac..

[bob]

The Axiom reports in GetProtocolInfo that it can support both audio/flac and audio/x-flac..

Interesting. Here is the flac resource it's getting sent:

Code: [Select]

res protocolInfo="http-get:*:audio/x-flac:DLNA.ORG_PN=FLAC;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000" duration="0:03:51.000" size="29416063" nrAudioChannels="2" sampleFrequency="44100" bitsPerSample="16">http://192.168.1.125:52100/Music/F4.flac</res
And here is the resource it's getting for mp3:

Code: [Select]

res protocolInfo="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000" duration="0:03:51.000" size="9424501" nrAudioChannels="2" sampleFrequency="44100" bitsPerSample="16">http://192.168.1.125:52100/Music/F4.mp3</res
Do you see any issues there Andrew?

[AndrewFG]

Both those res entries look good to me (apart from the obvious missing XML delimiters).

However it is perhaps worth mentioning (not sure why) that the Axiom unit does NOT claim to support the L16 format. Even though it (therefore wrongly) claims to be DLNA compliant.

[bob]

Both those res entries look good to me (apart from the obvious missing XML delimiters).

However it is perhaps worth mentioning (not sure why) that the Axiom unit does NOT claim to support the L16 format. Even though it (therefore wrongly) claims to be DLNA compliant.

I wonder perhaps if it doesn't like this:
DLNA.ORG_PN=FLAC
Perhaps under advanced options one could turn off both DLNAExtra and DLNA to see if that makes a difference.

[AndrewFG]

Bob I am not sure what you are getting at here. Not having seen the MC logs. Is the renderer somehow failing when you send SetAVT? Does it thereafter indicate a state change TRANSITIONING or PLAYING? And/or does it send a HEAD or GET request for media? And if so does it request a specific mime-type or types? And if so does MC actually supply that mime-type?

[jmone]

So - I'm back at home in 24hrs.  What do you want me to try/log etc (and with what version of MC).

[jmone]

I did another capture, this time with a MP3 using the Generic DLNA Profile.  Same as before, V69 Works / V70 Fails.  I've sent you both a link in the PM.  I did not change any settings at all between V69 and V70 (just installed V70 over the top of V69)

[bob]

Bob I am not sure what you are getting at here. Not having seen the MC logs. Is the renderer somehow failing when you send SetAVT? Does it thereafter indicate a state change TRANSITIONING or PLAYING? And/or does it send a HEAD or GET request for media? And if so does it request a specific mime-type or types? And if so does MC actually supply that mime-type?

Andrew, it never gets that far.
The transaction ends as soon as SetAVTransportURI is done.
I'm not seeing why. The last dump appears to have identical SetAV's...

[bob]

I did another capture, this time with a MP3 using the Generic DLNA Profile.  Same as before, V69 Works / V70 Fails.  I've sent you both a link in the PM.  I did not change any settings at all between V69 and V70 (just installed V70 over the top of V69)

This is pretty odd. The SetAVTransportURI commands from success and failure look the same. The connection is terminated right after that command is sent.

With the Generic profile, the default option is "specified format when necessary" and under Advanced in that section are the choices of formats to convert, can you tell me what's checked there??

Also, does this same profile work in .70 to other devices?

One other thing to try is to turn on the "ignore transport events" switch in the DLNA controller option for the axiom.

Finally perhaps a MC log of 70 failing with a mp3 to the axiom would be good.

[jmone]

DLNA Server Settings (Generic DLNA) - Specified output format only when necessary, and the following are checked:
- DLNA
- DLNA Extra

I can play to a Pio DLNA Speaker in V70 Just fine

I've attached a Log from V70 of:
- Axiom Speaker : Fail
- Pio Speaker : Works

[bob]

DLNA Server Settings (Generic DLNA) - Specified output format only when necessary, and the following are checked:
- DLNA
- DLNA Extra

I can play to a Pio DLNA Speaker in V70 Just fine

I've attached a Log from V70 of:
- Axiom Speaker : Fail
- Pio Speaker : Works

Thanks.
What are the formats specified in 70 under the DLNA server configuration->Audio->Advanced->Audio Formats to Convert?

[jmone]

Nothing is checked

[bob]

Nothing is checked

I assume it's set to "Specified format when necessary" ?

[jmone]

Yes

[jmone]

Did the latest MC Log give any hints?

[bob]

Did the latest MC Log give any hints?

Perhaps.
In the zone for the device, is the DLNA controller option "Ignore GetPosition Failure" checked or unchecked?

[bob]

I'm thinking that might have an effect.
Can you try reversing whatever it's set to and see if that makes a difference?

[jmone]

Nope - makes no difference

[bob]

Nope - makes no difference

Ok to match the setting your Generic DLNA server in 70 in the DLNA server configuration->Audio->Advanced->Audio Formats to Convert dropdown would you please select everything but mp3 (so it matches what the behavior was before), powercycle the axiom and try again?

[jmone]

Done - no differnce

[bob]

Done - no differnce

I'm stumped!
Turn off any firewalls on your windows PC long enough to run a test?

[jmone]

Done - No Difference. 

All I know is that it works 100% for all version up to V69 and 0% from V70 regardless of the settings or source material (or windows/network settings).  One of the changes in V70 must be impacting it, but only for the Axiom Air not other DLNA devices (fyi - the Axiom Air is actually a RasPie running a custom Volumio build).  Over the weekend I'll sideload MC on the device and I bet that will work.

[bob]

Done - No Difference. 

All I know is that it works 100% for all version up to V69 and 0% from V70 regardless of the settings or source material (or windows/network settings).  One of the changes in V70 must be impacting it, but only for the Axiom Air not other DLNA devices (fyi - the Axiom Air is actually a RasPie running a custom Volumio build).  Over the weekend I'll sideload MC on the device and I bet that will work.

Ok that's helpful. I can try setting up a Volumio server here and try it tomorrow.

[jmone]

You could borrow one of my Air's - want to swing by and pick it up? 

[bob]

You could borrow one of my Air's - want to swing by and pick it up? 

Love to!
I haven't been there since 1991!!

[bob]

Ok that's helpful. I can try setting up a Volumio server here and try it tomorrow.

Ok, I reproduced it.
It didn't always happen but did frequently when the device was first started up.
It seems that when I reduced the timeout on response to the DLNA command to 2 seconds from 10 Volumio isn't always fast enough to respond.
There could also be an issue with retries. I'm checking on that... Anyway putting the timeout to 4 seconds seems to make it always work.

[jmone]

Good sleuthing! 

[jmone]

I presume the fix is NOT in V86 (still does not work).  Don't you love how obvious a soln is.... once you find it (but up to that point it is a head scratcher!!)

[bob]

I presume the fix is NOT in V86 (still does not work).  Don't you love how obvious a soln is.... once you find it (but up to that point it is a head scratcher!!)

It didn't quite make it in yet. Next build will have it. I'm giving more time for the SetAV commands to execute.
I'm guessing Volumio is starting to do some of the work involved with the transfer before returning from the SetNext call even though play hasn't been triggered yet...

[AndrewFG]

It didn't quite make it in yet. Next build will have it. I'm giving more time for the SetAV commands to execute.
I'm guessing Volumio is starting to do some of the work involved with the transfer before returning from the SetNext call even though play hasn't been triggered yet...

Yeah. It will do a GET to start to preload the stream into buffer to ensure a gapless play (especially for SetNextAVTU rather that SetAVTU), and so it will check MC’s response to that GET to confirm an HTTP 200 response and that the mime type header etc. are Ok before it sends its response to the SetAVTU call. So its possible that a delay in MC’s GET media server might in fact be the cause of the delay in the renderers SetAVTU response. (In particular if MC is transcoding..)

EDIT: so you might even consider tweaking MC’s timeout on SetAVT calls depending on whether you see that GET (or HEAD) and when you respond to it..

[bob]

Yeah. It will do a GET to start to preload the stream into buffer to ensure a gapless play (especially for SetNextAVTU rather that SetAVTU), and so it will check MC’s response to that GET to confirm an HTTP 200 response and that the mime type header etc. are Ok before it sends its response to the SetAVTU call. So its possible that a delay in MC’s GET media server might in fact be the cause of the delay in the renderers SetAVTU response. (In particular if MC is transcoding..)

EDIT: so you might even consider tweaking MC’s timeout on SetAVT calls depending on whether you see that GET (or HEAD) and when you respond to it..

Interesting and it makes sense. MC shouldn't delay in returning from the GET though since it serves the file while it's being transcoded. I'll need to check the wireshark trace to be sure.
edit: Ok checked. It seems the axiom is just incredibly slow in responding to the SetAV.
The trace goes like this:

Code: [Select]

Seconds       Action
6.5            MC Sends SetAV
10.4           Axiom responds
10.4           MC sends Play
10.5           Axiom requests the file with a GET.
There is nothing in the trace between the 6.5 and 10.4 second marks. Hard to figure what it could be doing for 4 seconds.