Client Disconnects
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Re: Client Disconnects
I have had disconnects in the past on my ps4 after 20 or so minutes watching something, but after i managed to get it online to update the mediaplayer it started to behave. maybe try deleting and re-installing the media player on your ps4 and see if that helps.
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
Re: Client Disconnects
You'll need a lot of patience if you're ever going to get a reply from a developer. They have been been even more rare on this forum than usual lately.
As a former developer I can say that nobody probably knows the reason. I haven't even paid much attention to the changes made since 7.0.0, since I consider much of the new code to be of a too low quality. As such, I don't really know if they have introduced new issues that can potentially cause this. That said, I think there have been problems with the PS4 for some users "as long as I can remember", but my impression is also that it mostly works for some PS4 users. This, combined with nothing really revealing in the logs, makes this issue difficult to handle when one don't have a PS4 to test with.
I see that your log file is full of
...which is very likely to be the cause for your problems. You have allocated 683 MB to the JVM, which should normally be sufficient, but for some reason it isn't. The default heap space allocated for Windows installations is 1280 MB (while Linux is 768 MB by default if I remember correctly). I don't think there is any good reason for this, more or less all development takes place on Windows and for some developers that seems to be the only platform they "care about". My guess is that the default JVM stack allocation has been bumped to resolve some issue at some point, but the person doing this hasn't cared to change it for macOS and Linux.
You can easily change the JVM stack size in UMS.sh, and since it seems that you have available memory, you should try to increase it so that you don't get out of memory errors. Eventually you will however, since UMS has a flawed design that manifests itself somewhat like a memory leak (although it technically isn't) which will mean that it will eat more and more memory over time.
While the fundamental design flaw have been there at least since UMS 5.0.0, the changes in 7.0.0 have made the problems much worse. If you don't absolutely need some of the stuff added in 7.x or 8.x, I would stick to 6.8.0.
If adjusting the stack memory and/or downgrading to 6.x doesn't help, I think you'd need to some kind of network capture (similar to WireShark) and post that.
As a former developer I can say that nobody probably knows the reason. I haven't even paid much attention to the changes made since 7.0.0, since I consider much of the new code to be of a too low quality. As such, I don't really know if they have introduced new issues that can potentially cause this. That said, I think there have been problems with the PS4 for some users "as long as I can remember", but my impression is also that it mostly works for some PS4 users. This, combined with nothing really revealing in the logs, makes this issue difficult to handle when one don't have a PS4 to test with.
I see that your log file is full of
Code: Select all
DEBUG 2019-06-15 09:48:08.348 [ffmpeg64-21-1] Cannot grow buffer size from 52,428,800 bytes to 209,715,200 bytes.
DEBUG 2019-06-15 09:48:08.349 [ffmpeg64-21-1] Error given: java.lang.OutOfMemoryError: Java heap space
You can easily change the JVM stack size in UMS.sh, and since it seems that you have available memory, you should try to increase it so that you don't get out of memory errors. Eventually you will however, since UMS has a flawed design that manifests itself somewhat like a memory leak (although it technically isn't) which will mean that it will eat more and more memory over time.
While the fundamental design flaw have been there at least since UMS 5.0.0, the changes in 7.0.0 have made the problems much worse. If you don't absolutely need some of the stuff added in 7.x or 8.x, I would stick to 6.8.0.
If adjusting the stack memory and/or downgrading to 6.x doesn't help, I think you'd need to some kind of network capture (similar to WireShark) and post that.
Re: Client Disconnects
As long as you keep finding "java.lang.OutOfMemoryError" when you search your logfile, there's no use looking at other aspects. After an out of memory error has occurred, UMS' state is to be considered corrupted, as it is completely random what have been stored in memory and what haven't. Any application that gets and out of memory error must be stopped/closed and started again.
You can simply expect "everthing" to go wrong once this error has been logged, so if adjusting the heap size didn't solve this, there must be some other reason why this happens. In any case, don't blame neither the console as long as you keep getting this. It must be solved to have any hope that the server will work properly.
You can simply expect "everthing" to go wrong once this error has been logged, so if adjusting the heap size didn't solve this, there must be some other reason why this happens. In any case, don't blame neither the console as long as you keep getting this. It must be solved to have any hope that the server will work properly.
Re: Client Disconnects
The log files usually compress very well, so just (g)zip it and it shouldn't be big.