/hydrus/ - Hydrus Network

Archive for bug reports, feature requests, and other discussion for the hydrus network.

Index Catalog Archive Bottom Refresh
Name
Options
Subject
Message

Max message length: 12000

files

Max file size: 32.00 MB

Total max file size: 50.00 MB

Max files: 5

Supported file types: GIF, JPG, PNG, WebM, OGG, and more

E-mail
Password

(used to delete files and posts)
Misc

Remember to follow the Rules

The backup domains are located at 8chan.se and 8chan.cc. TOR access can be found here, or you can access the TOR portal from the clearnet at Redchannit 3.0.

Uncommon Time Winter Stream

Interboard /christmas/ Event has Begun!
Come celebrate Christmas with us here

8chan.moe is a hobby project with no affiliation whatsoever to the administration of any other "8chan" site, past or present.
(16.41 KB 480x360 sOTQsdwEdk8.jpg)

Version 335 hydrus_dev 01/10/2019 (Thu) 03:09:25 Id: d494fe No. 11238
https://www.youtube.com/watch?v=sOTQsdwEdk8 windows zip: https://github.com/hydrusnetwork/hydrus/releases/download/v335/Hydrus.Network.335.-.Windows.-.Extract.only.zip exe: https://github.com/hydrusnetwork/hydrus/releases/download/v335/Hydrus.Network.335.-.Windows.-.Installer.exe os x app: https://github.com/hydrusnetwork/hydrus/releases/download/v335/Hydrus.Network.335.-.OS.X.-.App.dmg linux tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v335/Hydrus.Network.335.-.Linux.-.Executable.tar.gz source tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v335.tar.gz When I first made this release, Github’s file upload was not working right, and I used Mediafire instead. Github is now working and I have updated the links above. I had a great four weeks updating hydrus to python 3. The update went well, and the releases today are ready for all users, but there are special update instructions just for this week. python 3 The client and server now run completely and exclusively on python 3, updating from python 2. The new version has a variety of benefits, mostly in better unicode vs. data handling, but for hydrus it also runs a little faster, uses less idle CPU and significantly less memory, and has a little less ui-jank. I am pleased with the update. None of it was extremely difficult, but there was a lot to do, a few headaches, and some new stuff to learn. I am glad I took the four weeks. I also appreciate the users who tested the preview releases in the past couple of weeks. I have squashed a ton of little bugs, and everything normal like file downloading and browsing seems to work completely fine, but there are likely a couple of small issues still out there. If a dialog breaks for you and you get some popups about some datatype being mishandled, please send it to me and I'll get it fixed up for v336! some notes Unfortunately, for technically difficult reasons, I could not compile 'debug' versions of the executables, so these are gone this week. I will revisit this, but the original debug builds were a bit hacky and may no longer be practically possible in py3. Also, I am not certain if the database menu's 'set a password' will have kept correct password data for unusual keyboards, so if you use this function, the client will, just for this v335, forgive incorrect passwords! If this happens to you, the client will give you a popup with more information and tell you how to try to fix it. I would appreciate feedback here, if you encounter it. Due to a natural library update unrelated to py3, your hydrus sessions will likely be wiped (this also happened to some running-from-source users a little while ago), which means Hydrus will have to re-login to any sites you have logins set up for. If you have special cookies you need to save or re-import from your browser, get set up before you update! Now, because py2 and py3 are incompatible, the new version cannot be run in a folder that still has old .dll files hanging around. Please follow the following to update: update instructions for windows installer Just for this week, I have added a routine to the installer to delete the old files (but obviously saving your db directory where your database and files are stored!), so you shouldn't have to do anything. I nonetheless recommend you still make a backup before you update. Backups are great, and if you don't make one yet, this week is a great time to start. If you are a particularly long-time user and the installer fails to clear everything out, you may need to delete the old files yourself, like the extract users will have to: update instructions for windows and linux extract You will have to perform a clean install, which means deleting everything in your install folder except the db directory before extracting as normal. This is simple, but do not get it wrong. Do not delete your db directory–this is where your database and files are stored. As always, if you have a recent backup, you don't have to worry about any possible accident, so make sure you have one. update instructions for os x Due to technical limitations, the OS X release is now App only. Furthermore, this App release will no longer store the db inside itself! The default location for your db is now ~/Library/Hydrus (i.e. /Users/[you]/Library/Hydrus). This also means that the future update process will be as simple as replacing the existing Hydrus Network App in Applications, just one action. I apologise that this important change has taken so long to come out, but we got there in the end.
[Expand Post]If you are updating this week, you will need to make the Hydrus folder under your Library yourself and move your existing db there so the new Hydrus can pick up where you left off. If you use the tar.gz, you'll be moving the contents of your install_dir/db, and if you use the App, you'll want to right-click->Show Package Contents on your old py2 App and navigate to Hydrus Network/Contents/MacOS/db. You want the contents of db, not the db folder itself, so the path to your new client.db file should be ~/Library/Hydrus/client.db, for instance. If you cannot see your Library folder, check this: https://www.macworld.com/article/2057221/how-to-view-the-library-folder-in-mavericks.html If you have trouble with this, please let me know and we'll figure it out together. update instructions for running from source You'll need to make a new py3 venv and make new shortcuts. I now use pycryptodome instead of pycrypto and dropped some libraries, so I recommend you go to the 'running from source' help page again and just paste the new pip line(s) to get set up. I don't think 3.4 will work, but 3.5, 3.6, and 3.7 all seem ok. Obviously contact me if you run into trouble. I'm also interested in success stories! full list - important: - hydrus now runs completely and exclusively on python 3! - for users who are updating, the client has special install instructions for just this week: - if you are a windows or linux user who extracts to install, you will have to delete your old install's files (but keep your db folder!!!) before installing/extracting the new version so there are no 2/3 dll/so conflicts (don't delete your db folder!) - if you use the windows installer to install, this v335 installer will do the clean install for you! there is absolutely no way this could go wrong, so no need to make a backup beforehand :^) - if you are an os x user, I am now only releasing the client in the app. furthermore, the default app db location is now ~/Library/Hydrus (i.e. /Users/[you]/Library/Hydrus). you will have to move your existing db to this location to update, and thereafter you'll just be replacing the app in Applications! - if you try to boot a non-clean mixed 2/3 install, the client will try to recognise that and give an error and dump out - please check the release post for more detailed instructions here - . - semi-important: - the db password feature may be one-time broken for unusual keyboard languages, so failures this version will be forgiven with an appropriate error message explaining the situation. feedback from чики брики lads appreciated - I may have fixed the issue some linux/os x users were having launching external programs, including OS ffmpeg (it was a child process environment issue related to pyinstaller) - although I did most of my devving here on py 3.6, the client seems to run ok on 3.5. I doubt 3.4 will do it, if you mean to run from source - I moved from the old pycrypto to the new pycryptodome, so users who run from source will want to get this. I also dropped some libraries - . - misc bug fixes: - fixed the 'load one of the default options' button on manage tag import options when a set of default options is orphaned by a deleted url class - removed some popup flicker related to long error messages - fixed some parsing testing ui error handling - cleared up some bad text ctrl event handling that could sometimes cause a recursive loop - listctrls should now sort text that includes numbers in the human-friendly 2 < 10 fashion - cleaned up some bad external process calling code and improved how child process environment is set up - finally figured out the basic problem of a long-time nested dialog event handling error that could sometimes freeze the ui. I may have fixed it in one case and will keep working on this - . - boring details: - ran 2to3 to auto-convert what could be done - updated environment to python 3 - went over a whole ton of unicode encoding/decoding manually to update it to python 3 - removed all the old tobytestring/tounicode calls in favour of new python 3 handling - fixed all the file io to do bytes/str as appropriate - corrected a bunch of / vs // int/float stuff - fixed up twisted, which has some str/bytes stuff going on - fixed all the listctrls to deal with column sorting None values amongst ints/strs - fixed png export/import, which had some fun bytes/bytearray/int/str issues - updated the swf header parsing code to py3 (more str/bytes stuff) - misc float/int fixes - fixed up some http.cookies handling, which has changed in py3 - improved some ancient loopback connection code that was only really checking to see if ports were in use - cleaned up a bunch of now-invalid parameter tuples that 2to3 helpfully marked - numerous misc other refactoring and so on - updated the new network engine to now decode non-utf-8 responses correctly based on actual response header - removed some old py2 manual http multipart code - removed the old py2 'matroska or webm' parsing py, replacing it with some direct ffmpeg format inspection - replaced all % formatting with the new .format system. I will slowly move to this rather than the current endless concatenation mess - deleted some more misc old code - tightened up some spammy network error reporting - converted all /r/n to /n in my environment project, ha ha ha - the ui seems to better support rarer unicode characters like - updated some of the install/update/backup help for all this, and some misc other stuff as well - fixed misc bugs next week A lot of small stuff piled up over the holiday. I will spend a week or two trying to catch up and also planning out the client API, which will be my first big job of the year. I hope you had a good Christmas and New Year. Mine were great, and I am looking forward to 2019. Let's keep pushing and see if we can do some fun stuff. Thank you for your support!
Anonymous 01/10/2019 (Thu) 04:03:39 Id: c2d6c5 No. 11239
Ok guys, I'm going to build this from source, don't try to stop me.
Anonymous 01/10/2019 (Thu) 04:18:08 Id: 77a872 No. 11240
It deleted my database.
Anonymous 01/10/2019 (Thu) 05:34:13 Id: e78389 No. 11241
>>11238 So I just saw this sticky appear and went to the github page for the release as usual, but I saw this: >for users who are updating, the client has special install instructions for just this week: >if you are a windows or linux user who extracts to install, you will have to delete your old install's files (but keep your db folder!!!) before installing/extracting the new version so there are no 2/3 dll/so conflicts (don't delete your db folder!) >if you use the windows installer to install, this v335 installer will do the clean install for you! there is absolutely no way this could go wrong, so no need to make a backup beforehand :^) And I really didn't trust the smiley with the carat nose. In my experience that literally means you're bullshitting. Anyway, I know hydrus dev wouldn't do us like that… I would think… but I'm gonna wait for others to make more noise if they will, cause I am just a meek laptop Windows user with a 1TB hard drive with 30 gigs of space left. I can't afford to backup, even if it's easy to just say "I told you to backup bro."
Anonymous 01/10/2019 (Thu) 05:49:24 Id: c0cfdf No. 11242
Everything seems to have updated fine here, I'll let you know if I run into any issues.
ice cold ~baka~ 01/10/2019 (Thu) 06:38:20 Id: 9c1daf No. 11243
Proud extract user. Will wait a good 10 day before doing anything, due to heavy hot repaging action. Will track attentively nonetheless.
Anonymous 01/10/2019 (Thu) 08:29:28 Id: b9c229 No. 11245
>>11241 Just take a backup before updating and you should be good to go.
Anonymous 01/10/2019 (Thu) 08:31:25 Id: b9c229 No. 11246
>>11245 Nevermind, I'm sleepy and missed last part. .zip your archive to several parts and upload to Mega or something, maybe?
Anonymous 01/10/2019 (Thu) 08:43:18 Id: 9d7d6e No. 11247
(1.38 KB 670x24 taskmgr_2019-01-10_02-27-12.png)

