Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Got a ploblem with Valheim #92

Closed
kieeps opened this issue Sep 18, 2021 · 4 comments
Closed

Got a ploblem with Valheim #92

kieeps opened this issue Sep 18, 2021 · 4 comments

Comments

@kieeps
Copy link
Contributor

kieeps commented Sep 18, 2021

I haven't tried much else then Minecraft and Valheim, but for some reason i have to run docker exec --user amp amp-linux ampinstmgr --nocache upgradeall after every time i restart the container or the Valheim instances wont start. would it be possible to have the instance upgraded on container start?

It already updates everything else :)

@kieeps
Copy link
Contributor Author

kieeps commented Sep 18, 2021

wait.... i just checked main.sh and it seems to already do just that:

# Upgrade instances
echo "Upgrading Instances..."
su ${APP_USER} --command "ampinstmgr UpgradeAll" | grep --line-buffered -v -E '\[[-#]+\]'

maby just add the --nocache tag then?

EDIT: PR up

@MitchTalmadge
Copy link
Owner

Thank you, I think this was caused by CubeCoders releasing a patch under the same version number as the original release, which my continuous deployment scripts cannot detect. I've started a release of v18 which should hopefully solve this.

Adding nocache breaks the way this repository works, since I bundle the CubeCoder update file with the container image, and I rely on the cache mechanism to apply the update. I had nocache in the past and it resulted in an update being applied every single time the container was restarted which was very slow due to how CubeCoders limits download speeds.

@kieeps
Copy link
Contributor Author

kieeps commented Sep 23, 2021

I see, yeah that would slow things down for sure :-)

Not sure how often this issue would appear, many it was one weird one time thing since releasing an update with the same version number seems like a human error :-D do they expose the md5/CRC on the update files somewhere?

EDIT: v18 did fix this problem

@kieeps kieeps mentioned this issue Oct 11, 2021
@MitchTalmadge
Copy link
Owner

MitchTalmadge commented Nov 9, 2021

I see, yeah that would slow things down for sure :-)

Not sure how often this issue would appear, many it was one weird one time thing since releasing an update with the same version number seems like a human error :-D do they expose the md5/CRC on the update files somewhere?

EDIT: v18 did fix this problem

Thanks for the suggestion! I found out that they expose a last-modified header on the update file, so I was able to bake that into the auto update workflow here on GitHub. Now this shouldn't happen again :)

Glad to hear it's fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants