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.
____________________________
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
21d4b0 No.11099
Merry Christmas hydrusdev.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11100
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11101
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11102
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11103
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11104
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11105
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11106
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11107
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11108
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11109
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
80dbf4 No.11110
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
447af2 No.11112
>>11110
we have IDs here cowshitter
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
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
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
61fb53 No.11114
>>11098
Merry Christmas and thanks for a great year with Hydrus!
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
b3608f No.11115
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
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.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