(1.80 KB 626x17 taskmgr_2019-01-10_02-41-34.png)

white is a fresh restart on 334 blue is initial start up on 335 going to be interesting for me to see what has changed and what has not in the coming weeks as I abuse the fuck out of the program.
Anonymous 01/10/2019 (Thu) 13:03:54 Id: b9c229 No. 11249
>fresh restart >almost 3gb ram usage Just how many files do you have?
Anonymous 01/10/2019 (Thu) 16:13:03 Id: f2121b No. 11254
>Have an old Vista partition on-hand, for the sake of game compatibility >It somehow runs most programs designed for Win7 and up, sometimes without issue, sometimes with a little tinkering >Up to v334, as long as ffmpeg was manually replaced (using a v3.0 EXE), Hydrus was completely useable >As of v335, the client process immediately self-terminates, without error logs or even attempting to boot New releases of Python always ditch compatibility with an old Windows OS once the official "extended support" ends, so this was inevitable. Those of you still in the XP or Vista seats should change cars if you want to continue The Ride, and Win7 folks should be wary of Python updates when their "extended support" ends next January.
hydrus_dev Board Owner 01/10/2019 (Thu) 18:18:43 Id: d494fe No. 11255
>>11240 If you aren't having a giggle to give me a heart attack, can you describe more what your update process was here? Which OS and which build did you use? Did you see any errors?
hydrus_dev Board Owner 01/10/2019 (Thu) 18:26:34 Id: d494fe No. 11256
>>11241 There's no funny business in this release, and I have tried to make everything work properly, but this is a big step and something can always go wrong. Read the update process for your build in this release post carefully and follow the steps. If you are skeptical about the exe installer going right, you can always follow the steps for the extract release, which will also work. Don't delete your install_dir/db folder. Every week is a great time to start making a backup. I strongly recommend you buy a cheap 1-2TB external usb drive like a WD Passport (usually about $60, or cheaper second-hand from a friend) and set up a regular backup routine, as described here: https://hydrusnetwork.github.io/hydrus/help/getting_started_installing.html Losing a lot of shit due to hard drive fault or accident fucking sucks big time, and once you sort out a backup routine, you no longer worry about it.
hydrus_dev Board Owner 01/10/2019 (Thu) 18:28:45 Id: d494fe No. 11257
>>11247 Yeah, my client, which has ~1.3M files, now sits at a happy 500MB memory usage and 0.3% CPU idle, where before it was 850-1,500MB and ~2.5%. I am really pleased with the changes. If I understand right, py3 does some better stuff with the python/C++ interface, so they reduced a bunch of memory (and CPU scheduling) bloat.
hydrus_dev Board Owner 01/10/2019 (Thu) 18:37:46 Id: d494fe No. 11258
>>11254 Yeah, I am sorry about this. The new python relies on Visual Studio 2015 dlls, which I'll bet are just incompatible with <Win7. You'll have to keep on 334 unless/until you can a newer machine. There are no db changes this week, so you can roll back using the same extract only clean install instructions (or just to a backup). I had thought I had put this in the release post notes, but I think I only put it here: https://hydrusnetwork.github.io/hydrus/help/getting_started_installing.html That users with <Win10 may need Visual C++ Redistributable for Visual Studio 2015, as here: https://www.microsoft.com/en-us/download/details.aspx?id=48145 I didn't get a conclusive answer from my <Win10 test users here, but I didn't hear any problems either, so it may not be completely needed. I expect most people have it for vidya anyway. If this is a problem for 7/8/8.1 users, I may be able to fold the redist installer exe into my InnoSetup script, just like vidya would. Here's some more info on this, including the table of working compilers (WARNING: it is Microsoft versioning hell), in case you are a madman who wants to try to get this running from source on 3.4 or something: https://wiki.python.org/moin/WindowsCompilers
Anonymous 01/10/2019 (Thu) 19:22:11 Id: 75867a No. 11259
(4.29 KB 637x35 ClipboardImage.png)

