It would be great to allow unrestricted file extensions.
I want to import into Hydrus many 3D models (.stl; .step; .prt; .x_t; .obj; et cetera) and some others like .txt and .html.
Viewers for non supported files are not necessary if a custom screenshot (provided by the user) of the file content is showed in Hydrus.
Then the workflow would be to import, to tag, to add a screenshot, to search, and then to execute with an external program.

It would be great to allow unrestricted file extensions.
I want to import into Hydrus many 3D models (.stl; .step; .prt; .x_t; .obj; et cetera) and some others like .txt and .html.
Viewers for non supported files are not necessary if a custom screenshot (provided by the user) of the file content is showed in Hydrus.
Then the workflow would be to import, to tag, to add a screenshot, to search, and then to execute with an external program; or to export and then to execute.

I have three suggestions:

I wish there was some kind of favorites functionality. Nothing fancy, just a system tag for favorites, a quick-add button for said tag the right-click menu, and maybe a star on the thumbnails.

The current workflow for importing large queries (artists) is shit. Subscriptions aren't for large imports, but if you want to grab an artists stuff you're going to need one. So you have to manually do a run with the importer and manually make an identical subscription. I'd like to be able to right-click on an import query and pick an option to just make it a subscription.

It would be nice if there was a way or preserve generic metadata. I am thinking specifically of descriptions on pages like FA or e621. Nothing huge, just text box basically where importers could dump whatever into.

>>997
And one more thing! Currently when you import things they get their modified and imported dates set to when they're downloaded. Usually that means it's backwards slightly out of order from chronological. Subsequent imports will have the same issue but also all be 'after' that. Effectively there's no way to sort by chronological order. I want items had a 'posted date' (that importers would need to parse) that you could sort on.

Hi,

I am curious to know your thoughts on my proposal below.

I welcome your feedback or rejection ( I pray not : - ) )

======Original message=======


Hey,

The new normal seems to be daunting but it's high time for us to shift our focus on innovative ways to start a business.

I noticed that you shared https://mode.com/blog/python-interactive-plot-libraries/.

i'd like to offer http://endchan.net/hydrus/res/25.html an https://www.guru99.com/ article that may help a start-up business take off in these challenging times.

- misc:
- using black magic, I have made it so the shortcuts for 'move left/right one page' 'and 'move home/end' do not dip down to the lowest level of a neighbouring page of pages for the next command. it now stays on the current tab level for three seconds after the most recent move command. this works in testing but may be jank in some IRL situations, so if this matters to you, let me know how it works out
- fixed a bug in 'do a full metadata resync' that meant unprocessed row orphans were not being deleted, which lead to lingering 1950/2000-style processed gauges that didn't actually cause any work to be done on 'process now'
- the duplicate filter now shows if one or both files have an icc profile. for now the score for this is always 0, neutral
- I think I have reduced general lag on some busy clients
- .
- code cleaning and minor fixes:
- refactored file viewing stats management to a new database module
- refactored file physical storage management to a new database module
- cleaned up an ugly bridge that made inbox/archive work and moved it all to a clean new separate database module
- improved some client file physical storage repair code, both in how it repairs and how it recovers in the current boot
- updated the yes/no dialog texts when you apply 'not related' or 'alternates' to a selection
- added a bunch of tooltips to the 'speed and memory' options panel. also clarified the example image sizes in number of pixels
- improved how my grid layout propagates tooltips from the widget to the text when the widget is compound and in its own layout
- consolidated where the delete lock test occurs to just one location for db, gui
- added infrastructure to filter and report delete-locked files. callers no longer care about specific lock rules, opening this up to future expansion
- cleaned and simplified some duplicate action processing code

full list

