I am not taking about a problem with different formats or something hard to catch… the latest regression with the web client is basic functionality of being able to edit and / or add files… I don’t have time to link to the post but right now everyone is in workaround mode having to use the front end served off the plex website rather than their machines …
Now … i agree that you guys are probably working harder than squirrels before winter… but from the outside it looks as though working smarter AND harder would produce better and more consistent results.
Lets hope that you guys can get some division heads in there that know how to get projects back under MANAGEMENT and tighten up your processes so that each release fixes more than it breaks…
And for the love of god… get some good people working on the front end for the big screen crowds not just the device kids… plex was a HOME THEATER project at its roots and right now its FAILING miserably in that department with its current ‘preview’ effort that is at best an advanced alpha that is a step back in functionalities over the 8 year old code it is supposed to be replacing…
All the best you you and your teams there… I really do want plex to get back on top… and thanks for your service… never gets said enough … even if you were a trash hauler … hehe…
You and I both have our opinions how things could be done better but in all fairness, we don’t know the details. Plex never gives roadmaps and they’ll never discuss internal issues. All we can do is speak in a unified voice and help them.
Do you mind if I don’t pick up your trash tomorrow? I still have a hangover from last night.
@natelabo said:
I’ve run the optimize a few times… I just ran it again… Isn’t this set to automatically happen during nightly maintenance?
Anyways I tested again after optimizing. Still get a ton of the “Transaction was held for too long messages…”
You have the same problem that I had. Actually it’s more of a problem with Plex. I had a pm discussion with a Plex dev and we confirmed that it would not help with even a rebuild of the database.
The problem is with your sync items. Or rather, that Plex has pretty complex queries regarding them. In my case, the combination that I have a rather big library (database is almost 500 MB) and had like 70 different sync jobs caused this problem.
Turns out Plex runs these queries almost every time a transcode is started. At least in my case. For me this caused a CPU spike on the server from pms.exe which on my meager dual core was enough to start stuttering of the transcode. Obviously your CPU is more powerful, but maybe checking this wouldn’t be a bad idea? Maybe the transcode is on the same core? I think I’ve heard vc1 transcodes are limited to 1 core so maybe that’s why? Just guessing.
Anyway, at the end of the day I just deleted my sync items and that made the problem go away. Let’s hope you don’t have to but it kinda seems like the same thing.
I removed all sync items. Are you referring to items that sync to devices? Problem still exists…
I’m not sure how large my database is… But library consists of 60,000 songs,1200 movies and 500 TV Shows?
I’ve checked core use and it often is not going over 50%… Actually while it’s not working PlexPy is reporting that playback is paused. Transcoding speed never goes above 1.
Devices are now reporting that server doesn’t have enough power to convert.
This wasn’t an issue a week ago… Super frustrated.
I’m probably going to spin up a test VM and see if it’s just this server install…
Thanks for your insight.
Regarding sync items, I mean the sync “jobs”, I guess. I mean the things you set up to create a sync. Like if you go to Plex Web and click the sync tab in the upper right (under “status”). I had like 70 jobs here (one for each music artists I had synced to Android). I don’t know if the amount mattered, but I removed all of the sync jobs just to be sure, and my problem went away. And yeah, our libraries looks more or less similar size wise.
To be clear, I’m talking specifically about the “Transaction was held for too long messages” in the sync item generator. When this message appeared in my logs, Plex Media Server.exe ate up an entire 3.9GHz core for about a full minute. This left only one core for transcoding (Plex Transcoder.exe) and it would sometimes not be enough to keep transcoding speed over 1.
So, do you still get the message in the log after you deleted your sync items? You say that your transcoding speed never goes above 1. That tells that your server can’t transcode the file fast enough. Which could be the case if the sync items causes a spike on the same CPU as the transcode.
Otherwise, since it’s only happening to vc-1 files, and since that is the only format that I know of that uses only one core for transcoding, it has to be assumed that either one single core of your CPU is too slow for your particular transcode, or that suddenly, something demands attention of that core at the same time. Which is why I keep nagging about the sync items
That’s what I thought. I removed all of those… Still same problem. I never had this before. Processor is E3-1276v3.
I did further testing. I actually started up a completely new VM. It is now my belief that a single core of my processor is not fast enough to transcode VC-1 files with bitrates above 30Mbps. It is interesting… I’ve never noticed the problem because I transcode locally to 10Mbps 1080p but my remote users are limited to 720Kbps. Is it easier for the transcoder to transcode to 1080p format if that is what the source is?
Here are the XML details of an example file that works locally yet not remote:
-Performance
# of Cores
4
# of Threads
8
Processor Base Frequency
3.60 GHz
Max Turbo Frequency
4.00 GHz
Cache
8 MB SmartCache
Bus Speed
5 GT/s DMI2
# of QPI Links
0
TDP
84 W
Since the CPU Benchmark number mentioned in the guide says roughly 2000 for a 10Mbit 1080p, I’d venture on a guess and say that that is the case, yes.
(Pushing anything from 30Mbit down to 720Kbit on the fly sounds strainous regardless of cores, I’d recommend expanding on storage and keep two copies of each media file - one for local and one for remote)
@natelabo In my experience, it is more straining to transcode to 1080p than to 720p or lower. Although some people seem to think the opposite.
I guess the only thing I can think of regarding your problem is that a subtitle is in use? I have noticed that transcoding with a subtitle can sometimes cause a lot of extra strain. This can explain why a single core “suddenly” can’t do it.
When it comes to the VC-1 codec, the decoder Plex uses is limtied to 1 thread and therefore stuck to 1 logical core. Your CPU has an overall passmark rating of 10,231 which is really good, but a single core/thread score of 2287. That is a great score for 1 core, but it’s not enough to handle a 30Mbps file. You mentioned PHT earlier. If you are using that (or PMP or OpenPHT), they can direct play VC-1 so there is no need to utilize the decoder so it can work locally for you. If your remote user is not using one of these clients or another client that directly supports VC-1 or your internet bandwidth cannot handle the full-size file, then the video needs to transcode and that’s where it has issues.
@MovieFan.Plex said:
When it comes to the VC-1 codec, the decoder Plex uses is limtied to 1 thread and therefore stuck to 1 logical core. Your CPU has an overall passmark rating of 10,231 which is really good, but a single core/thread score of 2287. That is a great score for 1 core, but it’s not enough to handle a 30Mbps file. You mentioned PHT earlier. If you are using that (or PMP or OpenPHT), they can direct play VC-1 so there is no need to utilize the decoder so it can work locally for you. If your remote user is not using one of these clients or another client that directly supports VC-1 or your internet bandwidth cannot handle the full-size file, then the video needs to transcode and that’s where it has issues.
I have begun testing the optimize feature built into Plex. Can you tell me is there a way to filter by codec in the auto optimize? I only want to optimize VC1 files…