(9.10 KB 313x180 ClipboardImage.png)

(27.28 KB 470x451 ClipboardImage.png)

>>11255 The first update run to 335 Pushed 'try to load last session' and got a freeze on startup. However the 2nd time I ran it and pushed load last session it went normally. I think that hes just messing with you, my database is fine. Will report back if anything changes, thanks for the work hope this is a better hydrus than ever.
Anonymous 01/10/2019 (Thu) 20:09:36 Id: 94949d No. 11260
Does't start on Windows 7 with 2015 libraries, no logs or console messages, just silently quits. Tried with clean install and install over the previous version. Starts on Windows 10 though. Will investigate further.
Anonymous 01/10/2019 (Thu) 23:31:17 Id: 77a872 No. 11261
>>11255 Windows 10, not sure what my old build was (it wasnt the most recent), and I used the normal installer. On boot I got the "looks like you're new" message and all the db/client_files folders are empty. Didn't get any error messages.
Anonymous 01/11/2019 (Fri) 00:34:47 Id: f29e19 No. 11263
(33.00 KB 597x203 Untitled.jpg)

>>11238 I think I asked this already, but would there be any hiccups if I deleted these old mappings archives? Obviously they're highly outdated. >>11261 Was your db folder in a different directory? I wouldn't think the installer would wipe all your files
Anonymous 01/11/2019 (Fri) 01:38:31 Id: 073269 No. 11265
>>11238 Thanks for the update dev! Everything seems to be working fine on my machine (win10), except that I can't change the ratings of my files anymore.
Anonymous 01/11/2019 (Fri) 01:50:02 Id: e78389 No. 11266
>>11256 I gained the balls to do it after your reply, and it worked (I just ran the installer on Windows 7). It even preserved my tabs and black theme, which I did not expect. I thought everything would be lost except the files and tags. I didn't read anything beforehand though, like a retard. Anyway yeah, not having a safety net sucks. It's pretty indefensible. Tbh I was kinda projecting in that post cause I've seen so many people just say "dude, backup", but for the many dozens of times I've seen it said in the wild, not one person ever provided any resources on how to do it. Yet everyone gives the people who get burnt shit for not having backed up. It's just really free to say out of context but that doesn't in itself save anyone. So thanks for the effort, actually. I appreciate it. And definitely, moving forward you need to have a backup… It should be part of the first step for everyone.
Anonymous 01/11/2019 (Fri) 03:10:07 Id: 77a872 No. 11267
(50.25 KB 926x531 Untitled.png)