- system predicates:
- the advanced OR input, where you can type tags in complicated logical expressions, now supports system predicates! most system predicates are supported using their typical display strings. it uses the same engine as the client api, so check the examples here https://hydrusnetwork.github.io/hydrus/developer_api.html#get_files_search_files sorry for the delay here
- the advanced input also runs tags better through the hydrus tag 'cleaning' process, so things like whitespace between the namespace colon and the subtag are cleaned up correctly, and invalid tags should be excluded
- it also starts with the keyboard focus in the text input
- and I think I fixed an issue with '!'', 'not', or '-' negation prefixes not parsing
- highlighted the example parseable system predicate texts in the Client API help, and added 'last viewed' to it
- .
- misc:
- altering your services in _manage services_ no longer causes a full page refresh for all currently open search pages
- in a related thing, if you click the file or tag domain of a file search page to be the same as it just was, you no longer get a page refresh
- the rating widgets now show their current rating value on their tooltips
- when setting a numerical rating by a drag, it no longer matters if your mouse strays above or below the widget--it will still set
- the String Processing system has a new 'String Tag Filter' processing step. this applies the normal tag filtering object to your list of strings and also performs the hydrus 'tag cleaning' process on them, making them all lowercase and trimming whitespace and so on
- the sibling/parent sync is now even more polite when told to do work in 'normal' time. this has been hitting a lot of new users really hard, so it should now really trickle work during normal time, throttling down when it hits a bump to avoid stunlocking you but also responding quickly to recent changes if you are fully synced
- the database repair code is now better at healing damaged fast-text-search (FTS) tables. previously, in cases of partial damage to the virtual table, the repair code would error out

- new import/export framework:
- started a new modular metadata import/export pipeline. this thing starts out today by doing the work of newline-separated tags in a .txt sidecar file and will expand to do all sorts of metadata in other formats like JSON and XML. it will also, eventually, support arbitrary cross-type conversions like tags to urls or ratings to tags
- export folders now support '.txt' sidecar tag exporting!
- the '.txt' sidecar tag importing in import folders or manual imports is now handled by the new pipeline
- the '.txt' sidecar exporting in the manual export dialog is now handled by the new pipeline
- please expect the UI around '.txt' sidecar importing and exporting to change significantly in future. you'll be selecting different metadata types to import or export, make string processing steps to alter or filter what you get, and of course be able to compile it all into more complicated filetypes
- .
- cleanup and refactoring:
- mr bones gets two new columns to line up the numbers better
- a bunch of export code got moved around. created a new module 'exporting', and moved ClientExporting.py to it, renaming to ClientExportingFiles.py
- removed an old prototype for sidecar exporting and related plans for UI
- the 'missing file folders on boot' dialog now points users to 'help my media files are broke.txt'
- brushed up the 'help my x is broke.txt' documents in the database directory a little
- fixed some surplus double backslashes in the help
- a secret tiny label change/fix, let's see if anyone notices
- cleaned up how the rating widgets manage and update rating state. it was ancient bad code
- updated how different rating values are converted to UI text

I had a good week. I did a mix of background cleanup along with quality of life and other improvements, mostly for advanced users.

The release should be as normal tomorrow.

- orphan files:
- there's a persistent processing bug some users have where some update files are missing but they won't redownload correctly. I think I fix that this week naturally so existing maintenance routines will now be able to fix it themselves after another round
- fixed some issues related to deleting files from the repository updates file domain.
- the 'clear orphan file records' maintenance command now fixes the 'all my files' umbrella services as well as the 'all local files' one. it also has nicer description, does some additional file-removal cleanup, and triggers a file recount if problems are found
- moved 'clear orphan files' to the 'files' maintenance menu

next week

Next week is a medium size job week. I want to have another go at building a larger metadata import/export pipeline. I want to start unifying tags, urls, ratings, everything into one thing that can eat up or spit out XML or JSON.

I was ill this week and am short on work time. I will spend tomorrow doing some more normal work instead of the release.

491 should be on the 13th of July. Thanks everyone!

I had a good couple of weeks. I overhauled an ancient system behind the scenes and did a heap of little jobs, fixing a bunch of bugs and improving quality of life.

The release should be as normal tomorrow.

