Xaero

Is there any particular reason we can't implement SPICE for video, with the OpenGL Acceleration (Spice works when manually enabled, but the GL stuff isn't compiled in on Unraid - or at least virt-manager claims it isn't) Spice supports dynamic resolution, audio, USB redirection and clipboard integration in the guest with drivers unlike the VNC Implementation for KVM. And there's already spice web clients (though they do have some limitations, like not supporting celt audio or USB redirection)

M.2 is just a physical interface for SSDs. M.2 PCIE SSDs are generally substantially faster than conventional SATA SSDs. I currently use a bifurcation riser with two M.2 slots for my cache pool and performance is pretty great (though I do manage to bog down the less optimal 660p ssds I have occasionally) The biggest concern is cooling. NVME drives run quite a bit warmer than their SATA counterparts. They don't need to be cold (in fact its bad for them) but they also need to not overheat.

Looks like this has been an issue with Norco for a couple of years now, which is unfortunate. They may be more closed than usual due to COVID. What's wrong with your backplane? EDIT read more of OP - which revision of the backplane do you have, might be as simple as replacing a fuse on the board if it's one of the later ones. EDIT2 now I'm concerned because I also have an RPC-4224 as my primary chassis, if this is the case I may need to look at migrating to a different chassis.

Also worth Noting that the Norcotek website appears to have a JS exploit injected into the page's header. My Antivirus is blocking it. Try shooting an e-mail to [email protected]

Convert offending videos to a format your transcoding hardware supports. Keep in mind not all codecs have hardware transcoding support, and not all cards support all formats that do. Any time the card is not capable of decoding the source format - the decoding will fall back on the CPU. Similarly, if the target format is not supported by the GPU, the encoding will fall back on the CPU. We (the forum members) don't have enough information on the situation to identify why you are having this problem currently.

Correct. Everyone using nvidia transcoding with Plex on Linux has this problem with Plex. There isn't really a simple workaround. I tried injecting a wrapper script to monitor the transcode process and then manually kill the offending process once the transcode has ended, but it isn't reliable, and can interfere when multiple users are streaming transcoded content simultaneously. I think I have some new logic that will work properly - but ultimately Plex or Nvidia needs to figure out why this is happening. According to a recent post on the thread regarding this issue - nvidia was able to replicate the issue in their lab environment, and they were able to use some internal testing drivers that no longer exhibit the issue. That driver release "should" fix the problem permanently for everyone. It's odd that this behavior only seems to happen with Plex, and not Emby - but they are different applications so there could be a different interaction in software there. Here's the thread on the Plex forums: https://forums.plex.tv/t/stuck-in-p-state-p0-after-transcode-finished-on-nvidia/387685 fuser -kv /dev/nvidia* will kill the offending process (and any other other processes using the GPU) by the way.

To build on this, allow setting a title for the code tag spoilers; for example: [ code = "/etc/ssh/sshd_config" ]...[ /code ] could change the header of the spoiler to the name of the file or command of which the code block contents come from?

Would it be possible to implement the fix depicted here: https://github.com/rakshasa/rtorrent/issues/861 Currently, the bug presented in that thread is present in this container. I've been having to screen -r my docker and manually stop and start torrents because I still cannot seem to stop getting the errors in regard to the getplugins.php (my previously implemented resolution stopped working, after a couple of months and incidental docker updates... This seems to be a constant struggle with rtorrent on unraid. Regardless of the number of active torrents.) EDIT: I'm at a loss. I'm back to square one basically. I'm going to backup my rutorrent config folder; and try starting over but I'm back to the abysmal 20-30kb/s and unresponsive (or not even loading) webui. Nothing in the logs seems of relevance. I've read through logs and even enabled advanced logging. There's no "errors" so to speak, just the rtorrent application sitting at 99.99% IOWAIT. I'm wondering if it doesn't like the merged filesystem that unraid uses? I'm downloading to an NVME SSD and the only application with this issue is rtorrent. I'll post back with what I figure out.

Interesting, admittedly I don't use the docker myself, the glibc dependency must have either changed or been removed so it doesn't work anymore. Good that you got it working!

nvidia-smi is provided by the nvidia docker runtime. On your netdata docker are you using --runtime=nvidia in the additional parameters? If not it won't have nvidia-smi.