>>11263 >Was your db folder in a different directory? I wouldn't think the installer would wipe all your files Nope, default directory. And it definitely overwrote them.
Anonymous 01/11/2019 (Fri) 03:28:27 Id: eb700c No. 11268
>>11267 Is this real? I'm glad I'm making a backup of my entire directory beforehand. If you didn't, then I'm terribly sorry.
Anonymous 01/11/2019 (Fri) 03:41:43 Id: 77a872 No. 11269
>>11268 I forgot I deleted my backup last week cuz I needed room. Didn't realize it til after the wipe…
Anonymous 01/11/2019 (Fri) 03:54:02 Id: f29e19 No. 11270
>>11267 Could you try previous versions/shadow copy?
Anonymous 01/11/2019 (Fri) 04:04:28 Id: eb700c No. 11271
(10.88 KB 468x445 screenshot.5.png)

>>11269 Ah, well if your best bet is to use a file recovery program and hope the .db's are still recoverable. On another note, I updated just fine.(Windows extract). As the other anon said, ratings seem to be broken.
Anonymous 01/11/2019 (Fri) 04:08:47 Id: eb700c No. 11272
>>11263 You don't need to keep them anymore if I recall. I deleted all mine and the tags were still intact, so I'm guessing it permanently adds the tags to your main db once you sync it once.
Anonymous 01/11/2019 (Fri) 04:44:37 Id: 77a872 No. 11274
(2.74 MB 640x360 6968ac102eea5bafd01e63c3a780a11daf8f42bac1162229042648d13e8a2bb9.webm)

