FFMPEG process out of control, uses all ram.

[suicidesamurai]

I keep having an issue where FFMPEG starts a process upon UMS startup and that process continues to grow in memory until the computer stops responding. I am running Mac OS Yosemite, with the latest Java 8, and this problem occurs with UMS version 4.1.1 to 4.20.

[Optimus_prime]

suicidesamurai, Please post trace logs so we can look at the issue. Instructions are here viewtopic.php?f=9&t=556

[suicidesamurai]

Ok here is the log, I had to kill FFMPEG near the end as it had used 1.27 gigs of ram and the computer wasn't responding.

[Whistler]

Just chiming in with the same ffmpeg issue so you know it's not an isolated issue.
Fortunately my system did not stop responding while ffmpeg was eating all my cpu cycles and RAM.
My system was sluggish but still responded. Ffmpeg kept running for approximately 3.5 minutes and used up to 1.5 gigs of RAM before terminating on its own.

Quitting and restarting UMS did not bring the ffmpeg issue back. However, rebooting then starting UMS did bring it back with the same pattern.
I saved my debug log after ffmpeg terminated and I quit UMS.
FWIW UMS will continue to run and stream videos just fine after ffmpeg terminates...not sure about transcoding though.

Also running Yosemite and UMS 4.2.0 (Java 8)
My trace debug log looks very similar to suicidesamurai's but maybe there are enough differences to help narrow it down.

[SubJunk]

Does it happen if you use the Java 7 version of 4.2.0 too?

[Whistler]

Does it happen if you use the Java 7 version of 4.2.0 too?

Yes it does.
I run the UMS Java 8 on my 2009 mac mini which only has Java 8 installed so I tried UMS Java 7 on my 2012 MBPro which only has Java 7 installed.
Both systems are running Yosemite.

Since it was the first run of UMS on my MBPro I went through the setup wizard with defaults and no further setting changes.
The same ffmpeg situation exists with the Java 7 version...runs near 100% CPU utilization for approximately 3 to 3.5 minutes then terminates.
UMS still runs and streams just fine after ffmpeg terminates.
It's starting to look like a Yosemite issue.

The fact that on my system (and possibly others') ffmpeg just hogs the CPU for a bit and releases on its own that this may be more widespread but others may not even notice the few minutes of system sluggishness after a reboot and UMS restart.

Let me know if you need me to try anything else or provide more console logs.

[SubJunk]

Could you try with versions 4.0.0 and 4.0.1 too? They have different FFmpeg versions so that might help us see whether that's the issue

[SubJunk]

Oh by the way, systems with Java 8 installed can use any version of UMS - Java versions are backwards-compatible.

[Whistler]

Could you try with versions 4.0.0 and 4.0.1 too? They have different FFmpeg versions so that might help us see whether that's the issue

Same thing on both 4.0.0 and 4.0.1.
Also I just noticed, across all the versions I've tested, that upon reboot & UMS restart the "mplayer" process runs for about 30 seconds before terminating.
It is competing with ffmpeg for cpu cycles during that time. I don't know if that's normal mplayer startup behavior or not and it may be totally unrelated to the ffmpeg issue.

Before I forget....thank you for working on this problem and thank you for UMS in general.
It's still the best media server out there for my purposes and my device makeup.
Twonky, PLEX, and XBMC come close in different respects and have their place within the media server ecosystem but UMS takes the prize.
Everything I need and nothing I don't.