FPP sequence playback is broken in 4.0 Beta 2 #367
Comments
|
Is that the same file you sent me? Can you attach it the FSEQ to this as well along with the pixel count / dimensions of the matrix? |
|
There seems to be an issue when the files are uploaded with FPP Connect. When uploaded manually (rendered for just the device), they play fine. The file sizes are different as well when uploaded via FPP Connect. I'll figure out what's going on today. Also, I've attached two fseq files based off the FPP_Multisync_Test sequence that you sent me. One is a standalone rendered for the 8x32 matrix you have. The other is rendered for an 8x32 matrix as well, but with the layout changed so that it renders the same in the diagnostics tab once the columns set to 32. If you could do some testing with these while I work on what's going on with FPP connect, I'd appreciate it. Thanks! |
|
It's the xlights project I sent you guys the other day. |
|
The header is messed up in this file. Now that we pay attention to sparse ranges, the data in the sparse ranges structure needs to be correct. My latest changes will validate the ranges and ignore them if they are not valid. 11:57:35.344 -> ------ ParseFseqFile:InputFPPRemotePlayFile.cpp:201: Convert Raw Header into a processed header ------ |
|
I think the range code is incorrect in xLights, if you have a FPP controller and a ESPixelstick, I think it breaks. |
|
Just pushed code that ignores ranges if they are incorrect.
Martin
On Thursday, September 30, 2021, 12:03:54 PM EDT, Scott H. ***@***.***> wrote:
I think the range code is incorrect in xLights, if you have a FPP controller and a ESPixelstick, I think it breaks.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
Build from PR is here - https://github.com/forkineye/ESPixelStick/actions/runs/1291838875 |
|
With the range fix (PR #370), It's failing to render in a single controller setup where the file contains all channels yet is still sparse since that is what xLights uploads. For instance, 'matrixTest' is a single controller setup. The full fseq that xLights saves renders fine, the sparse uploaded via FPP Connect does not. However, if the controller is part of a larger show where the channel value is invalid and ignored, it works as in this sequence: |
|
@MartinMueller2003 Maybe best if we just ignore the channel count in the main header when a sparse file is detected? We still want to support non-sparse files for things like single controller setups, standalone props, etc... |
|
Please send me the files and I will take a look
Sent from Yahoo Mail on Android
On Thu, Sep 30, 2021 at 17:38, Shelby ***@***.***> wrote:
@MartinMueller2003 Maybe best if we just ignore the channel count in the main header when a sparse file is detected?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
They're attached here - #367 (comment) Something else interesting, I noticed I added the sparse range data to my script as well, here are what the above files look like: |
|
in the current version bogus will get flagged and will not run. it is not valid. matrix should run ok.
Sent from Yahoo Mail on Android
On Thu, Sep 30, 2021 at 21:30, Shelby ***@***.***> wrote:
Please send me the files and I will take a look
They're attached here - #367 (comment)
Something else interesting, I noticed bogusTest-sparse.fseq had the header channel count set per the spec. I'm curious how some people are getting sparse fseq files with headers that aren't per spec? Maybe something going on in FPP connect when uploading to multiple controllers with different fseq formats?
I added the sparse range data to my script as well, here are what the above files look like:
bogusTest-sparse.fseq
---------------------
Channel Count: 2550
Sparse Start: 510
Sparse Channels: 2550
matrixTest-sparse.fseq
----------------------
Channel Count: 2560
Sparse Start: 0
Sparse Channels: 2560
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
Using current code, The bogus file will play using the non range mode. It will log an error message to the status report being sent to the UI. Matrix test full play fine since it has no ranges and the header is valid Playing the matrix test sparse currently results in the file "Playing" but nothing comes out. This is because the range does not have a channel count. I will modify the code to revert to playing without using the ranges. 09:14:07.986 -> ------ ParseFseqFile:InputFPPRemotePlayFile.cpp:219: dataOffset: 72 ------ |
|
@MartinMueller2003 |
|
Sorry I already submitted my change |
|
Five line change using info already present |
|
@MartinMueller2003 |
|
That makes very little sense when compared to the FSEQ reference document which clearly states the channelOffset in the range is just that, an offset into the frame at which to send the data. FYI: My implementation is based on the code I was examining in the FPP 5.2 branch. In that code the range presents offset into the frame and number of bytes to send for each range. For a given range, offset plus length must not exceed frame size.
On Friday, October 1, 2021, 09:48:52 AM EDT, Shelby Merrick ***@***.***> wrote:
@MartinMueller2003
There were two issues in the way we were handling the files. One was the using the sparse start channel. It references the channel offset of the master sequence and doesn't pertain to us. The other issue is it was looking for the start of sparse ranges in the wrong location.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
@patdelaney |
|
Anyone able to verify if either the latest CI build or the one linked above this post takes care of this? I've tested it a few different way but would like some verification before we drop a beta3. |
|
@patdelaney verified |
ESPixelStick Firmware Version
4.0-beta2
Hardware Version
Artstick esp8266
Binary release or compiled yourself?
Actions Beta 2 build
Web Browser (and version)
Chrome
Access Point
Ubiquiti
Describe the bug
Playing know good sequence directly or via fpp remote display random data on the output see attached YouTube link.
Note: The same sequence played in Beta 1
https://youtu.be/6UE-LjuXRb8
The text was updated successfully, but these errors were encountered: