mirror of
https://github.com/OpenEPaperLink/OpenEPaperLink.git
synced 2026-03-21 00:04:28 +01:00
[GH-ISSUE #94] free space aware behaviour #3359
Assignees
sascha_hemi
Clear assignees
sascha_hemi
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/OpenEPaperLink#3359
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 @coelner on GitHub (Jul 26, 2023).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/94
Describe the bug
the AP is configured not to generate preview images. This saves a lot of space, because I can handle more tags without storing the current image.
the problem is that if the current date is chosen, it will be generated at midnight, but for all tags on the same time. Because there are no checks for free space, it will skip a lot of tags, because empty images are created. You need to delete those empty files manually and re-trigger the current date for each tag separately. While you doing it manually, the whole process is slow enough to generate-deliver-delete successfully. Well, at least until midnight.
To Reproduce
Steps to reproduce the behavior:
Have a lot of tags (more than capable of handling) with the current date
Expected behavior
functional: generate the images as soon as space is given free, retrigger it through a queue, have a buffer for each tag type in use as spare
organizational: show a warning if too much tags are associated, disable settings for new tags
Screenshots
Additional context
related to: https://github.com/jjwbruijn/OpenEPaperLink/issues/82
@nlimper commented on GitHub (Jul 26, 2023):
as you said, it's strongly related to #82, so I will combine them. Working in it to fix it.
@coelner commented on GitHub (Jul 27, 2023):
Yes and no. This issue can be spread a little bit wider. If you use multiple APs, do the load balance the tags between them? Or takes the AP with the best RSSI the specific tag? Here you should get a dead lock, because the AP in charge do not deliver new content, because of error prone failure handling. The tag could try another AP if the current one is stuck or the AP initiate a hand-over to another AP. But I have not looked into it, so I just assume.
#82 is more a optimization for a single use case in using the rare space/ram/cpu on a single AP and not just wasting it by generating/storing the same content over and over again. however this could be expanded to a more generic content generation.
@nlimper commented on GitHub (Jul 31, 2023):
When a tag is starting, it chooses the AP with the best RSSI. It stays there as long as the AP is up. You can trigger a rescan in the config of the tag on the webpage. Also, you can set the tag to 'roaming mode', which periodically does a rescan. It's in the content card 'set tag config'.
From the latest release on, the AP only generates a new image if there is enough space for it. If not, it keeps retying until there is space again.
Also, I'm working on a 'mirror tag content' option, which doesn't need it's own raw file to be generated. That will be a solution if you have many tags with the same content.
To keep my own overview of todo-items, I'm closing this issue for now. The mirror option is on my todo list, it will come shortly-ish.