>>11271 Good call on the recovery program, Recuva managed to salvage a surprising amount of stuff from scanning my backup location. Weirdly it doesn't find anything at all when I scan the Hydrus directory. If it didn't delete them, where did they go?
Anonymous 01/11/2019 (Fri) 06:01:46 Id: 44224f No. 11276
>>11274 Is this real life?
Anonymous 01/11/2019 (Fri) 11:34:52 Id: 009547 No. 11277
>>11238 Nice work! Thanks to the Python3 migration, I'm finally able to run client.py directly. If there are any Gentoo users here who want to do the same: You probably want "pip install –user wxpython" (takes a while to complete). The rest can be installed from portage.
Anonymous 01/11/2019 (Fri) 19:37:43 Id: c88222 No. 11279
>>11238 Importing a folder of files where some of the files are likely to be corrupt. UnicodeEncodeError 'charmap' codec can't encode character '\u014d' in position 95: character maps to <undefined> Traceback (most recent call last): File "include\HydrusFileHandling.py", line 333, in GetMime mime = HydrusVideoHandling.GetMime( path ) File "include\HydrusVideoHandling.py", line 227, in GetMime lines = GetFFMPEGInfoLines( path ) File "include\HydrusVideoHandling.py", line 117, in GetFFMPEGInfoLines info = proc.stderr.read() File "c:\python36\lib\encodings\cp1252.py", line 23, in decode UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 1646: character maps to <undefined> During handling of the above exception, another exception occurred: Traceback (most recent call last): File "include\HydrusData.py", line 835, in Print print( str( text ) ) File "include\HydrusLogger.py", line 130, in write self._log_file.write( message ) File "c:\python36\lib\encodings\cp1252.py", line 19, in encode UnicodeEncodeError: 'charmap' codec can't encode character '\u014d' in position 90: character maps to <undefined> During handling of the above exception, another exception occurred: Traceback (most recent call last): File "include\HydrusThreading.py", line 307, in run callable( *args, **kwargs ) File "include\ClientGUIDialogs.py", line 1083, in THREADParseImportablePaths mime = HydrusFileHandling.GetMime( path ) File "include\HydrusFileHandling.py", line 346, in GetMime HydrusData.Print( 'FFMPEG couldn\'t figure out the mime for: ' + path ) File "include\HydrusData.py", line 839, in Print print( repr( text ) ) File "include\HydrusLogger.py", line 130, in write self._log_file.write( message ) File "c:\python36\lib\encodings\cp1252.py", line 19, in encode UnicodeEncodeError: 'charmap' codec can't encode character '\u014d' in position 95: character maps to <undefined>
Anonymous 01/11/2019 (Fri) 20:31:43 Id: e78389 No. 11281
>>11279 Yeah, I think I just got this, but I posted it in the bugs thread on the catalog.
Anonymous 01/11/2019 (Fri) 22:43:48 Id: cc7fe9 No. 11282
>>11271 >>11265 I have the same rating problem as these anons. All rating values can only be set to the minimum value, or the maximum value, but nothing in between. Existing ratings are unaffected.
Anonymous 01/12/2019 (Sat) 02:15:31 Id: 9d7d6e No. 11283
>>11257 3.3 million files here, and currently little over 100k open due to massive file imports to clear up a hdd, going to probably get that down to around 20k open over the weekened if I have time/willpower to do it.
Anonymous 01/12/2019 (Sat) 03:50:05 Id: a4c1c6 No. 11284
Congratulations on the migration, hydrus.
Anonymous 01/12/2019 (Sat) 05:11:34 Id: b11e03 No. 11285
(73.68 KB 1354x728 34575474.jpg)

