This is definitely going to be very vague... the device I use to watch hulu has been acting really weird when trying to watch with pi-hole running.
Do I run pihole -d when trying to watch a show??
If not, anything I can do?
Edit - hulu works as expected with pi-hole disabled. And I have not blacklisted any .hulu. related items.
Yes, a pihole -d when it's acting strange, along with some details as to what the client is doing that it normally wouldn't do are a great place to start.
OK, well here is the token m8qazqsedb . What has happened is that recently (I would say since core v.2.11.2 or thereabout) the second hulu loading screen hangs so I found myself manually configuring the ip address, subnet, gateway and dns server. Just since around an hour or so ago I would reach the point of when the show should actually start. On my tv It loads hulu, hulu plus, then I am able to choose the show, it goes to the network splash, the show details, then gives me a blank screen and the network logo on the bottom right of the screen. The show doesn't start.
While pihole -d was running this was what was going on. Hope all this makes sense.
Thanks!
Thanks, the first thing I noticed was
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3006ms
rtt min/avg/max/mdev = 20.088/20.835/22.007/0.847 ms
Packet loss from the Pi-hole to the Internet. Can you try a longer ping from the Pi-hole, and also from a client device?
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=21.3 ms
From 192.168.1.2: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.3)
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=21.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=21.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=47 time=19.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=47 time=19.3 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=47 time=20.0 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=47 time=21.7 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=47 time=21.3 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=47 time=21.2 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=47 time=20.6 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=47 time=20.3 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=47 time=20.5 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=47 time=20.2 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=47 time=20.6 ms
^Z
[1]+ Stopped ping 8.8.8.8
from the pi
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=20.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=20.6 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=47 time=20.4 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=47 time=20.4 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=47 time=21.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=47 time=19.1 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=47 time=20.0 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=47 time=20.5 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=47 time=19.7 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=47 time=21.4 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=47 time=19.9 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=47 time=20.4 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=47 time=20.5 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=47 time=21.2 ms
^Z
[1]+ Stopped ping 8.8.8.8
from desktop
You've got a lot of packets being dropped on the way to the test machine. And there looks to be a route change in the middle of things.
Can you run traceroute 8.8.8.8 and we'll see if we can find the cause of the loss of packets and the reason for the midstream redirect.
This is the first day THIS kind of thing has happened.
Even gave the router a reboot.