Delayed Device and Network config so they do not happen in Web Event Context

[MartinMueller2003]

Added additional range checking for FPP
Added proper time adjustment when time is slipping

[forkineye]

This is using the sparse start channel again to calculate an offset which is incorrect. The sparse start channel is there to know where the channel was in the master sequence. For example, if the sparse start channel is 410, then index 0 of the sparse data block will be the channel data for channel 410 of the master sequence. It needs to be reverted back to e00481b or something similar.

[forkineye]

This is using the sparse start channel again to calculate an offset which is incorrect. The sparse start channel is there to know where the channel was in the master sequence. For example, if the sparse start channel is 410, then index 0 of the sparse data block will be the channel data for channel 410 of the master sequence. It needs to be reverted back to e00481b or something similar.

[MartinMueller2003]

This is using the sparse start channel again to calculate an offset which is incorrect. The sparse start channel is there to know where the channel was in the master sequence. For example, if the sparse start channel is 410, then index 0 of the sparse data block will be the channel data for channel 410 of the master sequence. It needs to be reverted back to e00481b or something similar.

That makes no sense. If the start value is not an offset into the frame then there is no need for a range. Looking at the FPP code, the start is used as an offset into the frame in the file not as an offset into the master data set. There would be no reason to have such a value.

[forkineye]

This is using the sparse start channel again to calculate an offset which is incorrect. The sparse start channel is there to know where the channel was in the master sequence. For example, if the sparse start channel is 410, then index 0 of the sparse data block will be the channel data for channel 410 of the master sequence. It needs to be reverted back to e00481b or something similar.

That makes no sense. If the start value is not an offset into the frame then there is no need for a range. Looking at the FPP code, the start is used as an offset into the frame in the file not as an offset into the master data set. There would be no reason to have such a value.

The whole point of sparse though is to have a sub-set of data from the master sequence. The channel start is a frame offset in the context of the master sequence. I'll reach out to Dan for clarification.

From https://github.com/FalconChristmas/fpp/blob/master/docs/FSEQ_Sequence_File_Format.txt:

The channel count is per frame within this file which may not
be the full number of channels needed to output. For example, if there
is a single "sparse range" of start channel 5000 with lengh 50, the
channel count in bytes 10-13 will be "50" as there will only be 50
channels per frame within the file. If there are multiple sparse
ranges, each range is appended one after another into the frame
with the channel count being the total lengths of the ranges.

[MartinMueller2003]

This is using the sparse start channel again to calculate an offset which is incorrect. The sparse start channel is there to know where the channel was in the master sequence. For example, if the sparse start channel is 410, then index 0 of the sparse data block will be the channel data for channel 410 of the master sequence. It needs to be reverted back to e00481b or something similar.

That makes no sense. If the start value is not an offset into the frame then there is no need for a range. Looking at the FPP code, the start is used as an offset into the frame in the file not as an offset into the master data set. There would be no reason to have such a value.

The whole point of sparse though is to have a sub-set of data from the master sequence. The channel start is a frame offset in the context of the master sequence. I'll reach out to Dan for clarification.

From https://github.com/FalconChristmas/fpp/blob/master/docs/FSEQ_Sequence_File_Format.txt:

The channel count is per frame within this file which may not
be the full number of channels needed to output. For example, if there
is a single "sparse range" of start channel 5000 with lengh 50, the
channel count in bytes 10-13 will be "50" as there will only be 50
channels per frame within the file. If there are multiple sparse
ranges, each range is appended one after another into the frame
with the channel count being the total lengths of the ranges.

OK I will refactor. Based on this, the channel offset is the length of the previous range. All we want is the SUM of the subset of channels in the ranges. Dont take the latest version.

[MartinMueller2003]

FYI: The ever increasing time difference is a reporting issue. The clock on the ESP wanders a bit. I have adaptive code in place that "adjusts" a virtual time base to derive the master frame time and try to stay in sync. The reporting code did not take that into consideration when reporting how far into the file we had played.

[MartinMueller2003]

To be honest, this means a player like the ESP does not need to actually support the ranges. We just need to get the final channel count from the ranges and as long as it is less than than or equal to the Frame Size, we can ignore the ranges entirely. That would reduce the play overhead.

[dkulp]

To be honest, this means a player like the ESP does not need to actually support the ranges. We just need to get the final channel count from the ranges and as long as it is less than than or equal to the Frame Size, we can ignore the ranges entirely. That would reduce the play overhead.

That's exactly what the code I submitted last year did. It assumed the one range in the file is the range that the ESPixelStick needs and just uses it. That works fine if using FPP Connect to upload the needed sparse fseq file, but not so well if using a full fseq file when saved directly from xLights.