Tyler

Yep me either — just updated and I’m also not seeing the errors in either Unraid system log or PMS log.

That's more than 4 of us seeing the issue with same symptoms, got to be something on the Plex PMS side of things. Have created a thread over in their forum: https://forums.plex.tv/t/pms-beta-1-16-2-1297-errors-when-scanning-music-library-related-to-gracenote-gcsp/433087 Feel free to chime in. Unfortunately I doubt that'll help, I have that as my usual setting and still see the errors.

I think I’ve narrowed it down further, seems to be related to Music library scanning. If I scan music individually I get the errors, with other types of media libraries I don’t. Then went looking in the Plex Server logs, and can see; “Gracenote: Exception at line 1036, error 276889603 (Item not found.)” at the exact same time as the Unraid ones And doing a search for “gcsp gracenote” returns a few hits relating to development with the Gracenote API/SDK.

I’ve noticed this issue too, and after some troubleshooting it seems to be related to Plex library scanning. Is everyone running the beta server version 1.16.2.1297 ? The date seems to line up with when I noticed the issue. If I trigger a full scan through the web interface; left menu next to the “Libraries” heading, click the ellipsis/“...”, then “Scan library files”. Wait until it completes, then I see these errors in the Unraid system log. I have Plex set to do a periodic scan daily, and also I see these errors once a day with no manual interaction. (I also have partial scanning when changes are detected, and this does not trigger the issue.) Can anyone verify that they’re see the same behaviour, and that the number of repeating logs a day matches their scanning frequency?

Here's my config (with a few things redacted, and IPv6 stuff removed / disabled to make it a bit simpler). I've had it running for quite a while now, so it's far from a fresh install. If you haven't already, I'd recommend reading the config guide on Docker Hub: https://hub.docker.com/r/pihole/pihole Particularly the Important Upgrade Notes and Environment Variables sections, as they explain in more detail the various "DNS" entries. Repository: pihole/pihole:latest Docker Hub URL: https://hub.docker.com/r/pihole/pihole Icon URL: https://i.imgur.com/OWkNcEn.png WebUI: http://[IP]:[PORT:80]/admin Extra Parameters: --cap-add=NET_ADMIN --dns 127.0.0.1 --dns 1.1.1.1 Network Type: 'Custom: br0' Fixed IP address (optional): 10.1.1.100 Privileged: Off Variables ('Key'='Value') 'ServerIP'='10.1.1.100' 'WEBPASSWORD'='my password' 'DNS1'='1.1.1.1' 'DNS2'='1.0.0.1' 'IPv6'='False' 'INTERFACE'='eth0' 'DNSMASQ_LISTENING'='all' Ports (host port : connection type) 53 : TCP 53 : UDP 80 : TCP Paths ('container path' : 'host path' : 'access mode') '/etc/pihole/' : '/mnt/cache/appdata/pihole/pihole/' : 'Read/Write' '/etc/dnsmasq.d/': '/mnt/cache/appdata/pihole/dnsmasq.d/' : 'Read/Write'

If they follow their stated schedule it’ll take a week. Full details here, with the relevant part of the post in this case being...

Might be worth trying to change the “LAN Networks” setting in Plex under Network (enable advanced settings). They’re entered in the format: 127.0.0.1,192.168.1.0/255.255.255.0 More details here: https://support.plex.tv/articles/200430283-network/

I noticed something that could be the cause of your issue, in the Docker run command you posted in your GitHub issue that you've set the variable: 'INTERFACE'='br0' I believe this variable needs to refer to the name of the container's internal interface which is 'eth0', rather than the name of UnRaid network interface the container is running on which in your case is 'br0' @bonienl posted instructions a few pages back on how to re-configure this If you haven't tried this already it might be worth giving this a shot

Try mapping the /config path to a cache or disk share, rather than the user share. Will depend on where your “appdata” is stored, e.g. /mnt/cache/appdata/plex or /mnt/disk1/appdata/plex See this post for some details why:

I had the same issue with nothing in the Query Log or data in the graphs. diginc posted a fix in an issue raised for this on GitHub, and it worked for me. Although the only step I had to do was edit the config file /dnsmasq.d/01-pihole.conf and change the line from "log-queries" to "log-queries=extra", then restart the container.

Have a look at this help article: https://support.plex.tv/hc/en-us/articles/201370363-Move-an-Install-to-Another-System I’ve used this method successfully to move my library around in the past. The first step to disable the emptying of trash is important, but sounds like this may already be too late unless you’ve got a backup of the appdata from your Win10 system.

Thanks @CHBMB and @sparklyballs! Now working for me with the fping IPV4 only build. You've gone above and beyond to get this working with v6.3

Thanks for the replies guys. Yes and with multiple browsers (Firefox, Safari, Chrome), still nothing on the graphs. Me too, only using IPV4. Running unRAID 6.3.5

