The CPU usage of the program is becoming an issue for us because it means that we can’t use any version above 2.1.10 in the studio as the computer there isn’t very good!
Just thought I’d mention it and see if anyone else has the same problem?
As of v2.1.18, I have reduced the update frequency of the progress bars. mAirList should perform much better now.
Other options which could be worth trying to disable:
- Remaining time display in playlist.
- Playlist icons.
Does any of these tips help? Please let me know, I might find the reason for the high CPU load and prevent it.
Torben
I have further investigated this problem, which seems to be a major issue. The CPU load is generated by the playlist GUI object.
Given that you have enabled the progress bar and/or the remaining time display, the row of the playing item needs to be repainted regularly (at least ten times per second). This seems to be an expensive operation, in particular when the item has a comment.
I have now introduced some optimizations which lead to a much lower CPU load (2-3% on my AMD 64) as long as you play only one item as a time. As soon as two players are active, the CPU load is still at about 25%, which is much too high. I will try to find out the reason for this strange behavior.
Torben
Hi,
The mAirList setup we have has no playlist icons and no countdowns. The main progress bar is also disabled.
mAirList became unworkable on Thursday to the point where I actually took the station off air because the system was taking far too long to respond - we ended up playing out of CD players and mobile phones until an emergency computer could be drafted in!
The new computer has 512mb ram and 160gb hdd and seems to run OK. It’s on a fresh install of Windows XP Home with AVG Antivirus and Juice podcast downloader running, as well as Icecast media server and SimpleCast encoder.
Some more observations regarding the bad playlist performance:
When an item is playing, its node in the playlist GUI is constantly redrawn a few times per second, in order to update the progress bar and remaining time/ramp. (As of mAirList 2.1.20, this also happens if both features are switched off.) The “expensive” operation during the update is the redraw of the item comment - the longer the comment gets, and the more lines it takes, the more CPU cycles are consumed. This can already be observed in mAirList 2.0, but it seems to be even worse in mAirList 2.1. Though I’m not quite sure why.
mAirList 2.1.21 will try to reduce the repaints to a minimum number. I’m also looking into a possibility to redraw only part of the node - that is, the progress bar - during the frequent updates.
Gavin, that doesn’t sound good - perhaps there is another issue which is not related to the playlist?
Torben
Gavin, that doesn't sound good - perhaps there is another issue which is not related to the playlist?
Gavin - is that me?
Oh, Ant, my apologies, I had just read a different post by Gavin, and I mixed up the names 
Heh, no problem.
As far as the problems go - We relaunched our old playout PC later and disected it to see what was wrong. The only programs running were mAirList, Juice, Icecast, and Simplecast - not even antivirus was running on this occasion.
It may have been something else - I’m not sure if there was a memory stick plugged in, copying files, for instance - but something wasnt right.