Stable version of FPP

[Ebuechner]

As you can tell by my subject line, I want to inquire what the last stable version of FPP was so I could run it.
I'm currently on 7.3.5 and I had my show lock up on me again tonight.
FPP comes completely unusable and I can't get to the main page while this is going on. I ended up doing a hard reboot and then everything is running fine again until the next time it flakes out. Plus the other issue. I was asking about where I have one sequence that acts funny to the point I had to remove it from the playlist. 
I've been running FPP for years so this isn't my first time but this is the first time I've had issues that I haven't been able to sort out.

[Ebuechner]

2023-11-30 18:46:12.289 (1800) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1605A8C0   output count: 45/45   time: 198 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:12.289 (1801) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1705A8C0   output count: 15/15   time: 198 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:12.289 (1802) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1805A8C0   output count: 12/12   time: 198 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:12.289 (1803) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1405A8C0   output count: 34/34   time: 198 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:12.289 (1804) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1505A8C0   output count: 28/28   time: 198 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:18.022 (1803) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1505A8C0   output count: 28/28   time: 104 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:18.022 (1804) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1405A8C0   output count: 34/34   time: 105 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:18.022 (1802) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1805A8C0   output count: 12/12   time: 104 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:18.022 (1800) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1605A8C0   output count: 45/45   time: 104 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:18.022 (1801) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1705A8C0   output count: 15/15   time: 104 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:29.075 (1802) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1705A8C0   output count: 15/15   time: 105 ms    errCount: 1) with error: 0   Success
2023-11-30 18:46:29.074 (1801) [ChannelOut] /opt/fpp/src/channeloutput/UDPOutput.cpp:515: sendmmsg() failed for UDP output (key: 1405A8C0   output count: 34/34   time: 105 ms    errCount: 1) with error: 0   Success


just in case anybody's interested in what I was dealing with.

[JonD]

I mean this in the nicest way, but you tend to post minimal information about your problem in several different posts.  People have offered you suggestions, but instead of following up and letting us know what works and what doesn't, you post another thread with minimal information.  I understand your frustration, and am sorry about the troubles, but there are thousands of devices running FPP 7.3.5 just fine. Maybe, just maybe, this problem is limited to your system, or your configuration.  PLEASE start with one problem, stay in the same thread until the first problem is resolved, follow up to questions, and let us know what you have tried. 

7.3.5 is stable for me.  Anything that 7.3.0 touched was problematic.  Once I downloaded a new 7.3.1 image, installed fresh a copy, restored from backup, and then upgraded to 7.3.5, it has worked for me.  If you have tried that, you could go back to 7.2, but maybe it is a problem with the pi/bbb, or maybe it is a weak power supply, and then NO VERSION is going to be stable, because the issue is not with the software.
 
 

[Ebuechner]

Minimal information! I wish I could give you more information. This is running on a pi 4 which is the same setup that I've had for several years. Only difference is the FPP version. The pis are being powered by a mean well power supply that I have a power meter attached to and the voltage was stable when I was having the problem. Last time I had this glitch I reset everything and it didn't happen again so I thought it was a one-off problem. I do plan on taking your suggestion and loading a new FPP on a different SD card and then do a backup and restore onto the new SD card. Skipping 7.3.0. but this has been an intermittent problem that I can't reproduce at will. The one sequence that I have out of 73 that acts up I can reproduce easily. I have to leave town in a week's time for a while and it'll be nice to know that I can rely on this while I'm gone.
Id like to point out that you'd mentioned that you have seen this on your system a few times. Then you said that the last time it happened you restarted FPPD and all was good.

[CaptainMurdoch]

For the fseq that is acting up, the only way for us to test that will be for us to have the .fseq so we can see if it gives us the same error.  If you uploaded the models to FPP from xLights, you could also use FPP's HTTP Virtual Display to see if the lights go out on the Virtual Display.  Maybe the problem is in the render side, not the player side.  Have you watched the FPP Status page while the sequence is playing.  Does it stop playing at that point?  If so, then it could be corrupt which could point to multiple different possible issues.  If you can post the .fseq and virtualdisplaymap file (which can be downloaded from the FPP File Manager Upload's directory), then someone might be able to see if they can figure out what is going on with the sequence.

[JonD]

I have seen the issue several times, but mainly after 7.3.0 and before re-imaging to a fresh copy of 7.3.1.  I have only had a couple of issues since, and only then after I was messing with the player while the show was running.

I would place the problem sequence in the penalty box for now, once everything is stable we can add it back to the mix.  If everything is stable except for the one sequence, I am not sure re-imaging is step one.  I would focus on the sequence. 

[Ebuechner]

I used a fresh SD card this morning and installed 7.3.1 and then upgraded to 7.3.5 as suggested.
Did a backup and reloaded all of the sequences after doing a render all.
I even went as far as to delete the FSEQ file for the sequence in question as well as the render cash from xlights before doing the render all and even renamed the sequence and audio file. 
The sequence still acts up and it even glitches in the virtual display (I didn't know that existed before).
The sequence ran fine last year. I even tried going back to last years xlights and doing a render on the sequence and still had the same issue.
Getting the sequence to work would be a bonus but the big thing for me is having FPP run without locking up occasionally.
I went into the file manager /uploads and I can't find the virtualdisplaymap file

[CaptainMurdoch]

If it glitches in the Virtual Display it is more than likely an issue with the .fseq file so we'll need to see it.

I gave the wrong location of the map file.  It is in the config directory.  You should be able to use a URL like the following one to download it:

http://yourfppinstanceip/api/configfile/virtualdisplaymap

It will probably display in your browser, so you may need to right-click and select 'Save As' from the browser's popup menu.

[Ebuechner]

https://drive.google.com/file/d/1d1kn0LiFi38c3pyAUkxZE4zAZ8M1gxCE/view?usp=sharing
https://drive.google.com/file/d/1FYzfcTSL2nf7xLj-w1TgSNxdHl7Fe2CG/view?usp=sharing

[JonD]

What version of xlights are you using?  I am sure you probably posted at some point, but the search feature only works for me every 10th try.

[Ebuechner]

2023.20 on a Ryzen 9 / windows 10.

Right now I'm loading all my files on a USB drive so I can transfer to a different computer, and see if I get a different results with generating an FSEQ file from a different computer.
Maybe all my troubles have been from unstable FSEQ files?

[CaptainMurdoch]

This sequence glitches on my beefy server development systems as well.  I even uncompressed the .fseq into a 4GB uncompressed version and it still glitched.  I am leaning towards it being a rendering issue.  Has it always glitched in the same exact spot every time you have regenerated it in xLights?

[JonD]

Maybe all my troubles have been from unstable FSEQ files?

You would like to think xlights would error on the the render.  What does the xLights "Check Sequence" report look like?  From the xlights "File" menu "Export House Preview Video" option, can you save the video and play it without the errors?  Will the sequence play correctly when you select "output to lights" in xlights?

[Ebuechner]

I only get one whiny warning on all of my sequences because I have autosave turned off.
What really throws me is the sequence runs perfectly from xlights and will output just fine.
I just tried the video and it works fine too.

[Ebuechner]

That sequence is a few years old and this is the first year that it glitched. When I see it glitching on my show. It's always in the exact same spot but it doesn't seem to follow any pattern. I kept on watching to see if there was one affect or something that I could point my finger at but I really can't put anything together. What gets me is that's a sequence that I put together for someone else so I'm not the only one with a copy.