I sincerely hope no one out there is tracking Cesium user reviews as closely as I am, but if you were you would notice a concerning trend over the last 6 months. An increasing number of users report experiencing strange lags, delays, and general performance issues.
While the reports look similar, diving in deeper revealed a ton of inconsistency. There didn’t seem to be a specific trigger or action, the issues were consistent for some users and sporadic for others, and in general there wasn’t a clear explanation why some – but not all – users were affected. It was a devil of a problem that I couldn’t replicate on my own devices. It wasn’t until I began collecting crash logs that a pattern became clear.
Cesium delegates actual playback to the iOS system player (needed for iCloud and Apple Music support). This means that Cesium must communicate with the system on an ongoing basis, basically just to make sure that the two are in sync. In some instances Cesium requests a certain property of the system player, while the system posts notifications about changes to certain properties that Cesium can listen for. They basically fall into two groups:
- Player State Properties: these are needed so that the UI reflects the current state of the system player. The details of the currently playing song, whether playback is paused, playing or stopped, the current playback time in a track, shuffle and repeat modes, etc.
- Queue Properties: these are crucial to how Cesium interfaces with the system queue. The count of items in the queue, where the system player is in that list, fetching tracks from the system queue, etc.
What the crash logs showed were that the system was not always returning these properties in a timely way. In fact, the app was crashing because it exceeded the iOS cutoff for inactivity – while waiting for the system player to return. Instances where a property was returned more quickly might avoid a crash, but could still cause a period of unresponsiveness. The logs showed that certain properties were more common culprits, but crashes were caused by a variety of them.
Great, so you can blame Apple again. What can be done?
Well, first I could (and have) reported the issue to Apple. Next, I had to look for ways to decrease the number of calls to the system. Unfortunately, not all calls can be omitted or Cs would show no playback info and be pretty useless. But a lot of the queuing stuff could default to the standard boilerplate functionality provided by Apple. There would be less functionality, but there would be fewer system calls, and in theory better performance.
Cesium 4.2 will include a new setting called “Advanced Queuing”. This setting controls all of the extra queuing features that have become part of Cs over the years: viewing the queue, queue reordering and reshuffling, shuffling by album or grouping, playback history and the resume queue feature. If you are experiencing performance issues, disabling this setting may be a solution. Advanced Queuing will be enabled automatically for updating users, but will be disabled by default for new downloads. I look forward to working with Apple to resolve the root issue.