Thanks. I should have checked the scripts to make sure I was running the correct command. When running this with the --debug option I still see the same error with fping. FPing: Got fping output: '(null): can't create raw socket (must run as root?) : Address family not supported by protocol' Also tried running the same fping command directly and also same result. Can someone who has everything working try running fping to see if they get this same error? root@c381ec688e22:/$ s6-setuidgid abc /usr/bin/smokeping --config="/etc/smokeping/config" --nodaemon --debug ### assuming you are using an fping copy reporting in milliseconds ### Compiling alert detector pattern 'someloss' ### >0%,*12*,>0%,*12*,>0% my $d = shift; sub { my $y = $d->{loss}; for(1){ my $imax2 = min(@$y - 3, 12); my $imax1 = min(@$y - 3, 12); my $minlength = 3; my $maxlength = 27; next if scalar @$y < $minlength ; my $i1; for($i1=0; $i1 < min($maxlength,$imax1); $i1++){ my $i2; for($i2=0; $i2 < min($maxlength-$i1,$imax2); $i2++){ next unless defined $y->[-3-$i1-$i2] and $y->[-3-$i1-$i2] =~ /^\d/ and $y->[-3-$i1-$i2] > 0 ; last; } return 0 if $i2 >= min($maxlength-$i1-$i2,$imax2); next unless defined $y->[-2-$i1] and $y->[-2-$i1] =~ /^\d/ and $y->[-2-$i1] > 0 ; last; } return 0 if $i1 >= min($maxlength-$i1,$imax1); next unless defined $y->[-1] and $y->[-1] =~ /^\d/ and $y->[-1] > 0 ; return 1; } return 0; } Smokeping version 2.006011 successfully launched. Not entering multiprocess mode with '--debug'. Use '--debug-daemon' for that. FPing: probing 20 targets with step 300 s and offset 294 s. FPing: Executing /usr/sbin/fping -C 20 -q -B1 -r1 -i10 cam.ac.uk facebook.com web.mit.edu linuxserver.io 208.67.220.220 al.ktz.me www.ucsd.edu 208.67.222.222 www.berkley.edu 8.8.4.4 google.com www.telefonica.de jupiterbroadcasting.com youtube.com www.indiana.edu www.uea.ac.uk 8.8.8.8 cixp.web.cern.ch FPing: Got fping output: '(null): can't create raw socket (must run as root?) : Address family not supported by protocol' Calling RRDs::update(/data/DNS/OpenDNS2.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/DNS/GoogleDNS2.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/DNS/OpenDNS1.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/DNS/GoogleDNS1.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/UK/UEA.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/UK/CambridgeUni.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/UK/IBNorwich.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/Germany/TelefonicaDE.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/Switzerland/CernIXP.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/Europe/Switzerland/SBB.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/JupiterBroadcasting.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/GoogleSearch.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/Facebook.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/Youtube.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/InternetSites/linuxserverio.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/MIT.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/UCSD.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/IU.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/Sun.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/UCB.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500804998:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) root@c381ec688e22:/$ s6-setuidgid abc /usr/sbin/fping -C 20 -q -B1 -r1 -i10 cam.ac.uk facebook.com web.mit.edu linuxserver.io 208.67.220.220 al.ktz.me www.ucsd.edu 208.67.222.222 www.berkley.edu 8.8.4.4 google.com www.telefonica.de jupiterbroadcasting.com youtube.com www.indiana.edu www.uea.ac.uk 8.8.8.8 cixp.web.cern.ch (null): can't create raw socket (must run as root?) : Address family not supported by protocol

