XnView MP - The most scalable solution

Tips about scalability

XnView MP provides (one of) the most scalable multimedia managers available today. Here are some hints for making the most of this fine software.

Use WebP compression for your thumbs

In the main menu, navigate to Tools | Settings | Database and choose Lossy - High quality (WebP) from the Compression drop-down. WebP is a significantly better compression algorithm than JPEG and and can reduce the disk-space footprint of the database file that MP uses to quickly redisplay image thumbnails in the Browser.

From a technical perspective, the stored size of each thumbnail bitmap can be quite close to the Operating System sector size (for example: 4K) and very close to XnView MP's DB page size (8K). This mean means that a typical 30% gain in compression from JPG to WebP (esp. when correlated with issues related to page overflow) can be of huge importance to:

• • keeping the thumbs database as small as is practical, hence enabling MP to keep much more of it in memory (which means quicker thumbs display).
  • reducing the amount of Input/Output Operations from/to database/disk, dramatically improving the speed.

Be conservative with the size of the stored thumbnails.

XnView MP can dynamically (and temporarily) resize the thumbs to fit which ever thumb size you select using the browser thumbnail sizer, but without changing the stored size. As a matter of policy, be willing to accept a slight 'fuzziness' in the appearance of your thumbnails.

A good approach would be:

Use the thumbs slider (in the Browser) to approximate the (normal) thumb size that works best for you, day-to-day. Then, go to Tools | Settings | Database and press Get thumbnail Size. The dialog will capture the thumb size you formerly selected using the slider in the Browser. Then, reduce the resulting thumb dimensions a small amount (e.g. 10% or so) by adjusting the values in the Setup dialog, but keep the height vs. width ratio proportional to the shape of the thumb images you want (vertical vs. horizontal vs. square).

Assure the best storage environment for your databases

• • Keep your databases - especially the Thumbs.db database - on SSDs rather than Hard Disks.
  • Try to put the databases on a secondary (non-busy) drive (not the drive with the operating system on it).
  • If you can, have the two databases themselves (xnview.db and thumbs.db) each on separate drives - this will speedup access.
  • Note> To change the location of your databases, navigate to Tools | Settings | Integration | Paths. You can change the paths from the 'Other settings' pane.
  • Increase the "Memory usage for database engine" settings value (in the Tools | Settings | Database panel). If you have a big image collection and lots of RAM memory, set the value at 100 - 200 MB or even more.
  • Periodically optimize your Database: See the next section for how to do this.

Database maintenance options

In the main menu, go to Tools | Settings | Database and press the Optimize... button. The options there are explained below.

First, however, it is important to understand the notion of cataloged vs scanned

• A Scanned file is the a file which is added to (entered into) the database by the (automatic) subsystem which builds the thumbnails and enters all the basic (meta)data about the said file: name, directory, EXIF, machine-generated IPTC etc.

• A Cataloged file is a Scanned file for which an user has added information (information = data with human meaning): color, rating, keywords/categories, tags/albums, user comments (& other human generated IPTC), etc.

So, Cataloged = Scanned + User Entered Information

Keep the above terms in mind when you read the descriptions below.

Optimize (long process)

Because of the way the operating system maintains disk storage, over time the MP database files can become fragmented into several pieces stored in different locations on the drive. When this happens, the time to retrieve a certain info from the database increases (sometimes a lot) because of 1) disk fragmentation - the disk head will need to jump from sector to sector to find the requested info and 2) pointer / page fragmentation: the program needs to jump from page to page in the disk cache maintained in memory (because of a -very- deep chain of pointers traversed frequently) in order to locate and retrieve the desired record / index bucket.

That's why DB engines have a feature (usually called VACUUM or COMPACT) which freezes the current DB, copies the entire content to a new, entirely contiguous file (which is, of course, "ok"), deletes the old DB, renames the new DB to the old name and connects to it. Because of all this transfer, the process is very slow for a large file.

Remove empty directories

Performance can be enhanced by removing the folders which have 0 (zero) files in database. This action makes the Folders database table smaller, thus making thumbnail retrieval somewhat faster. MP's empty-folder-removal process is very efficient, so for most systems, simply leave this option enabled.

Clean files

Sometimes it is worth the effort to remove the (meta)data AND the thumbnails from the scanned files but NOT from the cataloged ones. This removes all the non-cataloged file data from the DB and doesn't take much time: a very useful and efficient tool to eliminate the 'fat'/cruft from the database file.

Clean thumbnails

Typically, the thumb image bitmaps are the group of database items which uses the most disk space. Even though storing the thumb images in the database speeds their display in the browser, as the MP continues to add thumbs, the database file size can become so large that display of the thumbs retrieved from the database will visibly slow.

Cleaning the thumbnails will remove all thumb images from the database file but retain the (meta)data from the scanned files AND from the cataloged ones. After cleaning, the database will be considerably smaller. From that point forward, MP will automatically add the image thumbs back to the database as the user uses the Browser to navigate through the disk storage hierarchy.

Check for orphaned directories

This action removes "lost" or "orphaned" directories from the database: folders which the OS cannot find anymore. As an important caution, always consider why a folder might be missing from the file system. Perhaps it is on removable media (which has been removed!), or maybe the connection to its server volume has failed, or the user doesn't have rights to view the folder anymore. Or perhaps the folder has simply been relocated elsewhere.

Each missing directory situation may need to be examined for cause, so show great care when dealing with orphaned directories. Nevertheless, removing them can be very efficient in maintaining database performance and the speed at which the thumbnails appear in the Browser.

Check for orphaned files

The same principle from 'Check for orphaned directories' but the process is much slower and less efficient.