Print

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

[tWreCK]

I get the following error while trying to stream from media center  - "There was a problem controlling the selected DLNA device. Double check your device, server & network settings."

I've searched the forum for similar problems/errors and your Wiki etc but haven't been able to resolve the issue. I'm running Windows 10 & Media Center 25. I'm not sure where the problem lies. I had a work pc running Windows 7 and Media Center 24 streaming video & music without a problem. Any help is appreciated......

[JimH]

You could read the wiki topic on DLNA.  It mentions that some devices work in one direction, but not the other.  I think you're trying to use the TV as a Renderer.  Depending on the device, it might work.

User AndrewFG has a program that can analyze the Renderer.  It's in his signature.

[tWreCK]

Yes - I'm using the TV as renderer. I've read the DLNA Wiki and configured the settings as best I could. Sometimes it's not quite clear where in media center you change certain settings.

As I mentioned above - it has worked in the past. Upgraded from MC 24 > MC 25. It's running on a Windows 10 pc. I ran AndrewFG's media renderer program but much of the info is over my head. I don't know what to look for or how to interpret the results. I've attached the report.

[RoderickGI]

Well, the report shows an error and unsupported capabilities:

AVT:SetNextAVTransportURI (gapless play)=Supported
AVT:SyncPlay (synchronous play)=NOT Supported
RC:GetVolume action=Supported
RC:SetVolume action=NOT Supported
AVT:Event Subscription=Missing Notification
RC:Event Subscription=Missing Notification
HTTP User Agent (client)=??
Play test file result=Play failed => Command "SetAVTransportURI" failed / Subscribe error

The important ones are bolded. Note that SetAVTransportURI is reported as supported, and yet it failed. I did see that a bit on my TV when testing earlier using a wireless network. I haven't seen it since I put the TV on an ethernet connection. I have also seen similar failures after trying to play something that the TV couldn't play. So reboot your TV and then run the Media Renderer Analyser again. That doesn't mean putting the TV into Standby Mode. Power it down and back up, or Reboot it using whatever method Samsung provides. Reboot the PC as well for good measure.

If the problem persists, for comparison my Sony KD-65X9300D shows the following for the same capabilities:

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
Play test file result=Play success => Start Ok / Stop Ok

I'm no expert, but it looks like your TV doesn't handle Transport Events. Try checking the "Ignore Transport Events" setting. If that doesn't work, check "Disable SetNext Support". See the image for how to find those.

Your TV seems to be about the same age as mine, a 2015 model, so I would expect similar capabilities. There may be some setting in your TV that needs to be turned on. For example in my Sony, I need to turn on its Renderer capabilities to be able to push media from MC to the TV. But then, if your TV is showing up in the Media Renderer Analyser, and identifies itself as a Renderer (UPnP Device Type=urn:schemas-upnp-org:device:MediaRenderer:1), then I expect it should work. The manual isn't very helpful. 

Try creating MC log of the failure and search it for "SetAVTransportURI" to see if there are any errors associated with it.
Search the forum for "SetAVTransportURI" and have a read of some of the threads. You might find a hint.

If you have more than one DLNA Server set up in MC, then make sure that you have one associated with your TV. The menu option for that is visible in the image.

Otherwise, hope that AndrewFG comes along to advise.

[RoderickGI]

Also, I forgot to mention. It could be that your firewall is blocking incoming HTTP traffic from the renderer. If you can, turn that off and try again.

See https://yabb.jriver.com/interact/index.php/topic,106260.msg738956.html#msg738956

[AndrewFG]

The problem is that the renderers state change notifications (transport events) are not getting through. There are three possible causes..

1) the renderer is not sending any notifications (in which case the Ignore Transport Events setting in MC might ameliorate it),

2) the client PC has a firewall that is blocking incoming HTTP calls (in which case change the firewall settings to allow MC.exe to receive incoming HTTP calls), or

3) the router is not routing those calls properly (this may be because the renderer and MC have IP addresses that are on different subnets than the router is able to route, in which case make sure that both client and renderer are getting their IP addresses from the router via DHCP reservations)

[tWreCK]

Thx for the replies 

AndrewFG -  tried setting Ignore Transport Events but that didn't resolve it. Renderer (Samsung TV) & MC (windows 10 PC) are on the same subnet and both have DHCP reservations receiving static IP's.   

