Any tips on improving xSchedule playback?

Hi all, hope your November/early season is going well!

I hope this is the correct place for all this, very sorry if it is not.

I have started doing tests on my display. I am new to this, and it is a relatively small display - only about 1500 channels total. I have encountered some issues with xSchedule, the first being packets per second counter drops occasionally (I do get output though), and the turtle appears next to the counter. The other is also related to the packets per second as well. For some reason, xSchedule is only outputting 42 packets per second, when it should theoretically be around 80 (right?). The sequences are 40FPS FSEQ files, and the network is DDP. And since DDP only permits 1440 channels per packet, it should be 80 right? I have xLights configured to output 1500 channels, andboth are using the same xlights_networks.xml file. Any ideas on how to fix this?

In terms of the packet drop issue, I should mention that the playback computer is an old 2012 MacBook Pro with a dual core i5, 512GB hard drive, 4GB ram. Definitely not very powerful in terms of today's standards. It is running Mojave, the 2018 release. Multi-threaded transmission is enabled, which seemed to yield some slight improvements. The copy of xLights that is running is an old version of xLights for Mac with xSchedule (2019 or so). I made the sequences on my primary laptop, and transferred the fseq files onto the playback computer. All of the audio playback files are WAV, which should take less processing time compared to MP3. The playback computer is connected to a Netgear GS305 gigabit switch, which connects to the controller which is a 2022 edition Genius Long Range. The controller network is connected to the built in Ethernet port on the Mac, and it is separate from the home network. Could the laptop possibly be too slow to run the 40FPS sequences? xSchedule is using about 14 percent of the CPU when I looked in Activity Monitor, no other big processes that I can see. I am thinking maybe replacing the hard drive with an SSD might fix this, anyone else have similar experience?

Thanks for your time, and happy holidays!

pkittenguin124 said:

old version of xLights for Mac with xSchedule (2019 or so).

Click to expand...

I would tackle this first. xLights has come a long way since then. Get up to a 2024 version of xLights on your player laptop.and see if the issue is still there. Might be some issues between your primary computer xLights files and your player laptop version of xLights

Your computer should be fast enough to run xSchedule fine (after all i am running FPP from a raspberry Pi)

It might also be worth upgrading the software of your Genius Controller to the last version, again some improvements/bugs have come up recently.

See how you go

Johnnyboy said:

Get up to a 2024 version of xLights on your player lapto

Click to expand...

Sadly not an option. xSchedule was removed from xLights Mac a fair while ago.

pkittenguin124 said:

xSchedule is only outputting 42 packets per second, when it should theoretically be around 80 (right?).

Click to expand...

No - 40fps * 1500 channels = 60,000 channels per second., At 1440 ch per packet, that needs 41.6 packets, so 42 packets total.

pkittenguin124 said:

I am thinking maybe replacing the hard drive with an SSD might fix this,

Click to expand...

Doubtful. Unless if the lags co-incide with disk access. In Activity monitor, try to correlate the disk read counter with the lags/turtle.
A fseq with zlib compression is tiny - especially for 1500 channels.

Also I'd look at any small spikes of CPU that could be causing it.

pkittenguin124 said:

All of the audio playback files are WAV, which should take less processing time compared to MP3

Click to expand...

If it is disk access causing the issue; then having MP3s would yield a better result. A 3 minute CD quality file is a 30MB WAV or 3MB MP3.

Skymaster said:

No - 40fps * 1500 channels = 60,000 channels per second., At 1440 ch per packet, that needs 41.6 packets, so 42 packets total.

Click to expand...

Hold up, I might be talking crap here. The math adds to what xSchedule is showing though. Time to investigate

if you are going to spend money, sadly migrating away from the Mac is the best option - to something more long term supportable like FPP on RasPi or xSchedule on windows

darylc said:

if you are going to spend money, sadly migrating away from the Mac is the best option - to something more long term supportable like FPP on RasPi or xSchedule on windows

Click to expand...

True. Spend $100 on a Pi and a Sound blaster Play3 and you're done.

Skymaster said:

Sadly not an option. xSchedule was removed from xLights Mac a fair while ago.

Click to expand...

Interesting! Not a Mac person so just assumed it was the same as windows.

Thanks for your replies!

Skymaster said:

Doubtful. Unless if the lags co-incide with disk access

Click to expand...

The sequences do start slow initially at ~30 packets per second when xScheduler changes sequences. Going to convert the WAVs to MP3s tonight and see if that changes anything.

I did notice that when I do anything else on the computer, such as open a browser or load anything else like an interface menu the packets per second ct momentarily drops down to 20 or so.

Johnnyboy said:

upgrading the software of your Genius Controller

Click to expand...

I feel like it is a problem on the xSchedule side of the matter because when I disconnect the MacBook from the wired network and play the sequences I get the same results. I also ran a ping test in the Terminal, it said no packets were lost and each took on average 0.55 milliseconds to receive. I do have the 2019v xSchedule running, I could try one from 2020. I am honestly not sure why I did not install the last available 2020 version instead.

I know DDP was a newer protocol at the time in 2019 when that version of xLights was developed, maybe the xLights development team has improved their implementation of it. I can try it with ArtNET or sACN and see if I get better results.

But I have a new problem that I recently discovered, it seems like only xSchedule can actually output something to the controller. When I run test mode in xLights itself (the one with the sliders & chase patterns), there is no DDP data created. I checked the Input page on the Genius controller to see if there was any DDP packets going through, the only DDP data comes through is when xSchedule is outputting it.