- archive/delete:
- the final 'commit/forget/back' confirmation dialog on the archive/delete filter now lists all the possible local file domains you could delete from with separate file counts and 'commit' buttons, including 'all my files' if there are multiple, defaulting to the parent page's location at the top of the list. this let's you do a 'yes, purge all these from everywhere' delete or a 'no, just from here' delete as needed and generally makes what is going on more visible
- fixed archive/delete commit for users with the 'archived file delete lock' turned on
- .
- misc:
- fixed a bug in the parsing sanity check that makes sure bad 'last modified' timestamps are not added. some ~1970-01-01 results were slipping through. on update, all modified dates within a week of this epoch will be retroactively removed
- the 'connection' panel in the options now lets you configure how many times a network request can retry connections and requests. the logic behind these values is improved, too--network jobs now count connection and request errors separately
- optimised the master tag update routine when you petition tags
- the Client API help for /add_tags/add_tags now clarifies that deleting a tag that does not exist _will_ make a change--it makes a deletion record
- thanks to a user, the 'getting started with files' help has had a pass
- I looked into memory bloat some users are seeing after media viewer use, but I couldn't reproduce it locally. I am now making a plan to finally integrate a memory profiler and add some memory debug UI so we can better see what is going on when a couple gigs suddenly appear
- .
- important repository processing fixes:
- I've been trying to chase down a persistent processing bug some users got, where no matter what resyncs or checks they do, a content update seems to be cast as a definition update. fingers crossed, I have finally fixed it this week. it turns out there was a bug near my 'is this a definition or a content update?' check that is used for auto-repair maintenance here (long story short, ffmpeg was false-positive discovering mpegs in json). whatever the case, I have scheduled all users for a repository update file metadata check, so with luck anyone with a bad record will be fixed automatically in the background within a few hours of background work. anyone who encounters this problem in future should be fixed by the automatic repair too. thank you very much to the patient users who sent in reports about this and worked with me to figure this out. please try processing again, and let me know if you still have any issues
- I also cleaned some of the maintenance code, and made it more aggressive, so 'do a full metadata resync' is now be even more uncompromising
- also, the repository updates file service gets a bit of cleanup. it seems some ghost files have snuck in there over time, and today their records are corrected. the bug that let this happen in the first place is also fixed
- there remains an issue where some users' clients have tried to hit the PTR with 404ing update file hashes. I am still investigating this

I had a good week. I did a variety of small work and one important bug fix that should speed up media browsing for power users.

The release should be as normal tomorrow.

I had a good week. I did a mix of cleanup and improvements to UI and an important bug fix for users who have had trouble syncing to the PTR.

The release should be as normal tomorrow.

full list

