[Amarok] Scanner now also looks for "folder.*" as cover ima

Dan Meltzer parallelgrapefruit at gmail.com
Fri Jan 22 15:56:08 CET 2010


On Fri, Jan 22, 2010 at 9:26 AM, Jeff Mitchell <mitchell at kde.org> wrote:
> On 01/22/2010 09:11 AM, Dan Meltzer wrote:
>> constructing QFileInfo's is
>> relatively expensive, especially in bulk like we are doing here.
>
> Where's the proof? :-)
>
> The reason I bring this up is that for independent reasons I asked the
> KDAB people giving the training yesterday the same exact question -- how
> expensive it is to use QFileInfo vs. just a stat (which itself is very
> fast, even in bulk), even at quantities in the tens of thousands. They
> claim that it's nearly as fast, and in some cases (like Win32) faster. I
> trust them on this -- they *are* the Qt experts :-)

Right, but creating 40,000 qfileinfo's to scan 10,000 files is going
to be more expensive than creating 10,000 qfileinfos to scan 10,000
files, reguardless of the specific numbers.
>
>> More to the point, isn't amarokcollectionscanner supposed to spit out
>> image paths?  It's already reading everything in the filesystem, so it
>> would make sense for it to parse cover.blah's at the same point.
>
> It does spit out image paths. The scan result processor is using
> heuristics to determine which is the best one to use. Possibly this
> could be moved to the scanner -- the code is a bit complicated and I
> don't know what the implications would be.

If it spits out paths, then we should just do a string search rather
than creating a qfileinfo (which needs to load at least some stuff
from the hd, I'd assume.-- The docs are not entirely clear about how
much is precached vs. how much is loaded on demand.

>
> Mark, as for your implementation -- since folder is relatively unused,
> I'd put it as the *last* thing to try, not the second-to-last. I'll
> change this when I remove the big loop.
>
> --Jeff
>
>


More information about the Amarok-devel mailing list