[GH-ISSUE #462] Sometimes double refresh on Solum M3 2.9" Lite (and others) #1939

New Issue

sascha_hemi · 2026-03-20T20:07:47+01:00

sascha_hemi commented

2026-03-20 20:07:47 +01:00

Originally created by @olanwe on GitHub (May 2, 2025).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/462

Describe the bug
Certain updates cause the tag (Solum M3 2.9" Lite - EL029H4WRC, Tag FW 0029-ARIA) to get refreshed twice. Not sure if this is a problem related to the tag FW or the AP (running FW 2.81), because it is sometimes difficult to reproduce.

To Reproduce

This works on my side - at least today...
[ {"image": ["images/no_stream_128x102.jpg", 33, 33] }, {"textbox": [174, 62, 190, 60, "Der Störungsmelder\nist nicht erreichbar!", "bahnschrift20.vlw", 1, 1.25] } ]
Steps to reproduce the behavior:

Upload image file to images/ folder
Open JSON-upload form
Insert JSON and upload it to the tag
Check tag and log

It helps playing around with the content if it does not show this glitch at first.

Expected behavior
Log should show:

    13:06:14 xxx reports xfer complete
    13:06:14 xxx block request /current/xxx_865804.pending block 0, len 1043 checksum 750
    13:05:15 new image: /current/xxx_865804.pending
    13:05:13 Updating xxx

The tag is then updating the display once.

Observed behavior
Instead, the block request is not being logged - although the change is actually being transmitted and the intended upload must have taken place. The tag refreshes the display twice: The first time right after upload and the second time on the following data poll.

    13:08:16 xxx reports xfer complete
    13:07:15 xxx reports xfer complete
    13:06:45 new image: /current/xxx_956263.pending
    13:06:43 Updating xxx

Additional context
I have also tried several variations to find the origin of the problem:

Send this JSON via upload form to the tag: glitches
Send the exact same JSON to another tag type (e.g. 4.3" with same firmware) without any modification: works!
Upload jpeg-image of generated JSON: glitches
Just change text (e.g. replace a character): glitches
Remove image and only leave text: works
use different font: works
tried older tag firmware 0029-BUGF: glitches too.

Image used in the test

Rendered jpeg-image that glitched when being uploaded onto my tag (using a different font here):

Originally created by @olanwe on GitHub (May 2, 2025). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/462 **Describe the bug** Certain updates cause the tag (Solum M3 2.9" Lite - EL029H4WRC, Tag FW 0029-ARIA) to get refreshed twice. Not sure if this is a problem related to the tag FW or the AP (running FW 2.81), because it is sometimes difficult to reproduce. **To Reproduce** This works on my side - at least today... `[ {"image": ["images/no_stream_128x102.jpg", 33, 33] }, {"textbox": [174, 62, 190, 60, "Der Störungsmelder\nist nicht erreichbar!", "bahnschrift20.vlw", 1, 1.25] } ]` Steps to reproduce the behavior: 1. Upload image file to `images/` folder 2. Open JSON-upload form 3. Insert JSON and upload it to the tag 4. Check tag and log It helps playing around with the content if it does not show this glitch at first. **Expected behavior** Log should show: ``` 13:06:14 xxx reports xfer complete 13:06:14 xxx block request /current/xxx_865804.pending block 0, len 1043 checksum 750 13:05:15 new image: /current/xxx_865804.pending 13:05:13 Updating xxx ``` The tag is then updating the display once. **Observed behavior** Instead, the block request is not being logged - although the change is actually being transmitted and the intended upload must have taken place. The tag refreshes the display twice: The first time right after upload and the second time on the following data poll. ``` 13:08:16 xxx reports xfer complete 13:07:15 xxx reports xfer complete 13:06:45 new image: /current/xxx_956263.pending 13:06:43 Updating xxx ``` **Additional context** I have also tried several variations to find the origin of the problem: - Send this JSON via upload form to the tag: glitches - Send the exact same JSON to another tag type (e.g. 4.3" with same firmware) without any modification: works! - Upload jpeg-image of generated JSON: glitches - Just change text (e.g. replace a character): glitches - Remove image and only leave text: works - use different font: works - tried older tag firmware 0029-BUGF: glitches too. Image used in the test ![Image](https://github.com/user-attachments/assets/5a81f6e6-7940-46e2-bf00-7492c7a5922f) Rendered jpeg-image that glitched when being uploaded onto my tag (using a different font here): ![Image](https://github.com/user-attachments/assets/fbbc5e68-4631-455f-b585-1eb56ef0ad1a)

sascha_hemi added the bug label 2026-03-20 20:07:47 +01:00

sascha_hemi commented

2026-03-20 20:07:48 +01:00

@olanwe commented on GitHub (May 2, 2025):

Short Update: Looking through the logs I discovered a classic Solum M2 2.9" having the same issue, so this issue is not solely related to the Solum M3 2.9":

21:47:45 0000028281613B1F reports xfer complete
21:47:05 0000028281613B1F reports xfer complete
21:46:43 new image: /current/0000028281613B1F_56715.pending
21:46:39 Updating 0000028281613B1F

It is connected to a different AP at a remote site, so I cannot see if it is really updating twice at the moment.

Another observation:
When sending the same JSON over and over to the tag, the AP will (correctly) refuse it as being already displayed on the tag. As soon as the second xfer message has been received from the tag, the AP will handle the image as a different one and create an update request for it:

22:07:08 0000028281613B1F reports xfer complete
22:06:28 0000028281613B1F reports xfer complete
22:05:57 new image: /current/0000028281613B1F_210598.pending
22:05:53 Updating 0000028281613B1F
22:05:48 0000028281613B1F reports xfer complete
22:05:43 new image is the same as current image. not updating tag.
22:05:40 Updating 0000028281613B1F
22:05:33 new image is the same as current image. not updating tag.
22:05:30 Updating 0000028281613B1F
22:05:08 0000028281613B1F reports xfer complete
22:05:06 new image: /current/0000028281613B1F_160204.pending
22:05:03 Updating 0000028281613B1F

The manually triggered "Updating" messages contain the same JSON every time, so the second xfer message seems to mess up the internal image change logic.

@olanwe commented on GitHub (May 2, 2025): Short Update: Looking through the logs I discovered a classic **Solum M2 2.9" having the same issue**, so this issue is not solely related to the Solum M3 2.9": ``` 21:47:45 0000028281613B1F reports xfer complete 21:47:05 0000028281613B1F reports xfer complete 21:46:43 new image: /current/0000028281613B1F_56715.pending 21:46:39 Updating 0000028281613B1F ``` It is connected to a _different AP_ at a remote site, so I cannot see if it is really updating twice at the moment. **Another observation:** When sending the same JSON over and over to the tag, the AP will (correctly) refuse it as being already displayed on the tag. As soon as the second xfer message has been received from the tag, the AP will handle the image as a different one and create an update request for it: ``` 22:07:08 0000028281613B1F reports xfer complete 22:06:28 0000028281613B1F reports xfer complete 22:05:57 new image: /current/0000028281613B1F_210598.pending 22:05:53 Updating 0000028281613B1F 22:05:48 0000028281613B1F reports xfer complete 22:05:43 new image is the same as current image. not updating tag. 22:05:40 Updating 0000028281613B1F 22:05:33 new image is the same as current image. not updating tag. 22:05:30 Updating 0000028281613B1F 22:05:08 0000028281613B1F reports xfer complete 22:05:06 new image: /current/0000028281613B1F_160204.pending 22:05:03 Updating 0000028281613B1F ``` The manually triggered "Updating" messages contain the same JSON every time, so the second xfer message seems to mess up the internal image change logic.

sascha_hemi commented

2026-03-20 20:07:48 +01:00

@olanwe commented on GitHub (May 3, 2025):

Second short update:
I downgraded the remote AP from 2.81 to 2.75. The problem seems to be gone. Although the "block request" notice is still missing, I only receive a single "xfer complete" and the AP refuses to update the tag with the same image now.

@olanwe commented on GitHub (May 3, 2025): Second short update: I downgraded the remote AP from 2.81 to 2.75. The problem seems to be gone. Although the "block request" notice is still missing, I only receive a single "xfer complete" and the AP refuses to update the tag with the same image now.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#1939