Hey, I am sorry for delay, just catching up.

 >>/959/
 >>/962/
Ah, there has been a misunderstanding. I never knew you could paste a booru gallery URL into the thread watcher and have it do something.

The thread watcher is meant for things like endchan or 4chan. It repeatedly checks the same thread url for new image posts. It seems my downloader code is accepting single gallery pages into the watcher, but then is not sure what to do with them after that page is hit.

Please use the 'gallery' downloader for gallery-like boorus. That lets you input text like 'skirt' or 'samus_aran' and it will do a multi-page search with a nice 'query' saved based on what you typed in.

If you would like to 'watch' a gallery download, please check out the 'subscriptions' system, which does exactly what you want:

https://hydrusnetwork.github.io/hydrus/help/getting_started_subscriptions.html

 >>/965/
Thanks. A user was telling me a week or two ago that NTFS compression, which you can do straight from windows explorer, is good as well--about 40-50% savings on the client*.db files. This is pretty interesting, and I would like to gather more data on performance impact. Seems like if you have a killer SSD and CPU it is doable though.

I don't know enough about compression tech to know why that can update quickly, but I guess there is a constantly maintained compression 'dictionary' for that file in the NTFS filesystem so you can update a single block in the file without having to de a bunch of recompute based on other blocks in the file.

My biggest tables in the database are basically two copies of the same data, but 'forwards' and 'backwards', which I think explains why compression is working so well. I have to have the data splayed out like that for SQLite to work fast, but if it seems modern CPUs can de/compress that on the fly, it would be pretty neat.