I’ve been struggling for months on Debian with plex server randomly getting stuck at 100% cpu usage. It seemed to happen whenever metadata was being refreshed. It could be like that for days, with only a service restart solving it temporarily. Today I dug through the logs and found the [CreditsDetectionManager] BufferingLineReader: failed to read line (error: -1) error.
With lots of experimenting, I found out that sometimes running ‘touch’ on the folders it was stuck scanning would let it continue, but it would come back again. Same thing happened if I opened that specific folder in my file browser, but still temporary.
I eventually tried stopping plex, copying the folder containing the problem files to another drive, copying the folder back to where it was, and starting plex again. Now all of the files refreshed and credit detection didn’t cause any errors in the logs. I’m not sure why this worked for me, but I haven’t seen it mentioned anywhere, so I thought I would post here in case it helps someone. I’ll post again if the errors come back or the cpu gets stuck again, but so far so good.
Interesting… I’m running Plex as a docker container on an Unraid server with 7x 22TB HDD and 4x 4TB NVME cache drives where I keep recently downloaded files for 90 days before moving them to the HDDs. The files that are being rescanned are all on the HDDs.
Considering the file system XFS makes the media share folder seem like one big disk, I wonder if moving the files between disks would even do anything. This is primarily affecting TV shows, at least 100 files. A waste of power to be “detecting credits” of the same file every single day.
I’m not using any kind of virtualization, but I am using an XFS file system too. I then use mergerfs to pool them. The files are already spread between disks in my pool, so I moved them to an SSD and then back. Also, like someone else said, the issue is just with TV shows for me, not movies.
What do you mean by XFS makes the media share seem like one big disk? I’m not aware of that ability.
I may have expressed myself incorrectly. In Unraid, due to parity writing being somewhat slow, most of the writing is done to the cache NVME drives and then transferred to the HDDs at night during a mover schedule. Though a recently “ripped” TV show is sitting on the NVME drive in the media folder, Plex can’t tell whether it’s on the HDDs or NVME. It just sees that share folder sitting in one big drive. Hope that makes sense.
Circling back to the issue, I wish there was a way to disable scheduled credit detection on just have it run when new media is detected. I guess I’m just going to disable it for now which sucks as it’s a great feature when it works.
Are we ever going to get some meaningful progress on all the credit detection issues? Having it stop trying after 3 failures is a nice band-aid, but when will we get a real solution?
I got the same problem on a Asustor Nas, is there a way to disable the credits detection for one TV Show episode like we can do with one single movie?
I did this to some movies to avoid every day 90% processor usage on that movie while detecting credits with Plex doing daily scheduled tasks:
The option for a single TV Show episode is not there, or am I missing something?
Same option for the whole TV Show itself is there, but I have this issue with some episodes, not all of them.
So, for some reason, every few months, Plex would try to do credit detection for the same files and the log would show this BufferingLineReader error. I just noticed that the ones I was seeing were files with Opus audio codec. I’m gonna convert them to AAC to see if I still get the same error.
