[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]

/hydrus/ - Hydrus Network

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

Catalog

Name
Email
Subject
Comment *
File
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Options
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.

New user? Start here ---> http://hydrusnetwork.github.io/hydrus/

Currently prioritising: simple IPFS plugin

 No.2277

Hello,

first of all: neat program! :) Really like the features. I've been looking for a suitable application for collecting stuff such as memes and artwork forever. I'll probably also use it for my No Man's Sky screenshots when it's finally out. I'm expecting to take a shit ton and to tag them with all the relevant data like planet name, available resources, creatures etc. so I can look it up later if needed or just for the memories - since we don't really know how much the ingame encyclopedia will track.

Anyway, I've connected the hydrus network client to the remote tag repository and updated all the way. I've then imported just a single folder of 40 quite popular images (ranging from around 500kb to 5mb) to see if the auto-tagging is working. Works like a charm. All the picturs are sitting at around 50 tags each now.

One question though: is it normal that loading the images via system:everything takes around 20 seconds (used my phone timer to measure)? Remember, I do only have 40 pictures in the database (and all the tag mappings from the repo, but coming from a dev background myself I'd think think they'd be ignored in the query when using system:everything). Using the title:xyz tag to limit the result set to a single image also takes around 17 seconds. Normal?

I'm sitting behind a fairly powerful gaming pc that's also kept very clean and has no performance issues in any other application. Relevant specs: i5 4690k, 32 gb ddr3 2400mhz, 1tb samsung 850 pro series ssd (yes, my only drive, I only care for the performance and don't need that much space anyway :P). I guess my gtx 980 ti won't matter much in this case. :D

I've already tried vacuuming the db. Any suggestions or feedback?

—

Second question: I'm also using a macbook pro with a high-dpi display I'd also like to run the client on (probably syncing the db between the two devices). It seems the client doesn't support the doubled resolution of its so-called retina display (it has a 2880x1800 resolution but is basically rendering it as it would a 1440x900.

using the quadrupled pixels for extra sharpness), so everything looks quite pixelated. Doesn't matter in the application but this unfortunately also applies to images. I guess there's no easy way to fix that (maybe a limitation of the python gui renderer used)?

 No.2279

Soo… I've been playing around with my resolution problem on the macbook for a bit and adding the following to the Info.plist of the application seems to at least partially fix it (most of the text is fine, images seem to look good too):

<key>NSHighResolutionCapable</key>

<string>True</string>


 No.2287

File: 1458419541395.jpg (96.03 KB, 800x480, 5:3, 4c99bba97268688f1dc356ca69….jpg)

>>2279

I would expect your results to appear very quickly, certainly in less than a second, so something odd is definitely going on. I've written a page on this in general:

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

But in your case, you just vacuumed and you don't need to defrag, so that's the two usual culprits gone. If you like, try generating some db profiles of the system:everything search, as described right at the bottom of that page. That should help us see what is lagging so much.

>>2277

>>2279

I hate this DPI scaling stuff. I think I remember that Win 10 was doing it for someone a while ago, and he ended up running it in some compatibility mode or something. Thank you for finding that NSHighResolutionCapable variable–I will include it in future OS X releases' plist file.


 No.2291

Thanks for the suggestion of creating some db profiles. However, I did a clean reinstal of v197 l (I also deleted the DB) and that seemed to fix it. Like you said, images now load in less than a second (probably more like 100ms).

I remember that I had a few Internet disconnects when I first synced with the repository (having some problems with my router lately, it sometimes crashes when I'm downloading with combined speeds > 100 Mbit/s). Could that have created some issues in the database (e.g., corrupt tables) that would have caused it to slow down that heavily?

Anyway, thanks again for your help. I'll probably use the OS X client quite extensively (since I won't be home at my PC all the time due to work reasons) so if you need any help with checking for bugs or optimizing stuff (like the DPI scaling) I'd be happy to help. :)


 No.2300

>>2287

Well, I think I spoke too soon. I have now experienced the same problem I had on my PC on OS X too. The scenario:

- Fresh Installation

- Complete sync with the repo (in the client)

- No local tags

- Import of a single image (821KB png, 68 tags in the repo)

- Vacuumed the db

- "system:everything"

This takes around 30 seconds before the loading is finished and the image is rendered. The macbook is not as powerful as my PC, but still quite the machine (2.5GHz i7, 16GB RAM, 512GB SSD). Running on the latest OS X 10.11.3. Something definitely seems fishy here.

Here the relevant part from the log I created: http://pastebin.com/6VYDvUAE

Kind of weird to me that most of the stuff shows up as taking up no time at all (0.000), but you can clearly see the one call taking over 27 seconds.

Hope you can help. :(

P.S.: Performance was fine with several hundred files before syncing to the tag repository. Since I did report that performance on PC was fine after reinstalling, I guess it may be because I didn't sync to the repository after the reinstall because I didn't find the time to do so. What I also noticed: everything seems slow in general. Opening the "manage tags" window for the image takes around a minute.


 No.2301

>>2287

And, since I thought it might be useful for finding the error, also a log for opening the manage tags window (which takes around a minute as I already mentioned): http://pastebin.com/tik35T4u

This one's a lot longer since there are more entries with actual time values and I didn't want to leave anything out.


 No.2306

File: 1458670341559.jpg (533.17 KB, 1964x1538, 982:769, 9ad701a527740bffb2b7e7136d….jpg)

>>2291

>>2300

>>2301

Thank you for these profiles. I repeated them on my dev machine and discovered something similar, although not pronounced enough for me to previously notice, and found it was all due to a single very inefficient line of sql–the bit that fetches raw tag ids for files. I can't remember it being a problem before, and I don't really understand why it is running so slow now (sqlite's query optimiser reports to have no problem with it), but tweaking the way it takes its parameters somehow reduces its time from 2.5 seconds to about 9ms!

This fix will be in tomorrow's release. Please give it a go sometime and let me know if your problem is any better.


 No.2309

>>2306

Thanks, sounds good. I'll try the update as soon as it's available. :)



[Return][Go to top][Catalog][Post a Reply]
Delete Post [ ]
[]
[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]