You may choose not to run mm-detect and
instead write client applications that manually manage databases to better control database
naming and improve performance. Your media applications can read a special PPS object
to learn the mountpoints of newly inserted mediastores and, from these mountpoints, explore
the filesystem to determine which media files need to be synchronized. This information is
required when invoking mm-sync to start synchronizations.
The process of synchronizing mediastores using
mm-sync from a client application is as follows:
-
The user inserts a mediastore, for example, a CD, iPod, USB stick, or
Bluetooth device.
The appropriate device publisher (usbpub,
mmcsdpub, or cdpub) notices the
newly attached mediastore and publishes its information to the
/pps/qnx/mount/.all PPS object.
-
A running media application notices a new entry in the
.all object and reads that entry's id
attribute, whose value indicates the mediastore's unique ID. The application
checks if the database associated with this unique ID is loaded; if not, it
loads the database by writing its configuration object into the appropriate PPS
directory (/pps/qnx/qdb/config/).
A client application must ensure any database is loaded before
trying to synchronize or play the media content on the corresponding device.
See the Maintaining database persistence section for more information.
The .all object entry also contains the
name attribute, whose value an application can use as a
descriptive mediastore name to display in the HMI.
-
The application determines what mediastore content needs to be synchronized.
It first obtains the mediastore's mountpoint by reading the
mount attribute in the .all object entry
and then explores the files from this mountpoint.
The decision as to what content to synchronize depends on many factors,
including the elapsed time since the mediastore's last synchronization (if
known), the available system resources, and the mediastore type. Files and
folders not seen before need to be synchronized if they contain media the
user might play. Folders that have fewer contents than before may need to be
resynchronized to ensure their database information is up to date.
-
If a synchronization isn't necessary, the application proceeds to Step 9. Otherwise, it connects
to mm-sync by calling mm_sync_connect()
with the filename argument set to the device object used for
synchronizations.
The default device is /dev/mmsync, but you can change
this in the mm-sync configuration.
-
The application can request to receive event notifications by calling
mm_sync_events_register(). The function's
event argument must be set to a struct
sigevent object that has been initialized with the signal information to
be delivered with each event.
Event notifications help a client application track synchronization progress
and learn about any errors that may have occurred.
-
The client code starts synchronizing the mediastore by calling
mm_sync_start(). The application must provide the path of the
device object used by the mediastore's QDB database, the mediastore's
mountpoint, and a synchronization path that covers the content that needs to be
synchronized.
The device object is stored in /pps/qdb/ and has the
same name as the database. The application can choose any database name, but
it should incorporate the mediastore's unique ID.
The function call returns an operation ID, which the application uses to
refer to the synchronization operation when issuing other commands, such as
sync_status_get_byid() to query the synchronization
progress.
-
Applications receiving event notifications can use the appropriate system call
to wait for the signal defined in Step 5 to be delivered, then
call mm_sync_events_get() to retrieve the event information
each time the signal is received.
The application knows the synchronization is complete when it receives the
MMSYNC_EVENT_MS_SYNCCOMPLETE event.
-
When all playback or recording activity has finished and the mediastore is no
longer needed, the application can disconnect from mm-sync
by calling mm_sync_disconnect().
-
The application unloads the mediastore's database by deleting its
configuration file from the PPS configuration directory
(/pps/qnx/qdb/config/).
Note: Client applications can synchronize content incrementally through directed
synchronizations, which entail giving mm_sync_start() a
synchronization path with one folder. After a synchronization completes,
applications can examine the contents of the files and
folders tables and pick a subfolder to synchronize in the next
mm-sync call. In this manner, applications can explore the
mediastore using database queries and directed synchronizations.