Controller Versioning #5060
Comments
|
What would you consider a controller configuration version? You can literally change anything anywhere and that would need a batch render. I like this idea - just not sure how we could detect/show it.. |
|
Anytime you change something in xlights that affects the channels or controller settings. I'd treat the version global for all controllers within a show. I'd increment the version number only when any controllers configuration is changed within the show. I would embed the controller configuration into the FSEQ. I hope the file format supports meta data. This way in FPP Connect, you can show the version number next to each sequence, and warn if any don't match with what is going to be pushed.
Down the road, the FPP devs can store and return this version number so FPP Connect can decide if it needs to upload a new configuration or not. And what will be ultimate end goal, is for FPP/xschedule to support staging an entire show with newly compiled sequences and controller configurations, ready to be published in real time and the ability to revert back to the most recent show. (In case, something went bad with a newly published show)
In short, this would the road map to bringing basic dev ops to pixel shows.
Batch rendering can take me a couple hours
Yahoo Mail: Search, Organize, Conquer
On Mon, Dec 16, 2024 at 15:30, ***@***.***> wrote:
What would you consider a controller configuration version? You can literally change anything anywhere and that would need a batch render. I like this idea - just not sure how we could detect/show it..
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
I can't see staging and having more that one.. that's way too unique.. however, one of the things we've been thinking for the new year, is an alert of sorts when xligths config vs the ctrls is differnet, similar with what you are saying. It will be relatively easier for FPP based to flag diff, not sure of the other ones.. but the idea is that it will "query" the ctrl for port & pixle config and comp with what xlights has and raise an aler that they don't match. |
|
the idea thrown around before is to create a controller hash code whenever the auto start channel code is triggers, then set a flag when they are different. I think trying to controller firmwares to support some version number will be hard to impossible. |
|
Storing a string variable of the version pushed by xlights onto the controller is hard? The various versioned configurations would sit on the PC/Mac. FPP Connect would do the work. All the controller needs to do is store the integer.
Yahoo Mail: Search, Organize, Conquer
On Mon, Dec 16, 2024 at 19:27, Scott ***@***.***> wrote:
the idea thrown around before is to create a controller hash code whenever the auto start channel code is triggers, then set a flag when they are different. I think trying to controller firmwares to support some version number will be hard to impossible.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Open-source... feel free to have at it. |
|
Thinking about the staging. I think something as simple as having an A & B folder could work. Sequences in folder A could be currently running. New sequences along with new controller configuration if needed is uploaded to folder B. Then have an option to promote folder B to current at either the start of a new sequence or at the start of a loop.
The controller would execute a apps stop, apply configuration, point fppd to folder b, start fppd.
The contents in folder A would not be removed so the end user could flip it back if necessary. However, if a new config or sequences were added, it would override folder A
Yahoo Mail: Search, Organize, Conquer
On Mon, Dec 16, 2024 at 19:04, ***@***.***> wrote:
I can't see staging and having more that one.. that's way too unique.. however, one of the things we've been thinking for the new year, is an alert of sorts when xligths config vs the ctrls is differnet, similar with what you are saying. It will be relatively easier for FPP based to flag diff, not sure of the other ones.. but the idea is that it will "query" the ctrl for port & pixle config and comp with what xlights has and raise an aler that they don't match.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
True but since I'm not an official dev. I highly doubt my changes would be accepted. I will admit, there will be coordination needed between the ctrl vendors and xlights.
Yahoo Mail: Search, Organize, Conquer
On Mon, Dec 16, 2024 at 23:08, ***@***.***> wrote:
Open-source... feel free to have at it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
I'm failing to see how FPP Connect needs to be involved at all. If the xlights_networks or xlights_rgbeffects files is newer (simple timestamp check) then the fseq file, then the sequence needs/should be re-rendered as something has changed. FPP Connect already checks the fseq file and only sends it to the remote if it has changed so that wouldn't need to change at all. |
|
Dan I tend to agree .. there is just way too much variation - save on the controller/layout tab always means there is a possibility of a channel breaking change. |
|
The default even for the xLights rendered sequence is supposed to be sparse. Thus, the "source" fseq file should only have the channels for the models that are actually included in the sequence. Thus, that check would be useless. If I only sequence my megatree in one sequence, then the ranges won't include the other props on the same controller anyway. |
But that will be per sequence, no? I'm thinking more of a general/high level check, if FPP based.. what's its channels, if pushing outputs what are those channels compared with the ctrls config in xLights. Yes, we'll send the "right" channels, but if the sequence wasn't rerenderd, it may not have them all. |
|
I have not looked at the source .. but this is what I was referring to. I pulled in a fseq from a different showfolder. |
|
So that only tells you if you don't have models configured in a controller. What about if you moved models between two ports. Should be the same number of channels.
Yahoo Mail: Search, Organize, Conquer
On Tue, Dec 17, 2024 at 8:38, ***@***.***> wrote:
I have not looked at the source .. but this is what I was referring to. I pulled in a fseq from a different showfolder.
WARN: Playlist '<unnamed>' has step 'Hamster On A Piano - Parry Gripp' with FSEQ item Hamster On A Piano - Parry Gripp with 835916 channels when only 132740 channels are configured to be sent out.
ERR: Playlist '<unnamed>' has step 'Aerosmith - Dream On 400s' with FSEQ item Aerosmith - Dream On 400s with 21280 channels when it should be 132740 channels.
ERR: Playlist '<unnamed>' has step 'Aerosmith - Dream On 100s' with FSEQ item Aerosmith - Dream On 100s with 21280 channels when it should be 132740 channels.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
I am thinking long term of being able to rollback changes. Say (and this has happened to me) that someone goofs up a configuration and the sequence just looks wrong. it would be great to rollback to a good known state of sequences and ctrl config to keep the show going. As opposed to triaging and hoping you get everything back together in time. I suppose the a timestamp could work, just wouldn't really help if I needed to quickly restore a previous configuration, and the sequences that went with it. |
|
File - Restore Backup |
|
Yes yhat could be done but does that restore rendered sequences too? Or must you rerender everything?
Yahoo Mail: Search, Organize, Conquer
On Thu, Dec 19, 2024 at 22:23, ***@***.***> wrote:
File - Restore Backup
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Batch Render.. fseq are very large and you don't want to save them. |
|
I disagree. That's like saying you should only save the source code on your production promotions and recompile the code if you need to rollback. Rerenderinf takes me hours to do. Im sure others are in the same boat. Im not saying keep an infinite history, but a rolling 2 to 5 versions.
Yahoo Mail: Search, Organize, Conquer
On Thu, Dec 19, 2024 at 22:32, ***@***.***> wrote:
Batch Render.. fseq are very large and you don't want to save them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Everytime you save a sequence it will be a version. So 2-5 will be like the last 6-20 min. Still.... batch render. |
|
Im not suggesting creating the version when you save it only when you upload it. There is no point on versioning the sequence until it is uploaded to any controller. Batch rendering is not an efficient answer. It's just a default answer.
Yahoo Mail: Search, Organize, Conquer
On Thu, Dec 19, 2024 at 23:45, ***@***.***> wrote:
Everytime you save a sequence it will be a version. So 2-5 will be like the last 6-20 min. Still.... batch render.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
cybercop23
added
Unlikely To Be Implemented
Is your feature request related to a problem? Please describe.
I cannot tell which version of a controller configuration that a compiled sequence was used. So when uploading, to be safe, I must batch render all my sequences which can take hours. So if I had a version of the controller configuration in the sequence and when I open FPP Connect, I can see that I need to re-render any sequences that are not using the same version of controller configuration.
Describe the solution you'd like
Ability to see versions (a number) of controller configuration that are embedded into a rendered sequence in FPP Connect
Describe alternatives you've considered
Batch render every time I am going to upload
Additional context
This could come in handy on the FPP side. A configuration and the sequences associated with it could be staged on controllers and applied all at once. It would also allow FPP to not play sequences that are not sequenced with the current controller configuration.
The text was updated successfully, but these errors were encountered: