https://www.youtube.com/watch?v=wrh0tdmbfiE
windows
zip:
https://github.com/hydrusnetwork/hydrus/releases/download/v345/Hydrus.Network.345.-.Windows.-.Extract.only.zip
exe:
https://github.com/hydrusnetwork/hydrus/releases/download/v345/Hydrus.Network.345.-.Windows.-.Installer.exe
os x
app:
https://github.com/hydrusnetwork/hydrus/releases/download/v345/Hydrus.Network.345.-.OS.X.-.App.dmg
linux
tar.gz:
https://github.com/hydrusnetwork/hydrus/releases/download/v345/Hydrus.Network.345.-.Linux.-.Executable.tar.gz
source
tar.gz:
https://github.com/hydrusnetwork/hydrus/archive/v345.tar.gz
I had a good week. The big thumbnail update is done, which means for an important update. Users with smaller databases have less to think about, but anyone with 1,000,000+ files should definitely read all of the following:
thumbnails
This is a great week to make a backup before you update!
Until now, the hydrus client has used two simple thumbnails–one 'full-size', one 'resized'–for each file. Hardware has moved on since then, and so has my code, so it is now feasible to have a single smarter thumbnail that will resize itself on demand. The work for this was done this week. This makes for a simpler and less wasteful storage system and more flexible thumbs all around.
The main thing is that on this update, the client will delete the surplus thumbnails. You will get a popup before it happens to remind you. Specifically, it will delete the 256 'rxx' 'resized' subfolders in your database's file store. If you have moved these folders through the
migrate database dialog, this is no problem–the client will delete them wherever they are. Depending on your collection and platform, it could take a few seconds or several minutes. Your new thumbnails may load just slightly slower the first time, but this will return to normal in time.
The best news is that the old 200x200 limit is gone! You can now set your thumbnails' size under
options->thumbnails up to 2048x2048! I am now running 360x240 on my 4k machine and like it a lot.
Note that if you previously moved your 'resized' thumbs to an SSD but not your old 'full-size' thumbs, you will want to recheck the
migrate database dialog at some point to make sure you move your newly active thumbnail folders to fast storage. This is likely to be a big job, so plan for it.
The migrate database help regarding all this has been updated:
https://hydrusnetwork.github.io/hydrus/help/database_migration.html
Also, be prepared for your next backup run to have significant additional delete overhead as all your backup's 'rxx' folders will be deleted as well. If you have fewer than, say, 250,000 files, I do not think you need to think much of this, but if you have many more, you might like to manually delete these folders from your backup yourself right before your next run. There are 256 of these folders, named in hexadecimal from r00 to rff. Preemptively deleting them will save you backup-scanning time and keep your recycle bin sane (if your backup program deletes to recycle bin). Make sure you do a permanent delete (Shift+Delete on Windows) to skip over the recycle bin yourself.
I tested the new system thoroughly, but as always, some unusual scenario may present problems. The system is more complicated than 'if the thumb is the wrong size, resize it and save it back to disk', so some edge cases may throw an error. Please report any bugs, and I'll try to have them fixed for 346.
full list
- or search:
- set out a plan to achieve some simple conjunctive normal form (e.g. (blue eyes OR green eyes) AND (blonde hair OR red hair)) OR search support
- started work on the object extension and search code to support this search in a very basic (and likely inefficient-for-some-scenarios) way–we'll work on this as we discover the most common inefficiencies
- .
- thumbnails:
- the client no longer uses both 'master' and 'resized' thumbnails–it uses a single, smarter thumbnail
- only the 'txx' thumbnail directories (formerly referred to as full-size) are now used, and the thumbnails inside will regenerate and scale themselves as needed on demand (and will be careful to not save changes to disk when when their source file is non-local)
- the old 'rxx' 'resized' thumbnail directories are no longer referred to anywhere in the code or ui
- the old 'rxx' thumbnails directories will be permanently (i.e. no recycle bin) deleted on update. this is a big job, and you will be prompted on update before it happens
- if you have migrated your db to put 'resized' thumbs on an SSD but not the formerly 'full-size', you will want to recheck the 'migrate database' dialog once you have booted and set a new thumbnail override to move the txx directories over
- due to the smarter thumbnail, 200x200 is no longer the hard limit for hydrus thumbnails! you can now set up to 2048x2048
- all file storage location information is now stored directly in the client db (rather than the options object), which should make for more easily export/importable options in future and improve manual fixing as needed
- added more thumbnail-resizing related popup spam to file report mode
- fixed a windows-only issue that was making the migrate db dialog close after a file move event concluded
[Expand Post]
- updated database migration help for new concepts and ui
- cleaned up some misc storage code
- .
- the rest:
- fixed a problem in the client api with fetching file identifiers from file_ids
- fleshed out 'help my db is broke.txt' with more specific clone recovery examples
- fixed import support for a variety of single-frame music webms
- fixed an edge-case preview viewer initialisation bug that was trying to draw the canvas before any media was set
- network report mode now states url classes of urls about to be parsed
- misc small fixes and cleanup
next week
I got started on OR search this week. I have a decent plan and feel good. I hope to have some sort of prototype ready for 347. Otherwise I will do some small jobs. I may look into adding multiple-files 'known urls' management.