thatsthefrickenlightning

Noted, thanks!

Having some hardlink troubles. I added '-H' to Unbalance's flags (so the field now reads '-XH', the X is a default). Then I moved a folder containing hardlinked files to another drive. I hoped the system would know that these files were hardlinked, find the other copies and copy them over as well, all while keeping the directory structures that hold the files intact. That unfortunately didn't happen. The initial files were moved just fine, but the other hardlinked files are still on the original disk. So the end result is the same files on two drives and the space savings of hardlinking temporarily undone. What am I doing wrong here? Any help grealy appreciated, thanks.

You'd need to read the last ~2 pages to get up to speed on that, but in a nutshell: no HW tone mapping on Intel in this container at the moment. LSIO's Plex Server works for this. Not sure about your specific Intel gen, but in general, it works there.

Perhaps the packages simply aren't available for Arch yet, or they're not in the right working condition. With LSIO's container running on Ubuntu (if I'm not mistaken), that's a different ball game. Maybe @linuxserver.io can weigh in on this: are there Arch equivalents of ocl-icd-libopencl1 and beignet-opencl-icd available and are they working? We're having some trouble with this over here (no HW tone mapping on Intel). Thanks much.

I see, I misunderstood the question a bit then - thanks. Luckily, I still gave the full and correct info. I read Plex's requirement and am suspecting that Coffee Lake is not the minimum and they just didn't formulate that very well (and that it's a Ubuntu-specific minimum, for whatever reason). This suspicion is supported by the Wiki page for QSV stating Kaby, Coffee, Whiskey and Comet Lake all have the same capabilities, QSV wise. EDIT: no, that's not the case, but their differences seem to be few and are not based around encoding or decoding h.265 video. Looking for ward to more from you two. Thanks. Edit 2: found this post from a Plex moderator on their forum. The table towards the bottom of his post lists the i7-7700K as capable of 'hardware transcoding h265/HEVC (8/10bit → SDR/HDR)'. My i3 is of the same generation so it should be able to do this without issue, and in my view it does do hw tone mapping without issue on LSIO's container.

Are those the two options? It's an i3-7100, so if those are the two options, I'd go with Haswell, as that's newer, but it's still older than my gen. The generational name of my CPU is Kaby Lake, the GPU is an HD 630, the QSV version is (according to wiki) 6. Hope that helps.

Alright, that generated a ton of lines in the console (again, can paste if you want), but it finished without an error afaik and I restarted the container. Transcode speed on the 4K HDR file is still 0.7 however, so no luck.

Thanks binhex. I tried the commands in the order you gave them, got no errors, rebooted the container where necessary, but I'm still not getting a transcode speed above 1.0 on my 4K HDR file. I'll be here for any other instructions and let me know if you need screengrabs of what the console returns, I have those too.

Great work @SloppyG, I'd figured out pacman is what apt is on other distro's but that's as far as I'd gotten. Glad we seem to be making some progress. Looking forward to seeing binhex's reaction, but am grateful for all his work regardless. In the meantime, I may move over to LSIO's container, but if this were a relatively simple and quick fix, waiting is also a good option. Decisions, decisions...

I bit the bullet late last night and installed the linuxserver PMS container to see if I could garner more info. Lo and behold, after giving that container access to the Intel iGPU, I could transcode three whole streams of my 4K HDR file to 1080p simultaneously with a speed of ~1.5. How much ram does Plex have available for you, Arturo? Because while it's performing much better, you're still doing better than that. @binhex, unless I'm doing something else wrong, I suspect your container is missing the library and driver to tone map HDR->SDR in hardware with an Intel iGPU (info). I cannot transcode & tone map one 4K HDR file to a 1080p SDR stream on your container without buffering but on linuxserver's container, I can do three. @SloppyG, I think this is relevant to you as well.

Thanks for your reply, but subtitles are disabled in my tests.

Hi, thanks a lot for your reply. I'm not sure the info you posted demonstrates that tone mapping is working on your system, though. I see no mention of HDR or anything of the sort in the sample file you posted. Since my post I've upgraded from an i3-6100 (Skylake) to an i3-7100 (Kaby Lake, so 10-bit h.265 encode/decode capability is there now), but my sample 4K HDR file still won't play on clients that are not HDR capable. Transcode speed is simply not above 1.0 and my dashboard shows CPU usage is high (66%+ on all 4 cores/threads) and the iGPU is being left largely alone. Files that are h.265 but without HDR are converted by the iGPU without issue. Would love to hear your thoughts. Specifically, I think I need to find out how I can check if the drivers mentioned in the Plex support article are present. Another thought: that Plex support page says 'HDR to SDR tone mapping support is currently available as a Plex Pass preview'. If that info is still up-to-date, shouldn't we be using the container binhex/arch-plexpass? I say that, because binhex says that container will 'allow Plex Pass account holders to get early access to new features'. Am I simply on the wrong container? EDIT: on 2nd though, the option to enable tone mapping is in the settings, so it seems we're on the right version. So it's a driver thing? Thanks. EDIT: to add, I was thinking the i3-7100 simply wasn't strong enough, even with hardware acceleration enabled. This post however says that multiple high-bitrate 4K HDR transcodes & tone maps should work just fine. Jesus, this has me so frustrated.

Hello, I've got a problem with tone mapping hdr to sdr. My system (i3-6100) cannot tone map even a single 1080p ~6mbit hdr10 stream to 1080p sdr. Transcode speed does not go over 1.0. Intel Quick Sync is enabled and works (i see 'HW' in Tautulli), but I suspect the necessary dependencies that the Plex devs talk about here are missing, and that the tone mapping is done in software and only the rest of the transcode work is done by QSV. Are my suspicions right? How do I check for the presence of the “libOpenCL” library and “Beignet” GPU driver and how do I install them? Or maybe it would be easier to switch to a different Plex Server container? Many thanks. EDIT: Or my i3-6100 simply does not support hdr->sdr tone mapping in hardware? EDIT 2: I've discovered my i3-6100 doesn't support hardware decoding of 10-bit h.265 files, so that's where the slow transcode speed and high cpu usage is coming from. If anyone can tell me, I'd still like to know if this container is equipped for tone mapping by means of Quick Sync and if my i3-6100 is capable on tone mapping at all. Wikipedia has me suspecting it's not, but the info feels incomplete ('hdr10 tone mapping per qsv 7 but nothing on DV'). Thanks.

Just walked through this guide. I had to enable the ipgu in the bios, which required me to borrow a vga cable from a neighbor, but after that things went pretty smoothly. Thanks a lot! This is a great improvement over software transcoding and will be sufficient for now.

My hero. I saw the setting, but somehow forgot to fiddle with it. I feel a bit silly now. I've donated to you again. Thank you!

Hello everyone, hope you're all well. I'm having an issue with this docker container. Until a few days ago, I could access the webui while away from home by way of the Wireguard access server built into Unraid. Lately though, requests to the webui are timing out, but only when Wireguarding into my home. If I'm not on Wireguard but am connected to my home wi-fi, I can reach the webui just fine. It's not a firewall issue; if I change the port of for example Radarr to 8080, it connects fine, even through Wireguard. So it seems to be the QBVPN docker that's giving clients the cold shoulder if they VPN into the home via Wireguard. Can anyone help me out with regards to what changed or what I need to change to give my away-from-home devices the green light? Many thanks.

This is a bit of a side question, but since you can only see the web UI in this form of QB, I'm having an issue. I can't find torrents with tracker status 'not registered with this tracker' (i.e. deleted from site) easily. I need to click every torrent and check manually. Does anyone know of a better way to do this?

You're very welcome! Perhaps this is a bit of hillbilly tech, but if you have your entire library in your torrent client and in your plex server and they should be hardlinked, you could just delete your whole Plex library. If the files are hardlinked, there should be no change in the drive space indication in unraid.

I left /data and /config alone, deleted /media and created /mnt ( = /mnt) for Sonarr, Radarr and qBitTorrentvpn.

I'll have a go at that. No clue why one server would work and the other would not if the port forwarding api was down. Unless servers have their own api. E: current-gen Vancouver works like a charm. So either the error is untrue (no hate) or there are multiple port forward apis.

Doubt it. On august 25th PIA said 'Next Generation servers do not currently offer port-forwarding outside of the application'. Without port forwarding, I can't get any traffic going at all, neither in nor out.

Getting this now: '[warn] PIA VPN port assignment API currently down, terminating OpenVPN process to force retry for incoming port...' Will wait a bit but maybe this is the end of QBVPN until the migration to next gen is complete?

Switched to this endpoint on the legacy network. Working for now. Not ideal, because trackers expect me on a different ip (range), but it'll do for now. Thank you!

Thanks for the info. What would your alternative be? I'm impressed. If I hadn't donated already, this would get me to.

Thank you very much for this. I had to turn my server off for some maintenance and I thought that was the problem, but it was this. Next-gen config files work for me, but no actual torrent client activity until port forwarding is supported. Any ideas when that will be?