Tyler

Members
  • Posts

    56
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Location
    Australia

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Tyler's Achievements

Rookie

Rookie (2/14)

8

Reputation

  1. Yep me either — just updated and I’m also not seeing the errors in either Unraid system log or PMS log.
  2. 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.
  3. 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.
  4. 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?
  5. 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'
  6. 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...
  7. 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/
  8. 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
  9. 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:
  10. 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.
  11. 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.
  12. 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
  13. 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
  14. 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
  15. 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!