windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v195/Hydrus.Network.195.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v195/Hydrus.Network.195.-.Windows.-.Installer.exe
os x
app: https://github.com/hydrusnetwork/hydrus/releases/download/v195/Hydrus.Network.195.-.OS.X.-.App.dmg
tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v195/Hydrus.Network.195.-.OS.X.-.Extract.only.tar.gz
linux
tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v195/Hydrus.Network.195.-.Linux.-.Executable.tar.gz
source
tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v195.tar.gz
I had a good week. I worked on several different things and did a bit more IPFS stuff. An important bug fix means all clients will have to do a bit of reprocessing.
ipfs stuff
I've written up some basic IPFS help here:
https://hydrusnetwork.github.io/hydrus/help/getting_started_ipfs.html
So if you have been holding back, check that out and have a play with it.
I've also added IPFS services to 'system:file service', so you can now find all your pinned files again, and I've added an option to the manage services dialog to make copying multihashes more flexible.
repository processing bug
I discovered an important bug in repository processing that meant some content was not being processed in certain situations. I have fixed the bug, and I've retroactively semi-reset repository processing. Your repositories will go over all their updates again and reprocess, picking up anything that was missed.
Even though the clients are going back to the start, it won't take too long to catch back, as reprocessing content that is already in the db works about 10-20 times faster than regular processing (my laptop is working at 8,000 rows/s, my dev machine at 20,000 rows/s). Just let your clients keep syncing like normal, and you should be caught up again within the week.
8chan thread watcher
I fixed a bug that was sometimes missing OP images in the 8chan thread watcher, but I've since discovered a new problem–lots of boards have started to host their images and thumbnails off media.8ch.net rather than 8ch.net (including now /hydrus/). I presume this is related to the various dev work and migrations and so on of the recent months being sorted out, but unfortunately the JSON API doesn't specify which domain I should be using, or at least I can't find where it so says.
I don't follow 8chan news very closely, so have I missed some tweet about a migration to media.8ch.net for content hosting? Is there a master board list somewhere of which boards are using which domain that I can just hardcode for now? Is there a 'board API' that'll give a bit of JSON describing the board? Something like this:
https://8ch.net/settings.php?board=k
If there is an easy answer to this that I have missed, let me know, otherwise I'll go officially ask someone. I guess /operate/ would be the right place?
If there isn't an easy answer, then I'll probably write an extra step into the watcher that fetches the html version of the page and inspects the links manually to figure out the domain, and cache that info for the rest of the session.
Anyway, for now I am keeping the thread watcher pointed at 8ch.net. /pol/ and /v/ and a handful of others work, but /s/ and and /k/ don't, for instance.
all known files and tags
In preparation for the new cache layer, I have disabled searches over 'all known files' cross-referenced with 'all known tags'. This search domain is so massive, computationally heavy, and so very rarely used, that it is ultimately best to just not support it going forward. If you want to search absolutely everything your client knows about, open up several 'all known files'/'specific tag service' searches in parallel.
full list
- wrote up a v1.0 ipfs help page
- added ipfs services to 'system:file service'
- added a 'multihash prefix' option to ipfs services in 'services->manage services'–it will prefix thu given text to multihashes copied to the clipboard (e.g. you could use 'http://127.0.0.1:8080/ipfs/')
- fixed a bad repo sync processing bug that was incorrectly assuming packages were completely processed when they often were not
- all repos will have their processing timestamps reset on update, forcing a (fast) reprocess of everything they have to cover the previously missed content
- fixed 8chan OP image parsing, which was sometimes failing due to absent md5s in the json
- widened the splash screen a little more so repo sync text can fit a bit better
- a couple of splash status texts are shuffled around
- updated to sqlite 3.11.0 for windows
- if sqlite3 reports at least version 3.11.0, the db will stick to WAL for large transactions (lke vacuum and content processing), since these are fast now
- 'namespace:*anything*' will now only appear if the a/c input has no 'subtag' component., e.g. 'character:'
- import and export folders now print simple summaries to the log if they do some work
- tidied up the 'pages' menu
- the various hardcoded 'delete' key events are now also triggered by a backspace on os x
- added a rough 'copy known urls' to the regular thumbnail menu. this is prototype, let me know how you would like this information managed and displayed in future
- in prep for the new cache layer, the autocomplete dropdowns (and hence search domains of all contexts) no longer support 'all known files' cross referenced with 'all known tags'
- misc cleanup
next week
I'll move both IPFS directory sharing and my new cache layer forward.