![]() |
![]() |
![]() |
![]() |
This chapter introduces some configuration techniques that you can use to tune MME performance for the environment in which it will be deployed, and some useful troubleshooting information. It contains the following topics:
This section describes some configuration techniques that you can use to tune MME performance for the environment in which it will be deployed. It includes:
When using the MME in embedded systems with limited resources, imposing limits on specific operations can imnprove system performance and the overall end-user experience.
The MME configuration file provides elements that control set limits to everything from buffer sizes to database usage. Careful configuration of these elements can help optimize the MME's overall resource usage and speed.
This section describes some key configuration elements and what they do. For a complete list of the MME configuration elements and descriptions of how to use them, see the other chapters in this guide. For more information about configuring io-media see the io-media chapter in the MME Utilities reference; for more information about configuring the QDB, see the chapter Backing up and Restoring MME Databases in this guide, and the QDB Developer's Guide.
This section describes key synchronization configuration elements.
The greater the number of items an MME sycnhronization examines in a folder, the greater the memory resources it requires for the synchronization. The <MaxFolderItems> element limits the the number of items the MME examines in any one folder during synchronization.
Limiting the depth MME synchronization will go on mediastore's file system may be required to maintain optimal performance. The maximum depth of recursion can be set with the <MaxRecursionDepth> configuration element. When the MME synchronization process reaches the set folder depth limit, it ends the recursion of the folder chain, returns to the last common folder level, and continues with the next item at that level.
Playlists created by end users can be extremely large and processing them can strain limited sytem resources. The <MaxBytes> and <MaxLines> configuration elements in the <PLSS> element can be used to set a limit to the memory the MME will use to synchronize playlists, as well as the number of lines in a playlist the MME will process.
MME synchronization performance can be affected by the number of synchronization buffers available to the MME while adding media data to its database. Generally, the more buffers available, the faster the synchronization, but the greater the memory resources required. The <MaxSyncBuffers> configuration element can be used to increase or decrease the number of synchronization buffers available to the MME.
No embedded system has an infinite amount of space to store media data collected during synchronizations, and in a system with limited resources, maintaining data for rarely used media can reduce performance, and prevent synchronization and playback of new media. The <MaxDatabaseSize> configuration element can be used to limit the size of the MME database. When the database reaches or exceeds the set limit, the MME automatically begins pruning old, unused data from the database.
The MME includes a default set of indexes that has been carefully chosen to maximize MME performance for synchronization, playback and track session handling. These default indexes are in the mme.sql and mme_library.sql schema files delivered with the MME.
The effects of indexing on performance depends on a number of factors, including the system platform and the specific contents of mediastores; in particular, for synchronizations, the number and size of folders and files.
Judiciously used, indexes can improve performance. However, adding indexes increases the database size and can, therefore, produce the inverse effect and degrade performance:
It is expected that you will add indexes to your projects to obtain the best possible performance for each project. To ensure optimal synchronization performance in your environment, we suggest that you consider the recommendations below:
For information about how to add indexes, see “Adding and removing indexes” in the chapter Configuring Database Behavior.
If your environment hosts media files on USB storage devices, you should ensure that your configuration allows sufficient RAM for read-ahead processing of large files, such as MP3 files. You can change the configuration by adjusting the cache and vnode values that devb-umass passes to io-blk.so with the blk option.
A reasonable starting configuration for the blk option is: cache=512k,vnode=256. You should, however, establish benchmarks for key activities in your environment, then adjust these values for optimal performance.
For more information about the utilities, see devb-umass and io-blk.so in the Neutrino Utilities Reference.
This section includes:
![]() |
To get more or less information about your implementation you can adjust verbosity and debug levels. For more information, see:
|
If you have trouble with your MME installation or with playing media, try the following:
# pidin arg
# io-media-generic -DD
To start mme in verbose mode:
# mme-generic -vvv
You can use sloginfo to view messages from the system log.
If you set the verbosity level for the MME to log errors and warnings, you can use the log entries to determine the source of a configuration assignment.
When the MME uses its compiled configuration assignments (in config.h), it makes log entries of type WARN (3), followed by the assignment used and its value. If the assignment comes from the user-managed XML configuration file, mme.conf, the MME makes log entries of type INFO (5).
This behavior makes it easier to determine which configuration assignments the MME takes from the mme.conf XML configuration file, and which assignments are in its compiled configuration. Knowing the source of a configuration assignment can help in tracking down a problem, especially since it is relatively easy to make errors when specifying a configuration value, and little information is available when a badly formed XML document is used.
Common MME configuration errors are:
If the MME is not behaving as expected after a re-boot, you should check the logs to see the source of the assignments. The log type: INFO or WARN, indicates the source of the assignment and the first place to check for an error.
If the MME used a default compiled setting when you expected it to use your configuration, check that:
The MME's command-line interface (mmecli) can be used to set and view the MME logging levels. To view current logging levels, use mmecli get_logging. For example:
# mmecli get_logging # (rc=0,errno=0) mme@0:0;mdi@0:0;sync@0:0;mdp@0:0. Execution Time=0.055
The above result shows four logging modules: “mme”, “mdi”, “sync”, and “mdp” with all their logging verbosity levels and flags set to 0:0 (verbosity=0 and flags=0).
To set new logging verbosity levels, use mmecli set_logging. For example:
# mmecli set_logging sync 8 0 # (rc=0,errno=0) logging set to 8 0. Execution Time=0.001
The above example shows how to set the synchronization logging module verbosity to 8. A get_logging command would show the new synchronization verbosity level:
(rc=0,errno=0) mme@0:0;mdi@0:0;sync@8:0;mdp@0:0. Execution Time=0.001
Use the command-line option -C to see the contents of the configuration file for io-media:
# io-media -C
For more information about configuring io-media, see io-media-generic in the MME Utilities Reference.
The MP3 parser filter mpega_parser logs error messages to record conditions such as the ID3Tag in MP3 files exceeding the maximum size handled by the filter, and thus requiring pre-parsing of the tag. For example:
Jun 20 14:36:18 5 20 1 io-media-generic/aoi: mpega_parser: ID3TagV2.3 too big (320940bytes) pre-parsing ... Jun 20 14:36:18 3 20 1 io-media-generic/aoi: PreParseID3Tag() offset 10 truncating at offset on invalid ... Jun 20 14:36:18 3 20 1 io-media-generic/aoi: mpega_parser couldn't preparse the ID3TagV2.3 Looking for ... Jun 20 14:36:18 3 20 1 io-media-generic/aoi: ID3Tag V2.3 size 10bytes max = 65536 checking ID3V1 failed ...
To have mpega_parser log these types of messages, start io-media with at least one level of debug verbosity (at least one -D).
![]() |
In a production environment, always run the MME, io-media, and other components and modules at zero verbosity. |
For complete information about configuring the QDB, see the QDB Developer's Guide.
Different database file attach orders for QDB and DMS result in different locking orders, which cause database deadlocks.
To prevent database deadlocks caused by different database file attach orders, ensure that your projects lock databases in the same order as they are attached:
If you don't have an mme_custom table, use this order:
![]() |
Locking your database files in any other order causes database deadlocks. |
Before attaching database files in DMS, you can have the client ask QDB the attached order for the files. Below is an example of how to ask QDB the attach order of database files, and the result:
qdbc 'pragma database_list;' Rows: 5 Cols: 3 Names: +seq+name+file+ 00000: |0|main|/fs/tmpfs/mme.db| 00001: |1|temp|| 00002: |2|mme_temp|/fs/tmpfs/mme_temp| 00003: |3|mme_custom|/fs/tmpfs/mme_custom.db| 00004: |4|mme_library|/fs/tmpfs/mme_library.db|
![]() |
If a file doesn't have a filename (row 1), then don't attach it. |
During the development phase of your project you should configure your systems to ensure that you are able to correctly separate performance problems from deadlock problems, and understand and solve each problem accordingly:
You can change your system configuration when you prepare your system for the production environment.
Testing of the MME has revealed that increasing the MME's maximum number of synchronization threads (<MaxThreads> in the MME configuration file) without also increasing the maximum number of threads available to the QDB can result in the QDB and MME locking up.
If multiple MME synchronization threads that need to lock the database exhaust the number of available threads, the QDB can find itself without the thread it requires to unlock the database, thus causing a deadlock with the MME waiting for the QDB to unlock the database while the QDB is waiting for the MME to release the thread it needs in order to unlock the database.
Deadlocks like the one described above have been observed in scenarios where the MME has attempted to synchronize multiple and large mediastores at the same time; for example, a USB stick with eight partitions.
Always ensure that the QDB has a threadpool with more threads than will be required by the MME synchronization threads plus any other processes that may lock the MME database. The characteristics of the QDB threadpool can be set with the -o thread* options; for more information, see the QDB Developer's Guide chapter Starting QDB.
![]() |
![]() |
![]() |
![]() |