Up
I reboot my HTPC weekly during off-hours. Takes care of "issues" that get induced with time.
Which Plex programs are doing this? Check the resource monitor and see what is actually running.
In the processes tab of the windows task manager, there's no tasks that get this big amount of memory. But the problem is just that: the PMS task allocates memory without deallocating. It causes Windows to be not able to know wich process took memory and it can't free up!
For me, rebooting the PC is a big problem: first because the same server controls my home functions because of a domotic smart home, second because it get much time to reboot...it's so slow!!!!
In the processes tab of the windows task manager, there's no tasks that get this big amount of memory. But the problem is just that: the PMS task allocates memory without deallocating. It causes Windows to be not able to know wich process took memory and it can't free up!
For me, rebooting the PC is a big problem: first because the same server controls my home functions because of a domotic smart home, second because it get much time to reboot...it's so slow!!!!
See if you can get closer to the problem by trying to get diagnostics for the Plex Team through SysInternals VMMap
When I was having problems I tried the option of launching Plex Media Server from within VMMap to get the ability to trace what goes on but when I was trying it,, it was using an earlier version of VMMap which was crashing when using this option. I reported it at the time to the developer and hopefully the current version of May 2014 has a fix for that.
I gave up on doing big filtered slideshows as the memory related crashes led to database corruptions and inconsistencies losing most of the folder thumbnails and i do not want to end up with the same problem on my new PMS.
Just going from 32-bit to 64-bit does not automatically double the speed. Most of what Plex does is just file handling, which will get very little boost in speed from 64-bit programming. The main grunt work is from the transcoder. The transcoder is based on FFMPEG. Here is a link to a site where a person compile FFMPEG into 64-bit from its native 32-bit. He only saw about a 10% improvement in speed. http://www.helyar.net/2014/compile-ffmpeg-64-bit-on-windows-with-msysmingw-w64/
A 10% performance improvement is still an improvement and nice to have.
I am puzzled by some of the comments regarding the difference between a 32bit and 64bit processor. The 64 bit processor simply means each register can point to memory addresses with a 64 bit number. So that is a LOT LOT more than the 32bit processor. This simply means it can support computers with more memory. So you need this if the application need heaps of memory which plex does not. Certain programmes speed up a lot on a 64 bit computer if they can make it quicker by consuming more than 4GB of memory by caching...this is not going to benefit plex. All plex would need to do to make a 64 bit version is compile it as 64 bit which is no big deal...
I guess to improve performance, if plex pre processed a lot more of the transcoding and store this in memory ready to send accross to the client this could help a lot and demand more memory, even this i doubt it would demand that much more and I suspect they do not want plex to consume huge amounts of memory anyway....
32bit or 64bit, just get as fast a processor as possible ....
Just going from 32-bit to 64-bit does not automatically double the speed. Most of what Plex does is just file handling, which will get very little boost in speed from 64-bit programming. The main grunt work is from the transcoder. The transcoder is based on FFMPEG. Here is a link to a site where a person compile FFMPEG into 64-bit from its native 32-bit. He only saw about a 10% improvement in speed. http://www.helyar.net/2014/compile-ffmpeg-64-bit-on-windows-with-msysmingw-w64/
You act like 10% is nothing. If AMD released a patch that would increase GPU performance that much people would be going ape ■■■■.
Sure, for gaming where improvements can increase FPS, anti-aliasing, shadowing, etc, 10% increase could be noticeable. But for the Plex transcoder, speed is not that big a deal. In most cases the transcoder can already go faster than real-time so going faster just means your CPU will throttle longer.
@MikeyC777: 64 bit registers means the processor can handle much larger and complex math in fewer steps. It isn’t simply about ram. Particularly with with video editing. Think of it like this. What if every sentence you wrote could only be 32 characters long. There could be allot of things you may not be able to write, or would take multiple sentences to convey. Then how much more could you explain per sentence if you raised that limit to 64 characters. It is kind of the same idea with how the cpu works. There is also no guarantee of any improvement with 64 bit computing because the app has to be optimized to take advantage of it, and it has to be right kind of workload.
@MovieFan I think the benefit of 10% is really up to the person being effected. What if that was enough to let someone go from 720p to 1080p. Or may allowed a 3rd stream that wasn’t possible before. Or what if it allowed a low powered fanless system to do transcoding that just wasn’t quite able to before.
No improvement should just be completely ignored because the improvement isn’t considered non substantial enough.
The one question I would have now though is with x.265 around the corner I would prefer they work on that then rewrite the transcoder for minor improvements. Although 64 bit just from the computational perspective should be the direction they are heading
Sent from my SAMSUNG-SM-N900A using Tapatalk
Any improvement is always good, but the cost benefit analysis needs to be considered. By switching to a 64-bit FFMpeg, you would have to have a 64-bit OS for it to work, which could impact a lot of users who are still on 32-bit OS's. Would the clients need to convert to 64-bit too? I do not know that one, but if they do, that would be a lot of work.
Plex already supports x265. I tested a few x265 samples I found on the Web and they transcode and play fine using the WebApp, my Roku, and on Android.
Completely agree with cost analysis. That is why I brought up the x.265 codec. I agree there would be some increased system requirements, but with the recent change to require vista or above do we really think most of the systems will not be 64 bit now. They could also keep the current encoder for 32 bit systems. It is probably pretty well optimized already.
I also wasn’t talking about taking a x.265 video and converting it to x.264 for play back on devices. I am talking about x.265 and streaming it to my 4k TV natively without transcoding.
Sent from my SAMSUNG-SM-N900A using Tapatalk
I thought PHT can do that already.
If PMS can then I should be converting most of my content to x.265. My understanding was it supported the scenario you mentioned were it would just convert it back to x.264 then send the stream to the clients.
My understanding was that pretty much everything for x.265 encoding was still to immature for prime time. Basically allot of optimization are still needed for it to be a practical option over x.264.
Sent from my SAMSUNG-SM-N900A using Tapatalk
Yeah...Protools or Adobe Premiere rendering videos presents quite a different "overhead" scenario than PLEX Streaming even local content. I've been busily trying to find everything that's out for WIN 7 64 (Surface---no so much) but I'm starting to ease up. Some Apps not written to actually properly use the 64 bit registry moves etc actually perform slower than their 32 bit counter parts.
PLEX is Great as a Stream Source--at 32Bits--Playon as well. They are NOT bottlenecks. PlayLater (a kinda DVR--now that might be a 'nuther matter. On the HW side I really like my WD TV LIVE that I bought on UBID for 49 bucks. It finds everything remotely DLNA SO between all the "i" things (pad, pod, phone, PC's, NAS's, and 6TB externals--I can just intranet everything and almost nothing needs to be trans-coded from the source--The WD handles just about all formats. ROKU is great for Netflix, HULU etc but SUX at streaming local content.
64 Bits---the Ability to access a lot more RAM is a plus---regardless, and NOW every Desktop, Laptop, Net book that I own uses SSD boot drives. What I need is more Mbps DOWN :-) Time-Warner has me at 110 and my Netgear Nighthawk manages to WIFI at nearly that speed (though I hardwired my entire space for Ethernet!) But I could easily get used to 200, 300, 400---like a lot of Europe already has!
I'm a bit confused, is there a 64-bit version of PMS for Windows or not? It seems that recent version of PMS for OSX only supports 64-bit processors and no more 32-bit processors. So what is with the Windows version of PMS? (and what about PHT 64-bit?)
Info here:
There is no 64-bit version for Windows - hence the discussion in this topic
I for one would like to see x64 added, certainly on the transcoder and library handler. Even if it's only a 10% increase, it's a welcome addition to my server. Is it known if the x32 version can adequately multi-thread? If not, I wonder how much that would improve the performance.
I would like to see an x64 version also.
@Jhackler said:
MovieFan wrote on August 14 2014, 4:55 AM: »Just going from 32-bit to 64-bit does not automatically double the speed. Most of what Plex does is just file handling, which will get very little boost in speed from 64-bit programming. The main grunt work is from the transcoder. The transcoder is based on FFMPEG. Here is a link to a site where a person compile FFMPEG into 64-bit from its native 32-bit. He only saw about a 10% improvement in speed. Loading...
A 10% performance improvement is still an improvement and nice to have.
Agreed. That 10% could be the difference between smooth playback and stuttering. And just by going 64 bit? If i could speed up the app i write at work just by changing to compile 64 but instead of 32, it’d be a no brainer.