New: More powerful "My music" layout (1 Viewer)
- Thread starter toby451
- Start date
Germany
I did some work on this a couple of months back. The issue as that this type of view is a real resource pig. Consider that for each item in the list MP must retrieve the artist info, artist albums and thumbnails for those albums. As you might guess, this slows MP down very noticably. I haven't ruled out finishing this but I need to work out a (significantly) better and more resource friendly way of getting and caching the data and images.
SteveV said:
SteveV - I for one appreciate your looking into this as a possiible screen (only as an option) for the Music plugin. As an idea I had, maybe this could be a realational database connection instead of the flat method it currently is in. But then I am not sure if SQlite would allow such a connection between songs and albums, but shouldn't this allow for a speedier lookup? In addition to that idea maybe the creation of thumbnal cache for each Artist for display could also help in the display of that info - then the CPU resources should only be required when a new artist or CD is added to the list. At least in theory - But then too I could be full of hooey.
Mike
Mike,
This would be a database view so yes, we'd be retrieving the album info from the the db. However, each artist in the list could have as many albums as can fit on the list control item, say 10-12 thumbnails per item. The list control itself contains 12 - 14 items depending on how it's layed out.
12 * 14 = 168 thumbnails worst case
The current views have 1 thumbnail per list item: 14 thumbnails worst case.
I'm not saying it's not possible just that it *will* be slower. I'm of the opinion that it's already too slow
. So, until I can come up with a better way to quickly access the thumbnails, I don't want to sink a ton of time trying to get it to work--need to put a little more thought into it. Hope this makes sense.
This would be a database view so yes, we'd be retrieving the album info from the the db. However, each artist in the list could have as many albums as can fit on the list control item, say 10-12 thumbnails per item. The list control itself contains 12 - 14 items depending on how it's layed out.
12 * 14 = 168 thumbnails worst case
The current views have 1 thumbnail per list item: 14 thumbnails worst case.
I'm not saying it's not possible just that it *will* be slower. I'm of the opinion that it's already too slow
. So, until I can come up with a better way to quickly access the thumbnails, I don't want to sink a ton of time trying to get it to work--need to put a little more thought into it. Hope this makes sense.
OK - Not to belabor the point but just to finish out my idea, then I will stop. Is it the retrival of the thumbnail or the text data that takes up the most amount of time? If it is the thumbnails (since they are graphic and takes more resources) why not create a mini-thumbnail cache for each artist which should be built only when a new CD or song is added? Then for each time it is queried for that artist the retrival of that long graphic image should be faster than to try and build those thumbnails on the fly.
I am trying ot look at this as two different issues and maybe they aren't.
If it isn't worth the effort and your time can be better spend on other features I completely understand.
Mike
I am trying ot look at this as two different issues and maybe they aren't.
If it isn't worth the effort and your time can be better spend on other features I completely understand.
Mike
One word:
EXCELLENT!
EXCELLENT!
The db access time should be negligible and we already create and save thumbnails to the \thumbs\albums folder for the other views. it's more of n IO issue at this point;
load 168 thumbs
paint 168 thumbs
user presses page down...
release the resources for 168 thumbs
load the next group of thumbs
etc.
Bottom line it *has* to be slower than it is now. There are a number of ways to get around opening 168 seperate files. We could create an image strip for each artist and the strip could contain all of the album thumbnails. End result is one image file open per artist vs 16. That said, I haven't given up on it. Just not ready to move forward.
load 168 thumbs
paint 168 thumbs
user presses page down...
release the resources for 168 thumbs
load the next group of thumbs
etc.
Bottom line it *has* to be slower than it is now. There are a number of ways to get around opening 168 seperate files. We could create an image strip for each artist and the strip could contain all of the album thumbnails. End result is one image file open per artist vs 16. That said, I haven't given up on it. Just not ready to move forward.
SteveV said:
That was what I was trying to convey as my idea but I wasn't very good at communicating it.
I know I have said it once, but it is worth saying again - Thanks for your work and your support on the MyMusic plugin in general. I appreciate your contributions in the MP community!
Mike
*UP* *UP* *UP*
We really want this!!!
How are things coming along?
We really want this!!!
How are things coming along?
This would be totally awesome. Many thanks to all who are working on it.
Perhaps if it is too slow, the number of displayed lines could be configurable? A fast machine might be able to show 20 lines, while an older machine could be set to 5. If the graphics scaled with the number of lines, this would also be nice just for overall visibility.
Perhaps if it is too slow, the number of displayed lines could be configurable? A fast machine might be able to show 20 lines, while an older machine could be set to 5. If the graphics scaled with the number of lines, this would also be nice just for overall visibility.