CPU : Intel Core i5-3570K 4x 3.40GHz
GPU : MSI Geforce GTX 960 2GB Limited Edition
RAM : 24 GB DDR3-RAM 1600MHz
Windows 10
- I have JAVA 8 Update 91 32Bit and 64Bit
- UMS has at the Start a CPU load of 0-5%.
- 30~min later UMS has a CPU load of 30% every Time.
- Screenshot: http://prntscr.com/btmd36
- LOG:
14:10:17 DEBUG Sending ALIVE...
14:10:37 DEBUG Sending ALIVE...
14:11:07 DEBUG Sending ALIVE...
14:11:37 DEBUG Sending ALIVE...
14:12:07 DEBUG Sending ALIVE...
14:12:37 DEBUG Sending ALIVE...
14:13:07 DEBUG Sending ALIVE...
14:13:37 DEBUG Sending ALIVE...
14:14:07 DEBUG Sending ALIVE...
14:14:37 DEBUG Sending ALIVE...
14:15:07 DEBUG Sending ALIVE...
14:15:37 DEBUG Sending ALIVE...
14:16:07 DEBUG Sending ALIVE...
14:16:37 DEBUG Sending ALIVE...
14:17:07 DEBUG Sending ALIVE...
14:17:37 DEBUG Sending ALIVE...
14:18:07 DEBUG Sending ALIVE...
14:18:37 DEBUG Sending ALIVE...
14:19:07 DEBUG Sending ALIVE...
14:19:37 DEBUG Sending ALIVE...
14:20:07 DEBUG Sending ALIVE...
14:20:37 DEBUG Sending ALIVE...
14:21:07 DEBUG Sending ALIVE...
14:21:37 DEBUG Sending ALIVE...
14:22:07 DEBUG Sending ALIVE...
14:22:37 DEBUG Sending ALIVE...
14:23:07 DEBUG Sending ALIVE...
14:23:37 DEBUG Sending ALIVE...
14:24:07 DEBUG Sending ALIVE...
14:24:37 DEBUG Sending ALIVE...
14:25:07 DEBUG Sending ALIVE...
14:25:37 DEBUG Sending ALIVE...
14:26:07 DEBUG Sending ALIVE...
14:26:37 DEBUG Sending ALIVE...
14:27:07 DEBUG Sending ALIVE...
14:27:37 DEBUG Sending ALIVE...
14:28:07 DEBUG Sending ALIVE...
14:28:37 DEBUG Sending ALIVE...
14:29:07 DEBUG Sending ALIVE...
14:29:37 DEBUG Sending ALIVE...
14:30:07 DEBUG Sending ALIVE...
14:30:37 DEBUG Sending ALIVE...
14:31:07 DEBUG Sending ALIVE...
14:31:37 DEBUG Sending ALIVE...
14:32:07 DEBUG Sending ALIVE...
14:32:37 DEBUG Sending ALIVE...
14:33:07 DEBUG Sending ALIVE...
14:33:37 DEBUG Sending ALIVE...
14:34:07 DEBUG Sending ALIVE...
14:34:37 DEBUG Sending ALIVE...
14:35:07 DEBUG Sending ALIVE...
14:35:37 DEBUG Sending ALIVE...
14:36:07 DEBUG Sending ALIVE...
14:36:37 DEBUG Sending ALIVE...
14:37:07 DEBUG Sending ALIVE...
14:37:37 DEBUG Sending ALIVE...
14:38:07 DEBUG Sending ALIVE...
14:38:37 DEBUG Sending ALIVE...
14:39:07 DEBUG Sending ALIVE...
14:39:37 DEBUG Sending ALIVE...
14:40:07 DEBUG Sending ALIVE...
14:40:37 DEBUG Sending ALIVE...
14:41:07 DEBUG Sending ALIVE...
14:41:37 DEBUG Sending ALIVE...
14:42:07 DEBUG Sending ALIVE...
14:42:37 DEBUG Sending ALIVE...
14:43:07 DEBUG Sending ALIVE...
14:43:37 DEBUG Sending ALIVE...
14:44:07 DEBUG Sending ALIVE...
14:44:37 DEBUG Sending ALIVE...
14:45:07 DEBUG Sending ALIVE...
14:45:37 DEBUG Sending ALIVE...
14:46:07 DEBUG Sending ALIVE...
14:46:37 DEBUG Sending ALIVE...
14:47:07 DEBUG Sending ALIVE...
14:47:37 DEBUG Sending ALIVE...
14:48:07 DEBUG Sending ALIVE...
14:48:37 DEBUG Sending ALIVE...
14:49:07 DEBUG Sending ALIVE...
14:49:37 DEBUG Sending ALIVE...
14:50:07 DEBUG Sending ALIVE...
14:50:37 DEBUG Sending ALIVE...
14:51:07 DEBUG Sending ALIVE...
14:51:37 DEBUG Sending ALIVE...
14:52:07 DEBUG Sending ALIVE...
14:52:37 DEBUG Sending ALIVE...
14:53:07 DEBUG Sending ALIVE...
14:53:37 DEBUG Sending ALIVE...
14:54:07 DEBUG Sending ALIVE...
14:54:37 DEBUG Sending ALIVE...
14:55:07 DEBUG Sending ALIVE...
14:55:37 DEBUG Sending ALIVE...
14:56:07 DEBUG Sending ALIVE...
14:56:37 DEBUG Sending ALIVE...
14:57:07 DEBUG Sending ALIVE...
14:57:37 DEBUG Sending ALIVE...
14:58:07 DEBUG Sending ALIVE...
14:58:37 DEBUG Sending ALIVE...
14:59:07 DEBUG Sending ALIVE...
14:59:37 DEBUG Sending ALIVE...
15:00:07 DEBUG Sending ALIVE...
15:00:37 DEBUG Sending ALIVE...
15:01:07 DEBUG Sending ALIVE...
15:01:37 DEBUG Sending ALIVE...
15:02:07 DEBUG Sending ALIVE...
15:02:37 DEBUG Sending ALIVE...
15:03:07 DEBUG Sending ALIVE...
15:03:37 DEBUG Sending ALIVE...
15:04:07 DEBUG Sending ALIVE...
15:04:37 DEBUG Sending ALIVE...
15:05:07 DEBUG Sending ALIVE...
15:05:37 DEBUG Sending ALIVE...
15:06:07 DEBUG Sending ALIVE...
15:06:37 DEBUG Sending ALIVE...
15:07:07 DEBUG Sending ALIVE...
@DaniGTA Did any Java update was running in background without your knowledge ? maybe automatic upgrade to Java 8u92...
If you get again this problem, could you provide your full log, please ?
http://www.universalmediaserver.com/forum/viewtopic.php?f=3&t=556
Nope no Java update was running wenn it starts get stuck at 32% CPU load it will be for ever and the Programm dont crash but the overlay get frezzed and you cant do nothing but Streams working.I have tried to make a log but it frezzed and i cant press "Make a package", http://prntscr.com/bz38mx i get this Problem every day because i have this Programm in the Autostart folder.
@DaniGTA Thanks for your feedback.
If you cannot do from the "Pack debug file" in the _Logs_ tab, do it with "Open full debug log" on the right down, and post the .txt file.
Could be a Java issue, not necessary UMS fault though...let's see if your log can help.
EDIT: But as you say you have 2 Java version installed, i will strongly suggest you to uninstall both versions with the special uninstall tool https://java.com/en/download/faq/uninstaller_toolinfo.xml restart your computer and reinstall the latest version that you really need http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html (32 OR 64 bit, not both since you'll only get problem)
If you don't know which Java version choose, i suspect 64-bit to be the correct one, install with "online download" from https://www.java.com/en/download/help/windows_manual_download.xml
Yes i had java 8 Update 101 32Bit and Java 8 Update 101 64 Bit installed,i have now uninstalled the 32Bit version
But it dosent has fix the CPU load bug,
here is the LOG:
debug.txt
@DaniGTA Do you mean you uninstalled all cleanely, restart and reinstall the 64-bit version ?
I ask you that because Java could be messy sometimes...and just uninstalling the 32-bit version will not resolve an eventual Java problem.
I have only uninstalling the 32bit version
@DaniGTA This is just guessing, but I see a couple of things I'd like you to try to change:
Anycast as the default renderer. Please set it back to Unknown player. It the second setting from the bottom on the General tab.General tab.@DaniGTA When you will set back your default renderer to Unknow renderer untick Force default renderer as well and post an other log.
This does not exempt you from properly reinstall Java tough. Two precautions are better than one ;-)
When i set to Unknow renderer my Blueray player wont play MKV. And it didnt fix the bug
Here is the other log with Unknow renderer and without Force default renderer
btw: before i had make this log i had clean installed java and restarted my PC.
debug.txt
@DaniGTA Since we don't have your full log, can you tell what renderer you are using, what model of Blueray player ? And post a copy of your "Unbekannter DLNA Client" file, don't forget to post it with an _.txt_ extension.
I use the AnyCast renderer for my SONY BDP-S6500 3D Blu-ray Player.
AnyCast.txt
And "Unbekannter DLNA Client" dont have a file in the folder renderers.
@DaniGTA So, when i see your renderer specifications https://esupport.sony.com/US/p/model-home.pl?mdl=BDPS6500&template_id=1®ion_id=1&tab=manuals#/manualsTab, i doesn't understand why you choose _Anycast_ renderer and not _Sony-Bluray2013.conf_ that is much more near your own specifications ?
P.S. Sorry about "Unbekannter DLNA Client", i just learn with _Google Translate_ that it was used for "Default renderer" in german language.
EDIT: PMS.17=Unbekannter DLNA Client PMS.17=Unknown renderer in https://github.com/UniversalMediaServer/UniversalMediaServer/blob/master/src/main/resources/i18n/messages.properties#375 ;-)
@Sami32 To be correct, it means "Unknown DLNA Client" - but that might be the German translation for "Default renderer" :wink:
@DaniGTA It was a long shot, I just looked at your log and saw those two things that were "out of the ordinary". I have no idea of what's causing the behaviour. I'd try to use a working renderer profile instead of defaulting to Anycast though. There might be some confusion in the communication between UMS and the renderer resulting in a lot of repeated messages or something of that kind generating the CPU usage, but that is just a guess as well.
If i use Sony-Bluray2013, MKV files will wont working on my Blueray player and with Default too.
I need too use the Funktion too Change the Audio and the Undertitles on the Blueray player thats only working with mkv i think.
DefaultRenderer.txt
@DaniGTA Could you post your log when you try to see a MKV movie with the _Sony-Bluray2013.conf_ ?
Did you tried to play them from the #--TRANSCODE--# folder ?
You can also try this renderer : (after have deleted the _.txt_ extension and disabled all the others renderers in UMS)
Sony-BDP6500.conf.txt
P.S. https://forums.plex.tv/discussion/200611/sony-bdp-s6500-plex-playback-constantly-freezing
http://www.universalmediaserver.com/forum/viewtopic.php?t=2379&start=120
With Sony-BDP6500.conf are MKV playable but i cant change Audio and Subtitles, and yes i have tried to play them from #--TRANSCORE--# folder there are not playable.
The CPU bug dosnt get fixed.
@DaniGTA Could you post your log when you try to see a MKV movie with the Sony-Bluray2013.conf, from the main folder and from inside the #--TRANSCODE--# with [No transcoding], FFmpeg and Mencoder engines ?
Just to be sure i understood correctly, you can change MKV audio and subtitle with Anycast renderer, right ?
With Sony-Bluray2013.conf MKV are working but i cant change Audio and undertitle and Transcode not working.
debug.txt
@DaniGTA When you played the MKV videos in the #--TRANSCODE--# folder with [No transcoding] you said the files didn't play, right ?
You are dealing with hight video bit deph, and i'm not sure you TV can deal with it or if your BlueDisc player that support it will downscale the video bit deph, so what is your TV model ?
With other video formats like mp4 or avi, do you get subtitles displayed ?
With the same movies on your USB, do you get the subtitles displayed ?
Which one are you using really, BDP-S6500 or BDP-S6700 ?
I use BDP-S6700 and the #--TRANSCODE--# folder dont get loaded and yes my TV can dealing hight video bit deph because i can watch the video without transcode but i cant change audio and undertitle. The video is working fine
The undertitle/audio change i get fixed with anycast my problem is the High CPU load by doing nothing.
@DaniGTA
1) You mean that from your USB your mkv videos are playing fine, right ?
2) And from your USB, you cannot change the audio or subtitles ?
3) What do you mean by the #--TRANSCODE--# folder don't get loaded ? that you cannot acced it or that when you select [No transcoding] nothing appened ?
Sorry to have difficulty to understand you but i'm not an english native either.
About your CPU issue, if it's not coming from your Java or renderer configuration, i really don't know.
You can disable all the renderers, or delete them and add this one:
Sony-BDP6700.conf.txt
EDIT: Some strange line are in your log, so it'll interesting if you can provide an other log with _Sony-BDP6700.conf_
DEBUG 2016-07-31 18:07:19.786 [cling-15] Subscription failed: dial on BDP-S6700: HTTP response was: 501 Not Implemented
DEBUG 2016-07-31 18:07:19.801 [cling-15] Subscription failed: IRCC on BDP-S6700: HTTP response was: 404 Not FoundDEBUG 2016-07-31 18:07:54.693 [mencoder.exe-2-2] INCORRECT files in the presence of B-frames. Moreover, due to bugs MPlayer
DEBUG 2016-07-31 18:07:54.693 [Thread-26] Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
DEBUG 2016-07-31 18:07:54.693 [mencoder.exe-2-2] will play these INCORRECT files as if nothing were wrong!
Some connections problem as well:
Connection error: java.io.IOException: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
With USB is no Problem but i with AnyCast its working fine too, from my USB i can change audio and Subitles. When i try too open TRANSCODE in the UMS log i become this error and on the Blueray player it wont be open:
java.lang.StringIndexOutOfBoundsException: String index out of range: 10 at java.lang.String.substring(Unknown Source) at net.pms.configuration.RendererConfiguration.getDcTitle(RendererConfiguration.java:2305) at net.pms.dlna.DLNAResource.getDidlString(DLNAResource.java:2376) at net.pms.network.RequestV2.answer(RequestV2.java:704) at net.pms.network.RequestHandlerV2.writeResponse(RequestHandlerV2.java:300) at net.pms.network.RequestHandlerV2.messageReceived(RequestHandlerV2.java:256) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.handler.stream.ChunkedWriteHandler.handleUpstream(ChunkedWriteHandler.java:142) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.handler.codec.http.HttpChunkAggregator.messageReceived(HttpChunkAggregator.java:145) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:459) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:536) at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108) at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337) at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
@DaniGTA That's interesting, i guess something was wrong with the true sexy japanese manga title ;-) perhaps too long. I'm not used to Sony renderers but Sony Blu-ray Disc are know to have some lenght limitations.
Try this new renderer configuration and return feedback and FULL log, please.
It's a try to solve #--TRANSCODE--# access problem, because i guess that with your _AnyCast_ renderer conf you can access it without error ?, and low the CPU used while transcoding.
Sony-BDP6700-Hi10p.conf.txt
EDIT: Could you send a screenshot of your detailed Java processes using your CPU.? you will need to see the _javaw.exe_ process.
When you told "30~min later UMS has a CPU load of 30% every Time", do you mean without doing anything on UMS or on your computer ? Do the others pure Java programs have this problem as well ?
Regarding the stacktrace above there seems to be a bug in RendererConfiguration.getDcTitle() that might or might not stem from 22b2924b9142ab7296a8df6d83db66e013c341be. I'm not sure how the wrapping logic works, so it's hard to pinpoint what is wrong, but it seems that indent is set to 10 in the renderer configuration and that when name is shorter than the indent, it will throw a StringIndexOutOfBoundsException. You might be the one to check out that logic @skeptical.
Although a bug, I doubt that has anything to do with the high CPU usage - but it explains why access to the TRANSCODE folder doesn't work for that renderer configuration.
I will test the Sony BDP6700-Hi10p.conf tomorrow. UMS is not used by Streams when i have show this bug or something and i use my PC but i dont have other pure Java programs that have this problem and i only have make the Test without other Java programs, my Computer is every time on use.
http://prntscr.com/c00ilb
You must explain me how i must make the details when i have the wrong details of the JavaW
@Nadahar I'm not sure if it really a bug or we need to add TextWrap = width:52 indent:10 height:3 whitespace:9 in the conf and as in the precedent try i defined a width of 42 i though that the value was incorrect, but for now i taken it out, let's see for a next try.
Concerning the freezing, maybe...i say maybe, that TranscodeFastStart = true could solve it, but that's will be also for the next try. The next renderer conf file is ready.
After that, i will have only one last card in hand, so any help is welcome ;-D
@DaniGTA That could be tricky as i use only Windows XP, but clicking on the details tab perhaps can give more informations ?
@DaniGTA JDownloader 2 is a Java program as well. While it shouldn't be a problem, there might be some kind of issue in relation to that.
@Sami32 I'm sorry but I don't know what you mean. Any index out of bounds is a bug per definition, the code should never end up asking for a part of the string that doesn't exist nomatter how long or short the string might be.
To figure out exactly what goes wrong here, the renderer configuration and the exact media name is needed, a full trace debug.zip while triggering the bug is probably the way to go.
I use JDownloader 2 but it dont have this bug. http://prntscr.com/c00qev The with 25% CPU is UMS and the with 0% is JDownloader2
@Nadahar Yes, you're right. I was trying to say that if i used a correct value maybe this error would not appeared, not meaning that this this exeption message is normal though, only that it appeared because i put an incorrect width value.
@DaniGTA I see that, I'm just saying that there is another Java program running at the same time and there is a slight chance that there could be some issue related to that. The reason is the way Java works, Java programs aren't really programs in the traditional sense. They aren't compiled into runnable code, but into something called bytecode. All Java programs/bytecode is then run by the JVM (Java Virtual Machine). The JVM is the program actually running on your computer, and it's doing what is instructed by the bytecode. I don't know if that makes any sense to you, but the fact is that JDownloader and UMS both end up being run by the same program, the JVM. When you install Java on a computer, you actually install the JVM.
With BDP6700-Hi10p.conf i cant change audio and undertitle but Transcode Working now there are all Audios but i want it like anycast that i dont need Transcode and i can change audio with one button.
Here is a debug.zip but without the CPU bug the CPU bug comes later
UniversalMediaServer 6.5.0
Java 1.8.0 101
ums_dbg.zip
Now i have a debug.zip with the CPU bug but it was very laggy and slow.
ums_dbg2.zip
@DaniGTA While i will check you log, you can test this new renderer configuration, and close all javaw.exe processes before start UMS and give feedback as usual ;-)
Sony-BDP6700-Hi10p.conf.txt
What do you mean by they are all audios ? that videos do not appear on your renderer ?
If it's that, just use that one:
Sony-BDP6700.conf.txt (updated)
(updated)
And replace your _UMS.conf_ in your _C:\ProgramData\UMS_ folder by this one:
UMS.conf.txt (updated)
For freezing test purpose:
UMS.conf.txt (updated)
EDIT: After @Nadahar remark, try to close all the Java program, using _javaw.exe_, before start UMS, and if you don't know how to... just kill the in the Processes tab in your _Task manager_.
@DaniGTA Why you can't make full debug log in TRACE mode and post it here or anywhere?
Without logs and some description so we can read log more easily it is hard to help.
Anyway There is a info from Nadar/Nadahar how to start UMS without GUI so you can try test UMS without GUI if it is problem there or not. GUI can use more CPU cycles when there is a refresh on actually played files as current position, buffering etc. If anything goes wrong with streaming to renderer it is possible that some exception is generated which can lead to some thread locked or getting into never-ending-cyclus so your testing without GUI also can help (with full debug log and e.g. time when CPU bug is introduced)
This bug comes too when i start the program and do nothing then. (no streams no gui open)
How i can make a full debug log in TRACE mode ?
That i have make already
@DaniGTA Yes, your last 2 logs are correct, @ExSport probably just didn't see them.
As a note, running UMS without GUI (aka headless mode as I'm sure @ExSport referred to) isn't really advisable for Windows since there's no way to stop UMS again other than killing it in the task manager. Killing programs from the task manager is never a good thing, since it doesn't give the program a chance to clean up and close things, and it could corrupt any (write) open file like configuration and database files. On Linux though, Ctrl+c will stop UMS correctly when running headless, the same will kill without -9 unless I am mistaken.
@DaniGTA The CPU bug is hard to pinpoint, I see nothing in the log at first glance. Do I understand you correctly that you don't have the CPU bug all the time? Or does it always come after a while? If so, how long is it before it starts?
I'm also wondering if you could test without JDownloader 2 running and with your Sony bluray player turned off or disconnected from the network and see if the CPU bug still exists then. It's not that that's a solution, it's just to try to narrow it down.
Without JDownloader and no connected Devices the bug comes later too (30mins~). That i have tested already. It comes every time 30min~ after the start then i have the bug all the time.
I must kill the Program with the Taskmanager because the gui not working anymore then or is very very slow.
@DaniGTA If the GUI becomes unresponsive it indicates that the bug is actually with the GUI thread. Sadly I can see nothing in the log giving any hints. Your latest CPU bug log goes from 13:27 to 13:50 (only 23 minutes). Do you have any idea at what time the CPU issue started?
I can see that UMS is communicating some with your printer at 192.168.2.110. Again, reaching for straws, could you try with the printer disconnected?
Except for the printer, I can see communication with 3 devices: 192.168.2.100, 192.168.2.101 and 192.168.2.109. What are these? Only 192.168.2.109 seems to be your bluray player?
I can test the most things with UMS at evening because at the day some devices are Online like one other PC Tablets Laptops Printers...
@DaniGTA I'm not that's fast, but the configurations files are ready to test now https://github.com/UniversalMediaServer/UniversalMediaServer/issues/946#issuecomment-236564287
Try the renderer conf that suit your need and the last _UMS.conf_ for freezing test purpose.
And in 30mn a new _debug.zip_ ;-)
@Nadahar Do you know why he get this in his log ?
DEBUG 2016-08-01 13:29:48.341 [cling-16] Ignoring device: MediaServer (RemoteDevice) Identity: (RemoteDeviceIdentity) UDN: uuid:00000001-0000-1010-8000-104fa81c1aef, Descriptor: http://192.168.2.109:64321/bdp-bx-ms.xml, Root: true
@Sami32 It seems like the bluray player also is a DLNA Media Server to me, but I'm a bit confused about what the different devices are - thus the question about the IP addresses. The bluray player can probably share it's own media via DLNA.
The other PC share too via DLNA
@Nadahar I did already make a configuration file trying to avoid that, but if it's not working, like you told already, shutdown all the others connected devices (4 ?), avoiding a _WireShark_ debug.
EDIT: After that I'll not far from giving away my tongue to the cat :-D
I will try it today at evening
@DaniGTA There's also a DLNA Media Server at 192.168.2.100..? I guess that's the other PC? Still, a DLNA Media Server at 192.168.2.109 indicates to me that the bluray player also is a server.
I suspect that there's a bug regarding the GUI/event dispatcher thread. There might be synchronization issues, or there might be an endless loop. The most likely cause IMO is the spawning of the renderer GUI panels, so it's important to understand exactly what is spawned when.
@Nadahar Risk of corruptness is here but media files are opened read-only = no risk, so minimal chance of losing DB which can be rebuilt is quite good reason to test it so we will be sure bug is GUI related or not:)
Btw. I killed javaw.exe process hundred times during testing and never spotted single corruption.
ums_dbg3.zip
Now i have test this:
What do you mean by they are all audios ? that videos do not appear on your renderer ?
If it's that, just use that one:
Sony-BDP6700.conf.txt (updated) //DidntWorked
(updated)
And replace your UMS.conf in your C:\ProgramData\UMS\ folder by this one:
UMS.conf.txt (updated)
Its not working i cant play the Video on my Blueray player, and the Audio has Worked on all configs but i cant change them. My mkv file has 2 Audios and i need too switch between them.
(Tested befor:)
I have it tested without a GUI and the CPU bug didnt get fixed
@DaniGTA I didn't check fully the log but i can saw that you didn't use my _UMS.conf_ as asked...so no CPU issue will be changed as the connections parameters are inside this file, crossing fingers for that could help ;-)
Btw, when you'll do, you can test with and without killing extra _javaw.exe_ processes if any are still active, just in case...I know it's a long shot, but your issue is not that easy to narrow.
P.S. Since you say about audio only, is it meaning that you can browse #--TRANSCODE--# folder without problem now ? and that you can select your subtitles ?
@ExSport While I agree that the risk is low, it's a matter of principle to me. It you terminate a program exactly while it is writing, you will get corruption. In addition you can get state mismatch if parts are updated and other parts aren't. It's not just UMS, it's basicly any program that do write anything to disk. I avoid terminating to the extent possible, and in return I don't have to reinstall much. My current Windows installation is from July 2009 (when I changed from XP to Win7), and my basic file structure on the Windows drive is from 1997. I never reformat, and I try to fix errors instead of just reinstalling. Some times I can't figure it out and I have to reinstall, but it's very rare.
@Sami32 @DaniGTA The issue with selecting audio and/or subtitle track has to do with streaming or transcoding. When a file is streamed all embedded tracks are sent to the renderer as one stream, and the renderer can pick which ones to use. When transcoding, UMS has to pick one before transcode, so the resulting stream only contains one track of each type. It might be possible to transcode with several audio and subtitle tracks for all I know, but it would waste CPU resources transcoding data that would never be used. I'm not sure if any of the transcoding engines support this though.
@DaniGTA When you say you have tested without GUI, what do you mean then? If the GUI is just closed/not visible, that doesn't really matter. UMS still updates it as normal, Windows handle if it's visible or not. To run UMS without a GUI, you have to start UMS with a command line argument, headless. To do it you have to open a "command promt" (run cmd.exe), navigate to the folder where UMS.exe is and then run
UMS.exe headless
Alternatively you can copy the Windows shortcut for UMS, and then modify the target string to contain headless, e.g change
"C:\Program Files (x86)\Universal Media Server\UMS.exe"
to
"C:\Program Files (x86)\Universal Media Server\UMS.exe headless"
Is this what you have done?
http://prntscr.com/c0ebpy i have add -console
http://prntscr.com/c0ebpy i have add -console
That doesn't work when I test it - you must remove the - and only add console. console and headless are aliases, so they are the same.
@Nadahar For the audio part i did modified the _UMS.conf_ preferences, and for subtitles part i configured to not be transcoded StreamSubsForTranscodedVideo = true, so it's why i was asking.
EDIT: I don't have your skill and calm, so i use _Deep Freeze_ :-D
With audio and subtitles i have no Problems its working very good with anycast and the Video is smooth, the CPU bug dont have a effect on the Stream.
With headless i have the bug too
@DaniGTA If we're ever going to figure out what is happening with the CPU usage, we have to figure out what triggers the bug. If it happens in headless mode as well, anything related to the GUI is eliminated.
As far as I can understand it must be due to some kind of endless communication loop with one of your devices. I see no other possibility than to disconnect them all from the computer/network and recheck for the bug. If it's gone then, connect them one at a time and retest until you find out what is triggering it. If disconnecting all devices doesn't help, I'm out of ideas.
03:44:09 TRACE Receiving a NOTIFY from [192.168.2.102:54083]
03:44:09 TRACE Ignoring self-originating request from /192.168.2.102:57233
A NOTIFY will be Ignored but a M-SEARCH not is it normal ?
03:44:09 TRACE Receiving a M-SEARCH from [192.168.2.102:62819]
The CPU load comes from M-SEARCH when M-Search comes up in the log the CPU load go up
at 30% 3-5sec in 3sec or so the next M-SEARCH comes up at a time it will stack up and a loop is there.
I have make a Video where you can see but i dont Uploaded it yet because i dont know if you need this.
I will test it with M-SEARCH ignored by 192.168.2.102
@DaniGTA If M-SEARCH is to blame and they are coming from UMS itself, I'm wondering if 2d20c806ef93326550bcaeb117aafd0fc787d453 could be the problem. This were first included in 6.4.0. Could you test a version prior to 6.4.0 to see if the problem goes away?
I have tested it with 6.3.1.1 and the M-SEARCH use only 1-3% for 1sec in
version 6.5 it has use 25-30% for 3-5 sec.
I have let it 30min run and the CPU load of UMS is 0% the bug is not in 6.3.1.1
@DaniGTA Thank you. I think 2d20c806ef93326550bcaeb117aafd0fc787d453 is the culprit then. You should just stay with that version until the issue is resolved. You should try to get a working renderer profile for your device though, as forcing a default renderer (and thus in reality skipping renderer detection) isn't an ideal solution .
@SubJunk I'm leaving this to you from here, I don't know if you just want to reverse it or try to modify it to achieve both the intended goal of 2d20c806ef93326550bcaeb117aafd0fc787d453 and avoid this problem. IMO one should stick to the standard though, and spamming something is bound to have side effects. I'm betting the reason for the late discovery of the Panasonics are something else, and 2d20c806ef93326550bcaeb117aafd0fc787d453 is just a crude workaround.
@DaniGTA @Nadahar thanks guys for your investigation, I really appreciate it :)
I think we should distinguish between two things:
1) UMS using 30% CPU (which is likely just 100% of one CPU core) to load something is not a bug. All programs use CPU cycles in order to run and in this case we have an operation running every 30 seconds so it uses CPU every 30 seconds. That's not an issue on its own since us Panasonic users get a lot of value from it.
2) If that causes the program to eventually become unresponsive, that _is_ a problem. It probably means we are not closing the resource correctly and I will look into it.
@Nadahar our main competitor seems to do these kinds of things every 10 seconds so we are still less spammy than the program everyone is using these days :)
I'm still learning about how we communicate between renderers, that hasn't historically been my main area of contribution to this program, so if you have any ideas about what a better fix to replace https://github.com/UniversalMediaServer/UniversalMediaServer/commit/2d20c806ef93326550bcaeb117aafd0fc787d453 would be, that would be helpful
I have asked the Cling developers whether searching regularly is recommended or not at https://github.com/4thline/cling/issues/174
@SubJunk My previous post was a bit lacking in clarity when I read it now. I haven't "proven" the bug to come from 2d20c806ef93326550bcaeb117aafd0fc787d453, it's just my suspicion. The only thing we know for sure is that the bug is introduced between 6.3.1.1 and 6.4.0.
Second, I don't think that sending the M-SEARCH in itself is causing that CPU usage. There has to be a "side effect" of some kind, either by UMS resonating with other devices going into some kind of communication loop or by creating some kind of internal loop within UMS or Cling. I'm basing that on the fact that most modern CPUs, like the 3570K, actually are immensely fast. I disagree that there's natural to spend 100% of one core for anything UMS does except for transcoding for anything more than a few milliseconds at most. Taking 100% of one such core for 3-5 seconds requires some very serious calculations or some repetitive behaviour. The very serious calculations isn't relevant here, and thus there has to be some rapidly repetative behaviour as I see it.
I don't have a solution to this, if we really want to get to the bottom of this we have to figure out the exact nature of the "side effect". There has been some considerable time since I read the DLNA/UPnP (I don't even remember which covers this, but I suspect this resides in UPnP) specs now, and I didn't really _read_ them (that's a huge task). I was simply searching for some things I was after and ended up reading some "irrelevant parts" (to that particular issue) as a part of that process. What I seem to remember is that all such behaviour is controlled in great detail, and there are strict definitions of when and how often to search. I also think I remember that the primary discovery logic is that any new device (whether media server or renderer, controller or otherwise) presents itself when it's connected to the network. Others will then respond to that. So, unless I'm mistaken, UMS should represent itself when started, and should reply with a response that will let UMS know they are there. The same thing goes if a renderer is turned on when UMS is already running. Regular searches should only be needed for the rare situation where the network has been physically disconnected when the greetings are done and later connected - which will undermine this model. But, I am not sure of my memory so don't take any of this as facts.
My main point about the specs though, are that they should be carefully respected. The reason is that there are so many different devices written by different people that's supposed to work together. People have different ways to solve things and different level of experience and overview, and some of the implementations may not be very robust. We must assume that some implementations simply won't handle if you do something outside the specs and rely on the order and timing of the specification in their parsing. Breaking just a minimal part of this, and the whole parsing could fail and be rejected, ignored or in worst case cause the parsing routine to hang/loop infinitely. Therefore, as I see it, the specs should be checked carefully before anything like this is adjusted.
Also, in the case of the Panasonic, I'd investigate why the "initial handshake" fails. Cling workbench are supposed to be helpful in that regard even though I haven't tested it, and WireShark of course. I'd prefer that logic to work over repeated searching any day, but it might very well be that repeated searches are warranted. I'd just make sure that the repeated searches follows the "rules of conduct".
I don't know if it can help, but i have a white flag ;-)
Requirement [7.2.4.7]: Due to the unreliable nature of UDP, control points should send
each M-SEARCH message more than once, not to exceed 10 M-SEARCH requests in
a 200 ms period. An M-SEARCH message and its repeated duplicates should all be
sent within a 10 second period.Comment: Wireless access points do not retry multicast traffic and may cause UPnP
discovery problems. This recommendation repeats advice from UPnP DA 1.0.1.
The 10 M-SEARCH messages per 200 ms period is consistent with maximum
saturation limit of 10 ssdp:alive messages per 200 ms period for UPnP devices
(guideline 7.2.4.2). Likewise, the sending all of the M-SEARCH messages in a
window of 10 seconds is consistent with the requirement where all duplicates of an
individual ssdp:alive message are sent within 10 seconds (guideline 7.2.4.4).Comment: Most devices that remain on the network for long periods should have
CACHE-CONTROL value of 1800. However, some devices (mobile, wireless, etc.)
that may want a smaller CACHE-CONTROL value.
Requirement [7.2.4.2]: UPnP network devices must not send more than 10 ssdp:alive
messages on a single network interface in any given 200 ms period.Requirement [7.2.4.3]: UPnP devices must send each advertisement set more than once
on a single network interface (It is recommended that UPnP devices send a total of 2
or 3 advertisement sets).
An advertisement set refers to the set of 3+2d+k ssdp:alive messages that UPnP
device sends as part of its periodic advertisements.
The repeated advertisement sets are referred to as duplicate sets.
The transmission windows for advertisement sets and duplicate sets cannot overlap
in time.
And a little compilation of more than 600 pages :
Requirement [7.2.4.9]: Upon startup, UPnP devices should broadcast an ssdp:byebye
before sending the initial ssdp:alive onto the local network.
Sending an ssdp:byebye as part of the normal start up process for a UPnP device
ensures that UPnP control points with information about the previous device instance
will safely discard state information about the previous device instance before
communicating with the new device instance.Requirement [7.2.4.10]: UPnP control points after acquireing a new IP address must
initiate searches (e.g. M-SEARCH) on the new IP interface.Requirement [7.2.5.9]: The HTTP servers and clients of UPnP endpoints (devices and
control points) must include the Content-Type header tag in every UPnP-related
TCP-based HTTP transaction (SOAP, GENA, and device/service description) that
contains an XML body. This content type must always be marked as the following:
• text/xml; charset="utf-8"
Note that charset parameter value is case insensitive and double quotations may be
omitted.
Furthermore, the XML must be encoded in UTF-8.Requirement [7.2.6.2]: If a UPnP device's HTTP server responds to a SOAP request as part
of an HTTP/1.0 transaction, then the UPnP device must close the TCP connection after
the response has been sent.
This guideline covers both kinds of HTTP/1.0 transactions:
• HTTP/1.1 server responds to an HTTP/1.0 request, and
• HTTP/1.0 server responds to an HTTP/1.1 request.
It should be noted that in both of the above cases, the UPnP device has the HTTP
server and the UPnP control point issues the HTTP request.Requirement [7.2.7.1]: A UPnP device's HTTP server must close the TCP connection after
responding to a SOAP request with the CONNECTION: CLOSE token.Requirement [7.2.22.1]: UPnP devices must send events to all properly subscribed UPnP
control points. The device must enforce a subscription TIMEOUT value of 5 minutes.
The UPnP device behavior of enforcing this 5 minutes TIMEOUT value is
implemented by specifying "TIMEOUT: second-300" as an HTTP header/value pair.Requirement [7.3.135.3]: If a UPnP AV MediaServer control point fails to completely
upload an IFO file and if res@dlna:resumeUpload="1" and if the control point initiates
a retry IFO attempt, then the control point must initiate the retry IFO attempt within 30
minutes of the failure.Requirement [7.4.45.2]: If an HTTP server detects 5 minutes of inactivity after a POST
transaction, then the HTTP server should close persistent (HTTP/1.1) connections.Requirement [7.2.4.1]: UPnP endpoints (devices and control points) should wait a random
amount of time, between 0 and 100 milliseconds after acquiring a new IP address,
before sending advertisements or initiating searches on a new IP interface.Requirement [7.2.4.4]: A UPnP device that uses the same UDN on multiple network
interfaces, must send each individual ssdp:alive message (from an advertisement set)
on all interfaces within a 10 second transmission window.
Time intervals between individual ssdp:alive messages on a single interface are not
restricted by this requirement.Requirement [7.2.8.7]: The HTTP clients of UPnP endpoints must close a persistent
connection (HTTP/1.1) within 60 seconds of inactivity (i.e., no traffic and no pending
requests).Section Comment: UPnP Device Architecture specification requires UPnP devices to
complete the SOAP response in 30 seconds. However, this can be difficult to
guarantee at the implementation layer for all types of UPnP actions. These guidelines
attempt to strike a balance between ideal goals and practical implementation needs
for both devices and control points.
That being stated, the original inspiration for these guidelines is that some UPnP AV
MediaServer devices cannot guarantee that a response will complete within 30
seconds for a variety of reasons. Network bandwidth, query complexity, and
hardware performance can vary. This being the case, such devices must still begin
their response within 30 seconds.
It should be noted that a UPnP AV MediaServer can reduce a long transmission time
for a SOAP response (for a CDS:Browse or CDS:Search action) by reducing the
number of returned items in the result. See the 7.3.64 MM CDS Browse/Search Action:
Reduced Response Behavior guideline for more information.Requirement [7.2.9.1]: UPnP devices must begin the transmission of a SOAP response
within 27 seconds of receiving a complete SOAP request.Requirement [7.2.22.1]: UPnP devices must send events to all properly subscribed UPnP
control points. The device must enforce a subscription TIMEOUT value of 5 minutes.
The UPnP device behavior of enforcing this 5 minutes TIMEOUT value is
implemented by specifying "TIMEOUT: second-300" as an HTTP header/value pair.Requirement [7.2.27.4]: When a UPnP control point gets an advertisement for a UPnP
device UDN on a different IP address from the one it has previously selected, it may
continue to use its selected IP address provided that it has received an advertisement
on the selected IP address in the last 10 seconds. Otherwise, if the UPnP control point
does not receive an advertisement for its selected IP address in the next 10 seconds, it
may change its selection to the new IP address. Even if the control point keeps the
selected IP address in this case, it should change its selection to the new IP address
when an access to the selected IP address fails.Comment: This guideline covers the scenario where a UPnP AV MediaServer can
neither find any CDS objects that satisfy the query nor calculate the TotalMatches
output argument accurately. Although some UPnP AV MediaServer implementations
may choose to report the accurate TotalMatches value, at the expense of violating the
27 seconds timeout rule, such behavior is not recommended for the same reason
stated in the previous guideline.Timely means that the Content Source (under Ideal Network Conditions) is able to
begin responding with the requested content data within 27 seconds of receiving the
request.Requirement [7.4.20.7]: An HTTP Server Endpoint must begin sending a response
message to an HTTP requests within 27 seconds of receiving the request. Valid
response messages must be either the response with content byte data, or
appropriate error messages.Requirement [7.4.100.2]: In the absence of SDP provisions any RTCP reports must be
generated and sent at the rate that is in accordance to one of the following:
• the RTP profile (AVP or AVPF) in use
• once every 5 seconds randomized within the interval [0.5, 1.5] times, such that the
resulting RTCP transmission interval is a random number in the interval [2.5, 7.5]s.
I confess that i never read the Cling documentation before.
I found some things that look interesting to me, hoping that could interested others people as well.
6.5.2. Alive messages at regular intervals
Some control points have difficulties with M-SEARCH responses. They search for your device, then can't process the (specification-compliant) response made by Cling and therefore don't discover your device when they search. However, such control points typically have no problem with alive NOTIFY messages, only with search responses.
The solution then is to repeat alive NOTIFY messages for all your local devices on the network very frequently, let's say every 5 seconds:
UpnpService upnpService = new UpnpServiceImpl(
new DefaultUpnpServiceConfiguration() {@Override public int getAliveIntervalMillis() { return 5000; } });
By default this method returns 0, disabling alive message flooding and relying on the regular triggering of local device advertisements (which depends on the maximum age of each LocalDeviceIdentity).
If you return a non-zero value, Cling will send alive NOTIFY messages repeatedly with the given interval, and remote control points should be able to discover your device within that period. The downside is of course more traffic on your network.
6.5.3. Using discovery options for local devices
...A rarely used setting of DiscoveryOptions is byeByeBeforeFirstAlive: If enabled, Cling will send a byebye NOTIFY message before sending the first alive NOTIFY message. This happens only once, when a LocalDevice is added to the Registry, and it wasn't registered before.
http://4thline.org/projects/cling/core/xref/org/fourthline/cling/model/DiscoveryOptions.html
From http://4thline.org/projects/cling/core/apidocs/org/fourthline/cling/UpnpServiceConfiguration.html
int getAliveIntervalMillis() Optional setting for flooding alive NOTIFY messages for local devices. Use this to advertise local devices at the specified interval, independent of its DeviceIdentity.maxAgeSeconds value. Note that this will increase network traffic. Some control points (XBMC and other Platinum UPnP SDK based devices, OPPO-93) seem to not properly receive SSDP M-SEARCH replies sent by Cling, but will handle NOTIFY alive messages just fine. Returns: The time in milliseconds for ALIVE message intervals, set to 0 to disable
It's look like Sony Bluray doesn't like it : http://www.universalmediaserver.com/forum/viewtopic.php?f=9&t=8544&p=27853#p27853
TRACE 2016-08-05 22:16:54.016 [UPNPHelper] net.pms.network.UPNPHelper Receiving a NOTIFY from [192.168.1.1:43411]
TRACE 2016-08-05 22:16:54.914 [UPNP-Search] net.pms.network.UPNPControl Searching for renderers with Cling...
TRACE 2016-08-05 22:16:54.914 [UPNPHelper] net.pms.network.UPNPHelper Receiving a M-SEARCH from [192.168.1.115:50267]
TRACE 2016-08-05 22:16:59.658 [UPNPHelper] net.pms.network.UPNPHelper Receiving a NOTIFY from [192.168.1.22:64321]
TRACE 2016-08-05 22:17:12.238 [UPNPHelper] net.pms.network.UPNPHelper Receiving a NOTIFY from [192.168.1.4:35258]
TRACE 2016-08-05 22:17:17.200 [UPNPHelper] net.pms.network.UPNPHelper Receiving a NOTIFY from [192.168.1.22:50201]
TRACE 2016-08-05 22:17:24.915 [UPNP-Search] net.pms.network.UPNPControl Searching for renderers with Cling...
TRACE 2016-08-05 22:17:24.915 [UPNPHelper] net.pms.network.UPNPHelper Receiving a M-SEARCH from [192.168.1.115:50267]
TRACE 2016-08-05 22:17:54.017 [UPNPHelper] net.pms.network.UPNPHelper Receiving a NOTIFY from [192.168.1.1:43411]
TRACE 2016-08-05 22:17:54.916 [UPNP-Search] net.pms.network.UPNPControl Searching for renderers with Cling...
TRACE 2016-08-05 22:17:54.916 [UPNPHelper] net.pms.network.UPNPHelper Receiving a M-SEARCH from [192.168.1.115:50267]
TRACE 2016-08-05 22:17:59.659 [UPNPHelper] net.pms.network.UPNPHelper Receiving a NOTIFY from [192.168.1.22:64321]
TRACE 2016-08-05 22:18:24.916 [UPNP-Search] net.pms.network.UPNPControl Searching for renderers with Cling...
TRACE 2016-08-05 22:18:24.916 [UPNPHelper] net.pms.network.UPNPHelper Receiving a M-SEARCH from [192.168.1.115:50267]
TRACE 2016-08-05 22:18:54.018 [UPNPHelper] net.pms.network.UPNPHelper Receiving a NOTIFY from [192.168.1.1:43411]
TRACE 2016-08-05 22:18:54.916 [UPNP-Search] net.pms.network.UPNPControl Searching for renderers with Cling...
TRACE 2016-08-05 22:18:54.916 [UPNPHelper] net.pms.network.UPNPHelper Receiving a M-SEARCH from [192.168.1.115:50267]
TRACE 2016-08-05 22:18:59.660 [UPNPHelper] net.pms.network.UPNPHelper Receiving a NOTIFY from [192.168.1.22:64321]
TRACE 2016-08-05 22:19:24.917 [UPNP-Search] net.pms.network.UPNPControl Searching for renderers with Cling...
TRACE 2016-08-05 22:19:24.917 [UPNPHelper] net.pms.network.UPNPHelper Receiving a M-SEARCH from [192.168.1.115:50267]
DEBUG 2016-08-05 22:19:25.833 [UPNP-AliveMessageSender] net.pms.network.UPNPHelper Sending ALIVE...
TRACE 2016-08-05 22:19:25.835 [UPNPHelper] net.pms.network.UPNPHelper Receiving a NOTIFY from [192.168.1.115:62412]
TRACE 2016-08-05 22:19:25.838 [New I/O worker #1] net.pms.network.RequestHandlerV2 Ignoring self-originating request from /192.168.1.115:59794
TRACE 2016-08-05 22:19:25.841 [New I/O worker #2] net.pms.network.RequestHandlerV2 Ignoring self-originating request from /192.168.1.115:59795
TRACE 2016-08-05 22:19:25.919 [UPNPHelper] net.pms.network.UPNPHelper Receiving a M-SEARCH from [192.168.1.115:50267]
TRACE 2016-08-05 22:19:27.361 [New I/O worker #3] net.pms.network.RequestHandlerV2 Opened request handler on socket /192.168.1.161:61232
TRACE 2016-08-05 22:19:27.361 [New I/O worker #3] net.pms.io.WinUtils Calling SetThreadExecutionState ES_SYSTEM_REQUIRED
TRACE 2016-08-05 22:19:27.361 [New I/O worker #3] net.pms.network.RequestHandlerV2 Request: HTTP/1.1 : GET : description/fetch
Great research guys :) Definitely some changes we can make based on those things
I've started to use https://github.com/UniversalMediaServer/UniversalMediaServer/pull/975 to do some of this stuff so let's use that to implement these things
Requirement [7.2.4.8]: The control point should wait at least the amount of time specified
in the MX header for responses to arrive from devices. The time waited for
responses should be extended by additional time (a second or two) to allow for
network propagation and processing delays.
Requirement [7.2.17.1]: UPnP control points must be able to accept GENA event
transmissions that are up to 20,480 bytes (20 KB) in size. This byte limit includes the
HTTP headers.Requirement [7.2.23.1]: UPnP endpoints (devices and control points) must be tolerant of
unknown headers, tags, fields, attributes, and values for HTTP, SSDP, XML, SOAP, and
GENA. Specifically, this tolerance guideline applies to:
• HTTP headers, tokens, values
• SSDP headers, tokens, values
• Unknown XML elements and attributes of SOAP or GENA fragments
• Unknown XML elements and attributes in device description files or service description
files
Tolerant behavior is defined as being able to successfully "parse and interpret" or
"parse and ignore" the unknown text.
Concerning the complex home network, as i can remember 3 cases on forum or Github:
Requirement [7.2.27.1]: When a UPnP device has multiple IP addresses, the device may
advertise on those IP addresses with the same or different UDN.
Comment: Multiple home network segments, wireless networking, and Auto IP can
combine to create usability problems that can be avoided by following the specified
rules.Requirement [7.2.27.2]: Each UPnP device advertisement must contain a return IP address
of the home network interface it is sent on.Requirement [7.2.27.3]: Upon receiving multiple advertisements for the same UPnP
device UDN, a UPnP control point should select the vendor-defined preferred
advertisement as the route to the device.Requirement [7.2.27.4]: When a UPnP control point gets an advertisement for a UPnP
device UDN on a different IP address from the one it has previously selected, it may
continue to use its selected IP address provided that it has received an advertisement
on the selected IP address in the last 10 seconds. Otherwise, if the UPnP control point
does not receive an advertisement for its selected IP address in the next 10 seconds, it
may change its selection to the new IP address. Even if the control point keeps the
selected IP address in this case, it should change its selection to the new IP address
when an access to the selected IP address fails.
After some renderer's firmware updates maybe that could be of some use: ?
Requirement [7.2.26.3]: In conjunction with the restrictions in 7.2.26.2, UDN may be
changed if a UPnP device changes its device description or any of its supported
services.Requirement [7.2.26.4]: If a UPnP device UDN changes, it must re-advertise on the
network using the new UDN.Requirement [7.2.26.5]: If a UPnP device UDN changes, it must send an ssdp:byebye for
the old UDN.
I think I've fixed this with https://github.com/UniversalMediaServer/UniversalMediaServer/pull/942/commits/d768df720698096484b16f7e7d51416ee68201dd
I'll do a version for master too so we can release it in the 6.x branch before 7.0.0.
Leaving this issue open until we get verification
for what it's worth i get the same "[Fatal Error] :1:1: Premature end of file." exactly, every time, 15 mins after starting UMS from scratch.
ums_dbg.zip
So now the Test with 7.0.0 and the bug is still there http://i.imgur.com/QhH8eTC.gifv (btw i dont care of ram usage).
Side info: The files in the folder cant changed oder deleted, i have take the rights from all to change or delete them.
Here you can see it very good that it comes from M-SEARCH: http://i.imgur.com/pJ4uhSN.gifv
JAVA 8 Update 111
Network:
Router - In the log Online
TV - In the log Online
BD-Player - In the log Online
Printer - In the log Online
Smartphone x2 - In the log Online
Tablet x2 - In the log Offline
PC x2 - In the log Online -PC1 Hosting UMS
Laptop x2 - In the log Offline
We have another similar report of this in https://github.com/UniversalMediaServer/UniversalMediaServer/issues/1652 and I'm going to close this in favour of that, since this issue took on a life of its own :)
Most helpful comment
I've started to use https://github.com/UniversalMediaServer/UniversalMediaServer/pull/975 to do some of this stuff so let's use that to implement these things