hydrus hanging

Name
Email
Subject
Comment *
File	Select/drop/paste files here
* = required field	[▶ Show post options & limits] Confused? See the FAQ.

Embed	(replaces files and can be used instead)
Options	Do not bump (you can also write sage in the email field) Spoiler images (this replaces the thumbnails of your images with question marks)
Password	(For file and post deletion.)
Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf Max filesize is 8 MB. Max image dimensions are 10000 x 10000. You may upload 5 per post.

File: 1453603934580.png (12.24 KB, 385x403, 385:403, hydrus error.png)

hydrus hanging Anonymous 01/24/16 (Sun) 02:52:14 No.1878

New user here, went all in with my stuff 2 nights ago and now having issues. can't access any files at all but database and files report as OK.Client has never closed cleanly since install. always hangs on "waiting for daemons to exit".

Any advice? Thanks in advance!

Anonymous 01/24/16 (Sun) 03:09:28 No.1879

How full is your hard drive, exactly?

Anonymous 01/24/16 (Sun) 03:14:13 No.1880

The drive hydrus is installed and stores to has some 300GB+ free. The system drive is skirting the red with nothing but a windows install and appdata (64GB SSD)

Anonymous 01/24/16 (Sun) 03:26:44 No.1881

In addition, typing in the tag field causes it to crash.

Anonymous 01/24/16 (Sun) 18:41:20 No.1884

>>1881

>>1880

Would by any chance your /temp/ folder be located on that almost entirely full SSD?

Anonymous 01/24/16 (Sun) 21:54:11 No.1885

>>1884

Thanks, but I can assure you this is absolutely not the case. Since last night and with a little more patience than I was previously granting, I can still access some files. However, large tags never finish loading, imports are taking hours instead of minutes or seconds, and the 'db locked' marker is ever present.

Anonymous 01/24/16 (Sun) 21:56:43 No.1886

(I have also managed to clear a bunch of space with no improvement, unfortunately.)

bob 01/27/16 (Wed) 08:58:24 No.1899

>>1886

First thing I would do is make a backup of your Hydrus in case something becomes corrupted. You generally won't lose your photos, but you could lose your tags/synced repository.

The reason why everything has slowed down is because (potentially) nothing is being optimized now that the vaccum database has been disabled. Have you tried doing database > maintenance > check database integrity?

If you haven't imported too many files, I would consider starting with a fresh Hydrus because you might have inadvertently screwed up something (I screwed up my database twice when I first started). Your can still access your hashed files in db > client_files. You'll lose any tags you manually added unless you want to mess with the database.

If that doesn't help, you'll probably have to wait for the developer to respond to your message (and he'll probably request some debug logs).

hydrus_dev ## Board Owner 02/02/16 (Tue) 21:35:07 No.1957

File: 1454448907931.jpg (194.16 KB, 1000x681, 1000:681, ed85edb4671fd5447fd58c96a3….jpg)

Several people have got this disk full error recently. When SQLite runs a VACUUM, it writes a couple of copies of client.db, one in your temp dir (%appdata%/local/temp for me), and another next door to client.db, at client.db-journal. For people synced to my PTR, client.db is about 3GB, so if you have less than 3GB free on your system drive or hydrus install dir, you get this error. I have written a little text file in install_dir/db about it, and I will now update the popup error message now we better understand what causes this.

If you cannot free up a few gigs on your system drive, you can leave vacuuming disabled. Vacuuming is basically db defrag–it is not very important, but nice to run every now and then.

I am thinking of breaking up client.db into smaller dbs in the coming month or so, which will alleviate this problem (and several others, hopefully!).

If you client is running slow, please check out this page:

http://hydrusnetwork.github.io/hydrus/help/reducing_lag.html

Now I think about it, if vacuum is already disabled but your client still isn't closing cleanly, then something else might be going on as well. Please check install_dir/logs/client.db and scroll to the bottom. Are there any database errors, likely after a 'shutting down gui' line?