I think it would be cool, if you from the admin interface could tell the new transcoder how many threads to use, going from 1 to amount of CPU cores in the PMS
Python:
import multiprocessing
multiprocessing.cpu_count()
That way, if you had like a quad-core box, you could set this to 2 threads, and the overall CPU usage from the indexer would never go over 50 %
Regardless of whether you like this or not, comments are welcome, as long as they are valid, and not just +1 posts
Also, if you agree here, then press the "Like This" on thispost.
And as a site note, and not counted by Plex according to the forum rules, I just wanna take it for a test spin, so there's also a poll, but it's the "Like This" that counts :)
Funny. Must be my mistake. Because when I read the topic post I comprehend something complete different about limiting how many processors a process can use. This would make the indexing process take even longer and thus make me wait even more for the media refresh scan to complete when indexing is enabled. Actually, I don't see how this topic is anything like requesting the thumbnail index process be asynchronous.
Heh, I’m not sure why, but this “feature” seems to be baked in on my server. The indexing process won’t use more than 50% of the CPU in my Mac Mini. I got impatient so I told it to index another section at the same time. Everything is still usable while they’re running, though transcoded content takes 15 seconds or so to start on my Roku (Plex/Web is pretty much instant) and the fan on that thing had been screaming since Monday with at least 3 or 4 days to go.
As an alternative to this request, what about creating the BIF files on demand? It seems stupid to do them all in advance when they’re just going to sit there, most of them unused in my case. Why not fire off a parallel process to index on the first play of a file and then save that BIF for reuse?
I never understood why it needed the transcoder to begin with. Wouldn't it be more CPU efficient to 'view' the movie at full resolution, take pictures of the full res movie and then scale them down after the picture is taken? Resizing a single picture is super fast whereas transcoding an entire movie has got to be a huge strain by comparison.
I never understood why it needed the transcoder to begin with. Wouldn't it be more CPU efficient to 'view' the movie at full resolution, take pictures of the full res movie and then scale them down after the picture is taken? Resizing a single picture is super fast whereas transcoding an entire movie has got to be a huge strain by comparison.
Interesting idea, but why do you think that they transcode in order to grap the screenshots?
Remember, that the new fancy transcoder is a clone of ffmpeg, and to capture, look here: