Cover Files Extraction Branch

[Alexander Stippich]

Hello Matthieu,

On Sonntag, 18. November 2018 10:56:01 CET you wrote:
> Hello Alexander,
> 
> Thanks for your work on this.
> 
> On samedi 17 novembre 2018 18:01:18 CET Alexander Stippich wrote:
> > Hello everyone,
> > 
> > I've pushed a branch called cover_manager.
> > It contains a working solution for the extraction of cover images embedded
> > in the files, but also does some more stuff. So here is a list:
> > -reorder all platform-agnostic scanning files to a single folder
> > -factors out the current code for cover searching into own class called
> > cover manager
> > -add tests and simple benchmarks
> > -optimizations for cover searching
> > -extract the cover art from music files
> > -resize when image is too large (512x512 current maximum)
> > -save all covers to standard data location, e.g. the same location where
> > the database is located
> 
> I have done a quick review of the branch.
> There are several blocking points.
> 
> I do not like that files and code unrelated to embedded cover images are
> modified in the same branch. Please separate each topic you want to work on.

This is really just the first commit. I will cherry-pick it for separate 
review and will rebase afterwards.

> As far as I understand what you did, you are saving all cover images you
> found (in directories or in metadata to a directory dedicated to store
> application data).
> Is my understanding correct ? In case yes, this is also a blocking point. We
> should not store cover images in this type of directory. They are not
> application data. We should also not duplicate existing files.

Your understanding is correct. The location of the data can easily be changed. 
I checked where Cantata is saving the files, and it uses the /.cache location. 
That's probably the best location, since after all they are used as a cache.
Is that okay for you?
Regarding the duplication of existing cover files in the folders, I also 
wasn't sure about this. But there are some good arguments in favor of it imho. 
They are scaled down automatically to the maximum size of 512x512 currently 
(which may still be too large). Thus they will serve as a fast cache for the 
covers and loading of possibly large files is avoided. Having all cover files 
loaded from Elisa in one single place makes future features imho more easier 
to implement. This should greatly ease the implementation of a 
QQuickImageProvider later.
And in case Elisa will download cover art automatically, this will also be the 
location.

Best regards,
Alexander


> > Future things I would like to look at:
> > -add a QQuickImageProvider for the cover manager (opinions?)
> > -add functions to create artist pictures from the album covers (like in
> > https://community.kde.org/KDE_Visual_Design_Group/Music_Player)
> > -make maximum cover size configurable
> > 
> > I would appreciate any feedback. I _think_ currently it is necessary to
> > delete the old database in order to get the new images, but this is an
> > issue unrelated to this branch.
> > 
> > Best regards,
> > Alexander
> > 
> > 
> > 
> > _______________________________________________
> > Elisa mailing list
> > Elisa at kde.org
> > https://mail.kde.org/mailman/listinfo/elisa
> 
> Best regards
> 
> --
> Matthieu Gallien