>>21085
Thanks. The mpv window is embedded into hydrus with duct tape and a prayer, so window manager bells and whistles can sometimes mess with it. You might like to play with the advanced window settings under
options->gui->frame locations, the 'media_viewer' set. Maybe setting it to start as maximised/fullscreen--or setting it to not, if it is on--helps the initialisation and the window manager hijack here. Otherwise, let me know how you get on. If it comes back, is there any pattern to why it does? etc...
>>21086
I think we spoke elsewhere about this, but in case that wasn't you, this is the latest quicksync afaik:
https://breadthread.gay/ . It should have the update files in its client_file directory, which you can import under
services->import repository update files, but you'll still have to talk to the PTR for a short time, on VPN or otherwise, to initialise your metadata store in the
review services panel.
>>21096
I'm not involved in running the PTR day to day anymore, but I haven't heard anything about this. I know plenty of Russian users have to use VPN to access all sorts of spicy locations like boorus, maybe it is the same, some odd ISP-level block to that data center? In any case, I generally recommend everyone use VPN these days, no matter what imageboard-tier stuff you are doing.
>>21098
>It would be cool if we could do booru wiki style entries where you could link to other tags or even URLs, but to me the most important part would be ease of looking up a basic definition for that tag. Maybe type it in to the add tag box and right click a candidate tag and hit 'see definition' or something.
Thanks--I think this is what I envision for a first version as well.
Well done for finding your backup!
You've already learned the lesson, but I'll still link you to the secret help page: https://hydrusnetwork.github.io/hydrus/after_disaster.html
>>21101
>>21102
>I guess if this works like i just described, doing the same in the future again and again would mean only the mappings that are missing in 'my tags' would get updated and it would not start a huge job and migrate everything for every single file again, right?
Yeah in general, I can and do skip this work when possible, and it is usually possible. My general default when there are 'overwrite' conflicts is just to merge, so if you throw 100 tags at a file, and it already has 80 of them, it'll simply add the new 20, no worries, and very fast. In general, 'I don't need to add this because it already exists' rows tend to work about 100-1000x faster than a new data row. So instead of taking 100 time units to do this work, it'll take like 20 + 0.08.
My general 'it might take ages if you regularly repeat this' worries are related to it taking a bit of time to set up this job just when you have to click all the UI, and then also when you sync from a gigantic datastore like the PTR to a local store, there is a bunch of unavoidable overhead just from the files you don't have. The PTR has a couple billion mappings, of which maybe a few million might apply to your local collection, so that '100-100x faster' bulk suddenly gets a lot larger. Even if I make the 99.9% of negative matches work very fast, it is still going to probably be ten or twenty minutes of waiting around to go through them, or maybe even hours, and if all that work only adds 100 tags in some fresh sync, I generally think it isn't work it.
Logically, though, there's no problem in running updates like this.
>>21117
Thank you very much--I will play with this!