Online_image not respecting buffer_size parameter

[Stubborn (Stub)]

Use case
SEED Studio XIAO 7.5” ePaper Display
Display dashboard via puppet

I have tried multiple different buffer sizes both with arduino and esp-idf and per the logs it always allocates 48000.
The image is never more than 7000 bytes the huge buffer is not needed and causes it to fail 80% of the time.

Is this a bug or am I misunderstanding?

esp32:
  board: esp32-c3-devkitm-1
  framework:
    #type: arduino
    type: esp-idf 


========================================
online_image:
  - id: dashboard_image
    format: PNG
    type: BINARY
    buffer_size: 30000
    url: http://192.168.0.210:10000/e-ink-1/0?viewport=800x480&eink=2&wait=10000&invert 
    #url: http://192.168.0.210:10000/e-ink-1/0?viewport=800x480&eink=2&wait=10000
    update_interval: 300s
    on_download_finished:
      - delay: 50ms
      - component.update: main_display

[10:33:16][I][online_image:109]: Updating image http://192.168.0.210:10000/e-ink-1/0?viewport=800x480&eink=2&wait=10000&invert
[10:33:31][D][http_request.arduino:134]: Received response header, name: etag, value: 
[10:33:31][D][http_request.arduino:134]: Received response header, name: last-modified, value: 
[10:33:31][D][http_request.arduino:140]: Content-Length: 5872
[10:33:31][D][online_image:175]: Starting download
[10:33:31][D][online_image:194]: Allocating PNG decoder
[10:33:31][I][online_image:212]: Downloading image (Size: 5872)
[10:33:31][W][component:407]: online_image took a long time for an operation (14733 ms)
[10:33:31][W][component:408]: Components should block for at most 30 ms
[10:33:31][D][online_image:089]: Allocating new buffer of 48000 bytes
[10:33:31][E][online_image:092]: allocation of 48000 bytes failed. Biggest block in heap: 31732 Bytes
[10:33:31][E][online_image.png:086]: Error decoding image: Incorrect PNG signature
[10:33:31][E][online_image:250]: Error when decoding image.

[Stubborn (Stub)]

Would reflashing to esp-idf NVS make any difference?
I dont want to play around and risk bricking stuff unless someone has confidence it could be effective, as all Seed studio docs are are arduino based

@bdraco

One-time serial flash recommended

To take full advantage of ESP-IDF’s Bluetooth performance improvements, you should do a full serial flash at least once. This ensures the partition table is updated and the NVS partition is resized automatically to be large enough for caching Bluetooth services.

If you skip this, BLE will still work just fine, and OTA updates will continue to work normally. The only downside is that BLE connections will be slower because the device has to refetch the full list of services on every connection instead of using the cache. If the service list is large, this can add a few seconds to connection time instead of just a few milliseconds.

That said, BLE was just as slow under Arduino, so if you don’t care about connection speed, you’re not really any worse off. But if you want the improved performance, it’s worth doing that one-time serial flash.

[zoogara (Daryl)]

@Stubborn

Would reflashing to esp-idf NVS make any difference?

Possibly not, another user has the same issue. The already used esp-idf and tried a reflash via USB.

ESPHome ePaper stopped working after ESPHome update

Ok total ESPHome noob. 1st device a Seeed 7.5" paper display been working great. There have been two update of ESHome in the last week. The first update killed the ePaper device it just went blank and no longer updated in fact is was completely blank. Tried updating the ePaper device and I am now getting the following when attempting the install RAM: [= ] 12.4% (used 40604 bytes from 327680 bytes) Flash: [======== ] 75.1% (used 1378030 bytes from 1835008 bytes) ================…

Maybe log a ticket on GitHub.

[Busta999x (Michael Horton)]

Ok

Found workaround.

The running out of memory issue appears related to png files, bmp work ok.

The 5kb png is reported as too large for 48k memory available.

The 48k bmp does not.

So something funky is occurring here.

Thanks for everyone’s assistance !! Very much appreciated.

[zoogara (Daryl)]

@Busta999x

The 5kb png is reported as too large for 48k memory available

Yeah think it’s related to how they get decoded internally - another user has the exact same issue.

[Busta999x (Michael Horton)]

@chromelex had the same issue, same workaround fixed the bigger issue.

[martijnotto (Martijn)]

I’m running into the same issue. I’m already processing the image through the camera proxy to resize it on the HA side and make it smaller. That yields a JPEG of 16753 bytes. It then tries to allocate a 153600 byte large buffer - which always fails.

I’ve tried setting buffer_size to 4k but it does not change anything.

[Stubborn (Stub)]

Confirmed BMP works here.
Size must be a bogus error message, and there is a bug with jpg handling.