Feature request: About the new Media Library plugin

[mistersister]

Just a suggestion:

I recently switched to the nightly build and realized there is a new media library plugin (which is awesome to have btw).

Since it has no config options I assume is into early stages of development but I'd like to make a couple of suggestions:

• The ability not to load any covers. Should offer better performance
• The ability to remove icons altogether. Or at least let icon size be configurable.

Thanks.

[Oleksiy-Yakovenko]

Hello,

thanks for the feedback.
You are correct, the feature is still under development and testing, and some settings will be added along the way.

Could you please share more details about performance issues that you encountered?
From what I understand, medialib performance is exactly the same as the general performance of probing/adding files to playlists, and it's already optimized pretty well, but perhaps I'm missing some other area?

[mistersister]

After adding all my music folders, scrolling the list and expanding/collapsing directories seemed to be slow, much slower than the filebrowser plugin I had been using previously.

However today seems to work just fine and can't appreciate any slowdowns while navigating the plugin. Maybe it was just because it was the time loading all cover arts?

Apart from this I think the stability seems to be pretty solid

[Oleksiy-Yakovenko]

It could be because of that, yeah.. Or because the library was still scanning in background.

[kuba160]

From my experience I think I can say that coverart loading in medialib is somewhat slow for me. I don't know what speed is to be expected though, and my setup has music stored on network drive (which I guess can cause bigger latency). When reloading deadbeef and jumping down it takes 1 second for the covers to start showing up. Sometimes scrolling the list cover loadning process can even take 5+ seconds but I couldn't reproduce it reliably. I have no proof but this reminded me of pretty similar bug when porting cover art to windows: There was a race condition that discarded the just loaded cover and tried to load it again in a loop until the conditions/timing was right.

Also I have a feature request: When deadbeef launches on system startup the drive sometimes isn't attached yet which causes the media library to be wiped out. It would be nice to have a feature that will prevent that. Solutions that come to my mind is rescanning the unavailable folder after some time (5-10 seconds maybe?) and/or a popup for user action (rescan, delete from media library, maybe keep cached library as is?).

EDIT: the race condition fix was for gtkui covermanager in this commit: 53c4691

[Oleksiy-Yakovenko]

I haven't encountered any slowness in medialib viewer when expanding / collapsing, and there's no lazy scanning -- so if the folder is visible, all data is immediately available, and there's no IO to do that. However, perceived slowness can be experienced from seeing the cover images lazy loaded. It's not a performance problem since it works by design, and it takes time to load the image files.

[kuba160]

I haven't encountered any slowness in medialib viewer when expanding / collapsing, and there's no lazy scanning

Just to be clear, me neither.
I'm suggesting that covermanager in gtk is not handling cover requests very efficiently, especially with many cover art requests (that only medialib can generate) which in turn can stall and prevent some covers from being updated.

[kuba160]

When inspecting how covermanager is called I found many repeating calls to covermanager_cover_for_track_no_default and to covermanager_create_scaled_image. It seems like _pixbuf_cell_did_become_visible can be called a lot, not sure why and if it was taken into consideration. From my 377 album library and single list jump it called for cover 4000 times (which can be fine) but called covermanager_create_scaled_image over 5000 times.
One possible loop:

1. _pixbuf_cell_did_become_visible gets called
2. It calls covermanager_cover_for_track_no_default
3. It returns NULL and will process the completion block.
4. Completion block starts and scaling of cover starts.
5. _pixbuf_cell_did_become_visible gets called again (either during replacement of cover or possibly after?)
6. Code executes exactly the same as in steps 2-5. Not sure why covermanager_cover_for_track_no_default returns NULL again.

After many repetitions it finally stops.

[Oleksiy-Yakovenko]

Good findings. I'll try adding some throttling there, if it's possible.

[Oleksiy-Yakovenko]

Not sure why covermanager_cover_for_track_no_default returns NULL again.

I may be remembering wrong, but I believe that it returns NULL if the image has not been cached yet, and completion block will be called. If it returns non-null it means that the image is immediately available and completion block will not be called.

[kuba160]

Also if I understand correctly, there is no scaled cover caching, right?

[Oleksiy-Yakovenko]

Not sure, can't remember at this time.

[kuba160]

I may be remembering wrong, but I believe that it returns NULL if the image has not been cached yet, and completion block will be called. If it returns non-null it means that the image is immediately available and completion block will not be called.

I also think this is how it is supposed to work yet in the loop example I have given, a repetitive call to covermanager_cover_for_track_no_default (for the same track over a span of dozen calls / multiple seconds) it still continued to return NULL, so I guess there is some problem there. I guess it is possible that cached cover gets overridden with NULL and the fix for the race condition I made before didn't cover some cases.

[Oleksiy-Yakovenko]

I have added separate issue for each reported topic from this issue.

#3098
#3099
#3100