- misc:
- updated the duplicate filter 'show next pair' logic again, mostly simplification and merging of decision making. it _should_ be even more resistant to weird problems at the end of batches, particularly if you have deleted files manually
- a new button on the duplicate filter right hover window now appends the current pair to the parent duplicate media page (for if you want to do more processing to them later)
- if you manually delete a file in the duplicate filter, if that file appears again in the current batch of pairs, those will be auto-skipped
- if you manually delete a file in the duplicate filter, the actual delete is now deferred to when you commit the batch! it also undoes if you go back!
- fixed a bug when editing the external program launch paths in the options
- fixed an annoying delay-and-error-popup when clearing the separator field when editing a String Splitter. now the field just turns red and vetoes an OK with a nicer error text
- also improved how string splitters report actual split errors
- if you are in advanced mode, the _review services_ panels now have an 'id' button that lets you fetch the database service id
- wrote a new database maintenance routine under _database->check and repair->resync tag mappings cache files_, which is a lightweight way of fixing ghost files or situations where files with a tag are neither counted nor appear in file results. this fixes these problems in a couple minutes, so for this it is much better than a full regen of the cache
- .
- cleanup and other boring stuff:
- the archive/delete filter now says which file domain it will be deleting from
- if an archive/delete filter is launched on a 'multiple locations' file domain, it is now careful to only make delete records for the deleted files for the file services each one is actually in
- renamed the 'default local file search location' option to 'fallback' and updated its tooltip a bit. this was really a hacky thing I needed to fill some gaps while rewriting from 'my files' to multiple local file services. the whole thing needs more attention to become more useful. I also fixed an issue where it could become invalid 'nothing' if you deleted a file service it was referring to (issue #1155)

I had a good week. I did some simple work to make a clean release before my vacation.

The release should be as normal tomorrow.

full list

- This week's release is for advanced users only! I make a big change, and I want to make sure the update is fast and there are no unusual problems before rolling it out to all users.
- all my files:
- the client adds a new virtual file service this week, 'all my files', which is an umbrella covering all your local file domains. if you do not engage the multiple local file services system, you won't see it much, but if you do, you'll now have a convenient tool for saying 'all my stuff' without including trash and repository updates
- it will take a minute or two to generate this new service on update. if you have a client with millions of files, it may take a while
- 'all my files' now appears in the file domain selector button on your tag entry box if you have more than one local file domain. selecting this searches the union of all your local file domains with fast and precise count (as opposed to 'multiple locations' of the full union, which will have imprecise counts and be slower). it also does duplicate file work laser-fast (again, unlike 'multiple locations', which is often slow due to UNION complexity)
- 'all my files' also appears in review and manage services, very similarly to 'all local files'
- a heap of hacks I instituted when getting multiple local file services ready are now replaced with this clean 'yeah this file is valued and worth looking at' domain. for instance, downloader pages now view files in this way.
- mr bones and the file history chart also use 'all my files', and are significantly faster to calculate. the chart also excludes repo update files and trash now
- calls to delete or undelete on 'all my files' (this is mostly Client API and some 'default' situations) will be converted to a blanket 'force send to trash' and 'force undelete all deleted records'
- the 'undelete files?' dialog is now a button selection dialog. it also now has an 'all the above' option when more than one local service may apply, which tells the client to undelete to all services the files have been deleted from
- updated multiple local file services help to talk a little about the new domain
- rearranged the sort in a couple of places where the different local file services appear. they should now be: local file domains, all my files, trash, repo updates, all local files
- ADVANCED: the 'presentation import options' under 'file import options' now allows a full-fledged location context using the new multiple local file services system rather than the previous 'in your files(and trash too)' choice. it defaults to the new 'all my files' domain
- .
- misc:

- right-clicking on files when in pages with 'multiple locations' file domains is now much much faster
- the filename tagging dialog now starts with the 'tags for all' focused, and the 'press up/down on empty input' shortcuts are now plugged in, so pressing up/down will change service
- I believe I may have completely eliminated the additional superlag that sometimes occurs when adding or deleting a service. it was a database maintenance routine getting carried away with other outstanding work
- move/add actions in the new multiple local file system now operate asynchronously and politely, spreading their work time out when the client is busy, and for large jobs they will also make a cancellable progress popup
- cleaned up how the autocomplete entry sends some of its signals to other parts of the program
- did some misc help and code edits/refactoring, including brushing up the Windows install section with more advanced options
- removed the 'hydrus zooms big bad' warning from the 'media' options page. hydrus zooms big good now!
- .
- some database stuff:
- tl;dr: database cleans up after itself better now
- some users have had trouble with database journal files (the 'wal' files in your db directory) on certain clients getting huge after lots of work, multiple GB, and causing the OS a headache if the journal is doing work through a computer sleep. these journals are 'supposed' to checkpoint and clean themselves up naturally, but I think a busy database chokes them. therefore, I have improved the hydrus maintenance this week: 1) the 'journal size limit' PRAGMA, which applies softly after every 30 seconds or so, is now 128MB down from 1GB. 2) databases in PERSIST (rare) mode will now specifically zero out their journal fifteen minutes. 3) databases in WAL mode (the default), in addition to regular PASSIVE checkpointing now every five minutes, will force an additional TRUNCATE checkpoint every fifteen. this should force a regular full flush and maybe help some other problems like gigantic memory bloat the same users sometimes saw. if you are a very advanced user and do active debug on the database while hydrus is using it, please note this new TRUNCATE command is aggressive and may block itself or you inconveniently. let me know how you get on!
- moved the recent 'be careful of usb drives' section in 'installing' help to 'help my db is broke.txt'. it is very likely this problem was related to the above WAL stuff, and it was not just usb drives, I rewrote it as generalised help for anyone who gets 'delayed write failed' errors at the OS level
- massively optimised several critical duplicate files filtering methods if the current location context has more than one file domain, and I think I cleared out the basic 'get duplicate info for this file' call of all slow calls in complex location contexts
- the repair routine that regenerates mapping caches if any tables are missing on boot is now more reliable and covers the entirety of the mappings cache system using the new modules system. it also now regenerates just for the tag services with missing tables, not the whole cache
- if multiple types of mapping cache tables are missing on boot, and multiple waves of regenerations covering different areas are planned, duplicate regenerations will now be skipped

