View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005316 | MMW v4 | Playlist / Search | public | 2009-02-19 14:11 | 2009-03-05 01:28 |
| Reporter | Ludek | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0005316: Limited Auto-playlists (restricted to X tracks or MBs or minutes) can be slow for some operations | ||||
| Description | Problem is analyzed here: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=37262&st=0&sk=t&sd=a&start=15 One auto-playlist with Rating<0, Staus is not podcast, Path contains ":\Media\" or "\Music\", Genre doesn't contain "Spoken Word" or "Xmas", this one takes more than 2 seconds on DB with 27477 tracks when performing Find more from same -> Playlist operation. The reason is that this auto-playlist is limited somehow (number of tracks ?, megabytes ?, minutes ?) and therefore we perform full query and get X tracks from DB and then determine whether the track belongs to this subset. We do so because everytime you use an auto-playlist that is somehow limited (e.g. to 500 tracks) then criteria based on sort order (date added in this case) could change and therefore we get all the current 500 tracks from DB. Possibilities to improve performance of this are: 1. Instead of getting all the tracks from DB and then putting them back by pre-filling PlaylistSongs table and then performing a query as for regular playlist we could improve this by using e.g. 'HAVING SUM(SongLength) < X' SQL clause or something like that. 2. As the user suggested: would be great if MM was able to expand the "more from same / playlist" menu even if it hasn't finished populating it - that way it wouldn't freeze up MM at all for anyone and longer playlists would just appear in the menu once they could. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1225 | ||||
|
|
I am not sure about 1. i.e. using the 'HAVING SUM(SongLength) < X' could on the other hand slow down filling tracklist by tracks from such auto-playlist. Not sure, this probably needs to be tested. The best way seems to be to use 'HAVING SUM(SongLength) < X' only for operations like this (find more from same playlist and for the List of playlists to which a song belongs in Song Properties - Classification tab). |
|
|
Re 1: SUM() is not acceptable when used in conjunction with HAVING or WHERE, so there is a problem with this for "megabytes" and "minutes" restrictions/limitations. But in case of limitations for number of tracks there can be used LIMIT clause and this speeds up things a lot. So for MM 3.1 I fixed (improved performance) at least limitations with regard to number of tracks. The performance is improved in build 1225. |
|
|
verified 1225 no regressions introduced |
