JonathanM

Yep, like @Frank1940 explained, you are still only capturing 1 of the 3 wires, either one of the white and black or brown and blue depending on country of origin, just not the green. Open the clamp, and wrap as many turns of that one wire as you can comfortably fit around the clamp, up to 10. Close the clamp fully or unwrap wire until you can, and start logging reported amps. Take the meters face value AMP number, and divide it by the number of wires that actually pass through the clamp. Voltage should be extremely stable, just take a reading at the plug you are using before and after you are done playing to be sure. Oh, if you want to take a current reading on all three wires one at a time, it could be educational if your house wiring is wrong. The two main conductors should yield identical results, and the green conductor should measure exactly zero at all times. If not, something is wired VERY wrong, and I'd have an electrician inspect it ASAP.

Pretty sure you are doing it wrong. I'd be more willing to bet you are currently seeing .82A for startup, .33 running. However... I don't trust your meter. Since you've already killed and skinned a power cord, separate out enough insulated wire in it to get several turns around the clamp, and try again. Each conductor that passes through the meter loop multiplies your value, so if you manage to get 5 turns you would divide the face value of the meter by 5. That should get the meter into the meat of its measuring range, where it is more accurate. 10 turns would be nice, but may not be doable. You need to also measure the voltage accurately, not just guess. Volts * Amps is the number we want, not watts. Now, the second part of your question. UPS's aren't commonly quoted in watts, as the VA number is bigger, and it's actually more accurate for what's being measured. The stated rating of the UPS is the maximum peak power it can supply, but has little if any correlation to runtime. Runtime is a measure of usable battery capacity and efficiency, and is rarely stated clearly because the variables are too hairy. Battery chemistry in most UPS's is pretty basic (actually very acidic) and hasn't changed in over a hundred years. Because lead is the heaviest ingredient in the battery and is responsible for overall capacity, you can bet that if you have 2 UPS's rated for the same rough peak capacity and one is twice as heavy, it will run your system for significantly longer. Bigger, heavier batteries = longer runtime. Conversely, if 2 UPS's are the same rough size and weight, the higher peak capacity will probably have shorter runtime under equivalent load because of inefficiencies in power conversion.

A good static discharge will go right through that coating, or jump to the nearest surface mount component leg. Best policy is "no touching".

Look, but DON'T TOUCH. I'm assuming everyone in the household knows better than to touch daddy's toys.

Sorry, I just figured it was a generic VPN thing. Occasionally (twice a week or so) deluge will say everything is ok, but there is no traffic. Stop the container, start it back, and everything starts downloading. I assumed my VPN IP or port had changed but deluge hadn't gotten the message.

I've seen this behaviour as well in the delugeVPN container, perhaps you could schedule a cron to reverify every hour or so? I'm not sure that the current method is catching changes consistently.

Are you using unraid's VNC server, or do you have a VNC server installed in the VM? You will see much better performance with the server running directly in the VM.

His head? I suppose in the right lighting, it is a golden globe.

Only if you do a new config. If you simply add them, unraid will clear them before allowing them to be formatted. Are you sure they are all perfectly healthy? Good smart reports, etc? You really do not want drives in your server with health issues, and failing to preclear and / or running slowly doesn't give me any warm'n'fuzzies about the health of the drives. How is it connected? If the total bandwidth to the enclosure isn't good, you will be slowing down parity checks or rebuilds to the point of being unusable.

Depends. Some USB adapters pass SMART info generically, some don't. Apparently that specific one doesn't. Try using the drive manufacturer's specific utility.

As long as you don't close the status bar, it will be there on the other computer. Just close the entire tab, it will stay running exactly as it is. There is no way I know of to determine the status of a transfer after you close the status in the krusader window.

Nope, forward your dvr to another port, 444 or something. Your router should allow you to redirect IP.FOR.DVR:443 to external:444 or something like that, and IP.FOR.UNRAID:443 to external:443 You would then go to https://your.domain.name for nginx, and https://your.domain.name:444 for your DVR. I wouldn't forward port 80 at all, unless your DVR requires it for some function. Much better to use SSL for everything if possible. Subdomain redirection may be possible, as well as possibly reverse proxy to your DVR through nginx, but that gets a little more hairy. Simply pointing your browser to different ports will work easily.

Not if you use https://your.domain.name. It will go straight to the nginx ssl site.

Why do you need 80 externally for this docker? I'm not being a smart alec, I'm genuinely asking. I don't forward anything other than 443.

Issue resolved here. Requests populating properly, thanks!

Set version you want, update container?

I'm currently running both, just to see how they behave, and Radarr has been much better to work with.

My crystal ball says "Future unclear but optimistic". Nobody knows until it actually happens.

Me too. Requests page is blank in the area where the requests would show. If you navigate to a requests category with no pending requests, it says "Sorry, we didn't find any results!", so that area of the page is updating.

Pretty sure it's not verifying the port is open, it's just verifying that your DNS is properly in place. Does pinging your FQDN that you are trying to get SSL certified resolve to your current public IP? It doesn't need to answer, just properly resolve. If not, then, no, the container won't start.

For the series you are troubleshooting, what is the path listed inside Sonarr? It's shown below the title block of the series or in the popup that comes up when you click on the wrench to edit the series.

Post your docker mappings and the corresponding paths internal to sonarr.

Like @Frank1940 said, you aren't stupid. Microsoft has been stubbornly doing it wrong for a LONG time. It's not exactly a settled issue. Now you know that time is relative, lunchtime doubly so.

That's the same location, just two different views. Try running mover and see if the one showing on the cache is gone.

If your dockers are configured correctly Sonarr should automatically remove the completed download from sab and put it in the season folder.