Had the same problem. It has something to do with the line count of the blocklist file. If I remember correctly updating fails around line 65530. So it seems to be some memory allocation problem. Using a "smaller" blocklist with less lines update works without problems.
65.535 is the limit of short - maybe that's the issue. But in that case it seems to be an issue inside AdGuard Home itself.
2 Likes
It's funny that more and more people are complaining, but GL.inet isn't responding on this.
@admon why should it be an issue inside of AdGuard itself based on this short vs long blocklist file? The only lead we have right now, is that in particular the GL-A1300 does not update heavy/large blocklists.
This router is sold with the AdGuard functionality but it's useless...
It's just a wild guess.
What is a wild guess?
It's just a guess that the problem is inside AdGuard. Maybe some architecture thingy, I don't know.
Guess it won't be solved in the next months - because nobody knows why it's happening.
Yeah because GL.inet is hiding so far. It's good to know there is a threshold limition based on short/long;
short list; 0-65530
long list; 65530-xxxxxx
AdGuard doesn't have settings to adjust these thresholds right? So maybe we can test with more short blocklists, but I was not able to find more than the one currently (sometimes) updating correctly; AdAway Default Blocklist.
That blocklist has just 6542 hits, but even this one is a pain in the ass for the GL-A1300 most of the time.
No, it's not about lists.
short is a data type in some programming languages.
Hi all,
I have tried it at my side, some of the smaller filter (tested 'no google') can be updated and loaded, but some bigger filter such as 'Adguard dns filter' can not be update. Then check the hardware status, I think probably the memory is too less to not enough to load it. Even if do separate update the Adg.
Depend on the hardware performance of the A1300, and learned from the R&D team, only recommend loading the smaller filter in the Adg, or will cause not enough memory to ensure the running of other system basic software.
And the other hand is, as the Adg (including filter and software) updates, it has grown to bigger than bigger to occupy the more memory.
1 Like
If I wget https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt directly to /etc/AdGuardHome/data/filters/1.txt, which takes just a second, everything works fine.
Also, symlinking /etc/AdGuardHome/data/filters to /tmp resolves the problem.
The real error message is this:
Tue Jul 2 21:44:26 2024 user.notice AdGuardHome[29196]: 2024/07/02 20:44:26.985138 29196#386 [error] POST 192.168.9.1:3000 /control/filtering/set_url: scanning filter contents: context deadline exceeded (Client.Timeout or context cancellation while reading body)
Which means the download timeout is reached:
So, this is definitely not a memory problem, but for some reason the download to /etc is very slow.
Perhaps the I/O rate of AdGuard is limited, for example with ionice?
1 Like
If the Adg reply error 500 or shows timeout (in the right bottom), can try to manual download the filter and move to /etc/AdGuardHome/data/filters, and reload it in the Adg manage page.
Please ensure the filter not too big. And I previously mentioned the 'memory' is RAM.
This device is sold as AdGuard capable, so you can't just point to the memory of the device!
In fact, I bought specifically this device for specifically this purpose.
So, this would be rather disappointing, not to say misleading.
Moreover, if memory was the problem, it wouldn't work either when the file was downloaded directly or when the directory is symlinked to /tmp (RAM disk).
The download is therefore the problem, not the memory.
There is definitely something wrong with the AdGuard integration, and an engineer should look into this.
1 Like
After reboot the directory will be empty then, please keep that in mind.
The problem occurs with plain AdGuard Home as well, seems more like a general AdGuard Home problem than an GL one.
Temporary solution to demonstrate it is not the memory:
cd /etc/AdGuardHome/data
rm -R filters
mkdir /tmp/filters
ln -s /tmp/filters filters
See the remark of @admon above !
Alternative temporary solution:
wget https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt -O /etc/AdGuardHome/data/filters/1.txt
The problem occurs with plain AdGuard Home as well, seems more like a general AdGuard Home problem than an GL one.
Perhaps, but why does it work when using /tmp ?
My Brume 2 has no issues with larger blocklists.
okay, I did not mean can't run Adg, please understand that some filters are getting bigger and bigger, resulting in a very large amount of memory consumption during downloading, loading, and the filter is working in parsing.
If select the lite version of filter, still runs perfectly.
yep, as Brume 2 is device positioning as the gateway which can process complex data base on some third-party applications.
okay, I did not mean can't run Adg, please understand that some filters are getting bigger and bigger, resulting in a very large amount of memory consumption during downloading, loading, and the filter is working in parsing.
That's not good enough. If this is the case, you shouldn't sell this device as AdGuard capable because it simply isn't as it is now.
If select the lite version of filter, still runs perfectly.
If I download the normal filter list manually, it runs perfectly too.
Where is the lite list?
1 Like
For the record:
There are no limitations being mentioned, and therefore I expect this to work, else the product is non-conforming.
1 Like
These discussions occur again and again. The problem here is that although it is stated that the product is compatible with this software ("Ready"), it is not stated that this is the case in all configuration cases.
It's like with computers: they may be "Windows-ready", but that doesn't mean that Windows-CoPilot, for example, will also work.