Maintaining database persistence

The mm-sync service doesn't create, load, or unload mediastore databases; mm-detect performs all three tasks when synchronizing mediastores to guarantee database availability for client applications. If you're not using mm-detect, you must manually detect mediastore insertions and load the relevant databases before you can synchronize media content.

In this latter case, client applications must also ensure database persistence between uses of specific mediastores. For example, suppose the user plugs a USB stick into their system, then removes and reinserts the same device. The application writer must ensure the database stays in memory or is reloaded when the USB stick is reinserted, so the user can once again access and play the device's media content. Keeping the database for a recently used device in memory can greatly speed up resynchronizations—recently used devices are likely to be reinserted soon and you can save significant time by avoiding reloading their databases.

Making databases available to applications

When a mediastore is inserted for the first time, mm-detect (if it's running) creates a database with a name matching the mediastore's unique ID (UID) that was read from the /pps/qnx/mount/.all PPS object. If you're not using mm-detect, your application must create a database configuration file that names the raw storage file (which has the same name as the database itself) and must copy the configuration file into the PPS database configuration directory (/pps/qnx/qdb/config/).

When a mediastore is inserted any subsequent time, the application just needs to copy the mediastore's database configuration file into the same PPS directory to reload the database, as explained in the instructions for setting up the mm-sync environment.

We recommend using the mediastore's UID along with the device type (also read from the .all object) to form the database name. Including the device type in the database name lets programmers identify the role of a database by examining the first few characters in its name. For example, for an inserted USB stick, the media application could name the database USB0-4f587192-d2fe-4efb-9fec-cd35531cfa45 to indicate that it holds media metadata for the first USB device that was attached to the system.

This naming practice makes it easy to check if the relevant database exists or is loaded, because the same value read from the PPS object can be used in the search string when looking up the database file by name.

Determining when to unload databases

When your client application knows a mediastore database won't be needed for some time (for example, when the corresponding device has been removed and no other media applications are running) or when memory is low, your client should unload the database to free memory for other applications.

For each database you want to unload, you must:
  1. Delete the configuration object with the same name as the database to unload from the config subdirectory under the PPS configuration path (/pps/qnx/qdb/).

    QDB removes the database from its control. QDB also deletes the status file in the status subdirectory because the database is no longer visible.

  2. If the database storage file is stored in RAM, move that file to persistent storage. You can speed up media applications by storing your QDB databases in RAM, but you must remember to move the storage files for any unused databases out of RAM and into persistent storage to avoid overusing system memory.

    Keeping inactive databases in persistent storage reduces the memory requirements of media applications while retaining important mediastore metadata. You can copy a device's database back into RAM when you need to access the device's media information again.