>>11238 Just updated to 335 using the Windows installer, Hydrus takes a really long time to start up for me now. It takes more than 6 minutes before I see the Hydrus logo. I think another issue I found was that I think the Sibling search function stop working, like Hyrus won't list any of my tags whenever I type something in the sibling window.
Anonymous 01/12/2019 (Sat) 11:28:12 Id: c0cfdf No. 11286
This error when clicking the "add tags based on filename" button in the import dialog, and then nothing happens
TypeError
'>' not supported between instances of 'str' and 'bytes'
File "include\ClientGUIDialogs.py", line 842, in EventTags
panel = ClientGUIImport.EditLocalImportFilenameTaggingPanel( dlg, self._current_paths )
File "include\ClientGUIImport.py", line 1509, in __init__
self._tag_repositories.AddPage( name, name, page )
File "include\ClientGUICommon.py", line 1818, in AddPage
if current_display_name > display_name:
Anonymous 01/12/2019 (Sat) 11:32:16 Id: c0cfdf No. 11287
>>11274 Those kind of programs can only salvage deleted files whose physical location on the disk hasn't been overwritten by something else. Most likely the disk where Hydrus is installed saw a lot of writing after the fact, possibly by the installer itself.
Anonymous 01/12/2019 (Sat) 12:29:35 Id: 68ae75 No. 11289
Everything works fine OS is arch linux and I'm running from source.
Anonymous 01/12/2019 (Sat) 13:03:06 Id: d647a7 No. 11290
I'm the linux user with Filter Tag Dialog issues. Still getting them in 335. Additionally, just now hydrus crashed on me when I attempted to open the subscription manager, after having had the filter tag dialog open some. Otherwise the update works nicely. Had expected more issues after such a large refactor.
Anonymous 01/12/2019 (Sat) 13:27:39 Id: d647a7 No. 11291
>>11290 Nope, I take it back. I'm getting a lot of: client: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0., even outside of the filter system. Basically, anything that can open a separate window now have a chance of crashing Hydrus, even the status reports in the lower left corner. I also got following error when just clicking around in a gallery:
The program 'client' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadPixmap (invalid Pixmap parameter)'.
(Details: serial 14451 error_code 4 request_code 139 minor_code 5)
Anonymous 01/12/2019 (Sat) 13:38:17 Id: 002c79 No. 11292
>>11291 Are you running tarball version or built it from source?
Anonymous 01/12/2019 (Sat) 14:54:01 Id: 002c79 No. 11294
Gentoo Linux, updated via git & built from source, everything works so far
hydrus_dev Board Owner 01/12/2019 (Sat) 18:51:31 Id: d494fe No. 11297
>>11267 >>11261 >>11269 >>11274 I am very sorry you have had this problem. I cannot explain it, and I hope you can recover as much as possible from your backup. It is stupid to ask, but just to be certain, is the install location correct and as you expected? It didn't change or typo for some reason? If you do a drive-level search for 'client.db', does that turn up a new unexpected location? And you never made a shortcut to launch the client with the -d switch? Also, is it possible that your install location became/stopped-being read-only? The newer version of hydrus will test if its install location is writeable, and if not, it will instead use ~/Hydrus (i.e. C:\Users\[You]\Hydrus). Is the screen at >>11267 at install_dir/db, and is there anything at ~/Hydrus?
hydrus_dev Board Owner 01/12/2019 (Sat) 19:01:08 Id: d494fe No. 11298
>>11260 Thank you for this report. Is there a crash.log or any .db files in install_dir/db? Is your Win7 an updated version, or does it not pull updates? Unfortunately, I don't have debug builds available, but how about server.exe in the install dir–does this run, or give you a better error? It should be runnable from the console, and print back to it.
hydrus_dev Board Owner 01/12/2019 (Sat) 19:03:32 Id: d494fe No. 11299
>>11263 Yeah, shouldn't be. As you probably know, the options for syncing those are unavailable and have been for a long time. The data record may still exist though. I would say try moving that folder somewhere and then boot the client and see if you can tag on the service(s) they were ever attached to. If it gives you an error, let me know and move the folder back, and I'll improve the error handling for next week.
hydrus_dev Board Owner 01/12/2019 (Sat) 19:05:20 Id: d494fe No. 11300
>>11265 >>11271 >>11282 Thank you for this report. I will have it fixed for next week.
hydrus_dev Board Owner 01/12/2019 (Sat) 19:08:08 Id: d494fe No. 11301
>>11266 I am glad it worked out. Let me know if you run into any trouble setting things up in future.
Anonymous 01/12/2019 (Sat) 19:10:49 Id: 5bcfb6 No. 11302
Damn, 335 is smooth. Updated from 332 and everything is smoother now.
hydrus_dev Board Owner 01/12/2019 (Sat) 19:14:18 Id: d494fe No. 11303
>>11274 >>11287 If it helps, a filename to look for, either in a different location or for undelete purposes, that would definitely be associated with the old install would be 'client - 2018-12.log', and maybe a bunch of earlier ones like 'client - 2018-6.log' and so on, depending on how long you have been using the software.
Anonymous 01/12/2019 (Sat) 19:41:29 Id: 77a872 No. 11304
(373.31 KB 600x408 d821a2ffaf5ec2d8a701f20f0b18afc3d48535c6a5e8152a0f6f524e6e1432f2.png)

>>11297 >Also, is it possible that your install location became/stopped-being read-only? The newer version of hydrus will test if its install location is writeable, and if not, it will instead use ~/Hydrus (i.e. C:\Users\[You]\Hydrus). Holy shit, my files are there! I just copied everything over and all seems ok. The logs go back to September, which is when I had a db issue, so whatever the problem was must have started then. I just checked, and the Hydrus directory is marked read-only. I don't know why it would be that way, but that may be the cause like you suggested. Thank you so much!
hydrus_dev Board Owner 01/12/2019 (Sat) 20:48:49 Id: d494fe No. 11305
>>11277 This is great, thanks for letting me know. Did you have to do anything special to get wxpython to compile right? I've had the biggest trouble getting the new versions going on Ubuntu. I get 40mins of compile and then a -1 error. Seemingly no matter how many gstreamer1.0-dev-bullshit packages I install. I end up just installing the wheel from their site.
hydrus_dev Board Owner 01/12/2019 (Sat) 20:55:33 Id: d494fe No. 11306
(61.22 KB 605x500 fuck.png)

