INTERACT FORUM
More => Old Versions => JRiver Media Center 24 for Windows => Topic started by: PGibby on April 17, 2018, 07:11:50 pm
-
Has anyone else ran across this one with MC24? Casting from an Android device, I get the error "renderer does not support action play (renderer bug?)". This worked with MC23, so wondering if there is a setting that needs to be changed. I've already flipped media network off and on. Bubbleupnp sees MC24, I just get the error when picking a track to play.
-
Could be firewall.
-
I disabled the firewall on both windows pcs, and I get the same error still with MC24. The one PC I have with MC23 still works.
Any other ideas anyone?
-
Both Bubble and MC certainly support the action PLAY().. so it is indeed very likely to be a problem on your firewall (most likely you have set your firewall and/or Windows Defender to allow MC23 through, but have not yet set it/them to allow MC24 through.)
-
I'll dive a little deeper into those settings then. :)
-
Ok, little more testing.
Firewall settings were default to allow MC24 through..so that is good. Disabling the firewall also doesn't fix it.
Now, couple additional observations:
Volume control from my android device is recognized on MC24. Also, if something is playing on MC24 initiated from that PC, I can connect with bubbleupnp and hit "stop". Whatever is playing on MC24 will stop.
So, controls work. It simply has that error when hitting play.
MC23 works flawlessly. I confirmed that MC24 firewall settings are identical to MC23.
-
Ok. So what are you trying to play? Are you converting media to a format that Bubble does not support?
-
Nope. Using BubbleUPNP to pull from Tidal with the Android device, and rendering with MC24. But, local files also fail the same way with MC24.
MC23 works swimmingly with BubbleUPNP/Tidal and local files using the same Android device.
Weird, isn't it? ?
-
Compare the DLNA server settings in MC23 and MC24 (Tools | Options | Media Network)
-
Yep, those are setup identically. Same result. MC23 works great, MC24 gets the error.
-
If one works and the other doesn't, either the settings are different, or a firewall or other "security" software is blocking.
-
Just wanted to say that I'm experiencing the same problem. I'd been using BubbleUPNP to interact with MC23 without any trouble at all.
Upgraded to MC24 this afternoon, went through the express upgrade process and am getting the "Renderer does not support action play (renderer bug?)" error as well with MC24.
Have disabled all firewalls and I'm still encountering the error.
-
What OS are you using?
I have win7 and win10. Both do it.
-
Windows 10.
I went into the Windows Defender and opened up everything I could think of, private and public, to MC24 but the error continues.
-
Interesting. I upgraded to MC24 and use BubbleUPnP and have not had this issue. I did have to restart the service on my Raspberry Pi that's running BubbleUPnP, but then MC24 picked up the dynamic zone and I played to it. I thought that was odd because I hadn't restarted the service in a few months I think. I don't use it terribly often, but I'll try it again a few times the next couple of days to test.
-
Do you have both MC23 and MC24 running at the same time? If the MC23 media server is sitting on the TCP/UDP listener ports, then the MC24 instance wont see the incoming messages from the renderer..
-
Hi, same bug here. I use BubbleUPnP on my PixelC tablet to stream (from tidal or from my local NAS) music with the MC 24 DLNA Renderer.
KO with MC24 even with Windows Defender and the Firewall disabled (Windows 10 Fall Creator Update). MC 23 is stopped (no background server) while doing the test with MC24.
OK with MC23 with the same settings.
Very annoying bug but MC is still the best media center !!
-
I've been running with only 1 instance of MC at any time.
-
Is Media Server running from MC23 or another previous version?
-
I can confirm the same problem here also. Win7 / Latest public MC24 64bit. MC23 service is not running.
Edit: If I change to any other renderer (TV, Foobar2000 etc.) it starts playing from MC server
-
Is Media Server running from MC23 or another previous version?
Nope, as part of my troubleshooting I uninstalled MC23 just to make sure.
-
I can confirm the same problem here also. Win7 / Latest public MC24 64bit. MC23 service is not running.
Are we all having problems with the 64bit version of MC24? Mine is also 64bit. And I believe my MC23 was the 32bit version.
-
That's something I haven't tried. I've been exclusively using 64 bit.
-
I started getting the message 'Renderer does not support action Play’ when I upgraded to MC24, I was using Bubble UPnP to play from Android.
I've been using MC running on Win7 32bit, playing to a DAC via USB.
Last night I installed the JRemote app, which you have to purchase and I was able to play music again using my phone.
-
I've identified the issue.
MC24 defines a non standard Play action in the AVTransport service, with additional arguments. From AVTransport/scpd.xml:
<action>
<name>Play</name>
<argumentList>
<argument>
<name>InstanceID</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable>
</argument>
<argument>
<name>Speed</name>
<direction>in</direction>
<relatedStateVariable>TransportPlaySpeed</relatedStateVariable>
</argument>
<argument>
<name>JRiverSyncPlayTime</name>
<direction>in</direction>
<relatedStateVariable>NextSyncPlayTime</relatedStateVariable>
</argument>
<argument>
<name>JRiverSyncServer</name>
<direction>in</direction>
<relatedStateVariable>NTPServerURL</relatedStateVariable>
</argument>
</argumentList>
</action>
It should be:
<action>
<name>Play</name>
<argumentList>
<argument>
<name>InstanceID</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable>
</argument>
<argument>
<name>Speed</name>
<direction>in</direction>
<relatedStateVariable>TransportPlaySpeed</relatedStateVariable>
</argument>
</argumentList>
</action>
-
Thanks. Can you ignore the change? I think I know the answer.
(I put a blank line in the source before and after the offending lines.)
Sorry to cause you the trouble and thanks for posting what you found.
-
Hi Jim,
I cannot easily workaround this issue.
First, the third party UPnP library used by BubbleUPnP discards action Play when parsing the AVTransport XML because it mentions 2
relatedStateVariable (NextSyncPlayTime and NTPServerURL) but is missing their definition block like other related state variables.
What's missing is is a <stateVariable> tag for both of them.
Then, assuming this would be fixed, the UPnP library validates that the number of arguments passed match the call and fails otherwise. The standard call has 2 parameters.
These added parameters is going to break compat with some control points, thus not a good idea. I suggest adding a separate command PlayMC with the added arguments.
-
Hallo guys.
I have been saying this clearly on the beta forum for a while already, but I will repeat it here again
I do applaud JRiver trying to implement a synchronised playing functionality..
HOWEVER you should NOT do it by creating your a non standard proprietary own kludge creation soap action..
PLEASE do this properly according the the UPNP approved standard DMR v3 SyncPlay action.
As you can see, going your own proprietary way, is NOT the proper solution, and as you see already, it has already resulted in breaking existing inter working with other renderers..
-
Andrew,
I can appreciate your point of view, but if the standard hasn't been implemented by anyone, it's not really a standard.
You may be right, but we're a long way down the road from that decision point. It's proprietary at the moment, but we may make it more open, even if it's ad hoc.
We'll solve the problem with breaking renderers.
Jim
-
We'll put it in a separate namespace.
-
There will be a quick fix in the next build (fixed the missing state variables bug). This made it work fine on my Bubble UPNP Android app. At a later date we'll come out with a namespaced version similar to how OpenHome did it.
-
I still think you should implement the standard. And not go proprietary. There is nothing wrong with being the first implementer. And indeed possibly great kudos. It is possible that renderer manufacturers have been holding back due to lack of a CP, and if you were to break the ice, possibly a whole bunch of people will join you. You never know, but perhaps Bubbleguum might work with you on this. And I am certainly willing to help with certification and test..