Beta 2112 - slow start again

musicadi

Peter, something you changed in 2112 seems to have increased starting time again.

Previous version was perfect in this regard. The app was started in about 1-2 seconds

Now, we’re back to 4-5 seconds.

musicadi

Interesting… after a few times opening and closing the app, I get 1-2 seconds starting time again, but once I use other apps and start ST4, I’m back to 3+ seconds

peter

I haven't changed anything in build 2112 that could affect start times. Most likely this is caused by something else running on your device.

musicadi

peter Also happens with no apps running.
Tried after a fresh ST4 install, forced reboot (hold On/Off + Home buttons) - waited a few seconds then opened ST4.

Then I opened Safari to type this reply, and ST4 crashed. The feedback window disappeared when I was trying to switch to Safari, but I created a support email with the logs.

AnthonyB

musicadi what is the CPU readout saying when you are at the front screen of ST4?
Do you have ST3 on the device? Does it behave the same (i.e. possibly some other audio app/process trying to interface with ST)?

Sorry, generic troubleshooting steps next to reduce/isolate outside possible impacts. test/validate between each as trial and error:

Ensure nothing is physically connected to the iPad
Turn off Bluetooth
Offload/Uninstall any other audio apps or apps that can run as an AU plugin or in someway 'interface' with ST4

musicadi

CPU load starts at 100% right after ST4 main window is rendered, the settles to about 10%

No other apps running, no AU plugins, bluetooth is off. ST3 installed, but not running

peter

Sorry, this is something I will not spend time on investigating. App startup times are only a minor concert. You start the app before the gig and that's it. Whether it needs 2 seconds or 4 seconds does not really make a difference.

musicadi

peter Ok, no worries 🙂

Just one thing that I can always reproduce that might be relevant:

select an empty window in the sidebar (ie. empty queue)
close the app
when opening, the sidebar width is increased at the same time when CPU load is 100%

I haven’t changed the default width.

AnthonyB

musicadi OK, now that is intriguing and I can partially repro that.

My repro results are a little different, but still unexpected.

Build 2135 on my 9th Gen iPad (iOS26.1.0) in portrait mode.

Open sidebar and create an empty Playlist
Go into the empty Playlist
Close ST4
Open ST4
Observations:
ST4 never opens with the empty Playlist visible, it always opens 1 level up at my root folder level showing a list of Playlists.
The sidebar right border 'creeps' a little to the right every single time. Just a bit, but it is visible if you are watching for it.

Video link - https://imgur.com/a/st4-2135-sidebar-empty-playlist-Zeu8clZ

Now, on the sidebar border movement, I suspected that we might be seeing an initial default position on app open, then a re-draw based on 'last known position'?
I tested this theory by:

setting the sidebar quite narrow and open/closing (sidebar seemed to open 'wide' then become narrow)
setting the sidebar quite wide and open/closing (sidebar seemed to open 'normal' then become wide)

So... the sidebar position change could be either a visible re-draw effect, or it could actually be creeping from last stored position, I'm not ruling out either.

What I am definitely seeing consistently is that the sidebar will never seem to open into an empty Playlist. Very much as edge case and pretty minor impact so really a low priority issue.

musicadi

AnthonyB Yes, I can also reproduce that. If a playlist was open when closing the app, at restart, the root playlist folder opens.

BTW the sidebar “redrawing” is also there with the default width. It doesn’t happen in the songlist though.

Looks like the “Loading…” message appears in a sidebar with a given width, and only later is the current width grabbed.

peter

Stage Traxx does not remember the detailed navigation path in the playlist window when you close the app. This caused issues on iOS versions below 18 and for consistency I removed it completely. So it remembers that you are in the playlist sidebar but you always start at the root when restarting the app. Same with the songs. You will never restart within a folder. Only at the root.

musicadi

peter Oh, okay. Are you also seeing the sidebar resizing just after starting the app? It happens at the exact time when the CPU load is 100%

peter

No, the sidebar does not change width. Do you have the iPad maybe lying flat on the table?

AnthonyB

peter No, the sidebar does not change width. Do you have the iPad maybe lying flat on the table?

Yes. That was the orientation when I tested and recorded the video.

peter

OK, that is caused by the uncertainty when iOS reports "flat" as being the current orientation. In that case the app defaults to "portrait" but that only happens once data is loaded and the view is initialised. Nothing to worry about and most users will not use ST when the device is lying flat.

musicadi

peter I just sent you a screen recording of what I mean.

I made the sidebar extremely wide on purpose, so you can see the effect.

This only happens in Playlist and Queue views.

I held the iPad straight.

AnthonyB

I retested with 2153 and holding it in portrait mode. I even deliberately rotated to Landscape, then back to Portrait, to ensure the Portrait orientation was the current 'known state'.

After closing ST4, then opening, there is still a noticeable draw, then redraw (which makes it look like the sidebar width changes), of the sidebar right border.
I get the sense that there is always a default position (width) of the sidebar on app launch (only after closing it), and then it re-draws it based on the the 'last known position'.

That said, I only observe this on the first time the app is launched after it is force closed, so based on what I'm observing, this is quite a minor issue in the big scheme of things.

musicadi

AnthonyB Doesn’t happen in the Songlist window, or at least it’s not visible.

It might be minor, but it could be the cause of the slower start.

Check the CPU: it jumps to 100% at the exact same time the sidebar seems to be redrawn (could be a coincidence, of course, since that’s also when the database is loaded)

AnthonyB

yeah, CPU spikes, but as you say, database is loading, song is being loaded, lots of stuff going on at that time to CPU spike is expected. I guess how long is spikes for is also going to be dependent on CPU generation, size of song database, complexity (lyrics, regions, number of tracks, etc.) of default selected song being loaded into player.

I'm using a 9th Gen iPad which has a 6-core 2.6 GHz A13 processor.
From memory you have an iPad Air 3? That has a 6 core 2.49 GHz A12 processor.
Based on https://www.cpu-monkey.com/en/compare_cpu-apple_a12_bionic-vs-apple_a13_bionic there's about a 30% jump in benchmark performance.

Not sure how many songs in your database (min is only about 150), and tracks per song on average (mine is generally 2 stereo audio files, 320kbps MP3)...

Assuming you have a reasonably sized database, it would be interesting to see if you see a performance difference by starting over (after a full backup obviously) with just a handful of songs. If you see is sizable perf difference, then it is more likely due to a sizable song database on a 'mid-strength' device.

musicadi

AnthonyB I have about 400. I'm almost certain iOS 26 is still crawling with bugs, so many of the issues spark from there. In any case, I think ST4 is pretty stable and everything runs smoothly now, so I would feel comfortable using it live.