There are a lot of threads describing the problem that MM is using 100% CPU time if during the start of MM a big Now Playing playlist is loaded. I often play a random mix of my whole collection and have also this problem.
What I do not understand is the following:
When I start MM with my whole collection in the Now Playing playlist I can see how all the tag data (interpret, album and so on) are displayed one line after the other for each song of the Now Playing playlist, and this takes for ever (the track names are all shown immediately). In the bottom line "Playlist: Reading tracks..." is shown and CPU usage is almost 100%.
But when I interrupt this reading by selecting another playlist or even my whole library and replace the Now Playing playlist with these songs all tags of all songs (even of my whole library) are shown immediately, CPU usage is going down to almost 0% and the "Reading tracks..." is no longer shown.
So, why can MM read songs very fast when putting them manually to the Now Playing playlist after MM has started, but reads the same songs very slowly when it recreates the previous Now Playing playlist during it starts?
Isn't it possible to change this?
100% CPU usage during start of MM
Moderator: Gurus
The tracks in your list are in your library so reading the information takes a very small amount of time. The tracks in your now playing list are not necessarily in your library and therefore the information needs to come from the tags. This is why it takes longer.
Download my scripts at my own MediaMonkey fansite.
All the code for my website and scripts is safely backed up immediately and for free using Dropbox.
All the code for my website and scripts is safely backed up immediately and for free using Dropbox.
Why are the tracks of my now playing list not necessarily in my library?
And even if some are not, I assume that probably most of them are. Wouldn't it thus be better (and faster) to try to read the information (title, artists...) first from the library and only for these tracks which are not in the library from the file tags. In this way displaying the now playing list could be much faster and would block the whole computer.
Another solution: It seems that the file names of the tracks of the now playing list are stored in a database, since the file names are displayed at once after starting MM. Isn't it possible to store the displayed information (title, artists...) in addition in this database?
Dieter
And even if some are not, I assume that probably most of them are. Wouldn't it thus be better (and faster) to try to read the information (title, artists...) first from the library and only for these tracks which are not in the library from the file tags. In this way displaying the now playing list could be much faster and would block the whole computer.
Another solution: It seems that the file names of the tracks of the now playing list are stored in a database, since the file names are displayed at once after starting MM. Isn't it possible to store the displayed information (title, artists...) in addition in this database?
Dieter
1) Lots of people play files by double clicking on them, so they appear in Now Playing but have not been added to their library
2) Now Playing gets the information from the files because it needs to check they are there and it is more useful to know the actual track details. In my opinion in is better (but slower) for it to do it this way.
3) This would encourage duplications of information and therefore inconsistencies.
I was about to suggest a script to fix your problem but I've just realised you are the same person that I am discussing this with in a separate topic. For anyone else, check this out: http://www.mediamonkey.com/forum/viewtopic.php?t=4644
2) Now Playing gets the information from the files because it needs to check they are there and it is more useful to know the actual track details. In my opinion in is better (but slower) for it to do it this way.
3) This would encourage duplications of information and therefore inconsistencies.
I was about to suggest a script to fix your problem but I've just realised you are the same person that I am discussing this with in a separate topic. For anyone else, check this out: http://www.mediamonkey.com/forum/viewtopic.php?t=4644
Download my scripts at my own MediaMonkey fansite.
All the code for my website and scripts is safely backed up immediately and for free using Dropbox.
All the code for my website and scripts is safely backed up immediately and for free using Dropbox.
1) I have all my tracks in MM, so I wasn't aware of that. But the solution of item 2) (first check the library and only if the track does not exist in the library check the file) would solve this problem.
2) If a file is no longer available (has been deleted or renamed) then it will also not found when looking for file tags.
If you mean that the information (file tags) have been changed then I would prefer to use the library entries, because these are also shown when I browse the library.
I often play a random mix of my whole library (about 6000 tracks) and it takes a huge amount of time until all tags are read in the now playling list. During this time almos 100% of CPU time is used. This is really an issue since I can almost not use my computer during this time.
I really like your ClearNowPlaying script as a workaround but this means that on the next day when I want to continue with playing the files I have to re-add them to the now playing list and re-mix the now playing list in order to have a random play. But this is not really a _continuation_ of the tracks I have already heard, since it is possible that some of the tracks which have been played yesterday will be played again today. In addition it is not possible to go back through the songs I heard the day(s) before.
Couldn't it be at least an option (in the settings) whether the library data (if available) or the file data is used for the now playing list?
3) Don't such inconsistencies already exist when you change the file name of a track in MM (it is then changed in the library but not in the now playing list)?
Dieter
2) If a file is no longer available (has been deleted or renamed) then it will also not found when looking for file tags.
If you mean that the information (file tags) have been changed then I would prefer to use the library entries, because these are also shown when I browse the library.
I often play a random mix of my whole library (about 6000 tracks) and it takes a huge amount of time until all tags are read in the now playling list. During this time almos 100% of CPU time is used. This is really an issue since I can almost not use my computer during this time.
I really like your ClearNowPlaying script as a workaround but this means that on the next day when I want to continue with playing the files I have to re-add them to the now playing list and re-mix the now playing list in order to have a random play. But this is not really a _continuation_ of the tracks I have already heard, since it is possible that some of the tracks which have been played yesterday will be played again today. In addition it is not possible to go back through the songs I heard the day(s) before.
Couldn't it be at least an option (in the settings) whether the library data (if available) or the file data is used for the now playing list?
3) Don't such inconsistencies already exist when you change the file name of a track in MM (it is then changed in the library but not in the now playing list)?
Dieter
Maybe you should suggest a rework of the now playing list in the wishlist forum so the MM team can look at improving it.
Download my scripts at my own MediaMonkey fansite.
All the code for my website and scripts is safely backed up immediately and for free using Dropbox.
All the code for my website and scripts is safely backed up immediately and for free using Dropbox.
Shouldn't Jiri or someone else from the MM team read this thread in the bug reports forum?
I consider this more as a bug due to the heavy CPU load which is used (and I have to admit, I shy away from the effort to describe and summerize all what has already been written in this thread).
Jiri, if you read that, can you please comment on it?
Thanks a lot
Dieter
I consider this more as a bug due to the heavy CPU load which is used (and I have to admit, I shy away from the effort to describe and summerize all what has already been written in this thread).
Jiri, if you read that, can you please comment on it?
Thanks a lot
Dieter