Explanation of ED (Extended Data)

[Florida-Rob]

Explanation of ED (Extended Data).
The sp fields are direct, and an easy string.
The ED are placed at the end of the file, but the data is not a string, and no explanation of its use ?
the data location for ED is documented here,
ID: sp, Size: 34, Data: xLights Windows 2026.01 64bit
ID: ED, Size: 18, Data: (�/�

�8 ID: ED, Size: 18, Data: (�/�

"ID: ED, Size: 18, Data: (�/�`�8..."
var_data : 58 52 18 57 09 00 00 00 00 00 0D 07 00 00 00 40 00 00
=offset 0x95718, length 1805
the actual data, at the correct offset, at the end of the file, at the exact place that its supposed to be.
But no format explanation of the data

[dkulp]

It can be whatever the application that wrote the xseq wants it to be.   In this case, the code is "XR" (0x58 and 0x52), which, again, can be whatever the application wants it to be.   The only two that are really defined are "mf" and "sp".  xLights has a few it uses, with the important ones being FC and FE which are the FPP command preset and effect timing tracks.  

[Florida-Rob]

Thanks for the reply
I have found that the facebook ZSTD need > 150KB to run, no matter how to try and contain the workspace for the algorithm, either Block, Raw or Stream.  So for small micros, its 'impossible' to use ZHSD.
So ZLIB works, typically 32KB, and works great.
BUT, BUT....
The ED section is ALWAYS encoded in ZSTD !

// XS - xLight xsq (zstd compressed binary)
// XN - xLight xlights_network.xml (zstd compressed binary)
// XR - xLight xlights_rgbeffects.xml (zstd compressed binary)

so...
How are we supposed to decode universes from the file?  as the blocks with Frames of Channels are in ZLIB, but the ED data is in ZSTD !

Why does XLIghts not use ZLIB for the ED Data !!!

am I missing something ?
Of course we can separate the Sender from Receiver, and program the Receiver (with the FSEQ file) with mapped Universe(s) to strip(s), but how is that mapped ?


you can see from the data below how a simple 2 universe, 200 LED, 600 Pixel, FSEQ as ZLIB is output, and also the memory usage during Zlib:

Directory contents of /sdcard:
  DIR: System Volume Information
  FILE: seq-200LED.fseq
Inside process_fseq
-->MEM FREE 151552
======================
== Xlights FSEQ V2.0 Header
======================
Channel Data offset : 216
variable Data offset : 128
FSEQ Version: 2.2
Channel Count: 1020
Frame Count: 600
Step Time (ms): 50
Compression : ZLIB
Compression Blocks : 12
channel Range Count : 0
======================
-->MEM FREE 151552
== Variable Headers
  ID: sp, Size: 34  Data: xLights Windows 2026.01 64bit
  ID: ED, Size: 18, Code: XR, Offset: 47126, Ln: 1805xLights_rgbeffects.xml (zstd), Data[0-9]:28 B5 2F FD 60 CB 1E 1D 38 00
  ID: ED, Size: 18, Code: XN, Offset: 48931, Ln:  460xLights_network.xml (zstd)  , Data[0-9]:28 B5 2F FD 60 25 02 15 0E 00
  ID: ED, Size: 18, Code: XS, Offset: 49391, Ln: 1415xLights xsq (zstd)          , Data[0-9]:28 B5 2F FD 60 9F 18 ED 2B 00
======================
-->MEM FREE 151552
== Compression Blocks
  Block 0: First Frame 0, Comp. Size 2594 bytes
  Block 1: First Frame 10, Comp. Size 17946 bytes
  Block 2: First Frame 76, Comp. Size 8241 bytes
  Block 3: First Frame 142, Comp. Size 1934 bytes
  Block 4: First Frame 208, Comp. Size 1375 bytes
  Block 5: First Frame 274, Comp. Size 1834 bytes
  Block 6: First Frame 340, Comp. Size 2672 bytes
  Block 7: First Frame 406, Comp. Size 4011 bytes
  Block 8: First Frame 472, Comp. Size 3420 bytes
  Block 9: First Frame 538, Comp. Size 2883 bytes
  Block 10: First Frame 0, Comp. Size 0 bytes
  Block 11: First Frame 0, Comp. Size 0 bytes
======================
  Block 0: MEM FREE 129024 SUCCESS 10200 bytes
  Block 0: Decompressed 10200 bytes. Starting timed output...
  Block 1: MEM FREE 56320 SUCCESS 67320 bytes
  Block 1: Decompressed 67320 bytes. Starting timed output...
  Block 2: MEM FREE 65536 SUCCESS 67320 bytes
  Block 2: Decompressed 67320 bytes. Starting timed output...
  Block 3: MEM FREE 71680 SUCCESS 67320 bytes
  Block 3: Decompressed 67320 bytes. Starting timed output...
  Block 4: MEM FREE 71680 SUCCESS 67320 bytes
  Block 4: Decompressed 67320 bytes. Starting timed output...
  Block 5: MEM FREE 71680 SUCCESS 67320 bytes
  Block 5: Decompressed 67320 bytes. Starting timed output...
  Block 6: MEM FREE 71680 SUCCESS 67320 bytes
  Block 6: Decompressed 67320 bytes. Starting timed output...
  Block 7: MEM FREE 69632 SUCCESS 67320 bytes
  Block 7: Decompressed 67320 bytes. Starting timed output...
  Block 8: MEM FREE 69632 SUCCESS 67320 bytes
  Block 8: Decompressed 67320 bytes. Starting timed output...
-->MEM FREE 151552
======================

[dkulp]

I would definitely NOT rely on anything in those or even rely on the existence of those.  Those were just added in 2026.01 and there is some debate about making them optional or even removing them.  Also don't rely on the format of them as they will be changing throughout this year.

xLights needs to push the configuration that is needed either via the "Upload Inputs/Output" buttons or via FPP connect.   

[Florida-Rob]

Where may we find the protcol definition for the 'configuration that is needed', either via the "Upload Inputs/Output" buttons or via FPP connect ? i belive its here

[dkulp]

Depends on the controller.   xLights has separate classes that handle that for each of the controller types it supports.   Falcons have their own code path.  FPP has its own.   ESPixelStick has its own, Experience, etc....   Basically, if the contoller has a decent REST api (json preferred, but not required) and the controller is publicly available, then xLights could be updated.