Increased java heap size not used?
Posted: Fri Jan 18, 2013 9:14 pm
Hi,
First of all: thanks a lot for UMS. It works like a charm and i love it! Keep up the good work.
For the sake of making UMS even better than it already is, i would like to report some (minor) bugs.
At installation time, i increased the java heap size to 2048. I also changed the transcode buffer size to 1280.
When i start UMS with UMS.exe, the typical out of memory errors appear soon when transcoding a movie. The same is true when i start UMS with the original UMS.bat.
However, when i change the -Xmx parameter in the original UMS.bat from -Xmx768M to -Xmx2048M, then everything works fine.
Hence, it seems that the override at installation time is not reflected in the exe or bat. Maybe this is a bug?
UMS reports 1452M as the maximum size for the transcoding buffer when using 2048M for the java heap. Using this value also results in memory issues (out of memory, buffer is flushed every 3 seconds). Lowering the value to 1280 solves the problem. The reported max value seems to be overestimated. Maybe this is a bug too?
Kind regards,
Impee
First of all: thanks a lot for UMS. It works like a charm and i love it! Keep up the good work.

For the sake of making UMS even better than it already is, i would like to report some (minor) bugs.
At installation time, i increased the java heap size to 2048. I also changed the transcode buffer size to 1280.
When i start UMS with UMS.exe, the typical out of memory errors appear soon when transcoding a movie. The same is true when i start UMS with the original UMS.bat.
However, when i change the -Xmx parameter in the original UMS.bat from -Xmx768M to -Xmx2048M, then everything works fine.
Hence, it seems that the override at installation time is not reflected in the exe or bat. Maybe this is a bug?
UMS reports 1452M as the maximum size for the transcoding buffer when using 2048M for the java heap. Using this value also results in memory issues (out of memory, buffer is flushed every 3 seconds). Lowering the value to 1280 solves the problem. The reported max value seems to be overestimated. Maybe this is a bug too?
Kind regards,
Impee