/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.
(58.08 KB 309x366 06e65cedbc0cd2d91f1edc786c8d4e9ca18f3b421518b97fdf205ede4719ca91.gif)

Python 3 Update Progress 2 hydrus_dev 12/25/2018 (Tue) 16:37:52 Id: 789e34 No. 11098
𝕸𝖊𝖗𝖗𝖞 𝕮𝖍𝖗𝖎𝖘𝖙𝖒𝖆𝖘! I had another good week. The client works about 95%, and I can get it into a proper executable release that runs fine. I now need to iron out the last issues and sort out Linux and OS X environments. I feel great about the schedule. I am still aiming for a Jan 9th release for v335.
Anonymous 12/26/2018 (Wed) 08:39:05 Id: 21d4b0 No. 11099
Merry Christmas hydrusdev.
/inth/ nBo 12/26/2018 (Wed) 09:28:17 Id: 80dbf4 No. 11100
>>11099 merry xmas
Anonymous 12/26/2018 (Wed) 09:28:38 Id: 80dbf4 No. 11101
>>11100 shill
Anonymous 12/26/2018 (Wed) 09:28:56 Id: 80dbf4 No. 11102
>>11101 merry christmas
Anonymous 12/26/2018 (Wed) 09:29:25 Id: 80dbf4 No. 11103
>>11100 who dat?
Anonymous 12/26/2018 (Wed) 09:29:36 Id: 80dbf4 No. 11104
>>11103 a shill
Anonymous 12/26/2018 (Wed) 09:29:43 Id: 80dbf4 No. 11105
>>11104
Anonymous 12/26/2018 (Wed) 09:29:49 Id: 80dbf4 No. 11106
>>11105
Anonymous 12/26/2018 (Wed) 09:29:55 Id: 80dbf4 No. 11107
>>11106
Anonymous 12/26/2018 (Wed) 09:30:22 Id: 80dbf4 No. 11108
>>11105 >>11106 >>11107 speaking of shills…
Anonymous 12/26/2018 (Wed) 09:30:36 Id: 80dbf4 No. 11109
>>11108 fuck off josh
Anonymous 12/26/2018 (Wed) 09:30:45 Id: 80dbf4 No. 11110
>>11109 wew
Anonymous 12/26/2018 (Wed) 10:00:51 Id: 447af2 No. 11112
>>11110 we have IDs here cowshitter
Anonymous 12/26/2018 (Wed) 11:20:35 Id: cbbb81 No. 11113
>>10944 Finally this happened again. Hydrus had to run a pretty big maintenance job at exit, and once it was done it's just stuck there in the task manager as client.exe. I noticed about two and a half hours after I exited the program. There are no .db-shm and .db-wal siblings in the db folder, and it's not using CPU/HDD. However, once I started writing this, it actually did shut down. Since I only caught this just before it shut down my notes about the .db file siblings and CPU/HDD usage might not be accurate. Here's the log, notice the 2 hour gap…
2018/12/26 09:15:06: hydrus client started
2018/12/26 09:15:06: booting controller…
2018/12/26 09:15:06: booting db…
2018/12/26 09:15:06: preparing disk cache
2018/12/26 09:15:10: preparing db caches
2018/12/26 09:15:10: booting db…
2018/12/26 09:15:10: initialising managers
2018/12/26 09:15:17: booting gui…
2018/12/26 09:15:21: Import folder cosplay imported 6 files.
2018/12/26 09:18:51: shutting down gui…
2018/12/26 09:18:51: waiting for daemons to exit
2018/12/26 09:18:53: vacuuming main
2018/12/26 09:18:53: Vacuumed Y:\db\client.db in 176 milliseconds
2018/12/26 09:18:53: Could not vacuum Y:\db\client.mappings.db (probably due to limited disk space on db or system drive).
2018/12/26 09:18:53: vacuuming external_master
2018/12/26 09:20:04: Vacuumed Y:\db\client.master.db in 1 minute 10 seconds
2018/12/26 09:20:04: vacuuming external_caches
2018/12/26 09:20:06: Vacuumed Y:\db\client.caches.db in 2.2 seconds
2018/12/26 09:20:06: database maintenance - analyzing

done!
2018/12/26 09:20:06: public tag repository sync: processing updates
2018/12/26 09:20:06: analyzing specific_deleted_mappings_cache_1_3
2018/12/26 09:20:06: analyzing specific_deleted_mappings_cache_9_3
2018/12/26 09:20:06: analyzing deleted_mappings_3
2018/12/26 09:20:06: fattening service info
2018/12/26 09:21:07: processed 1172848 definitions at 21831 rows/s
2018/12/26 09:30:02: processed 7445542 content rows at 13909 rows/s
2018/12/26 09:30:47: shutting down db…
2018/12/26 09:30:48: cleaning up…
2018/12/26 09:30:48:
2018/12/26 12:08:51: shutting down controller…
2018/12/26 12:08:51: hydrus client shut down
Anonymous 12/26/2018 (Wed) 11:43:56 Id: 61fb53 No. 11114
(2.44 MB 2480x3507 5bca7f91c4c2c29f811ce34f21b96f772160504ab66adf6642e04fbab025c968.jpg)

>>11098 Merry Christmas and thanks for a great year with Hydrus!
Anonymous 12/26/2018 (Wed) 12:44:58 Id: b3608f No. 11115
(927.84 KB 467x467 1414982275812.gif)

>>11098 Merry christmas.
hydrus_dev Board Owner 01/01/2019 (Tue) 21:44:36 Id: 789e34 No. 11148
>>11113 Thank you for this follow-up. Since the db does seem fully shut down and disconnected, my best guess here is that one of the daemon threads (which do maintenance stuff in the background) isn't waking up to receive the 'program shutdown' signal properly. In this case, the process will hang on, with that one thread asleep, until it wakes according to its natural check period (which are typically on the order of hours). I will check this code. It may also magically fix in py3 due to the different way some thread signalling works as well, so please let me know if this improves/worsens after v335. In this case, as the db is completely closed, there is no danger in just killing the process in task manager when this happens again.
Index Catalog Archive Top Reply
1
Forms
Delete
Report
Quick Reply