In regards to the PC having a firewall - Windows Defender Firewall & Antivirus are running on the machine as of present. I have tried allowing MC in the firewall > same result. I deactivated windows defender firewall/antivirus completely in registry and local group policy > same result. I have no other AV programs running. I'm not sure what else I can do. I was able to stream from a different windows 10 PC to the same TV just a couple of weeks ago so it would seem logical something in windows is blocking that traffic  - i just don't know what.

[JimH]

You may have a Renderer that just won't work. Did you try using the Samsung TV to control MC?  Pull rather than push, just to see what happens.

Updating the Samsung's firmware might also help.

[tWreCK]

I don't know how to use the TV to control MC - can't find any option for that in the Samsung menus. The TV has the latest firmware.

If the renderer just doesn't work than it wouldn't have worked before either or am I missing something?

[RoderickGI]

You can use the TV to pull media from the MC Server by finding and starting the appropriate App on the TV. I don't have a Samsung anymore to look at, but on my Sony the Apps are "Music" for audio and "Video" for video media. Once the App is running, look for a way to search for a select "Devices" or "Computers" or "Servers". You should find your MC Server listed in there. Select it and it should load information from the MC Library.

Actually, come to think of it, the Samsung I used to have may have let me select a DLNA Server such as MC in the Source listing on the TV, and then I could select contents and play them. Maybe a Google of how to do it would answer that question.

But that isn't a great experience, to put it mildly. Most TV Apps just let you scroll through long lists of media files, with little search capability. They are frustrating to use. Also, for example, the Sony Video App will happily show the Audio, Image, Podcast, and Video "directories" in MC, but will only let me play video. There is no one App that plays all media types on the Sony TV.


To the firewall. First, I use a Norton firewall, so can't advise exactly. But I know it is almost impossible to completely turn off Windows Defender. Even on my PC that uses Norton, Windows Defender will block some traffic during bootup at least. So I think the best idea is to turn Windows Defender back on, and make sure it has the correct rules.

First, check if MC can see the HTTP Messages/Calls being sent by the TV, if it is sending any. My TV is visible now as a renderer, and I can play Audio, Video, and Images to it, when connected from my Workstation installation of MC. When I run MC with the TV turned on I can go to;
Left Navigation Bar > Services & Plug-ins > Media Network > Select the MC DLNA Server associated with my TV "DLNA Media Server: Amintha (Sony TV)" and I will see HTTP GET and POST messages being from the TV to my Workstation. The TV is IP Address 192.168.0.12 and my Workstation is IP Address 192.168.0.10. See that attached image.

So, if I am interpreting that information correctly, my Workstation is allowing Inbound HTTP Messages/Calls from the TV. If I am wrong Andrew or anyone, please correct me!

Selecting the "DLNA Subscription Server" on that Media Network page also shows DLNA Event Notifications. See the second image.

You may want to check if you are seeing the same sort of Messages/Calls for your TV.

Interestingly, if I select the "Device discovery server (SSDP)" on the Media Network page mentioned above, I don't see any SSDP broadcast messages from the TV, which I would expect to see. I think that means that the TV isn't advertising itself. Yet DLNA Servers and Controllers see it. That is a mystery.


Anyway, back to the firewall issue. Given that my Workstation can see Inbound HTTP Messages, I went looking for a firewall rule that was allowing it.

I thought this one might be the rule, since it is called "Default Allow Media Player Sharing - HTTP (Private Network)". But it restricted Communications to port 10243, so no go.
Action: Allow connections that match this rule
Connections: Connections from other computers
Computers: Any computer in the local subnet
Communications: The rules will apply only if it matches all of ports the listed below: TCP, local port 10243
Advanced: not relevant
Description: Default Allow Media Player Sharing - HTTP (Private Network)


That rule sounds almost correct, but the actual communications are happening on ports 52101 an 52104, in the examples I posted above. While I have mostly seen ports in the range of 52100 to 52200 in the past, consistent with what I know of MC use of ports, I have seen port 52323 used at one time.


One of the two rules below, or both if these Messages are TCP rather than UDP, are probably what is allowing MC to see the Calls. I haven't tried to work out if these Messages/Calls are using TCP or UDP packets.

Action: Allow connections that match this rule
Connections: Connections from other computers
Computers: Any computer in the local subnet
Communications: The rules will apply only if it matches all of the ports listed below: TCP, All types of communication (all ports, local and remote)
Advanced: not relevant
Description: Default All Windows Media Player Sharing (Private Network)

Action: Allow connections that match this rule
Connections: Connections from other computers
Computers: Any computer in the local subnet
Communications: The rules will apply only if it matches all of the ports listed below: TCP and UDP, All types of communication (all ports, local and remote)
Advanced: not relevant
Description: Default All Windows Media Player Network Sharing (Private Network)

