UPnP Media Controller
Introduction
Basic Usage
Operational Modes
Option Dialogs
Multi-Renderer Synchronization
Using Firefox as a Media Browser
Preference Files
Device Information Dialog
Debug Window
Supported Devices
The media controller is a Java Swing-based UPnP A/V control point application, allowing user's to browse content on UPnP Media Servers and play it back on UPnP Media Renderers. The controller supports similar functionality as the A/V control point supplied with the Intel UPnP tools package, plus additional features to make it more suitable for routine day-to-day media playback. Support for playback of music content, pictures, and videos, is provided.
The controller is fully multi-threaded, allowing it to interact with multiple devices. A screenshot of the UI during a multi-device test run is shown below. During this run, the controller was controlling playback of music on two UPnP media renderers, and monitoring the progress of playback on a third device.
Following program startup via one of the supplied scripts, the media controller should detect all UPnP media server and renderer devices on the network. The discovery process typically takes on the order of 5-10 seconds, as UPnP devices are set up to respond with a random delay to avoid discovery broadcast 'storms' on heavily populated networks. An icon should be displayed for each discovered device in the server or renderer device window. Note that the UPnP device specification provides a mechanism for devices to provide their own icons to the controller, but not all devices currently implement this capability. If you see the default 'server disk' icon for a device, and would like to change it, see
here.
At this point, it is assumed that the controller has discovered at least one server device and one renderer device. If you need a server device for test purposes, a cross-platform server can be found at
www.twonkyvision.com. Likewise, if you have a server, but do not have a renderer device, the media renderer supplied with the Intel UPnP Tools can be used.
To get started, click on one of the server icons. A set of folders should appear in the browse tree window on the left. The heirarchy will typically start off with ('Music', 'Pictures', 'Movies') or something similar. For the purpose of this example select a music category to browse. When you reach the level where actual music tracks reside, the tracks should show up in the audio item panel on the right.
Each renderer device discovered by the controller has its own play queue. The queue is not considered 'active' unless the device's renderer window is open. Click on one of the renderer icons to bring up its window. Next, select one or more tracks in the controller's music track window, followed by 'Add Tracks To Play Queue'. The play queue for the renderer should become visible, and display the selected content. Hit the play button in the renderer window and device playback should begin.
Control Modes
The UPnP A/V Device/ControlPoint architecture allows a control point to browse media on a media server, and initiate playback of that media on a media renderer. After initiating the playback, the control point may remain the active point of control (issuing stop/ff/rew commands for example), or disconnect completely and let the media renderer and media server complete the playback on their own. At any time, a control point can reconnect to the renderer and server devices and regain control in order to modify the playback session.
This is a very flexible control model, but support for the second type of usage (start playback from external controller and disconnect) remains somewhat problematic in the case of music playlists. In order for a multiple-item playback session to continue in the absence of a control point, the UPnP renderer device must itself support playlists. Unfortunately, not all renderer devices support this at the current time, preventing an external UPnP controller from being able to queue more than a single item for playback. To play back music playlists in a consistent way on the widest range of devices, the controller is currently configured to
always remain the active point of control and handle the playlist queuing logic entirely on its own. This is the mode currently used by the media controller for
all renderers, regardless of whether or not the renderer supports playlists. Since this mode requires that the controller wait for the current song to end prior to queuing the next one, there is a small gap between tracks, noticeable on music albums with no silence between tracks. This will be changed in a future version so that the user can choose to send playlists to renderer device's that support them (and allow the controller to disengage from the playback session)
Audio Queue Insertion Mode
The controller supports two queuing modes in the renderer control window when rendering audio content - a 'Normal' mode where items are simply added to the end of the queue, and a 'Jukebox' mode, which is used to insert 'high priority' items after the current playing song. This is useful when one wants to hear a certain song without stopping/restarting the music stream. An image of the renderer play queue window following the insertion of two White Stripes songs after an actively playing B-52's track using jukebox mode is shown below. All the high priority songs are highlighted with a yellow/orange background so it is easy to differentiate them from the background playlist. Note that whenever the renderer is stopped, the priority of all items in the play queue is reset to normal priority, since at that point the user is free to restart playback at any point in the playlist by selecting a song before hitting the play button.
Slideshow Mode
When playing image slideshows, the anticipated usage is that a user will browse a number of picture folders and dynamically build a slideshow using pictures from a number of folders. Once the desired images have been added to a renderers slideshow play queue, the user may wish to shuffle the play order by dragging them around the screen prior to starting the slideshow playback. To accomodate this usage, the image view of the renderer window supports a slideshow 'compose' mode as well as a separate 'run' mode. When in compose mode, images may be repositioned relative to one another using drag and drop. Image playback, either via the controls at the top of the panel or by clicking on a given image, is only enabled when in run mode. Below are screenshots of the main controller and renderer windows during an image playback session (MacOSX).
One caveat regarding the slideshow capabilities of the controller is that the composed slideshows cannot be saved. This is due to the lack of support for the UPnP 'write/update' operations in the current generation of UPnP servers. If one wants to compose a permanent slideshow that will not be lost when the controller is terminated, one should use other means to organize the pictures prior to their export by the UPnP server. For one-time only quick slideshows, though, the controller functionality will hopefully prove useful!
Server Browse Options
The Browse Options dialog box is shown below. The large folder option group contains settings to ease the browsing of large music collections, by automatically creating alphabetical sub-folders when the number of items in a folder exceeds a certain threshold. This feature is enabled by default, with a threshold of 500 items. The selection option group contains a setting to automatically select all audio tracks that are browsed, so they may be immediately added to the
play queue of a renderer with a single mouse click (no need to manually select them first).
Renderer Options
The Renderer Options dialog box allows the
Renderer Monitoring Interval to be set, controlling how often track position information is updated in all renderer windows that are actively playing content. The default is 3 seconds to keep UPnP message traffic low, but if a user prefers the track position to update more frequently to more closely mimic other player interfaces, it can be reduced(typically to 1 second). The
Play Transition Timeout setting controls the amount of time the controller will wait for a renderer to transition to the
Playing state following a play command. After this period, the controller assumes that there is a problem with that item, and moves to the next item in the playlist if one is present. Lastly, the
Slideshow Interval setting controls the default interval between pictures when playing an automated slideshow
Synchronization Options
The controller supports a limited form of multi-device synchronization using a proxy server approach. The Synchronization Options dialog box allows the proxy server type (local remote), address, and port information to be set, along with how often a resynchronization is performed to correct for timing drift between multiple renderers. For more details on the capabilities and limitations of multi-renderer synchronization using the UPnP controller, see the discussion
here.
The controller supports user preferences via Java
property files, which use a simple text-based format. These property files are hand-editable, but this should not be necessary very often since the most commonly modified preferences can be changed via dialog boxes such as those described in the previous section, and saved using the 'File->Save Setup' menu option. There are, however, still some preferences that are not exposed by the UI. These include some options to handle what icons get displayed for a particular device, and a few special options to handle device-specific issues.
If modifying the preferences by hand, it is useful to understand a little bit about how the preferences mechanism is set up, especially with regard to how things are handled with regard to software updates. There are two copies of the preferences file used by the controller, one containing the 'factory default' settings, located in
$INSTALL_DIR/properties/MediaController.properties, and one containing the user-specific settings, located in
$USER_HOME/.cidero/MediaController/MediaController.properties. At startup, the default settings are loaded first, followed by the user settings. The user-specific preferences override the defaults. If the user preferences file does not exist (first time application is run), it is created by making a copy of the default file. When the controller software is updated, some preferences may have been added or removed. In order to update one's user-specific preferences file (not strictly necessary as defaults will be used where necessary), a "File->Save Setup" should be executed. This will update the user's file, adding the new preferences and removing the obsolete ones. Preferences in the original user's file that are still valid in the new software release will remain set to the previous user-specific setting. Note that if hand-editing the file corrupts the file somehow, the simplest fix is to remove the file and re-run the application to create a new one.
UPnP devices provide some basic information to control points, such as the 'friendly device name' and the IP address. An optional presentation URL is also supported by the protocol, and typically contains a link to a device status/control web page, or the manufacturers main home page. The device information dialog (Options->Device Information...) presents this information to the user. The dialog is shown below.
Clicking on a device's web page, if present, brings up the web page on the system's default browser. Note that the default browser under the Linux operating system is mozilla. This may be changed if desired in the preferences file.The default browser under Windows is set via the operating system.
With the proliferation of UPnP server and renderer devices, it can sometimes be difficult to track down subtle problems arising from characteristics of a given device's UPnP implementation. The media controller, like the Intel sample controller, provides a debug window to help track down this type of problem. The debug window is straightforward, with an upper panel containing a list of UPnP-related message traffic, and a lower panel that displays the detailed view of a single message when one is selected in the upper window.
A screenshot of the debug window is shown below. Note that the lower panel has the ability to automatically format XML metadata content embedded within UPnP messages. This is particularly useful when looking at mediaserver 'browse' responses. The types of UPnP messages displayed in the window can be filtered using the popup dialog shown to focus in on a particular message type.
Theoretically, the UPnP media controller is designed to work with
any UPnP A/V device. That's the theory! To date, most tests with a new device have uncovered one or two issues that resulted in modifications to make the controller more flexible and fault-tolerant. Some (probably most) of these issues were related to the controller itself, while others were related to device-specific UPnP implementation issues. It is expected that this trend will continue as additional devices are tested, but the required changes should become more minor as time goes on.
Below is a list of the UPnP A/V devices which have been tested so far for interoperability with the media controller. For the most part, these devices work reasonably well with the controller. Known device-specific issues are noted, along with the software or firmware version at the time of testing. As noted above, these issues are not necessarily indicative of a problem with a particular device, but rather the controller/device interaction. Please feel free to let us know if you spot any inaccuracies, or notice different behavior in a new software/firmware release
Windows Media Connect Media Server (downloaded on 12/2/2004)
- WMC Discovery Latency
- When the media controller is run on the same machine as WMC, it may not immediately 'see' the Windows Media Connect server. This is a known issue with WMC not responding to device search requests originating from the local host. The only solution at the moment is to wait a while (5 min or so) for WMC to broadcast its period "I'm Alive" message, at which time the media controller should see it. If you still don't see it after 5 min, you may need to add the controller device to the list of active devices for WMC (then wait 5 more minutes).
TwonkyVision Music Server (version 2.7)
Twonkyvision is the server most often used for testing the Cidero software and works well. The only known issue to date is that loading of thumbnail images is a bit sluggish when browsing pictures using the Cidero controller. We are trying to figure out how to speed this up a bit, but it does appear that Twonkyvision is set up to dynamically generate them each time an image is browsed, which presumably takes a bit of time.
MusicMatch Media Server (version 9.0/10.0)
- Genre/TrackDuration metadata support
- MusicMatch version 9.0 does not export Genre or Track Duration metadata via its built-in UPnP server. Also, M3U format playlists generated by MusicMatch do not utilize the #EXTINF-style extended playlist conventions, so Artist/Title metadata is not available to the media controller in some cases when using playlists. Version 10 adds support for TrackDuration metadata, but is still lacking the Genre data as of 4/4/05.
- Bit rate metadata units
- Version 10 adds support for UPnP 'bitRate' metadata, but the reported bit rates are in bits/sec, not bytes/sec as per the UPnP spec (understandable error given the UPnP field name!)
DLink DSM-320 Media Renderer (firmware version 1.04/1.05)
- Media Controller DSM-320 Icon
- The DSM-320 does not provide a device icon in its device description XML. Also, the modelName and manufacturer XML fields are blank. This means that only the 'friendlyName' is available to the MediaController as a means to determine device type in order to grab the DSM-320 icon. If the user changes the friendly name of the DSM-320 to something that doesn't contain the 'DLink" substring (not case dependent), then the MediaController.properties file must be edited to reflect the new DLink friendly name, otherwise a default (ugly) icon will get used.
- 'Stuck' Playback.
Rarely, when playing back a playlist, the DSM-320 has gotten 'stuck' near the end of the song, never transitioning to the STOPPED state so that the MediaController can notice the state change and queue/startup the next song. The media controller now has some 'stuck device' detection logic that triggers after 8 seconds and automatially issues a stop command. This seems to unstick the device after 4 seconds or so, and the playback continues on. If you notice a 12-second gap between songs, that may be what's happening (if you have the text window up from which you started the media controller, you should see some warning messages)
- Volume change events. The DSM-320 does not appear to be producing volume change events when the volume is changed via the DLink infrared remote control. This means that the media controller playback window for the DLink will not show the true current volume unless controlled via the playback window. Note that the DLink does produce the volume events when controlled externally by the media controller, so the basic volume eventing mechanism is functional.
- Undesirable menu overlays
When playing back images or videos remotely via the Cidero controller, the DSM-320 does not remove the overlays from the screen - whatever menu was on the screen remains and obscures the underlying picture or movie. The only workaround is to use the DLink remote to display a picture, thereby clearing the screen of all menus. This is ugly from a usability standpoint, but it only needs to be done once at the beginning of a playback session.
- Escaping of XML metadata.
The XML parser used by the media controller flags certain metadata returned by the device in response to controller actions as having syntax errors. The control point corrects for this where possible. Users of the debug window may notice warnings when this occurs. See the debug window for more details.
Roku SoundBridge M1000/M2000 Media Renderer (firmware version 2.3)
With the recent release of the 2.3 software, the Roku Soundbridge is a fully-compliant UPnP Media Renderer, with no known major issues. It is the only UPnP-enabled player to support the SetNextAVTransportURI UPnP action, allowing an external controller to manage its own independent play queue, while still achieving gapless playback. Very cool!
Philips Streamium 300i Media Renderer (Release P-1.4.4 F-17 Feb '05)
(Other Philips Streamium UPnP devices may work, but we have only tested the 300i)
- No support for SetVolume() action. This is expected, since the device itself does not support the controlling of the volume! The media controller detects the lack of support for the SetVolume() action at runtime and suppresses the volume controls in the Streamium's renderer control window.
- Issues when controller is shut down uncleanly. If the media controller is shut down in an unclean manner and brought back up, the external control interface of Streamium device can sometimes get confused and require a reboot to restore functionality. It appears that this may be related to the UPnP service subscription logic of the controller. Further experimentation is required to isolate this problem.
- Invalid Instance Id errors When using multiple instances of the controller to interact with the Streamium, it can sometimes report a UPnP error status of 'Invalid Instance Id'. There may be a workaround for this using UPnP commands to clear up the issue, but for now the only known fix is to reboot the streamium. Sorry 'bout that!
Unsupported Devices
The following devices cannot be controlled via an external UPnP controller at this time (please let us know if you know of any change in the status of the UPnP MediaRenderer interface for these devices!)
- OmniFi DMS1
- Netgear MP101
