/usr/bin/mono-sgen --optimize=all /usr/lib/emby-server/bin

[chiefnerd 18]

Constant and persistent in our server processes & currently at over 600%. This is the latest version and to be honest it's atrocious and clearly hasn't been tested on Ubuntu Trusty (yet again) because it is full of bugs

 

/usr/bin/mono-sgen --optimize=all /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -ffmpeg /usr/bin/ffmpeg -ffprobe /usr/bin/ffprobe -restartpath /usr/lib/emby-server/restart.sh

 

[Luke 37167]

Hi, can you discuss the defects you're seeing in a little more detail? thanks.

[chiefnerd 18]

Beside the fact FFprobe is taking upto 600% (6 cores) of the CPU to run a simple probe which to say the least is crazy, we have ffprobe running on our TVHeadend server probing 100 IPTV feeds concurrently and half the streams then have the audio transcoded to AAC- CPU rarely goes over 2% with the entire process at around 80% of a single core. BUt here we FFprobe on a single child process at over 600%- TBH that's dangerous ground and for it to be at that level for nearly 5 hours straight with over 13GB in it's process is mad!

 

On top of that the library refuses to scan cutting out and restarting Emby which I'm betting pound to a penny is due the first major point.

 

Web Interface- refreshing from the manage server side removes the options on the left panel forcing you to go into the library view then back to manage server again.

 

Image overlays in the library- appear blank, after 20 seconds they might appear. Click on extra options then brings the popup dialogue to the far top left of the screen instead of instantaneously and centred.

 

Web interface very sluggish and I'd kind of expect it to be when FFprobe is using almost all server resources probing 1 file (actually, just a TV channel already in ts format with h264 and AAC).

 

Upon update every single collection vanished- all of them.

 

Changing Meta Data names is slow and I mean very slow. Change the Title by adding in just 3D to the title then takes 5 minutes to update locking up the server in the process- I'm also putting money on this being due to the first major point.

 

This is not a Raspberry Pi - it's an intel E5-2620 v3 with a 128GB of RAM- it can handle anything you throw at it normally until this update when you;ve managed to bring it to a grinding halt.

 

And yes- Emby Sync was uninstalled when I noticed the scan issue and it's persistent. And as I've repeatedly said, I'm betting a pound to a penny all of these issues come down to the fact ffprobe is running uncontrollably.

[Luke 37167]

Can you offer suggestions of changes to the ffprobe command line for your environment?

[chiefnerd 18]

ffprobe does not need to be used to be used to transcode a TV channel- it's used to pull out media info, run once and exited, it's pointless it running constantly to check the exact same file when it;s not going to change.

 

Here's a standard command we use for transcoding which works:

 

/usr/bin/ffmpeg -i FILE -vcodec copy -acodec libfdk_aac -b:a 128k -f mpegts

 

That prompts ffmpeg to to get info from the file with -i command then copies vcodec and transcodes audio to AAC but absolutely any command can be used- there's no actual ffprobe being called, it's using it's in built function to read the media information. My suggestion? ffprobe only on library scans- it shouldn't be used on the output from something like TVHeadend and anything ffprobe can pick out like subs FFMpeg can do this natively with specific commands and trust us- it uses very little overheads ie not 600%

[chiefnerd 18]

 

All of those are being read and transcoded live- note the CPU use and also below- 0.33 of only 1 core utilised

 

[Luke 37167]

We only probe once when you import the content into your library, then we would only probe again if you manually refreshed that content, or the timestamp of the file changed. is that not what you're seeing?

[chiefnerd 18]

Luke mate- I told you the issue is persistent, that means it doesn't go away and it's child process is a TV Channel it's transcoding...the process size is now upto about 15GB. FFprobe is probing the the channel stream

[Luke 37167]

Luke mate- I told you the issue is persistent, that means it doesn't go away and it's child process is a TV Channel it's transcoding...the process size is now upto about 15GB. FFprobe is probing the the channel stream

 

The server does not probe live tv streams from plugins, however some of the live tv plugin developers have baked this into their plugin directly. You could consider taking this feedback to the tvheadend discussion and ask them to not probe the stream. I am sorry this is affecting your experience with Emby Server but this is not the intended default out of box behavior.

[chiefnerd 18]

This is being called by emby directly- here is yet another screenshot and this is having killed the process

 

[Luke 37167]

that looks like the emby process itself, not something emby called.

[chiefnerd 18]

within 30 seconds of starting a library scan- not hose levels - that means it's using 18 core threads of a maximum of 24!!!!! It' s using that many cores using FFProbe alone????? On a Library where nothing has changed???

 

[chiefnerd 18]

Then it'll crash itself, restart Emby then the same process will stay through the roof for 5 hours before settling down to 46% of a single core

[Luke 37167]

can you provide the emby server log? thanks.

[chiefnerd 18]

OH.MY.GOD- it just, actually finished scanning the library- after 15 hours today, it actually scanned the library! Shame it's still up over 300% even though it's finished.

 

You;re aware that the server logs for Emby is around 150MB yeah?

[Luke 37167]

if there's anywhere you can upload it i'll take a look.

[chiefnerd 18]

If there's something specific you're looking for I can search the log and pull entries otherwise the latest log after it restarted itself is 90MB or I'll restart emby again and get a smaller log

[Luke 37167]

i really just want to look at the whole picture.