Hi all, I'm trying to use this docker app too, but can't seem to get it working. I use a bunch of other Linuxserver.io containers without any issues (thanks guys!). Here's my docker run command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="smokeping" --net="bridge" -e TZ="Australia/Sydney" -e HOST_OS="unRAID" -e "PUID"="99" -e "PGID"="100" -p 8050:80/tcp -v "/mnt/cache/appdata/smokeping/data":"/data":rw -v "/mnt/cache/appdata/smokeping/config":"/config":rw linuxserver/smokeping In my unRAID network config I have bonding and bridging both disabled, I tried enabling bridging without any difference. I've tried to do some troubleshooting and I think @ziggie216 was onto something with this. How I arrived at this was checking the in-built Smokeping troubleshooting from within the Smokeping docker's shell. There does seems to be an inconsequential issue with the basic Smokeping troubleshooting saying the config file can't be found. But the config is definitely being picked-up because I can see all the (empty) graphs for each of the targets configured by the docker container. root@212bb2c07243:/$ smokeping --check ERROR: can't open /usr/bin/../etc/smokeping/config: No such file or directory root@212bb2c07243:/$ smokeping --debug ERROR: loading smokeping configuration file /usr/bin/../etc/smokeping/config: No such file or directory Running the Smokeping debug command against the actual config file gives this result: root@212bb2c07243:/$ smokeping --config /etc/smokeping/config --debug ### assuming you are using an fping copy reporting in milliseconds ### Compiling alert detector pattern 'someloss' ### >0%,*12*,>0%,*12*,>0% sub { my $d = shift; my $y = $d->{loss}; for(1){ my $imax2 = min(@$y - 3, 12); my $imax1 = min(@$y - 3, 12); my $minlength = 3; my $maxlength = 27; next if scalar @$y < $minlength ; my $i1; for($i1=0; $i1 < min($maxlength,$imax1); $i1++){ my $i2; for($i2=0; $i2 < min($maxlength-$i1,$imax2); $i2++){ next unless defined $y->[-3-$i1-$i2] and $y->[-3-$i1-$i2] =~ /^\d/ and $y->[-3-$i1-$i2] > 0 ; last; } return 0 if $i2 >= min($maxlength-$i1-$i2,$imax2); next unless defined $y->[-2-$i1] and $y->[-2-$i1] =~ /^\d/ and $y->[-2-$i1] > 0 ; last; } return 0 if $i1 >= min($maxlength-$i1,$imax1); next unless defined $y->[-1] and $y->[-1] =~ /^\d/ and $y->[-1] > 0 ; return 1; } return 0; } Smokeping version 2.006011 successfully launched. Not entering multiprocess mode with '--debug'. Use '--debug-daemon' for that. FPing: probing 20 targets with step 300 s and offset 212 s. FPing: Executing /usr/sbin/fping -C 20 -q -B1 -r1 -i10 www.uea.ac.uk www.ucsd.edu 208.67.220.220 8.8.4.4 google.com web.mit.edu youtube.com 8.8.8.8 www.telefonica.de www.indiana.edu www.berkley.edu 208.67.222.222 jupiterbroadcasting.com al.ktz.me cam.ac.uk facebook.com linuxserver.io cixp.web.cern.ch FPing: Got fping output: '(null): can't create raw socket (must run as root?) : Address family not supported by protocol' Calling RRDs::update(/data/USA/IU.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500781590:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/UCSD.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500781590:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) Calling RRDs::update(/data/USA/UCB.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1500781590:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) ... continues for each target (site/IP) ... If I try to run "fping" from within the docker's shell I get: root@212bb2c07243:/$ /usr/sbin/fping 8.8.8.8 (null): can't create raw socket (must run as root?) : Address family not supported by protocol So from what I can see "fping" doesn't run due to come sort of permission error, and possibly why no data is getting into the Smokeping RRD files / graphs. Searching for a solution only really turns up results relating to user/file permissions of "fping". So I tried messing with various file permissions and ownership with no result. Does anyone have any ideas or suggestions? Thanks!

No problem, glad it helped. Just a suggestion for the Home Assistant config, you probably want to enable the configuration option for "use_x_forwarded_for" so the client's IP address is passed to Home Assistant rather than the IP of the Nginx docker. This also allows you to use the IP Ban options. More details on the Home Assistant HTTP config page: https://home-assistant.io/components/http/ Here's a sample config for Home Assistant: http: api_password: MyPassWord base_url: SUB.MYDOMAIN.com:8123 use_x_forwarded_for: True ip_ban_enabled: True login_attempts_threshold: 5 And on the Nginx config side you've already got the relevant Proxy setting enabled: server { ... location / { ... proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ... } } That being said, if you're security conscious you're likely far better off managing things at the Nginx layer. And it's great that this docker already has Fail2ban built in.

Hi ritalin I have this Letsencrypt / Nginx docker, and the Home Assistant docker setup working. Just wanted to check if you've had a read of the Home Assistant team's guide for setting up Nginx: https://home-assistant.io/ecosystem/nginx/ Specifically their sample config in step 8 (looks like you've already done the rest). This is what I based my config on, and having a quick look over your config it seems to be missing a few settings/parameters. I'm by no means an expert with Nginx or docker, but if you're still having issues I can post a copy of my configs.

The updated Plex container is working well for me. Grabbing the current Plex Pass version (0.9.16.4) using "VERSION=latest". Thanks lonix and to all the Linuxserver.io team for your great work!

Thanks for taking a look. Just to see if everything would work today I just tried running another installplg on the plugin, latest version the same one that was already in the folder. All went ok (just the mkdir error in installplg on line 29). Plex was still installed and running, and it's replaced v1.0 of the control zip with v1.1 as expected. I also tried a stop/start using the web interface and terminal (/etc/rc.d/rc.Plexmediaserver stop & start), and all is ok. Weird, but good. Thanks for your help.

