mirror of
https://github.com/OpenEPaperLink/OpenEPaperLink.git
synced 2026-03-21 00:04:28 +01:00
[GH-ISSUE #503] Epaperlink update to 2.82 does not update filesystem #2529
Assignees
sascha_hemi
Clear assignees
sascha_hemi
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/OpenEPaperLink#2529
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jum0n on GitHub (Sep 14, 2025).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/503
Describe the bug
Filesystem shows 2.81 instead of 2.82 when doing full update and also if individual update
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Filesystem should update to version 2.82
Screenshots
current env: ESP32_S3_16_8_YELLOW_AP
build date: 2025-09-12 11:39
esp32 version: 2.82
filesystem version: 2.81
psram size: 8383655
flash size: 16777216
ESP32-C6 version: 0019
Additional context
Add any other context about the problem here.
@kvandt commented on GitHub (Sep 16, 2025):
Can confirm. Same her on Mini AP V4.
@jurasjo commented on GitHub (Sep 17, 2025):
Have you cleared the cache in the browser?
@kvandt commented on GitHub (Sep 17, 2025):
Yes, did multiple times. The ESP32 version was correct in the overview after updating. But strangely enough it is now correct after several power cycles of the AP. Must be some caching issue somewhere.
@saschaludwig commented on GitHub (Sep 18, 2025):
That is definitely a browser issue, I have the same issue that the fs version shows 2.81 in my default browser.
In another browser that has never seen the AP, the fs version is displayed correctly.
In my default browser, an incognito window does also show the correct version 2.82.
I fixed this with removing tag_db and tag_types from the browser's local store without rebooting the AP.
As far as I can see, the value gets either cached from
/version.txtor/sysinfoso force reloading those URLs could also fix the "issue".@jum0n commented on GitHub (Oct 3, 2025):
Sorry for delayed reply but now that I check, mine displays the correct version as well with no action from me. As stated, probably cached and then expired.