ebkr
[BUG] - It seems like R2/TS is starting to get REALLY slow with keeping posted on new mods or mod updates.
Describe the bug Whenever a new mod is released on TS/R2, or whenever a mod is updated, it seems to take the manager a full DAY before it finally realizes this. New mods don't show up in the "Online" tab, and current mods that have received updates won't let me update to the newest version (if I go to the "Online" tab and install a mod, it says that the previous version is actually the latest version, and doesn't give the option for the latest version).
I can't even do it manually on the site, when I go to click the "Install" buttons on the website, R2 gives me an error saying that the "mod does not exist", both for new mods and mods that need updating, because it was "unable to resolve [Mod_Name_Here] to a suitable Thunderstore mod". It's only the following evening that things then decide to show up.
And yes, I have restarted the program and also rebooted the PC. My internet is fine as well, I get 400 MBPS download via ethernet.
To Reproduce Steps to reproduce the behavior:
- I think this is pretty self-explanatory.
Expected behavior I expected to go the "Online" tab and see that a new mod has been posted, or on the "Installed" tab that I have "X" new mod updates. Neither are seen.
So uh... update.
If I manually import an updated mod via the settings
It says "You have 1 new available mod update"
And it's wanting me to downdate from my locally-imported mod
Still happens in 2024, it's absolutely horrendous even with a Modpack for Lethal Company that's extremely tiny in filesize as it's just a manifest. Ended up just deleting the modpack entirely, sharing profile codes with my friends would be way faster :/
This is likely due to an increase in the cache refresh time - Probably because of the influx of users due to LC.
The refresh is polled every 5 minutes and has been that way for a very very long time.
@MythicManiac can confirm if this is the case.
Still happens in 2024, it's absolutely horrendous even with a Modpack for Lethal Company that's extremely tiny in filesize as it's just a manifest. Ended up just deleting the modpack entirely, sharing profile codes with my friends would be way faster :/
This is considered the right way to share mod setups for what it's worth.
As for cache refresh times, nothing has changed on that front on our end at least intentionally, but I suspect there might be several tiers of different caching mechanisms that in worst case scenarios can lead to quite long refresh times. It's not ideal but it's not also an issue that's been considered high priority.
All that aside, we need to update the integration architecture just due to the sheer size of the API index on some larger communities, as it's already causing issues on slower connections. I don't know what exactly will it look like yet, but chances are it'll be able to receive updates much faster.
Is it possible to get this service to work with mirror download links, like github releases/direct downloads, so mod authors don't have to deal with the cache by hosting the mods themselves? Or is there a concern with that method?
This isn't about the download links, this is about the index of known packages. Download links work immediately after upload, the mod manager just doesn't know the package has been published before it's included in the index.
So to be clear, this is the index the mod manager relies on to know what packages exist: https://thunderstore.io/c/lethal-company/api/v1/package/ (this might not render in the browser at all given how large it is)
So mirror download links don't help with the update delay even if they were supported, but there are reasons they aren't supported. Download mirrors will be supported in the future (in fact we already have one, the configuration is just not exposed) but it's not as simple as just supporting arbitrary HTTP links (which would bring various issues to the ecosystem)
The integration architecture update I mentioned earlier is really about changing the data model we use for building & synchronizing the package index. The current solution is simple and works well if updates are rare, but for frequent updates there are better (and more complex) ways to implement the synchronization.