The multimedia detector service, mm-detect, keeps track of which devices are attached to a car's infotainment system and triggers the synchronization of media metadata from any newly attached device with the device's QDB database.
The mm-detect service ensures that client applications can display up-to-date media information to the end user, while relieving those applications from having to constantly monitor devices and to load and synchronize databases.
The following components work with each other and with mm-detect to automate the tasks of detecting devices and delivering up-to-date information on device media content to the end user:
Device publishers are hardware-support components that detect device insertions and, in response, write PPS objects to the /pps/qnx/mount/ directory. We refer to this fixed location as the device listings directory. For background information on the PPS service, see the PPS Developer's Guide.
Each attached media device has a PPS object with the same name as the device and whose contents store the device's mountpoint and filesystem information. This PPS object is managed by the device publisher designed for the device's hardware type. For example, when the user inserts a USB stick whose device name is usb1, the usbpub publisher creates a PPS object named /pps/qnx/mount/usb1. When the user removes the device, that same publisher deletes the PPS object.
The usbpub publisher is the only publisher included in the QNX CAR platform. This publisher is launched during bootup and runs as a persistent background process.
When a USB device doesn't have any partitions but does have a single, mountable filesystem, usbpub writes the device mountpoint to one PPS object whose name matches that of the device. When a USB device has partitions, the publisher writes the mountpoints of the filesystems of the various partitions to separate PPS objects. The names of these objects contain the partition indexes.
The media content detector utility, mcd, handles device and partition enumeration and mounting. The mcd service doesn't interact with mm-detect; instead, mcd runs as a background process and continuously monitors the /dev/ directory for new entries, which indicate device insertions. When it notices a device insertion, mcd enumerates and mounts the device's partitions based on a set of rules encoded in a special text file (by default, /etc/mcd.mnt).
The mount rules name the mountpoints to use for specific device objects (/dev/ entries). Device drivers create and name these objects based on partition properties such as filesystem type. For example, for an inserted USB mass storage device with distinct DOS and QNX4 partitions, the USB driver could create the device objects /dev/umass/umass0t1 and /dev/umass/umass0t7. The mcd service could then assign mountpoints of /fs/usb0 and /fs/usb1 for these two partitions. For further explanation of mount rules and a sample mcd.mnt rules file, see the mcd section in the Utilities Reference.
The mcd service doesn't work directly with the device publishers either; both sets of components run concurrently but independently. Each mount request is sent by mcd to the appropriate device driver (e.g., a USB device driver to mount a USB stick), which manages the mountpoint path. Each device publisher regularly polls its underlying device driver to learn of any new mountpoints. The publisher then writes any new mountpoints to the PPS objects in the device listings directory.
The multimedia synchronizer service, mm-sync, uploads media metadata from attached devices into QDB databases. Each device has its own QDB database that stores metadata on the device's media contents, such as media file IDs, artist and track names, cover art, and more. For information on the QDB database service and the storage standard used for its databases, see the QDB Developer's Guide.
The first time a device is attached to a car's infotainment system, mm-detect loads and initializes the device's database before invoking mm-sync to start the synchronization. The mm-detect service is responsible for ensuring database availability to mm-sync because although mm-sync writes to databases, it can't load or unload them.
Whether a device is attached for the first time or any subsequent time, mm-detect issues a command to mm-sync to synchronize media content from the entire device, starting from the root folder and descending into all subfolders systematically. The device's filesystem is accessed from the mountpoint previously set up by mcd.
The command sent to mm-sync also specifies to upload media file information, artistic creation and playback information for media tracks, but not playlist entry information.
The media file information stored in the database includes:
The artistic creation and playback information stored in the database includes:
The HMI for the QNX CAR platform consists of many applications that collectively provide users with a visually rich front end for interacting with the car infotainment system. The shipped version of this application platform includes one media application, Media Player, that reads the synchronization status updates published by mm-detect through PPS and refreshes the list of media sources shown in the HMI as needed.
Developers can write their own media applications to replace or run alongside Media Player in their car system. These alternative applications can read the same PPS object that Media Player reads for synchronization statuses. The status information published in this PPS object includes the device's name, media type, and a flag indicating whether the device has been synchronized yet.
Client applications can extract as much of this information as they need to refresh their HMI display. By default, mm-detect stores this object in /pps/services/mm-detect/, but you can reconfigure this storage directory.