Add the ability to cache specified, related, frequently accessed or partially watched content in memory during idle time, off-hours or overnight for immediate playback.
This would be extremely useful for powerful workstations or servers with lots of fast RAM.
This would also be a very good reason to produce a 64-bit version of PMS.
Edit: “… a 64-bit version of PMS for Windows.”
PMS is already 64-bit!
Then this would be a good use of 64-bit architecture.
Why? My videos start playing in about 5 seconds max. Don’t think your gonna gain much more.
Well, again for those of us running high end machines or just PCs with 16-128GB of RAM you could gain higher performance if streaming or transcoding from RAM than from disk and you’d reduce wear on your disks.
Just point your transcode to /tmp to use ram.
At this point, anyone can configure a RAM Disk for transcoding, but not the intelligent and automatic caching of chunks of frequently accessed or partially watched content so that it’s immediately ready for viewing. It would also give your transcoder time to “catch up” and eliminate delays in playback.
It would be a “YouTube” or “Netflix”-like experience.
Just like we can sync media to a client for smoother playback, Plex should be able to cache media to RAM for faster playback from the server.
What else are you going to use your 32-128GB of unused RAM for?
You’d get more cache misses than hits, it just wouldn’t be worth the effort or taking up all that free ram from potential other uses. When people have terabytes of media files they might just watch at random, what is the probability of a cache hit? Also you don’t need to stream from memory, a hard-drive is plenty fast enough.
Nice idea, but in reality it’s not been done for good reason.
This feature would be extremely useful for users with lots of spare, underutilized RAM and given the suggestion to be able to specify the content you wanted to cache, along with related content (the rest of an album, part 2 of a movie, the next item in a playlist or similar items in a collection), it is unlikely that you’d have a cache miss.
If you don’t think there are potential perfomance gains I’d recommend creating a RAM Disk, loading it with a small assortment of content and specifying your RAM Disk as the volume to transcode to and then let me know what you think.
You’re welcome.
Yes but you would have to specify the content to cache and so know in advance what you want to watch or listen to. That just wouldn’t work with most people who have multiple users and I for one don’t know what I want to watch or listen to until I sit down and turn on Plex, just depends on my mood.
As for trans-coding, the best solution is to not trans-code at all, and if you have a mobile device out of the home that needs the stream trans-coded due to bandwidth constraints, then as you know what it is you want to watch before leaving the house to be able to set it in the cache (if there was the option), then the better solution might simply be to copy it to a memory card or similar and take it with you.
I can understand in some circumstances there are a some users who might find it useful, but don’t forget Plex has to cater for the masses and has already so many bugs and issues to fix that redirecting development to a niche function like this just will never be given any time.
The wider question perhaps, is why spend so much on hardware with tonnes of memory you don’t have a use for currently?
Well, the point of the feature suggestion is to suggest features that you think will add value or performance to Plex. Not every feature currently in Plex is useful to every user and while Plex does have a lot of bugs to squash and Plex does have to cater to its common userbase, once in a while they can develop a feature for those who have invested a lot into Plex (notifications and transcoding are examples of niche features that few users really care about).
On the topic of transcoding, you are correct, it is always best to run a direct stream, but for times that you do have to transcode you’ll get a better experience by minimizing buffering and you’re also potentially sparing your HDDs or SSDs from multiple reads or writes.
Again, I did mention being able to specify content that you want to access and caching it overnight, off-hours or during idle time; you could also specify new content, related content, partially watched content - you know, the stuff that Plex already intelligently recommends.
I guess one solution would be to watch on deck and preload the next episode of a show. In the case of playlist it could take that into account and preload the next one.
That’s exactly what I had in mind.
I could see this as a cool feature benefiting those with low power servers. I’ve compared video on ssd cache to that on disk pool and see no difference in speed. Would ram be faster than ssd? Probably not noticable. I go from click to watching in 2-3 seconds no matter were the media is located Including over the network via smb share.
I wouldn’t expect there wouldn’t be a noticeable difference in loading, playback or transcoding to or from RAM compared to SSD, but then you wouldn’t want to host or transcode via SSD due to limited read-write capabilities of SSD.
Ideally, it is best to host media on HDD and that is where you may notice a slight difference depending on the speed of the drive and your SATA bus.
The point of preloading or caching media and transcoding to RAM is to reduce the read-writes to your drives (which slowly limits their lifespan) and using a much faster bus for playback and transcoding.
I use ram for transcode. My media is served from hd. My ssd just holds the meta data. All my drives are 7200. Pretty snappy overall. My only complaint is the occasional bottleneck when moving large amounts of data. I believe it’s Io wait related.
I’m sure most Plex users don’t think about using RAM for transcoding, much less prefetching.
