Hi all, I have a system with the following rough specs:
12700K
Z690 Aorus Elite DDR 4 motherboard
80 gigs of RAM
I currently have a single vdev which consists of 6 6TB HDs, running in raidz2. Everything is working fine.
However, I ended up having an extra 2 disks which would fit in my case, but would necessitate an HBA (my motherboard only has 6 SATA ports).
I bought an LSI HBA which is in IT mode with the latest firmware. I’d like to migrate the 6 disks to the HBA, and also add the extra 2 disks. I’d have all 8 on the HBA, which would free up the on-board SATA ports for a better set of boot drives (I’m using an NVME drive as my boot device, which is wasteful imo). I can get 128 gig SSDs super cheap.
Given that there is no way to extend an existing vdev (at least not currently), I’m forced to recreate the pool, in order to add the 2 new drives. That’s fine - I have 2 backups so it shouldn’t be an issue.
However since I may also go to the trouble of swapping to a new boot device, I’m left wondering if maybe now is the time to rethink my whole setup. I’m wondering if it might be advantageous to run Proxmox, with TrueNAS virtualized, instead of bare metal TrueNAS as I am currently running it.
I’d send the whole HBA through to the VM obviously so TrueNAS has direct access to my hard drives. I’m having issues with Plex with my current setup, so I need to migrate that setup to a VM anyway. I think running a VM on Proxmox is better than running it within TrueNAS, but I’m not experienced with Proxmox, so maybe I’m just confused.
I would love to hear any general advice you all could offer. Thank you.
Ehh - as easy as downloading & uploading a config file, I wouldn’t even use the word ‘trouble’.
I’m curious of what issues you’re having with Plex & if it is worth spending time investigating that instead of switching to proxmox. Visualizing is fine, but adds complexity & not something I’d personally do for a NAS to make Plex possibly not have issues.
That being said if you’re doing this for more-so homelab reasons & want to learn; go for it!
I’m really not certain why you’d need to run Plex in a VM instead of the APP or spinning up jailmaker to Plex in its own instance or a in a docker within jailmaker (man I’m hoping my terminology is half correct, as I’ve not used jailmaker; lots of separate posts on the forums with more useful info/correct info than what I’ve stated here).
Given that you have plenty of backups, I see no reason not to recreate the pool to your maximum liking. Whether it’s worth the time is a different question. But the extra storage space may come in handy.
Whether a proxmox setup makes sense or not is above my head. I’d consider going bare metal for simplicity sake and then put plex in a jail. That potentially insulates you from the coming kubernetes divorce in angelfish and bare metal is a lot simpler to diagnose when something goes wrong.
I’ve had a few people suggest jails now so I think I’ll go that route rather than Proxmox. Thanks for the suggestion!
I noted you’re running the 5900x in your server - that’s an amazing CPU. I’m running it on my desktop. I had considered swapping the 5900x into my server and bringing the 12700k on my desktop, but the transcoding support from Intel is just so pivotal.
What you are describing is in fact a CPU limited problem. During a transcode done through hardware acceleration, you get this:
GPU decodes the frame
Decoded “raw” uncompressed frame is sent over to the CPU
CPU edits the uncompressed frame by editing the PGS subtitle image into the frame and saves it
“Sub edited” uncompressed frame is sent back to GPU
GPU encodes the frame to H264
The CPU bit is done in a single thread and crunching uncompressed 4k frames through that editing task and shipping them back and forth to the GPU can crush pretty powerful systems.
I’m honestly not certain if either CPU could handle it if PGS is that much of a nightmare in 4k with baked in subtitles. Regardless of bare-metal, virtualization, or container.
The most common solution seems to be giving up & getting a client device that natively supports PGS subtitles so you don’t have to burn them in.
Unrelated, but ironically I also have a 12700k, but on a separate machine running Proxmox
“I’m honestly not certain if either CPU could handle it if PGS is that much of a nightmare in 4k with baked in subtitles. Regardless of bare-metal, virtualization, or container.”
Here is the issue with that explanation - when I have the iGPU active and try to use the PGS subtitles, the CPU utilization won’t go above 40% even though I’ve given the container permission to use the entire CPU.
However when I disable the iGPU and force the CPU to do everything, then it transcodes fine with the PGS subtitles, on the same file! I also see the CPU utilization go up.
The only other possibility (and maybe this is what you’re suggesting) is that when transcoding both video and subtitles, and when the video is transcoded by the iGPU but the subtitles aren’t, that specific type of transcoding is single thread limited. BUT - if I disable the iGPU, then the whole thing gets CPU transcoded, and that combination is open to multiple threads.
That seems very odd though I wouldn’t rule it out entirely. One strange symptom is that when I watch ‘top’, I see the transcoder never goes above 400% (4 threads at 100% ea). When I disable the iGPU, I see that process climb to over 1000%.
Last bit - if I have an iGPU and need to transcode a video & subtitles, does the iGPU still handle the video transcode, but then the subtitles are transcoded separately? I understood that the process happened together, so the CPU had to handle the whole thing. But, maybe I misunderstood.
I should add - with the iGPU enabled, the transcoding won’t go above 40% but the video buffers and buffers. With the iGPU disabled, the CPU utilization goes above 40% (closer to 80%) and then the buffering goes away.
This feels to me like a defect in Plex. The jail suggestion was originally posed by somebody in the previous forum thread who said he had an similar to mine in containers, but with Jellyfin - when he went to a jail, the issue went away.
Ha yes, thanks Stux. I agree - the consistency of the 400% CPU utilization makes it seem like a Plex limitation/defect. As you said that’s probably OK with an iGPU 99% of the time, but in edge cases like high bitrate 4k video + PGS subtitles, it isn’t.
I will open a defect with Plex to see what they have to say about it.
Hmmm this is probably good news but I went to open a ticket with Plex. I noticed that a new version of Plex landed in the last few days, so I went ahead and updated and retested it - the problem seems to have been fixed!
I went ahead and opened a ticket to confirm, we’ll see. I checked the release notes for version 1.40.3.8555 but I don’t see anything that looks on point.
It doesn’t sound like the issue was fixed -tbh I’m not sure why I’m seeing something different now.
You can read through the details of my Plex ticket if you’d like, but the TL;DR here seems to be the following.
With an active iGPU + PGS subtitles, and the client requires transcoding of the PGS subtitles, then the iGPU handles the transcode and hands off the result to the PGS renderer, which is run on the CPU.
Unfortunately in this case, the PGS subtitle transcode is single-threaded, and waits on the iGPU output before it can run. This is why I ended up buffering so much with my 4K transcode w/ PGS.
If you do NOT have an iGPU, then both the video transcode AND the PGS subtitle transcode are able to be run in parallel across many threads, then the resulting frames are merged together.
This represents an interesting trade-off in how Plex attacks problems with and without a GPU. This is an edge case where arguably you’re better off without the iGPU.
