ffmpeg logging/large embysvr.stderr file

[majorsl 23]

While attempting to troubleshoot what piece of media I might have that is corrupted, causing a continual library scan longer than 24 hours with > 90% CPU usage on my Synology, I discovered a couple of things:

 

1) I swear that in the past the ffmpeg logs were visible in the server console of Emby.... is this no more?

 

2) The errors/logging of ffmpeg seem to be defaulting to embysvr.stderr which is fine, I guess, but requires you to know where to look by ssh'ing into your Synology... and...

 

3) My embysvr.stderr hasn't been rolled since April 7th, 2018, and has grown larger than I tend to like these things to be:  ~490MB in my case.  Is there any housekeeping for Emby's std files?

 

I'm seeing a lot of ffmpeg probe failures.  I know this can be common, but it seems to be "more" with the last few builds.  I'm not going say it's a problem, I'm still looking to see what is happening with my scans, but wanted to note it if there is a known issue lurking.

[Luke 42077]

1) - they still are

 

For the others, please see how to report a problem. Thanks.

[majorsl 23]

Logs attached, screen shots of the Log area and the directory on the Synology.  Are there supposed to be separate ffmpeg*.log files here?  Also, note the size of embysvr.stderr as mentioned.  It's ~490MB so I didn't attach it, but I can put it somewhere if you want it.

 

Log.txt

Log (1).txt

Log (2).txt

Log (3).txt

Log (4).txt

Log (5).txt

Log (6).txt

Log (7).txt

Log (8).txt

Log (9).txt

[Luke 42077]

Yes if there were any transcoding sessions, then the ffmpeg logs would be there on that screen.

[majorsl 23]

Ah, okay. I was trying to find them because adding one 4K movie will spawn several ffmpeg processes which run for hours.  I'm trying to figure out what they are doing, I do have "Enable chapter image extraction" enabled, but don't recall it taking quite so long.  I plan to turn it off for the next movie addition and see how long the addition takes, but I didn't think it was that long.  Last night my "Scan media Library" took 8 hours and 36 minutes with the addition of a couple of 4Ks and a few 1080s...

[majorsl 23]

Any idea what might be going on with the logs provided?  I'm going on another 10 hour library scan with > 90% processor usage with Emby.  It seems to be ffmpeg causing this.  I added two movies, both with 1080 and 2160 versions.  I have not seen this behavior with my system before.

 

If you give me a couple of hints of things I should look for in the logs, I'm more than happy to look myself.

[Luke 42077]

Which log file contains this activity?

[majorsl 23]

Given the duration of the scans, it may span several as they probably rolled over during the scanning.  The are numbered reverse-chronologically.  My guess is it ended in the standard Log.txt, but started in Log 1, 2, maybe even 3.

 

I did not have debugging on for that, if you require it, I'd be happy to enable it and start another scan.

 

The scan DOES eventually end and the added items are identified correctly with all metadata.  TV episode scanning is very quick as it always was.  It seems only the Movie scan takes awhile.

[Luke 42077]

If you'd like to speed up your library scan, try removing these plugins:

	Pushover Notifications 3.1.1.0
	Roku Thumbnails 3.1.5.0
	Statistics 2.0.5.1

[majorsl 23]

Thank you very much for having a look.  I try not to bother you guys too much.

 

Sure, the Roku Thumbnails is a recent addition, so I'll try that.  I thought it was a separate task according to it's description and the item in scheduled tasks.  I've had it running for many weeks, so maybe this was always the culprit and I didn't notice until the past few days.

 

Pushover, I've had "forever", I'll remove it, but unless it's broken recently it never was a problem.

 

Statistics I installed when this started happening to locate "unknown", therefore potentially corrupted or "not right" media, which I did find some and replaced.  So, done with that too!

 

I'll post again if the removal doesn't seem to do the trick.  Thanks again!

[Luke 42077]

Thanks for the feedback.