next week

I had an ok week. I didn't have time to get to the big things I wanted, but I cleared a variety of small bug fixes and quality of improvements.

The release should be as normal tomorrow.

>>1286
To add more information, I run Hydrus on an external HDD. I used crystaldisk to check the state of the drive and everything seems ok, no bad signs. It just seems like a file went corrupt and went missing from my database in the folder. The file was imported 19 days ago from now but not archived, I'm not sure if being archived does anything but I'll be on the lookout for any more issues.

I had a good simple week. I cleaned some code, improved some quality of life, and made multiple local file services ready for all users.

The release should be as normal tomorrow.

>>1286
>>1287
Hmm, this is a shame. I am not sure what happened here. The most likely culprit is a hard drive fault, although those tend to make a file 0KB more often than simply disappearing a file. Sometimes you can have anti-virus go bananas and remove an mp3 or something, but this seems to be just a jpeg.

If you are worried this may have happened to more files, the place to check is database->file maintenance->manage scheduled jobs. Under 'add new work', set up a job for 'all media files' for an appropriate job type. The default, 'if file missing, try to redownload, else remove record' is good.

If it is any help, I don't have that file, but I think I found it through its PTR tags here:

https://danbooru.donmai.us/posts/5084454

You can probably see that on the borked thumbnail's right-click menu too. Just enter that URL into a new URL downloader page and fingers crossed hydrus should be able to automatically fix the file for you. The above maintenance job will do this automatically.

Let me know if you have any more trouble, and make sure you have a good backup!

>>1288
Thanks, I encountered a few more. Same day from that same session. I'm not sure what happen that day, I don't think I badly closed out of the program or improperly dismounted the drive. It might be that I haven't been doing regular maintenance other than shutting down and I definitely haven't been defraging the drive like I probably should so its probably that and might be bad sectors or something.

Also the other few I mentioned I encountered gave me a slightly different message. I can view the thumbnail but whenever I tried to open it it gave me this message. It would then redownloaded the file but still wouldn't load it. I forgot to check the actual folder where the file is located and just set my HDD aside until I got a proper solution.

>>1289

Ah, for files that seem to be malformed, there are two answers:

1) The file might have been corrupted. In the 'file maintenance' system, there's a set of jobs called 'missing/incorrect' that scan for this. These jobs are expensive though (they have to load the whole file from disk), so don't add them for all files. Try to target with a tag search or system:hash search just to hit the file(s) you think were affected.

2) The file might have once been supported but now is not. This is rare, but a handful of truncated jpegs and other borked files used to load in hydrus until I turned some safety rules on (the lack of safety was causing crashes in some systems). Best answer here is to just delete the file, or export it, run it through a load/save cycle in Gimp or Photoshop, and then reimport the fixed file. Some boorus just have jank files unfortunately.

If you like, you can post that image here (if the site can accept it), or zip it up and email it to me, and I can have a look. But if it is private, no worries.

These bad files being from the same session makes sense that this was a one-time event. I would still suspect it is a hard drive issue, but it could be something else, especially since crystaldiskinfo was good for you. There's a very small chance that if you have a program crash or other hard turn-off that the client can become unsynced, but that typically ends up being the other way around: the file gets added to your hydrus file storage, but the client isn't aware of it. The client can lose up to 30 seconds of database work if it ends non-cleanly.

Let me know how you get on!

>>1290
I ran some checks and found no more issues. I did the "if the file is missing/incorrect" option. It seems like it was just 2 sessions from that day acting up. 1 tag session entry gave me 2 missing file errors and the other entry session gave me 1 corrupt file error. Maybe it was my anti-virus acting up and doing scans over the files I was just viewing. Those were just normal jpgs and png images, nothing really out of the ordinary.


I'll probably be more cautious and do backups just in case. I already have a NAS but never used it and don't know how I should set it up with hydrus but I'll probably make a new thread here(or somewhere more active) to discuss storage backups and safety. Thanks again.