- Mar 24, 2021
- 195
- 211
I struggle with point 3 and 4 of these instructions. How do i get the zip? The artifacts don't do anything
- Mar 7, 2019
- 1,318
- 1,121
- Oct 1, 2020
- 1,303
- 885
Oh right, thanks! Totally missed that part of the discussion.Search is your friend
- May 20, 2024
- 151
- 169
the game The Lust City doesn’t update its status to 'completed' in F95Checker. I did a full refresh and a full recheck of the game itself.
- Aug 8, 2020
- 429
- 1,163
i'll install soon and check it out. It always did seem to lose the sort and go ascending alphabetical after playing around with paths, labels, and moving between tabs but I couldn't pin it down exactly. Thanks!rentalunshipped982 BrockLanders blackop simple_human FaceCrap
so, if this doesnt fix the sorting / filtering bug, idk what will.
i think i understand what is happening: gui thread checks recalculate_ids, if true it sets to false and starts filtering and sorting; however, it is possible that between executing the line that reads the value and the very next one that sets it to false, something else changes the value, and it gets lost. race condition basically. ive changed it to where setting recalculate_ids needs to acquire a lock (aka a mutex), so that while the gui reads the value and sets it to false, if something else is trying to set it to true it has to wait, and this new true will be picked up next frame and sorted again.
if this still doesnt fix it, i have a last resort of putting the *whole* recalculating logic inside the mutex, not only the flag telling it to recalculate_ids.
let me know if you find the sort bug again on build 1301. also, if nothing else pops up, id say this is basically ready for release, consider it a RC1
- Mar 7, 2019
- 1,318
- 1,121
Turns out he problem is deeper, not gonna be able to fix it anytime soon. There's some memory corruption happening inside pyimgui
- Mar 7, 2019
- 1,318
- 1,121
Updates are not gathered by your tool anymore, they are collected and cached by an api. If the data in the api is outdated, no amount of refreshing on your side will update it, it will update when it updates. Cache invalidation can take up to 1 week, except for actual updates where the version changes, which will be detected usually within 5 minutes, or at worst within 12 hours.
Before you ask, no, this will not change and it cannot change, we cannot continue how it worked before. Just be patient, does it really matter if it takes a few extra days to show "completed"? You're not missing any content
- Mar 7, 2019
- 1,318
- 1,121
That said M0narh , I have just come up with an idea to mitigate this. Currently I'm polling the latest updates api every 5 minutes for the most recent 90 entries (max allowed per request), comparing versions, and invalidating cache for versions that changed. This means, if an update happens, version changes, my api picks it up, someone refreshes and it caches the new version, and only after this the completed status is applied, my cache api won't notice this last change. What I can do is also use the extra metadata in the latest updates api response such as creator name, tags, prefixes and other stuff, hash this data and store it in cache, so next time it checks latest updates in 5 minutes and like that until it's no longer in the latest 90 updates, it will compare both the version string and the hashed metadata, so it can invalidate cache even when prefixes like completed, or tags or creator name, change. Still, this is not bulletproof, it's just an additional to what I already do with monitoring latest updates, so if the thread that changes is not in latest updates, this change will not be noticed until at most 7 days later when cache invalidates due to time. What I mentioned about 12 hours is that at this interval I also compare versions for *all* cached thread data with Sam's version api, which however only provides version information, so this will not be applicable to the metadata hash that would mitigate these extra things not being noticed, that's why it's not bulletproof. And I mean, even the versions every 12 hours aren't bulletproof, as some games aren't tracked by latest updates so they do not have a version assigned in this version api, but point is trying to make it as efficient and reliable as possible, without bombarding the forums with constant requests. By this point I would say 95% of things are picked up within 5 minutes by latest updates watcher, 3% within 12 hours by the version sanity check, 1% within 2 days if the version is not tracked in version api, and 1% within 7 days for small metadata changes to games tracked by version api
EDIT: just implemented this
Last edited:
- Mar 7, 2019
- 1,318
- 1,121
It depends, it tries to look for the version specified in the thread, if that's not detected it uses the OP edited date
Using Beta 1313 I'm getting "The F95Checker API returned error 'F95ZONE_UNAVAILABLE' when trying to refresh any new added thread. I assume this usually indicates that F95Zone is down, but since I am posting this it is not.
Last edited:
- Mar 7, 2019
- 1,318
- 1,121
It's been having a few issues over the past hour, there's a few messages in the logs about it. Nothing to do about it, just because you can access it doesn't mean everyone can. It could very well be intermittent issues and it just happened to the cache api in that precise moment. When something like this happens, my cache api saves the error and schedules a retry in 15 minutes. If you try now it probably works
Gotcha, was just posting to make sure that there wasn't any underlying issues! Thanks for checking
- Aug 8, 2020
- 429
- 1,163
That explains it, I came to report that I marked a novel in stored in a separate tab as finished in its checkbox and the few games in the tab sorted themselves from Z-A! I bet a flag is ticking that isn't supposed to, like you said. Cheers!
- Mar 7, 2019
- 1,318
- 1,121
just fixed this in latest beta. turns out, i already had the logic there, but it was flawed. it was skipping downloading the new image when url changes, but it was replacing the "custom" url text (just a marker to indicate its not a image from the forum) with the intended image url, so at the next update it noticed the new url and downloads it, because it forgot that it was custom. now, it will not remember the new image url if you have a custom image, so even at next update it will keep the custom image. you might experience this situation for a few more times, since maybe you have some custom images on disk that are not marked "custom" in the game info of the database. but new situations will not arise from now on if you update