| blob | e99ba9f714fda3f734eb329b8a81407ddd64cf3a |
2 <html><head>
8 </head><body>
10 <!-- Under construction image at top left -->
12 <!--<img src="undercon.gif" />-->
13 </div>
15 <!-- Banner image at top left -->
16 <div id="banner"><img src="mediaController-Dateien/cideroWebBanner.gif" alt="Banner" align="left">
17 </div>
19 <!-- Separator -->
22 </div>
24 <!-- Navigation bar on left -->
33 <!-- Page content on right -->
51 Java Swing-based UPnP A/V control point application, allowing user's to
52 browse content on UPnP Media Servers and play it back on UPnP Media
53 Renderers. The controller supports similar functionality as the A/V
54 control point supplied with the Intel UPnP tools package, plus
55 additional features to make it more suitable for routine day-to-day
56 media playback. Support for playback of music content, pictures, and
57 videos, is provided.<br>
58 <br>
59 The controller is fully multi-threaded, allowing it to interact with
60 multiple devices. A screenshot of the UI during a multi-device test run
61 is shown below. During this run, the controller was controlling
62 playback of music on two UPnP media renderers, and monitoring the
63 progress of playback on a third device.<br>
64 <br>
65 <img src="mediaController-Dateien/ControllerSimple2.gif" alt="Media Controller" hspace="10" vspace="10">
66 <br>
67 <br>
68 <img src="mediaController-Dateien/ControllerRendererWindow5.gif" alt="Media Controller" hspace="10" vspace="10">
69 <br>
70 <br>
73 one of the supplied scripts, the media controller should detect all
74 UPnP media server and renderer devices on the network. The discovery
76 are set up to respond with a random delay to avoid discovery broadcast
77 'storms' on heavily populated networks. An icon should be displayed for
78 each discovered device in the server or renderer device window. Note
79 that the UPnP device specification provides a mechanism for devices to
80 provide their own icons to the controller, but not all devices
81 currently implement this capability. If you see the default 'server
83 <br>
84 At this point, it is assumed that the controller has discovered at
85 least one server device and one renderer device. If you need a server
86 device for test purposes, a cross-platform server can be found at <a href="http://www.twonkyvision.com/">www.twonkyvision.com</a>.
87 Likewise, if you have a server, but do not have a renderer device, the
88 media renderer supplied with the Intel UPnP Tools can be used.<br>
89 <br>
90 To get started, click on one of the server icons. A set of folders
91 should appear in the browse tree window on the left. The heirarchy will
92 typically start off with ('Music', 'Pictures', 'Movies') or something
93 similar. For the purpose of this example select a music category to
94 browse. When you reach the level where actual music tracks reside, the
95 tracks should show up in the audio item panel on the right.<br>
96 <br>
97 Each renderer device discovered by the controller has its own play
98 queue. The queue is not considered 'active' unless the device's
99 renderer window is open. Click on one of the renderer icons to bring up
100 its window. Next, select one or more tracks in the controller's music
101 track window, followed by 'Add Tracks To Play Queue'. The play queue
102 for the renderer should become visible, and display the selected
103 content. Hit the play button in the renderer window and device playback
107 The UPnP A/V Device/ControlPoint architecture allows a control point to
108 browse media on a media server, and initiate playback of that media on
109 a media renderer. After initiating the playback, the control point may
110 remain the active point of control (issuing stop/ff/rew commands for
111 example), or disconnect completely and let the media renderer and media
112 server complete the playback on their own. At any time, a control point
113 can reconnect to the renderer and server devices and regain control in
114 order to modify the playback session.<br>
115 <br> This is a very flexible control model, but support for the second
116 type of usage (start playback from external controller and disconnect)
117 remains somewhat problematic in the case of music playlists. In order
118 for a multiple-item playback session to continue in the absence of a
119 control point, the UPnP renderer device must itself support playlists.
120 Unfortunately, not all renderer devices support this at the current
121 time, preventing an external UPnP controller from being able to queue
122 more than a single item for playback. To play back music playlists in a
123 consistent way on the widest range of devices, the controller is
125 remain the active point of control and handle the playlist queuing
126 logic entirely on its own. This is the mode currently used by the media
128 renderer supports playlists. Since this mode requires that the
129 controller wait for the current song to end prior to queuing the next
130 one, there is a small gap between tracks, noticeable on music albums
131 with no silence between tracks. This will be changed in a future
132 version so that the user can choose to send playlists to renderer
133 device's that support them (and allow the controller to disengage from
134 the playback session)<br>
135 <br>
138 The controller supports two queuing modes in the renderer control
139 window when rendering audio content - a 'Normal' mode where items are
140 simply added to the end of the queue, and a 'Jukebox' mode, which is
141 used to insert 'high priority' items after the current playing song.
142 This is useful when one wants to hear a certain song without
143 stopping/restarting the music stream. An image of the renderer play
144 queue window following the insertion of two White Stripes songs after
145 an actively playing B-52's track using jukebox mode is shown below. All
146 the high priority songs are highlighted with a yellow/orange background
147 so it is easy to differentiate them from the background playlist. Note
148 that whenever the renderer is stopped, the priority of all items in the
149 play queue is reset to normal priority, since at that point the user is
150 free to restart playback at any point in the playlist by selecting a
151 song before hitting the play button.<br>
152 <br>
153 <img src="mediaController-Dateien/rendererJukeboxMode.gif" alt="Jukebox Mode" hspace="10" vspace="10"><br>
154 <br>
157 When playing image slideshows, the anticipated usage is that a user
158 will browse a number of picture folders and dynamically build a
159 slideshow using pictures from a number of folders. Once the desired
160 images have been added to a renderers slideshow play queue, the user
161 may wish to shuffle the play order by dragging them around the screen
162 prior to starting the slideshow playback. To accomodate this usage, the
163 image view of the renderer window supports a slideshow 'compose' mode
164 as well as a separate 'run' mode. When in compose mode, images may be
165 repositioned relative to one another using drag and drop. Image
166 playback, either via the controls at the top of the panel or by
167 clicking on a given image, is only enabled when in run mode. Below are
168 screenshots of the main controller and renderer windows during an image
169 playback session (MacOSX). <br>
170 <br>
172 <img src="mediaController-Dateien/ControllerImageMode.html" alt="ControllerImageMode" hspace="10" vspace="10"><br>
173 <br>
174 <img src="mediaController-Dateien/ControllerRendererImageMode.html" alt="ControllerImageMode" hspace="10" vspace="10"><br>
175 <br>
176 One caveat regarding the slideshow capabilities of the controller is
177 that the composed slideshows cannot be saved. This is due to the lack
178 of support for the UPnP 'write/update' operations in the current
179 generation of UPnP servers. If one wants to compose a permanent
180 slideshow that will not be lost when the controller is terminated, one
181 should use other means to organize the pictures prior to their export
182 by the UPnP server. For one-time only quick slideshows, though, the
183 controller functionality will hopefully prove useful!
187 below. The large folder option group contains settings to ease the
188 browsing of large music collections, by automatically creating
189 alphabetical sub-folders when the number of items in a folder exceeds a
190 certain threshold. This feature is enabled by default, with a threshold
191 of 500 items. The selection option group contains a setting to
192 automatically select all audio tracks that are browsed, so they may be
193 immediately added to the play queue of a renderer with a single mouse
194 click (no need to manually select them first).<br>
195 <br>
196 <img src="mediaController-Dateien/BrowseOptionsWindow.gif" alt="RendererOptions" hspace="10" vspace="10"><br>
201 to be set, controlling how often track position information is updated
202 in all renderer windows that are actively playing content. The default
203 is 3 seconds to keep UPnP message traffic low, but if a user prefers
204 the track position to update more frequently to more closely mimic
205 other player interfaces, it can be reduced(typically to 1 second). The <i>Play Transition Timeout</i> setting controls the amount of time the controller will wait for a renderer to transition to the <i>Playing</i>
206 state following a play command. After this period, the controller
207 assumes that there is a problem with that item, and moves to the next
208 item in the playlist if one is present. Lastly, the <i>Slideshow Interval</i> setting controls the default interval between pictures when playing an automated slideshow<br>
209 <br>
210 <img src="mediaController-Dateien/RendererOptionsWindow.gif" alt="RendererOptions" hspace="10" vspace="10"><br>
214 The controller supports a limited form of multi-device synchronization
215 using a proxy server approach. The Synchronization Options dialog box
216 allows the proxy server type (local remote), address, and port
217 information to be set, along with how often a resynchronization is
218 performed to correct for timing drift between multiple renderers. For
219 more details on the capabilities and limitations of multi-renderer
220 synchronization using the UPnP controller, see the discussion <a href="http://www.cidero.com/multiRendererSync.html">here</a>.<br>
221 <br>
222 <img src="mediaController-Dateien/SyncOptionsWindow.gif" alt="SyncOptions" hspace="10" vspace="10"><br>
228 files, which use a simple text-based format. These property files are
229 hand-editable, but this should not be necessary very often since the
230 most commonly modified preferences can be changed via dialog boxes such
231 as those described in the previous section, and saved using the
232 'File->Save Setup' menu option. There are, however, still some
233 preferences that are not exposed by the UI. These include some options
234 to handle what icons get displayed for a particular device, and a few
235 special options to handle device-specific issues.<br>
236 <br>
237 If modifying the preferences by hand, it is useful to understand a
238 little bit about how the preferences mechanism is set up, especially
239 with regard to how things are handled with regard to software updates.
240 There are two copies of the preferences file used by the controller,
241 one containing the 'factory default' settings, located in <i>$INSTALL_DIR/properties/MediaController.properties</i>, and one containing the user-specific settings, located in <i>$USER_HOME/.cidero/MediaController/MediaController.properties</i>.
242 At startup, the default settings are loaded first, followed by the user
243 settings. The user-specific preferences override the defaults. If the
244 user preferences file does not exist (first time application is run),
245 it is created by making a copy of the default file. When the controller
246 software is updated, some preferences may have been added or removed.
247 In order to update one's user-specific preferences file (not strictly
248 necessary as defaults will be used where necessary), a "File->Save
249 Setup" should be executed. This will update the user's file, adding the
250 new preferences and removing the obsolete ones. Preferences in the
251 original user's file that are still valid in the new software release
252 will remain set to the previous user-specific setting. Note that if
253 hand-editing the file corrupts the file somehow, the simplest fix is to
254 remove the file and re-run the application to create a new one.
256 provide some basic information to control points, such as the 'friendly
257 device name' and the IP address. An optional presentation URL is also
258 supported by the protocol, and typically contains a link to a device
259 status/control web page, or the manufacturers main home page. The
260 device information dialog (Options->Device Information...) presents
261 this information to the user. The dialog is shown below.<br>
262 <br>
263 <img src="mediaController-Dateien/DevInfoWindow.gif" alt="DevInfo" align="center" hspace="10" vspace="10"><br>
264 <br>
265 Clicking on a device's web page, if present, brings up the web page on
266 the system's default browser. Note that the default browser under the
267 Linux operating system is mozilla. This may be changed if desired in
268 the preferences file.The default browser under Windows is set via the
269 operating system.<br>
272 With the proliferation of UPnP server and renderer devices, it can
273 sometimes be difficult to track down subtle problems arising from
274 characteristics of a given device's UPnP implementation. The media
275 controller, like the Intel sample controller, provides a debug window
276 to help track down this type of problem. The debug window is
277 straightforward, with an upper panel containing a list of UPnP-related
278 message traffic, and a lower panel that displays the detailed view of a
279 single message when one is selected in the upper window.<br>
280 <br>
281 A screenshot of the debug window is shown below. Note that the lower
282 panel has the ability to automatically format XML metadata content
283 embedded within UPnP messages. This is particularly useful when looking
284 at mediaserver 'browse' responses. The types of UPnP messages displayed
285 in the window can be filtered using the popup dialog shown to focus in
286 on a particular message type.<br>
287 <br>
288 <img src="mediaController-Dateien/DebugWindow.gif" alt="DebugWindow" align="center" hspace="10" vspace="10"><br>
289 <br>
293 Theoretically, the UPnP media controller is designed to work with <span style="font-style: italic;">any</span>
294 UPnP A/V device. That's the theory! To date, most tests with a new
295 device have uncovered one or two issues that resulted in modifications
296 to make the controller more flexible and fault-tolerant. Some (probably
297 most) of these issues were related to the controller itself, while
298 others were related to device-specific UPnP implementation
299 issues. It is expected that this trend will continue as
300 additional devices are tested, but the required changes should become
301 more minor as time goes on.<br>
302 <br>
303 Below is a list of the UPnP A/V devices which have been tested so far
304 for interoperability with the media controller. For the most part,
305 these devices work reasonably well with the controller. Known
306 device-specific issues are noted, along with the software or firmware
307 version at the time of testing. As noted above, these issues are not
308 necessarily indicative of a problem with a particular device, but
309 rather the controller/device interaction. Please feel free to let us
310 know if you spot any inaccuracies, or notice different behavior in a
311 new software/firmware release<br>
312 <br>
314 </h4>
315 <ol>
317 - When the media controller is run on the same machine as WMC, it may
318 not immediately 'see' the Windows Media Connect server. This is a known
319 issue with WMC not responding to device search requests originating
320 from the local host. The only solution at the moment is to wait a while
322 which time the media controller should see it. If you still don't see
323 it after 5 min, you may need to add the controller device to the list
325 </ol>
328 </h4>
329 Twonkyvision is the server most often used for testing the Cidero
330 software and works well. The only known issue to date is that loading
331 of thumbnail images is a bit sluggish when browsing pictures using the
332 Cidero controller. We are trying to figure out how to speed this up a
333 bit, but it does appear that Twonkyvision is set up to dynamically
334 generate them each time an image is browsed, which presumably takes a
335 bit of time.<br>
336 <br>
339 </h4>
340 <ol>
342 - MusicMatch version 9.0 does not export Genre or Track Duration
343 metadata via its built-in UPnP server. Also, M3U format playlists
344 generated by MusicMatch do not utilize the #EXTINF-style extended
345 playlist conventions, so Artist/Title metadata is not available to the
346 media controller in some cases when using playlists. Version 10 adds
347 support for TrackDuration metadata, but is still lacking the Genre data
350 - Version 10 adds support for UPnP 'bitRate' metadata, but the reported
351 bit rates are in bits/sec, not bytes/sec as per the UPnP spec
352 (understandable error given the UPnP field name!) </li>
353 </ol>
357 </h4>
358 <ol>
360 - The DSM-320 does not provide a device icon in its device description
361 XML. Also, the modelName and manufacturer XML fields are blank. This
362 means that only the 'friendlyName' is available to the MediaController
363 as a means to determine device type in order to grab the DSM-320 icon.
364 If the user changes the friendly name of the DSM-320 to something that
365 doesn't contain the 'DLink" substring (not case dependent), then the <i>MediaController.properties</i> file must be edited to reflect the new DLink friendly name, otherwise a default (ugly) icon will get used.</li>
367 Rarely, when playing back a playlist, the DSM-320 has gotten 'stuck'
368 near the end of the song, never transitioning to the STOPPED
369 state so that the MediaController can notice the state change and
370 queue/startup the next song. The media controller now has some 'stuck
371 device' detection logic that triggers after 8 seconds and automatially
372 issues a stop command. This seems to unstick the device after 4 seconds
373 or so, and the playback continues on. If you notice a 12-second gap
374 between songs, that may be what's happening (if you have the text
375 window up from which you started the media controller, you should see
376 some warning messages)</li>
378 DSM-320 does not appear to be producing volume change events when the
379 volume is changed via the DLink infrared remote control. This means
380 that the media controller playback window for the DLink will not show
381 the true current volume unless controlled via the playback window. Note
383 the volume events when controlled externally by the media
384 controller, so the basic volume eventing mechanism is functional.</li>
386 When playing back images or videos remotely via the Cidero controller,
387 the DSM-320 does not remove the overlays from the screen - whatever
388 menu was on the screen remains and obscures the underlying picture or
389 movie. The only workaround is to use the DLink remote to display a
390 picture, thereby clearing the screen of all menus. This is ugly from a
391 usability standpoint, but it only needs to be done once at the
392 beginning of a playback session.<br>
393 </li>
395 The
396 XML parser used by the media controller flags certain metadata returned
397 by the device in response to controller actions as having syntax
398 errors. The control point corrects for this where possible. Users of
399 the debug window may notice warnings when this occurs. See the debug
400 window for more details. </li>
401 </ol>
403 <h4>Roku SoundBridge M1000/M2000 Media Renderer (firmware version 2.3)</h4>
404 With the recent release of the 2.3 software, the Roku Soundbridge is a
405 fully-compliant UPnP Media Renderer, with no known major issues. It is
406 the only UPnP-enabled player to support the SetNextAVTransportURI UPnP
407 action, allowing an external controller to manage its own independent
408 play queue, while still achieving gapless playback. Very cool!<br>
409 <br>
410 <h4>Philips Streamium 300i Media Renderer (Release P-1.4.4 F-17 Feb '05)</h4>
412 (Other Philips Streamium UPnP devices may work, but we have only tested the 300i)<br>
414 <ol>
416 This is expected, since the device itself does not support the
417 controlling of the volume! The media controller detects the lack of
418 support for the SetVolume() action at runtime and suppresses the volume
419 controls in the Streamium's renderer control window.<br>
420 </li>
421 <li style="font-weight: bold;">Issues when controller is shut down uncleanly. <span style="font-weight: normal;">If
422 the media controller is shut down in an unclean manner and brought back
423 up, the external control interface of Streamium device can sometimes
424 get confused and require a reboot to restore functionality. It appears
425 that this may be related to the UPnP service subscription logic of the
426 controller. Further experimentation is required to isolate this problem.</span></li>
428 When using multiple instances of the controller to interact with the
429 Streamium, it can sometimes report a UPnP error status of 'Invalid
430 Instance Id'. There may be a workaround for this using UPnP commands to
431 clear up the issue, but for now the only known fix is to reboot the
432 streamium. Sorry 'bout that! <br>
433 </li></ol>
435 <h4>Unsupported Devices</h4>
436 The following devices cannot be controlled via an external UPnP
437 controller at this time (please let us know if you know of any change
438 in the status of the UPnP MediaRenderer interface for these devices!)<br>
439 <ol>
440 <li>OmniFi DMS1<br>
441 </li>
442 <li>Netgear MP101<br>
443 </li>
444 </ol>
445 <br>
446 </div>
447 </body></html>