PeterB

No, all of the other drives are solid - just Parity 2, my newest drive, which is sick.

The parity check completed in 16 hours, 11 minutes with zero sync errors.

Well, here are the diagnostics. It does seem to be simply a very high number of read errors near the beginning of the drive tower-diagnostics-20200927-2234.zip

It's because Parity 2 has clocked up 7942 errors during the parity check! Anyway, the estimated time is down to ten hours now. Clearly, I need to replace the drive, but with what? Are the WD Red Pro still good, or should I be looking at other models?

I think I have a problem - after an unclean shutdown the parity check started. Many errors are being reported on Parity2 drive and the estimated finish for the parity check is currently more than 400 days! Zero sync errors, though! Apart from changing the Parity2 drive (my newest drive) does anyone have any advice? The majority of my drives are WD Reds - what drives are people using now to avoid the issues with shingled drives?

I have CouchPotato/Jacket working fine through DelugeVPN Privoxy

A 7.5GB mkv download just completed on NewGen, and now playing. No apparent issues.

PIA NewGen up and running, with download, using the Sweden endpoint. Remote client connected without problem, from Linux Mint. All looking good, so far. Much kudos to binhex!

You're a Star, Sir!

Wow! I don't know what the version is of the docker image I just downloaded, but it connected to the Czech endpoint in a mere five or ten seconds! (I haven't yet got around to entering multiple endpoints in the configuration).

Information looks good, but only covers Wireguard, so far. OpenVPN script is still in progress - but it does give us hope that our issues will soon be resolved. I'm sure that Binhex will be on to it as soon as the OpenVPN script is posted. As far as connecting my router, which doesn't support OpenVPN or Wireguard, is concerned, I guess that I'm stuck with the oldgen endpoints.

Are you sure that you're using the correct .ovpn file? Is ca-toronto.privacy.network = ca.torronto.privateinternetaccess.com? A wild guess, but are you using the .ovpn for the newgen endpoint?

I'm currently set to use the Czech endpoint. We had a power outage this afternoon and it took two hours for the connection to come up afterwards. I think that all the endpoints still work but (depending on load?) it may take some considerable time for the connection to establish.

I'm currently connected to Czech Republic but I find that (most of?) the servers will eventually connected if you leave the docker to retry. Yes, I've seen lots of error 52 and 56, but it does connect, and once it is up there's no problem.

Not directly related to DelugeVPN, but I've been experimenting with with IPTV streaming, via PIA VPN, and find that I experience a lot of rebuffering on the stream. The rebuffering occurs whether I use PriVoxy from DelugeVPN, or I set up a dedicated VPN connection on my router, solely for use by Kodi. If I stream direct, not via VPN, rebuffering very seldom occurs, so I presume that the problem is due either to PIA, or general VPN overheads. The rebuffering seems to be most prevalent from about 1400 UTC (10pm here in Philippines). I'm thinking of changing VPN provider - Ivacy and Mullvad both claim to have fast connections and support port forwarding. Does anyone have relevant experience of these providers, either in terms of configuration/use with DelugeVPN, or streaming performance? Mullvad have the disadvantage that they don't support PPTP/L2TP connections, so wouldn't allow a connection direct from my router. Does anyone have suggestions for other VPN providers to be considered? I have a 100Mbps fibre connection.

I know what you mean - I only remember one power outage in the last seven years before I left UK.

If you're really worried about power outages, I suggest that you invest in a small UPS and use APCUPSD (built in to unRAID) to perform the safe shutdown. Here in Philippines, we can have several unscheduled power outages in one day. I used an APC BK650 UPS (since upgraded) and have set the configuration to power down five minutes after the power goes off. It works perfectly.

I first encountered this behaviour some months ago and cannot identify which build it started with. The issue cannot be produced at will and seems to occur only after many days running. What is certain is that the issue goes away after restarting the container. With unreliability of electrical supply here in Philippines, it's not often that there is sufficient time of continuous running for the issue to raise its head.

I've seen this happen on my set up - a four core/eight thread E3-1230v2 and a 50Mb fibre connection (since upgraded to 100Mb).

No 1 I've noticed recently, but not a problem for me - my PWMs don't shutdown, but run about 30% when 0 is sent. No 2 doesn't seem to be happening here - my log shows autofan switching between 39C and 40C, while the Unraid main tab is showing that the highest temp is currently 40C.

I was playing with autofan only last week, and thought, like you, that it was erroneously reverting to PWM 1 everytime I tried to configure PWM 2. I discovered that autofan is actually more functional than I first thought, but that isn't clear from the user interface. It seems that autofan discovers all the PWM controllers and allows you to enable/disable/configure each of them independently. It actually keeps separate .cfg files for each PWM controller. However, it still doesn't appear to get everything correct and the integration with System Temperature is a little suspect. I'm currently on 2020.06.21 version - I'm not sure which update you're referring to.

Okay, not as serious as I first thought. I believe that it's not Autofan which is misbehaving, but System Temp reports the same pwm percentage against all fan speeds, even for a fan which is not controlled by that pwm value (pwm2 in this case). I wonder whether System Temp and Autofan need some knowledge of which pwm value controls which fan? It's not clear, to me, how System Temp decides which pwm percentage to display - is there some information shared between the two plugins?

How are you loading the sensor modules? Be aware that, depending on what modules are loaded, the directory path to the sense and control values can change. I find that the 'Detect' options on the Autofan configuration are not very helpful. I make all my settings manually, even if one gets overwritten!. Autofan appears to start okay on boot, for me. My problem is that it sets my cpu fan to the same control value as the case fans!

I believe that autofan only takes account of drive temperatures. I'm not sure what happens when there are no drives reporting temperatures (eg all drives spun down).

I have a, what I believe to be serious, problem with the autofan plugin. I don't understand what the significance/purpose of the 'PWM Controller' field is. I'm offered options of 'nct6776 - pmw1', 'nct6776 - pmw2' & 'nct6776 - pmw3'. However, whichever option I select it always gets forced back to pwm1. My case fans are controlled by '/sys/class/hwmon/hwmon2/pwm2' but with this setting, I find that autofan always sets pwm1 to the same value as pwm2. This might not be so serious if pwm1 wasn't the controller for my CPU fan! Why is this happening and how can I stop pwm1 being adjusted? Is it because of the PWM Controller setting, or is it another issue?