https://youtube.com/watch?v=T9IjJIX50Ls [Embed]windowszip:
https://github.com/hydrusnetwork/hydrus/releases/download/v544/Hydrus.Network.544.-.Windows.-.Extract.only.zipexe:
https://github.com/hydrusnetwork/hydrus/releases/download/v544/Hydrus.Network.544.-.Windows.-.Installer.exemacOSapp:
https://github.com/hydrusnetwork/hydrus/releases/download/v544/Hydrus.Network.544.-.macOS.-.App.dmglinuxtar.gz:
https://github.com/hydrusnetwork/hydrus/releases/download/v544/Hydrus.Network.544.-.Linux.-.Executable.tar.gzI had a good week. File storage locations can now have max size limits. There is a security fix in this release, and
users who run from source will want to rebuild their venvs this week.Full changelog:
https://hydrusnetwork.github.io/hydrus/changelog.htmlmax sizeThis is just for advanced users for now.So, in
migrate database, if you have multiple locations set for your files, you can now, for all but one, set a 'max size', limiting the total mass of files it will store. The idea here is that if you have a 2TB drive and a 500GB one, then rather than having to keep playing with the weights to ensure the 500GB doesn't get too full, you can now set the 500GB location with a 450GB limit and hydrus will allocate that space and no more.
There are a couple of limitations. It isn't perfectly precise, so if your space is tight, give it a little padding (although remember that drives should be at least 10% free space anyway!). Also, it won't yet enforce these rules outside of the 'move files now' button. If you set a tight limit and then import many files, it will blow over that limit (at least until you open up
migrate database and hit 'move files now' again to rebalance).
The next step here is to implement automatic background file migration for always-on checking so we can have these rules apply without regular user intervention. My aim is to get rid of the lagtastic 'move files now' entirely so no file migration blocks other use. I hope to have this done in the next few weeks.
webpA remote execution (very bad) vulnerability was recently discovered in the main webp library. You probably noticed your chrome/firefox updated this week, which was fixing it. Our 'Pillow' image-loading library uses libwebp, and they rolled out an update themselves this week. The builds today incorporate the fix, so if you use them, just update as normal and you are good.
If you run from source, reinstall your venv.
However, if you are Windows 7 (or otherwise on Python <=3.7), I am afraid you cannot get the fix! As I understand, it just won't work for you. There is now an additional choice in the 'advanced' setup_venv script to choose the older Pillow version, so you can keep running, but I'm afraid with this and other things you lads are now solidly in the phase of limited security updates. I will keep supporting you as long as it is generally reasonable, but if you still want to use Win 7, I think the train is running out of track.
miscWhen images fail to render, they now show something proper in the media viewer. (previously they were just blank forever and made some error popups).
After last week's updates, Mr Bones gets a readability/layout pass.
The client
should stop mistaking various text files for mpegs in the pre-import phase!
I think the Docker client wouldn't boot last week, same for anyone else without the PSD-tools library. Sorry for the trouble, should be fixed now!
next weekI'd like to add a file search to the file history chart and get stuck into more file storage infrastructure updates.