Hi PhAzE, I downloaded the plugin from the links in the first post immediately before installing, at the time it looked like you'd updated them ~6 hours earlier. Here're the details, something doesn't seem quite right. Looking through the plugin it appears like this shouldn't have worked, I'm guessing my manual copy should of the Control file zip should not have worked, as the file name and hash didn't match. Here's a snip from: /boot/config/plugins/Plexmediaserver.plg <!ENTITY plgVersion "2015.02.21.1"> <!ENTITY pluginURL "https://github.com/PhAzE-Variance/unRAID/raw/master/Plugins/Plexmediaserver.plg"> <!ENTITY controlFILE "&name;-PhAzE-Control-1.1.tar.gz"> <!ENTITY controlMD5 "e9e9ed809fa98d7380e99c61fd13c1eb"> <!ENTITY controlURL "https://github.com/PhAzE-Variance/unRAID/raw/master/AppSupport/&name;/&controlFILE;"> Contents of /boot/config/plugins/Plexmediaserver/ root@Tower:~# ls /boot/config/plugins/Plexmediaserver Plexmediaserver-PhAzE-0.9.11.12.869-ab1cd47-x86.txz* Plexmediaserver-PhAzE-0.9.11.12.869-ab1cd47-x86.txz.md5* Plexmediaserver-PhAzE-Control-1.0.tar.gz* Plexmediaserver.cfg*

Hi PhAzE, Thanks for all the work you do on these plugins. Just want to give you some info about an issue I had upgrading my Plex install to v2 from v1 of your plugin on unRaid 5.0.6 today. I added v2 of a few of your plugins and after the reboot the Plex plugin hadn't installed itself. I manually ran installplg and got an error from the installplg script: "Warning: mkdir(): No such file or directory in /usr/local/sbin/installplg on line 29 unable to create directory". The plugin actually installed ok though. (I also got this same error with Sonarr, had to manual install of it too.) In the settings screen Plex was showing as not installed. The plugin config settings (paths, etc.) had carried across ok. I hit the install button and in the GUI I got the following status messages, sorry didn't take note of the exact wording: "/etc/rc.d/rc.Plexmediaserver install Unable to download ... Aborting install" And Plex didn't install. I had a look through the thread and noticed you mentioned installing the following file from GitHub manually as a fix for a similar sounding issue a few days back - Plexmediaserver-PhAzE-Control-1.0.tar.gz I noticed I had a different version of the file in /boot/config/plugins/Plexmediaserver, and that was updated on GitHub today - Plexmediaserver-PhAzE-Control-1.1.tar.gz I deleted v1.1 of the file and copied v1.0 from GitHub there, hit the install button on the Settings page, then Plex installed and is now working fine. Just wanted to let you know incase there was a change to Plexmediaserver-PhAzE-Control-1.1.tar.gz that can cause issues with new installs.

A vote here for moving to NFS v4. Please don't remove AFP support though, I'm another Time Machine user. I'm assuming it would only be dropped in v6 (remain in v5) so the recommendation would be to run a VM with AFP support, but personally I'd still prefer it native in unRAID until Apple moves to something newer.

No problem, I was just about to upload that info and saw your edited post. The data looks the same value wise (lots of zeros), just in a CSV format instead. Thanks for looking into it further. Tyler

No problem. Thanks! See attached. Seems there's no data for either the total number of kilobytes received/transmitted. Don't know enough about the sar command to know what to make of that. I'd bet if I reboot it'll start working again for a while at least, but I'll wait for the time being incase you need any other data/info. Thanks for looking into it. Should have also mentioned the issue is even more noticeable on Safari for iOS, and I'd guess that there're probably more users accessing via the iOS version. Safari's on Mac is my main browser, as IMO at the moment the others just feel like slow battery hogs on Mavericks in comparison. Thanks again. Cheers, Tyler Net_Stats_Output.zip

Hi Bonienl, I've been using Dynamix for a few days now, awesome work on getting a full featured GUI, plugin manager, and some esential plugins going. I'd been using the new WebGui since Simple Features broke with v5, and it's great to have lots of the stuff I got used to back. A trivial thing to mention; especially getting rid of the blinking lights, sometimes it's the little things. Coincidentally I'm having the same issues as both tr0910 (individual disk stats missing due to gaps in disk assignment) and clowrym (network stats flat-line). I've attached the info you asked for. On the network stats issue; I checked the System Log and there's nothing for hours either side of the point where to "zeroed", other than a few disk spin-downs. I use an Intel I350T2 NIC with dual ports, and one thing about my setup that's probably slightly out of the ordinary is that I have bonding enabled in balance-rd (0) mode. Another general thing I've noticed is on various settings pages (e.g. the Network Setting page) in Safari (v7.0.1) when input is disabled for a text box (aka "greyed out") the text is unreadable, as it's white text on light-grey background. On Firefox it looks ok (dark-grey text on light-grey background), but could still have a bit more contrast IMO. Again thanks for doing this for the community. Cheers, Tyler disk_vars.txt