>>11304 Great, that's fantastic, thanks for letting me know. I am glad we could figure this out. I am sorry for the confusion and stress here. I have a longer term plan to have better recognition of db locations. It would be nice in future if the client had a 'I think there's a db in your home dir m8' actionable label under the database menu or something.
hydrus_dev Board Owner 01/12/2019 (Sat) 21:10:01 Id: d494fe No. 11307
>>11281 >>11279 Thanks, yeah, I am getting a bit of this. I have to double-check how I am logging some shit. I thought py3 would be utf-8'ing the whole time, but I think the OS default CP1252 is overriding. I think I just need to tweak the various file open calls. Should be fixed in 336.
Anonymous 01/12/2019 (Sat) 21:13:52 Id: 009547 No. 11308
>>11305 >Did you have to do anything special to get wxpython to compile right? The pip way of installing it takes about 5 minutes on my Ryzen 2400G and works fine. I'm using pip install –user rather than Portage since WxPython 4.x.x isn't in Portage yet (there's an issue on Gentoo's bugzilla tracking a proposed version bump ebuild, but I didn't use that). > Seemingly no matter how many gstreamer1.0-dev-bullshit packages I install. I end up just installing the wheel from their site. If it's any consolation, Ubuntu / Ubuntu Server never worked out well for me either. It broke all the damn time, and the way of creating and/or patching packages there was rage-inducing when I tried it. I guess I'm going to try to compile the ebuild anyhow to see if I can provide any information.
hydrus_dev Board Owner 01/12/2019 (Sat) 21:14:23 Id: d494fe No. 11309
>>11284 Thanks m8. I am feeling better now we sorted >>11240 's problem. Really happy overall with the reports of better speed and so on. These various encoding bug reports are as I expected and should be clearable-up by 336. Keep on pushing through 2019!
hydrus_dev Board Owner 01/12/2019 (Sat) 21:29:41 Id: d494fe No. 11310
>>11285 Thank you for this report. Is that on Win7? When you start the program, can you watch client.exe's CPU and HDD during that preboot phase before the splash screen appears? Is it doing a lot of work, or idling a lot? Is there any chance an anti-virus program is checking the files being loaded in memory or something? The boot loader is a little different, so maybe it is triggering something the py2 one didn't. Also, are you running off an HDD or an SSD? If a HDD, is it defragged? If you hit file->restart, is it just as slow again (maybe with high CPU), or is it much faster (suggesting the program was then cached, and this is a hard disk issue)? That screenshot suggests your public tag repo doesn't have any siblings–can you go services->review services->remote->ptr? Do the numbers look good there, or does it think, say, that it hasn't processed any content yet? Does it have any tags at all? You can take another screenshot of it if you like.
hydrus_dev Board Owner 01/12/2019 (Sat) 22:12:32 Id: d494fe No. 11311
>>11286 Thank you for this report. I will have it fixed for 336.
hydrus_dev Board Owner 01/12/2019 (Sat) 22:15:09 Id: d494fe No. 11312
>>11290 >>11291 Thank you for this update. I am sorry the py3 didn't do it. I have some ideas on the tag dialog and archive/delete filter that I'll be working on in this and coming weeks. As >>11292 says, are you on source? I am sorry that I forgot if you were. Some Linux users get much better stability when they aren't trying to cross their OS flavour's with my Ubuntu's .so files.
hydrus_dev Board Owner 01/12/2019 (Sat) 22:17:28 Id: d494fe No. 11313
>>11308 Thanks, that's interesting. Don't worry about it too much though–the wheel here: https://extras.wxpython.org/wxPython4/extras/linux/gtk2/ubuntu-16.04/ Takes about 20s to install and works great for me. I'm just not experienced enough on the Linux side to figure out what wx wants.
Anonymous 01/12/2019 (Sat) 22:49:43 Id: 009547 No. 11314
>>11313 >Don't worry about it too much though No worries, doing just this is not much effort on Gentoo. Well, I compiled the wxpython 4.0.3 ebuild (with pypubsub rdepend commented out, don't need it) and of course uninstalled the version installed by pip. Took around 14 from extraction to install minutes with my current low-ish system load, works fine with Hydrus. The ebuild [it's simple, apart from the exact workings of the Gentoo helper functions] plus patches it applies (files/ subdirectory) is here: https://github.com/TheChymera/overlay/tree/master/dev-python/wxpython > I'm just not experienced enough on the Linux side to figure out what wx wants Maybe someone knows if you post the error. I don't think I'll be of much help without the ability to hands-on replicate the error [plus poor skills with Debian's / Ubuntu's package creation method].
Anonymous 01/13/2019 (Sun) 09:25:15 Id: b11e03 No. 11322
>>11310 >Is that on Win7? Yeah >When you start the program, can you watch client.exe's CPU and HDD during that preboot phase before the splash screen appears? Yeah I can see the client.exe. >Is it doing a lot of work, or idling a lot? It seems like its running fine I guess, I mean I can see the RAM usage in the processes tab in the task manager slowly going up from a little under 10k and climbing. nothing big or anything. It gets to around 70-80k before I see the Hrdrus logo and everything is running fine The CPU usage goes up and down from 01 to 00. It just seems like its running like a normal program to me before it starts. Its just that it takes a really long time before I see anything outside the task manager to show up. >Also, are you running off an HDD or an SSD? If a HDD, is it defragged? I'm using a 3TB external HDD(Don't know why I still use the install version on Hydrus on it). I just got it a few months ago and haven't bothered to defragged it yet. >If you hit file->restart, is it just as slow again (maybe with high CPU), or is it much faster (suggesting the program was then cached, and this is a hard disk issue)? Tried it and its doing the same thing. >Is there any chance an anti-virus program is checking the files being loaded in memory or something? I wasn't really sure since I use a free version of Kaspersky and never had a problem with it slowing down any of my programs. Just tried pausing my protection and suddenly it worked. So yeah its definitely my anti-virus program slowing down hydrus, fuck. This is like the 3rd time an anti-virus program has messed with any of my programs and having to hunt for a new one. >That screenshot suggests your public tag repo doesn't have any siblings–can you go services->review services->remote->ptr? >public Wait a minute, I think I got something mixed up here. My last pic wasn't meant to be my public tags, it was suppose to be my local tags. I think I got confused, usually when I right click on a tag to take me to my siblings/parents, it'll take me to my local tags. I think I got mixed up since it was the public tab that was shown first(This would explain a lot of things for me actually). So everything is fine really, I just needed to pay attention more.
Anonymous 01/13/2019 (Sun) 13:02:56 Id: 94949d No. 11325
>>11298 Resolved this issue by installing the latest Windows updates, it seems that one of them is required by some binary file.
Anonymous 01/13/2019 (Sun) 14:14:39 Id: 6915e2 No. 11326
(63.39 KB 474x421 proxy.duckduckgo.com.jpg)

>>11276 Or is this just fantasy?
Anonymous 01/13/2019 (Sun) 16:38:37 Id: 6915e2 No. 11327
(14.11 MB 477x512 Unbenannt.gif)

Also thanks to the hydrus dev for yet another version. You're a real trooper, a big guy so to say.
hydrus_dev Board Owner 01/13/2019 (Sun) 23:26:22 Id: d494fe No. 11334
>>11322 Great, thanks for letting me know. Maybe you can tell Kaspersky to ignore or treat the hydrus exe/install folder a little differently? Turn off 'active' protection or something so it isn't scanning every time it runs? >>11325 Great, thanks to you as well for letting me know! >>11327 UUUU Also, in this update, getting OS X PyInstaller to make a Framework-compatible Python 3 exe and app was, at times,extremely painful.
hydrus_dev Board Owner 01/13/2019 (Sun) 23:30:38 Id: d494fe No. 11335
>>11328 Thank you, these are excellent. I also get problems with them. I will check them this week and see if I can improve the file parsing.
Anonymous 01/15/2019 (Tue) 08:37:11 Id: b11e03 No. 11345
>>11334 >Great, thanks for letting me know. Maybe you can tell Kaspersky to ignore or treat the hydrus exe/install folder a little differently? Turn off 'active' protection or something so it isn't scanning every time it runs? Just letting you know I whitelisted Hydrus and it works, thanks.
hydrus_dev Board Owner 01/15/2019 (Tue) 19:49:58 Id: d494fe No. 11348
>>11334 >>11328 Hey, on closer inspection, these were giving me 18KB 'webm' files that were actually some kind of CloudFlare html saying 'we think you are a bot, please solve this captcha'. Once I solved that in my browser, they worked mostly ok in the current dev version (which admittedly now has some unrelated ffmpeg fixes). The /trash/ ones are now 404, but https://i.4cdn.org/gif/1547302893499.webm is giving me a resolution problem that I think I can fix today. I think part of this problem is the result of the cloudflare-4chan setup giving the wrong http header to say the file was 'webm' when it was really an html interstitial. The other half is that hydrus has no capability to solve these sorts of captchas. I have never encountered this CF page before on a content fetch, and if it is going to be a new 4chan thing, that's a shame. Let's hope it is a temporary thing that was a misconfiguration or an accidental statistical spike on that set of files due to some mis-aimed DDoS or something. Please let me know if you encounter more of this.
Anonymous 01/16/2019 (Wed) 04:19:12 Id: 9d7d6e No. 11351
(2.48 KB 1071x24 client_2019-01-15_22-14-49.png)

>>11348 just solved the captcha… no fucking clue why it did it for that one alone, or why it didn't give me the captcha but yea, now im getting this error with bringing it into hydrus. that said, there has been some with captchas, there is an I believe open source project that can solve captchas without user interaction. it feeds the audio solution into google, and google spits out a solution and its 80-90% effective. I know with fur afinity the issue is captcha, would it be possible to implement that into the program? google apparently already knows about the issue, but the captcha team more or less said, nothing we can do.
hydrus_dev Board Owner 01/16/2019 (Wed) 22:42:02 Id: d494fe No. 11354
>>11351 Thanks. I'd like to add captcha support, but diving back into the downloader code after all the work I did last year is not my top priority right now. It would be a lot of work, whether I would present login/download captchas to the user in the ui or try to solve them automatically. Current plan is to do it for the next big iteration on the downloader, whenever that will be. If 4chan or other sites start getting this CF captcha shit a lot, I'll bump it up the schedule, maybe as a hardcoded fix that recognises that CF page specifically. It is strange that both you and I got the same captcha issue, since I hadn't looked at that content/threads on my own machine/IP previously. That suggests to me the data source was the flagged problem, not the specific client, hence my DDoS-false-positive-on-that-thread suspicion. Again, we'll see if that starts happening more often.
Anonymous 01/16/2019 (Wed) 23:10:12 Id: 9d7d6e No. 11356
>>11354 Thing is, I saw it fail, checked it, and was able to download it outside of client, then when you told me about the captcha and I checked It I got the captcha too. No idea what what the hell was going on with that one.
Index Catalog Archive Top Reply
1
Forms
Delete
Report
Quick Reply