Maintaining database persistence

The mm-sync service doesn't create, load, or unload databases. When the user attaches a mediastore, the application must ensure that the mediastore's database is loaded before any synchronization can begin. When the application has finished using a mediastore or the user detaches it, the application can unload the database to free memory.

Client applications must 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 that 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 not having to reload their databases.

Making databases available to applications

When a mediastore is inserted for the first time, 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 QDB database configuration directory (/pps/qnx/qdb/config/).

When a mediastore is inserted any subsequent time, the application just needs to copy the configuration file into the same directory to reload the database, as explained in "Setting up the Multimedia Synchronizer Environment".

We recommend using the mediastore's unique ID (UID) and the device type (both can be read from the /pps/qnx/mount/.all PPS object) to form the database name. The device type should be included in the name to avoid a naming conflict that would arise if two or more devices were assigned the same UID by independent system components that each write to the PPS mountpoint information object.

Suppose the user inserts both an iPod and an audio CD, and both devices are assigned a UID of 4f587192-d2fe-4efb-9fec-cd35531cfa45 by the separate components that publish iPod and CD device information in PPS. In this case, the device databases could be named iPod-4f587192-d2fe-4efb-9fec-cd35531cfa45 and audioCD-4f587192-d2fe-4efb-9fec-cd35531cfa45 to eliminate ambiguity.

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 that a mediastore database won't be needed for some time (e.g., when the device has been removed and no other media applications are running) or if memory is low, your client should unload the database to free some memory.

For each database you want to unload, you must:

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.
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.