One more request:

please test with *large* numbers of images/photos/videos/mp3. 2000 or more is 
good start.

To avoid having to copy tons of videos, mp3s or jpg images, you can just make 
hard links to a single file. The name of the link is part of the cache key, so 
the effect is the same as having lots of separate files, and you don't have to 
copy hundreds of megabytes around that way.

Cheers,

Michi.


On 27 Jun 2015, at 13:48 , Michi Henning <[email protected]> wrote:

> 
> On 27 Jun 2015, at 13:36 , Victor Thompson <[email protected]> wrote:
> 
>> Have there been any recent changes to the silo? Testing looked good
>> the last time I personally checked, if there are deltas let me know
>> and I'll test as well.
> 
> The main delta is that, on Arm, we are now limiting the number of concurrent 
> gstreamer pipelines to 1 because anything else is too risky.
> On other architectures, we use as many gstreamer pipelines as there are CPU 
> cores. You should see around 780% CPU utilization on an 8-core machine with 
> heavy workloads, such as thumbnailing a whole bunch of videos at once.
> 
> Once the cache is hot, it delivers the thumbnails *very* fast. Please test 
> your applications not only with a cold cache, but also a hot one; the way 
> memory allocations happen is markedly different that way.
> 
> If you want to clean the cache and start afresh, just run
> 
> thumbnailer-admin clear
> 
> That wipes the cache completely.
> 
> You can see cache statistics by running
> 
> thumbnailer-admin stats -v
> 
> Please keep an eye out for requests with an invalid QSize (width or height == 
> -1). Get rid of all of these. Instead, ask for the thumbnail in the size you 
> need it. This drives the cache in the most efficient way possible.
> 
> Your application must be prepared to handle a smaller thumbnail than what it 
> asked for because we never up-scale. If original artwork is available only as 
> 512 and you ask for 640, the actual thumbnail you get will be 512. You are 
> guaranteed that you will never get something larger than what you ask for, 
> unless you ask for (0,0), in which case we deliver full size. (Don't do this 
> unless there is a good chance that you will need the same image again 
> shortly; otherwise, it just eats space in the cache and makes it less 
> effective.)
> 
> Cheers,
> 
> Michi.


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Reply via email to