Sean Meighan
Welcome => Do You Need Help? Post it here => Topic started by: Akentut on October 27, 2015, 02:25:47 PM
-
Have been working on sequence to past few days. Handel - Hallelujah Chorus. I have 48 Universes (24480 channels) although not all are being used, but quite a few. I have approx. 15 groups and 55 models (31 are pixel strings via 4 E682 and 24 are LEDs via SS24 Renard). The sequence was saving and rendering fine until today. After about 15 seconds more of editing the program would just freeze and no response. >:( Even though the program froze the XML was saved. The FSEQ file is approx 106Mb and the XML is 319K.
I loaded another sequence that has the same models and groups, with a file size of 62k xml and 61Mb fseq. This worked fine rendering and saving.
Is there a file size limitation? I'm using Windows 10, AMD X8 @ 4.2Ghz, 16Gb Ram. and SSD drives. Although the Christmas PC was running an i7 3.2Ghz, Windows 10, 8Gb Ram, SATA Drives. All running xLights 4.1.17.
Any help would be appreciated to no end. :'(
Alan
-
Update.... :o
While typing the above info, the program finally saved and unfroze.
2015Handel-Osiris.fseq Time - Update 1246.958 seconds.
Before the time was 30-40 seconds. Go figure.
Alan
-
Do you ever close xLights? The UNDO buffer will continue to eat memory until you quit the program.
-
Does the undo buffer clear between sequences?
-
I really need to study the code to figure that out. There are a couple different things that use memory. The UndoManager is allocating memory as you work and there is stuff that is saved out to the clipboard when you do a copy operation. I don't remember exactly how I'm handling things in the UndoManager.
-
I did restart the program, and I also restarted the PC. xLights would unfreeze after the rendering or saving was complete. Last time I looked at Task Manager it had 26% memory as it was rendering.
Alan
-
The program isn't supposed to freeze during render but it is supposed grey out a bunch of buttons to prevent you from sequencing new effects while it's saving.
It looks like the UndoManager doesn't get cleared out between closing and opening sequences which is probably a bug. If you open a new sequence you could probably have an Undo action already available that might crash the program. Would be pretty easy to add a clear function that could be called when loading a sequence.
-
Reloaded the same sequence, no undo's in the buffer. Added one effect and did a render. Watching the bottom task bar at bottom left of window go thru each model, it stops or looks like it stops at one of the models. Yes everything is greyed out as it doing it thing. If I could see what order the rendering is done, i may be able to disable the model (or look at the effects) and see if its a model causing it, or an effect I added recently.
alan
-
Sometimes Text effects have caused issues. At one time they had to be rendered on the main thread but I thought Dan was able to fix that. The rendering order is not deterministic because the effects are rendered by multiple threads.
-
OK! Well the main part of this sequence is the entire lyrics of Handel's Messiah. I have a 72x30 pixel grid (4'x8'), which worked fine last year. I did add a few more strands this year as I have a new house. I'd say I've added one more controller and approx 2000 pixels. I have about 45seconds left in the sequence, so if it takes 20 min to save, I may as well do the 45 sec before saving and just go have a beer (or two). ;D
When it's rendering, is there an order that it takes thru the models, or by channels?
Alan
-
I have the same issue with 4.2.18. Tried on my mac and windows machine and same behaviour. I'll keep my eye open on github to see if anything changes related to this one. If you need any debug info I'll send along.
-
If you can send your xlights* files and the XML file for the sequence, I can try and reproduce it. Generally, if I can reproduce something, I can get things fixed fairly quickly. It usually takes longer to reproduce something than to fix it.
-
OK, zipped up the file but it's still 9.2Mb, so I'll post online here's the link --> https://www.dropbox.com/s/ohpc93b30coy40a/Handel2015.zip?dl=0 (https://www.dropbox.com/s/ohpc93b30coy40a/Handel2015.zip?dl=0)
If you need any other file, just let me know, Tnx.
Alan
-
It's not hung, it's just taking a REALLY long time. The problem is in the Single Strand Chase code if you drop it on a model group and check the group all arches. What happens there is it takes the 400x400 "grid" and creates a virtual line 160,000 pixels long to run the chase across. The math for the chase wasn't really optimized for that kind of chase. It was taking about 15 seconds per frame to render.
I've done a little work to help that case and it now renders your sequence in about 30 seconds.
-
OK Tnx, I've DL'd the latest build and will work on the sequence a bit to remedy the chase.
Tnx for all the work.
Alan
-
OK, I successfully unchecked all of the single strand effects Group Arches and the save and rendering was reduced to 153 seconds. So I can add them back little by little to determine which was causing the problems.
I'll get back with my results today.
Alan
-
OK, I successfully unchecked all of the single strand effects Group Arches and the save and rendering was reduced to 153 seconds. So I can add them back little by little to determine which was causing the problems.
I'll get back with my results today.
Or you can update to 4.2.20 and the time to render the single strand things will likely drop by quite a bit anyway. :-)