So look for the rules above, or similar, in your Firewall. If you don't have either, you may need to create them. Unless someone else speaks up with better information.

[AndrewFG]

Thx for the replies 

AndrewFG -  tried setting Ignore Transport Events but that didn't resolve it. Renderer (Samsung TV) & MC (windows 10 PC) are on the same subnet and both have DHCP reservations receiving static IP's.   

In regards to the PC having a firewall - Windows Defender Firewall & Antivirus are running on the machine as of present. I have tried allowing MC in the firewall > same result. I deactivated windows defender firewall/antivirus completely in registry and local group policy > same result. I have no other AV programs running. I'm not sure what else I can do. I was able to stream from a different windows 10 PC to the same TV just a couple of weeks ago so it would seem logical something in windows is blocking that traffic  - i just don't know what.

It’s worthwhile keeping in mind that it fails to play both with my DMRA and also with MC. So the odds are on it being a problem either with the renderer itself, or with something blocking the traffic. I can’t really offer anything more..

[tWreCK]

Hey all,

Thx for all the helpful suggestions. The knowledge here is mindblowing. I've learned a great deal just by reading your posts (as well other threads here on the forum).

But Andrew you called it! After going back and forth with all the settings in MC and windows etc it all came down to the fact that for some odd reason "someone" had set the client pc manually with a static IP ? The static IP was the same IP my router was set to offer via DHCP but the mask was wrong. I flipped the client back to DHCP and voila! - streaming success once again! I should've checked this first thing but I was looking at the router etc. Just goes to show one should never take for granted the simplest of things when it comes to all things computer! Thx again guys - appreciate the help 

[RoderickGI]

Excellent.

I never think of that one, as I only use IP Address Reservations, or let DHCP assign a random one. I quit using Static IP Addresses for any of my devices decades ago.

This has been a learning exercise for me too, as I'm trying to understand better how DLNA works... and why it sometimes doesn't.

[AndrewFG]

I never think of that one, as I only use IP Address Reservations, or let DHCP assign a random one. I quit using Static IP Addresses for any of my devices decades ago.

This is a very frequent problem. Many routers won’t route traffic on IP addresses that they have not assigned themselves. Routers won’t route on IP addresses outside their own subnet. A router has no way of knowing if a device has set itself a static address so it risks to assign that same address to another device via its DHCP mechanism. UPNP generally works better if the IP addresses of servers and renderers are not changing all the time. And nothing will work if more than one device is using the same IP address.

So my recommendations are always 1) to have the router assign the addresses via DHCP (i.e. do NOT set the IP addresses statically inside the devices themselves), and 2) set the router DHCP mechanism to reserve the IP address that it first assigns to a particular device, so that it will always re-assign that address to that device whenever its DHCP reservation expires.

[JimH]

This is a very frequent problem. Many routers won’t route traffic on IP addresses that they have not assigned themselves. Routers won’t route on IP addresses outside their own subnet. A router has no way of knowing if a device has set itself a static address so it risks to assign that same address to another device via its DHCP mechanism. UPNP generally works better if the IP addresses of servers and renderers are not changing all the time. And nothing will work if more than one device is using the same IP address.

So my recommendations are always 1) to have the router assign the addresses via DHCP (i.e. do NOT set the IP addresses statically inside the devices themselves), and 2) set the router DHCP mechanism to reserve the IP address that it first assigns to a particular device, so that it will always re-assign that address to that device whenever its DHCP reservation expires.

We're very lucky to have AndrewFG's presence on this forum.  I've added a link to this on the DHCP topic on our wiki.  Thanks again, Andrew.

[tWreCK]

set the router DHCP mechanism to reserve the IP address that it first assigns to a particular device, so that it will always re-assign that address to that device whenever its DHCP reservation expires.

In most routers there is usually a function within the DHCP section called "manual assignment" or "MAC binding" (at least in mine there is) which will do exactly what Andrew explained. Your router assigns a set IP address via DHCP to a specific client (MAC address) everytime regardless of when the reservation expires. You're basically setting a "static IP" within the DHCP scope for the various clients (servers, printers, DC's etc).   

[RoderickGI]

My current, new, ISP provided router calls the function "Static Leases". Lots of different names, but it's the same process; assign an IP Address permanently via DHCP by reference to the MAC Address.

I will always think of it as "IP Address Reservation" though.