I just hope it works on YouTube on TVs. On my PC I can just use uBlock and that's been absolutely stellar. (I've disabled uBlock on YouTube just to let diversion do its thing).
No need to disable uBlock Origin on your YouTube browser - the adds hit your router before they hit your browser - so Diversion does its work anyway and gradually builds up "immunity" to the adds as it learns to cope with them.
In the meantime - at browser level YouTube shows zero adds .
I have the YouTube adblocking enabled. Should I keep seeing the same video ads over and over again though? I thought diversion was supposed to learn and adapt?
If you can find anyone outside of Googles/YouTubes HQ who knows their algorythms and logic how they determine what ads and what server serves them, let me know. I and others would like to talk shop.
With the crude method in use with the current experimental YouTube video ads blocking feature this is the best it can do. I have an improved version locally which will be included in the next Diversion release. It's not much better, but Anything helps that lowers the increasing number pf ads shown. For the price of exactly nothing for you users.
I just hope it works on YouTube on TVs. On my PC I can just use uBlock and that's been absolutely stellar. (I've disabled uBlock on YouTube just to let diversion do its thing).
No need to disable uBlock Origin on your YouTube browser - the adds hit your router before they hit your browser - so Diversion does its work anyway and gradually builds up "immunity" to the adds as it learns to cope with them.
In the meantime - at browser level YouTube shows zero adds .
I just hope it works on YouTube on TVs. On my PC I can just use uBlock and that's been absolutely stellar. (I've disabled uBlock on YouTube just to let diversion do its thing).
On the topic of Diversion blocking of YouTube ads on TVs, by the way, don't even bother if you are a subscriber to the (paid) service of YouTubeTV, it won't work. I tried this one day when the Diversion option for doing this first appeared, and was pleased to see the reduction in normal YouTube ads for several hours, then tried to use the YouTubeTV service (which is basically a replacement for cable TV, for those who haven't looked into it), but it absolutely would not work with this experimental YouTube Diversion ad blocking "on". Just a heads-up, in case anyone was thinking of trying it.
There are already several choices of "size" of built-in lists, which are more than adequate, no need to look elsewhere (IMHO).
Personally, I settled on the "standard" one, as it is a nice balance of blocking vs. needing to manually whitelist sites.
If you can find anyone outside of Googles/YouTubes HQ who knows their algorythms and logic how they determine what ads and what server serves them, let me know. I and others would like to talk shop.
With the crude method in use with the current experimental YouTube video ads blocking feature this is the best it can do. I have an improved version locally which will be included in the next Diversion release. It's not much better, but Anything helps that lowers the increasing number pf ads shown. For the price of exactly nothing for you users.
that will be uidivstats trying to resolve the names of local IPs to display in the logs. it tries to determine hostnames through other methods before falling back to PTR query
My pixelsrv-tls stopped working and I got strange performance issue when starting diversion. I already checked my pendrive filesystem with e2fsck and it's ok. What should I check?
that will be uidivstats trying to resolve the names of local IPs to display in the logs. it tries to determine hostnames through other methods before falling back to PTR query
My pixelsrv-tls stopped working and I got strange performance issue when starting diversion. I already checked my pendrive filesystem with e2fsck and it's ok. What should I check?
I reformatted my SD through amtm and reinstalled everything. I have diversion with pixelsrv-tls, uidivstats, flexqos.
Now pixelserv-tls works but I randomly loose pings on router:
Risposta da 192.168.1.1: byte=32 durata=7ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Richiesta scaduta.
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Richiesta scaduta.
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=101ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Update: I uninstalled uidivstats and the situation is quite better: I keep loosing pings but less frequently
I reformatted my SD through amtm and reinstalled everything. I have diversion with pixelsrv-tls, uidivstats, flexqos.
Now pixelserv-tls works but I randomly loose pings on router:
Risposta da 192.168.1.1: byte=32 durata=7ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Richiesta scaduta.
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Richiesta scaduta.
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=101ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata=1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.1: byte=32 durata<1ms TTL=64
Update: I uninstalled uidivstats and the situation is quite better: I keep loosing pings but less frequently
The pings you send go directly to your router. Maybe that timeout (Richiesta scaduta) is caused by your WLAN setup if that's how that device is connected to it.