The mm-sync service doesn't create, load, or unload databases. When the user attaches a device and its mediastores get mounted, a media application must ensure that their databases are loaded before it can synchronize their contents. When it has finished using a mediastore, the application can unload the associated database to free memory.
A media application 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 that the related database stays in memory or is reloaded when the USB stick is reinserted, so the user can once again access and play its media files. Keeping the database for a recently used mediastore in memory can speed up resynchronizations—recently used mediastores are likely to be reinserted soon and you can save significant time by not having to reload their databases.
When a mediastore is inserted for the first time, any application that wants to access content on that mediastore must create a database configuration file that names the raw storage file (which has the same name as the database). Then, the application 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 that 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. Including the device type in the name avoids a naming conflict that would arise if two or more devices were assigned the same UID by independent system services that each write to the PPS mountpoint 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 services 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 a 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.
When an application knows that a mediastore database won't be needed for some time (e.g., when the corresponding device has been removed and no other media applications are running) or if memory is low, the application should unload the database to free some memory.
Delete the configuration object with the same name as the database, 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 the 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 footprint of media applications while retaining important metadata. An application can simply copy a mediastore's database back into RAM when it needs to access that metadata again.