save-screen: "IOError: image file is truncated"

[shirriff]

When I do save-screen and there's a whole lot of stuff on the oscilloscope screen (i.e. high frequency oscillations), it dies with IOError. This seems to happen repeatably for dense screen contents, but save-screen works fine most of the time.

$ ds1054z save-screen 192.168.4.3
Traceback (most recent call last):
  File "/usr/local/bin/ds1054z", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/site-packages/ds1054z/cli.py", line 291, in main
    im.putalpha(255)
  File "/usr/local/lib/python2.7/site-packages/PIL/Image.py", line 1398, in putalpha
    self.load()
  File "/usr/local/lib/python2.7/site-packages/PIL/ImageFile.py", line 211, in load
    raise IOError("image file is truncated")
IOError: image file is truncated

[pklaus]

Hi @shirriff, thanks for sharing this report. I fear, it's out of the scope of this software to fix that. In my opinion, the safe option is to pause the scope and then fetch the screenshot as otherwise the scope might be overloaded in cases as the one you mentioned. Did you make any further observations concerning this issue?

[shirriff]

To clarify, this happens when the scope is stopped, so it's not a matter of the scope being too busy. The problem happens if there are a lot of pixels displayed, for instance if you traced a signal that oscillated a lot.

My assumption is that the image file is larger in this case (since the png file can't be as compressed), and this causes the problem with save-screen. Perhaps it overflows a buffer in save-screen, or gets split into two packets?

[shirriff]

Here's an example of a screen image that won't save from the oscilloscope.

This trace was generated by leaving the probes connected to nothing so they pick up noise and putting them on 10mV / 200ms, so there's a lot of pixels on the screen. Trying to download this with save-screen fails. If I move trace 1 down a bit so there's more blank screen or change the time base so the lines aren't as dense, then it downloads okay. This is why I suspect it's the size of the png file that causes the problem. The problem happens whether the oscilloscope is stopped or not.

Of course, this could be a problem on the oscilloscope side (either generating a bad image or truncating it while sending). But I'm putting the bug report here in case the problem is on the Python side.

[JimFuoco]

FWIW, Seeing the same issue here with my DS1054z.

[QrackEE]

I know this issue is very old, but just hit same problem. Thank you for your input, it allowed me to nail down the reason.
Long story short, the issue can be resolved by increasing DISPLAY_DATA_BYTES in init.py, in my case twice the size was enough. Correct me if I'm wrong, but I think that this value should be as big as the screen can possibly be (800x480x24 bit) thus 1,152,000 insteaad of 1000000

[gnbl]

Thanks for this, @QrackEE - I just ran into

OSError: image file is truncated

Which appears to be unhandled, as this is reported as well:

struct.error: unpack_from requires a buffer of at least 4 bytes for unpacking 4 bytes at offset 0 (actual buffer size is 0)

On Windows, the file might be at

C:\Users\<user>\AppData\Local\Programs\Python\Python38\Lib\site-packages\ds1054z\__init__.py

I just added

# DISPLAY_DATA_BYTES = 100000
DISPLAY_DATA_BYTES = 800*480*24

as suggested.

[ckuethe]

Yep, increasing that buffer fixed my truncated reads.

800*400*3 (3 bytes per pixel) was sufficient... #16 should be merged.

May 05 19:30:16 scopeserv[491398]: INFO:ds1054z:2.069 - finishing write
May 05 19:30:16 scopeserv[491398]: INFO:ds1054z:Receiving screen capture...
May 05 19:30:16 scopeserv[491398]: INFO:ds1054z:2.070 - starting read
May 05 19:30:26 scopeserv[491398]: INFO:ds1054z:11.383 - finished reading 104463 bytes
May 05 19:30:26 scopeserv[491398]: DEBUG:ds1054z:received a long answer: 23 39 30 30 30 31 30 34 34 35 ... 00 49 45 4E 44 AE 42 60 82 0A
May 05 19:30:26 scopeserv[491398]: INFO:ds1054z:read 104463 bytes in .display_data