Further examination shows that this is rooted in the fact that the initial lookup is a single query into the db, whereas for the .m3u playlist, the metadata for each track must be looked up individually in order to fully populate the Now Playing list.

Another possible approach that we discussed is to only populate those portions of the NP list that are visible (as Winamp does), however, I'm not certain that this 'solution' is better than the 'problem'.

So for now, we're going to leave this as is.

-Rusty

rfactor,

I'm able to replicate the problem--we're looking into it. Thx for the feedback.

-Rusty

MM in my experience takes quit a while to read the song info. I normally have a 1000 tracks loaded in the Now Playing and it takes a minute or so. I have never checked if CPU usage is at 100% during this.

I have found what appears to be an issue with the auto-reload of the 'now playing' list upon restart of MM when used with large selections.

I am using:
Windows XP Pro SP2
AMD Athlon XP 3000+ with 1GB memory
MM 2.3b1
Network share of music (55,000 songs, 220GB)

I can load my entire music selection (55k tracks) into the now playing area, and CPU usage will spike to 100% while loading, and then a few seconds later drops down to 0-2% average. That's normal operation.

However if I shut MM down while I have my entire selection in 'now playing', and then restart MM, CPU starts up at 100% (normal) but it then remains at an average of 97-100% CPU usage (as reported by windows task manager). This behavior will remain until I load a reasonably sized 'now playing' list and restart MM.

Once MM has been restarted I can then once again load my entire selection into 'now playing' and it will work fine until MM is restarted and it auto-reploads that very large 'now playing' selection.