That is what I had, and the fix in my case was to swap to the BFQ Scheduler. I also don't know exactly why that change fixed the problem, so it may very well not be applicable in every case 😞 I think rutorrent might not like the layered FS that unraid uses. I've tried saving directly to cache and letting mover handle moving the the array (using /mnt/cache/sharename in the rutorrent configuration) but that hasn't alleviated the other problems (The request to rutorrent has timed out) I have seen. I do no longer get the 504 gateway errors though.

This is fine, but it honestly has me reconsidering unraid as a viable platform for me. A bit too late in the game now as it will require substantial financial resources to migrate to a different platform. I know you, nor CA is affiliated with Limtech or Unraid, but its a pretty integral part of the user experience and its now tainted. And it's taken since last wednesday for me to come to this decision as a result. Hence the long gap between the event and me posting about it. I realized it happened. I had to think long and hard about how I wanted to proceed.

I'm not sure which application in the Community Apps library was responsible for the popup alert about COVID-19 support, but I will be uninstalling all CA packages as a result. It was invasive and I'm not okay with that. I get it was a good gesture, and its got some serious circumstances behind it - but I like it when other people aren't touching my systems. I'm even okay with pinning the apps to the top of the list like they are. Just not the invasive nature of the popup and warning banner. Felt like I was visiting a webpage with my adblocker off.

For users of the r8168 devices that are testing this - can you comment on network performance? I'm interested in seeing if the in-tree drivers for the 816x devices have improved to usable status or not haha.

If your issue was (500, [error,getsettings]) And not (50x, [error,getplugins]) It probably doesn't match the symptom I was depicting. I outlined very specifically when the scheduler change would be applicable.

Android running on Emulated ARM hardware would probably run worse, FWIW. This would be a use case for it then. You could however, set up a PXE boot SD card and store your development/testing images on a PXE server for the PI. This way you aren't constantly writing an SD card and your changes to the image can happen quickly.

Set the LANCACHE_IP to 192.168.11.150 AND DNS_BIND_IP to 192.168.11.150. Has to be the same as the Container IP. With it set to the Unraid IP it is trying to bind 0.0.0.0:80 which is going to try and bind 192.168.11.149:80 which is already in use by the Unraid WebUI. Can't have to services on one port so you get the error and it dies.

Why not run Unraid on that 10gbe nic? Then all of the containers can share that 10gbe bandwidth, lancache included. Significantly reduces the level of complexity, as well. Also the error you are getting right now is due to trying to bind 0.0.0.0:80 which is already in use by Unraid in this case. You should be able to use the container IP (192.168.11.150) instead of 0.0.0.0 but I'm not sure how to do that with this container.

If you have a desktop or laptop that was (or is) running Windows 7 of any variety - you can use the OEM key from that device to obtain the ISO from Microsoft. The key should be on a label on the device. If there is no label, and it has a Windows 7 sticker on it - it used a SLIC for the licensing - there are tools you can use to extract the key from a SLIC install as well. We used to have MSDN whcih had the ISOs available easily, and then we had Microsoft TechBench. Both of these have been discontinued, sadly.

Make sure that EuP is disabled in the bios. I Note that you are using an Asus board - and EUP would be present on their boards.

Microsoft: https://www.microsoft.com/en-us/software-download/windows7 Microsoft is where you get a reliable copy. This is the only 100% legitimate means of obtaining the ISO. Any other discussion would not be fit for the unraid forums.

Also worth noting what threw the exception: cpuidle_enter_state If it continues, try disabling "AMD Cool&Quiet" in the BIOS and see if it stops happening. If it does - try updating the BIOS and see if it persists. It's possible there is a cpufreq issue with the AMD frequency scaling when switching power states; this has happened in the past with new platforms and new power management features with Linux. EDIT: Many users are reporting kernel panics with "cpuidle_enter_state" on Ryzen platforms, Google will reveal. Seems to happen on kernel version 4.7x+ Stems from the way Ryzen generates random numbers. See this ArchLinux forum thread: https://bbs.archlinux.org/viewtopic.php?id=247900 Adding "nordrand" to the kernel parameters is a band-aid workaround; but AMD has supposedly issued fixed firmware to all motherboard manufacturers. I would update the BIOS and see if the issue persists.

Oh, rip

Try: #!/bin/bash DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )" $DIR will then contain the folder the script was ran from.