Yup, definitely the port causing the issue. Since it shows two ports per IP in the log I tried deleting the port information from the dni. The devices worked but the warnings became errors. So then I tried changing the dni to one of the address + ports from the log. Now I get two different port/warnings.
I've been assuming this is something with media render. These devices are also Alexa enabled speakers. Maybe that's the app I should be investigating.
Well now they are using yet another set of ports...
I don't have any answers for you here.
Probably the Chinese army's back door trying to probe the hub thinking it's a server. /sarcasm
They're just warnings, I guess I'll deal with it with silent resentment and scathing looks whenever I look at the logs.
I have always needed a name for that when I do it!! 
Perfect, well done.
These error have to do with the implementation of some DLNA Media Players....
What is happening is the the App discovers a player, and adds a device for it, using IP:PORT as the DeviceNetworkId...
When the HE receive data from a DLNA player, it tries to match it with the correct device... by matching the DeviceNetworkId against:
If none of these three match a the DeviceNetworkId of an installed device, then the error is thrown...
The problem is... Many DLNA devices do NOT send data from the same port that is reported in the SSDP discovery response... So the device driver sends commands to IpAdress:49152, but the response data comes back from IpAddress:56789... and is dropped by the system...
(I have seen this behavior with an LG WebOS TV and a Jam Audio WiFi speaker)
So... I have been experimenting.... I modified the connect App and driver so that it uses the MAC address as the DeviceNetworkId... And the driver now receives all data sent from the player...
I'm still fighting with an issue that the parse routines do not parse the data from the LG TV properly... But that is a separate issue...
Any chance you can share your Mac address based version? My HEOS speakers exhibit the same behavior
I intend to share, after getting permission of the original author... and after I've had time to sort out the parsing routines...
Ok... I have the driver and app to a point that they no longer throw errors and seem to work well...
The files are available here: OLD VERSION REMOVED see THIS post.
When you initially upload the files to your HE, any existing DLNA devices you have will probably freak out and generate errors... this should be considered normal... You should then run the Mediarenderer (Connect) appand rediscover your devices. This will (should) regenerate your devices with their new DeviceNetworkID. If you have issues, you should delete the App (which will also delete the child devices) and add it again.
Major changes:
Be aware that not all exposed functions/commands work with all DLNA devices...
IE: The "speak"/"playText" functions do not work (using the build in TTS engine) with an LG WebOS TV, but does work with a Jam Audio Rythm speaker. The correct commands are sent, but no speech is emited by the device. (This is due to the mp3 format produced by the built-in TTS engine being rejected by the WebOS TV)
If you find anything that is not right, let me know and i'll try to get it working.
cybrmage, I installed the Driver and the App.
The App discovered 4 devices:
3 Samsung TVs
1 WD TV Media Player
But (using the commands in the Device Screen) anything appear to work (volumen, play, OFF, ON, or similar actions)
Am I doing something wrong?
Thank you. My Eufy speakers are doing TTS like champs without the logged errors. No more silent resentment or scathing looks at my log files.
If it using DLNA don't see why not.
I just update mine to your version @cybrmage but getting the below error now any idea?
2019-10-11 18:44:00.120 errorjava.lang.NullPointerException: Cannot invoke method getAt() on null object on line 1015
well i did have working! after the the above post but noticed i wasn't getting voice on jam symphony now. checked logs getting below error.
2019-10-23 15:48:00.351 errorgroovy.lang.MissingMethodException: No signature of method: static java.lang.Math.round() is applicable for argument types: (com.hubitat.hub.domain.State) values: [com.hubitat.hub.domain.State(2019-10-20 11:53:00.461, null, level, null, 50, NUMBER)] Possible solutions: round(float), round(double), find(), rint(double), find(groovy.lang.Closure), random() on line 563 (playTextAndRestore)
gone back to old scottma61 versions and i've got voice announcements working again with no error, so don't know what the issue is.
The problem is the way that the volume is being set. I can see a problem in line 563 of the driver. Try replacing lines 562-564 with these lines and see if it works instead:
def setVolume(val) {
mediaRendererAction("SetVolume", "RenderingControl", getDataValue("rccurl") , [InstanceID:0, Channel:"Master", DesiredVolume:val.toInteger()])
}Many thanks @Ryan780 i will give it a try but it's gonna be next week now when i have time. Takes a while re selecting the speaker in all the rules lol. Working on old one for now.
Actually... The problem is not with how the volume is being set.... It's with the data that is being passed to the function. The playByMode() function calls the setVolume() function with the "currentVolume" variable... This variable is defined by a call to device.currentState("level"), which returns a state object. The correct call should be to device.currentState("level").value to get the numerica value of the state.
I also found the the playByMode() function did not operate correctly, which is why the playTextAndRestore(), playTextAndResume(), playTrackAtVolume(), playTrackAndResume(), playTrackAndRestore(), playSoundAndTrack() and speak() functions did not function correctly. The playByMode() function builds an array of hub actions to send to the DLNA device... basically...
setVolume / setPlaymode / setTrack / play / delay / stop / setVolume / setPlaymode / setTrack / Play
This set the desired volume, sets the tts file as the track and plays the track... then delays for the length of the tts track... then stops playback... restores the original volume, sets the original track and starts it playing...
However, the "delay" hub action only works for Zigbee and Z-Wave protocols. So what happens is that the DLNA device is told to play the tts file then immediately stop the tts file, so it appears that it does not work.
I have refactored the function so that the required delay is used, and the functions now work as originally intended.
The updated version is v2.6.1
Thank you for this, before I used SmartThings with hublink to get the trackDescription, but the new update is the best.
However I'm getting this error, can you help me fix it please?
From the log:
" org.xml.sax.SAXParseException: The element type "CurrentTrackMetaData" must be terminated by the matching end-tag "". on line 186 (parse) "
From the event:
" org.xml.sax.SAXParseException; lineNumber: 26; columnNumber: 3; The element type "CurrentTrackMetaData" must be terminated by the matching end-tag "". "
Thanks for your help and hard work.
Download the Hubitat app
