As can be seen from the attached logs, while running volume analysis, there is a clearly a problem with a file that Plex finds, but it just prints:
May 10, 2021 03:26:39.277 [0x7fa4a473bb38] ERROR - Analysis: Format error 'Invalid data found when processing input'.
…over and over again in Deep Analysis.log. I cannot find in any of the logs (even with Debug turned on) which file is causing the problem. Could anyone help me find the offending file? Thanks!
I think DEBUG logging is already on for that set - at least the checkmark is on. If I’m mistaken, let me know and I’ll upload another set of logs. Thanks.
Thanks for looking Chuck. Unfortunately, I’m 99% convinced it’s an issue with loudness analysis when music is added (or when the night-time scheduled processing takes place), not with a video file - for a number of reasons:
I’ve had GG for years, without any problems. This problem started a few weeks ago now.
When this happens, it uses my entire RAM and then takes down my server completely. For that reason, it’s been tough to troubleshoot even this far, but setting “Analyze audio tracks for loudness” in Library to “Never” stopped it for a week.
Tonight I had some time so I tried to force the issue by setting “Analyze audio tracks for loudness” back to “…and when media is added” and then added some music files.
(Also, it’s a difficult one to instigate as there seems to be no way of manually starting the loudness analysis process without adding new music or changing the scheduling. The “Analyse” menu option on media in my library doesn’t launch the loudness analysis process, no matter what the settings say.)
Thanks again your time on this so far; I’d love to get to the bottom of this so I can start using volume levelling again without my server crashing every night!
Were it that easy! I add a lot of music, all the time. This problem first reared it’s head some weeks ago and I initially ignored it (restarted the server, moved on) but when it happened regularly I started to look into it and narrowed it down to Plex. Long story short - whatever the album is that’s causing problems, it’s now buried relatively deep in my collection, hence trying to find from the logs which particular file it’s barfing on.
If removing all the music I’ve added over perhaps the last two months and then adding it back, album by album, is the only way forward, I guess I have to do it, but I’m trying to avoid that being the only option!
(BTW, if you look at the htop screenshot in the previous thread - yeah, I’m pretty sure where the issue lies!)
Thanks for looking at this, trumpy. I still think it’s to do with music, partly because it’s reproducible by forcing a loudness analysis to run, and didn’t occur for the whole week while loudness analysis was disabled. And also partly because of this image:
When this happens, the Deep Analysis logs fill up so fast that all five are completely filled with that same message nigh-on instantaneously and the moment where the issue first occurred is quickly lost to log rotation. Yes there is a coincident time stamp with something else the server is doing, but it’s not the Zero Point.
Right now I’m in the process of “unwinding”, as Chuck put it. I can already confirm that removing two weeks of new albums running up to where I can confirm by date the issue began has allowed the loudness analysis to complete without that error flooding the logs - which it would not do earlier this morning. So I think we’re on the right track; I just have to find out which of these 137 albums contains the tainted file (or files)!
And… after over 8 hours, I’ve found it/them… If I had started my search with “esoteric” file types, I’d have found them much more quickly, as they’re .dsf files. I have other .dsf files in my collection, and Plex recognises them (and these) perfectly but these particular ones make Plex’s loudness analysis process enter into an infinite loop until all the available memory is swallowed up and the server needs to be restarted.
On discovering these, I couldn’t kill the process fast enough to have any useful logs (all 5 full of the usual message by the time I got to them). @ChuckPa - would you like me to make one (or more) of them available to you to do some further investigating? (They are each approx. 300MB but I have the bandwidth to move them around as required.)
