[General Topics] Menneisyys:
The situation is similarly bad with Pocket Player, which also uses streaming:

As can clearly be seen, the Amperage has always been around 380 mA (with the lowest backlight level and default Wi-Fi sensitivity setting) – which is still about 100 mA’s more than with Rundo and its Wi-Fi power saving by pre-fetching contents. The somewhat lower CPU usage of Pocket Player doesn’t really help in this respect.

Note that the previous screenshot has been made on the 520 MHz HTC Universal because, on the x51v, for some reason, PP has produced far worse results, where the CPU usage is way more as can also be seen in HERE. Frankly, I don’t know what this is caused by.

Note that both Nokia’s engineers and Rudeo’s developers allow for continuous playback: Nokia pre-fetches the next song while still playing the last one and Rudeo fetches all the songs (and writes to the storage card) while playing the first (few) song(s). This results in no pauses between songs (if there are more than one of them) – only the starting of the playback of the first song will be delayed.

1.3.2 Remote controlling

The situation with pure remote controlling is pretty much the same as with above. The power saving feature of the Nokia kicks in quite fast and results in about 0.15-0.17W generic power usage (that is, about 0.07 Watts more than without Wi-Fi remote control activated). Windows Mobile-based devices, in this mode, fare far better than in the previous case as can clearly be seen in the following screenshot:

As can clearly be seen, the average current is 130-150 mA (just slightly more than without doing anything and a LOT less than the ~400 mA average of active Wi-Fi streaming), which clearly shows the Wi-Fi unit is idling and the CPU usage, which is very low, doesn’t contribute much to the overall power usage.

1.3.2.1 Try disconnecting / powering down your handset when not actively remote controlling!

Finally, a quick tip. As has also been explained in the RMC Bible, you can safely disconnect / power down your handset after initiating a (fully) remote playback – that is, between, for example, a NAS and a flat TV. Then, when you need remote control again, you just power on your device, let the Wi-Fi unit reconnect and you'll almost promptly be able to regain remote control on both the server and the renderer. This is pretty much the same as with traditional, non-UPnP RMC applications and, again, is thoroughly explained in the RMC Bible.

1.4 Networking

If you plan to use your handset in a “real” home environment (to, for example, control the multimedia data flow between a flat TV and a Network Attached Storage), you’ll end up having to use Wi-Fi.

You may (depending on whether your clients are Bluetooth PAN – see below – capable) also want to use Wi-Fi if you “only” have computers on your network. Then, you’ll have somewhat more choices: you can use both infrastructure and peer-to-peer (p2p) mode between the devices. The latter doesn’t require an access point and is supported by both Windows Mobile and Symbian.

However, if you strive for better battery life, you can also use Bluetooth (BT) Personal Area Network (PAN) if and only if all your UPnP components support it. Unfortunately, there’s no widespread support for BT PAN. Symbian devices don’t support it at all; neither do Windows Mobile ones with the MS BT stack in client mode (and, unrestricted, in server mode only with an additional hack). That is, it’s only with Windows Mobile devices with the (in cases, “hacked”, post-installed) Widcomm (Broadcom) BT stack that you can use this form of very battery-friendly form of multimedia sharing / control.

Please also see the related section in the old RMC Bible for more info on all these networking-related questions. Also, let me know if you don’t know how to set up these kinds of networks - but, of course, before asking, first, read the linked article (and all the backlinked ones - I've publsihed several, extensive tutorials on creating for example peer-to-peer Wi-Fi networks).

2. Desktop UPnP apps

Should you want to play with desktop (Windows, Linux, Mac etc.) servers / controllers / renderers, you’ll want to check out the following section. Note that you will in no way need these applications for your mobile UPnP clients to operate in an already-deployed UPnP home network; I’ve only presented it to you so that you know where to look for, say, a pure, but decent and free (!) controller running on any desktop or server OS (for that, I recommend Cidero’s app). These can help a lot with quickly seeing whether a given server is accessible / visible on the network, what content it offers etc.

Another great use for these apps (in this case, Nero MediaHome) is seeing what’s happening in the UPnP network, how many users / clients have connected to your server from which local IP’s. These apps greatly help in tracking down possible networking problems. For this kind of problem fixing, I recommend Nero MediaHome the most.

In the next three subsections, I elaborate on the three main components of the UPnP architecture: (Media)Server, (Media)Controller and (Media)Renderer. In general, there’re no software products implementing all these three functionalities (unlike, say, Conduits Pocket Player on Windows Mobile). There’s On2Share Pro - UPnP AV Suite that promises to implement all of this (it has a 14-day trial and is pretty cheap: only 19.95 euros), but I’ve never managed to make it really work – neither under Windows XP nor under Vista. (I’ve tried to do this on two different desktop PC’s, using two different networking topologies – both peer-to-peer Wi-Fi and using a standard access point. A no-go. While it did list the other UPnP-capable, visible (either a server (upper listbox) or a renderer (lower listbox)) participants:

(another screenshot of the lower part of the server list)

it wasn’t able to communicate with them in any way. (Note that the screenshot has been taken under Vista, using large fonts (a must on a 15" UXGA screen); this is why the lower left buttons are messed up; on XP, with normal fonts, it's correctly rendered. Also note that it displays 127.0.0.1 as the local IP, that is, localhost. This shows the computer had no active Internet connection when the app was started (I've, later, set up an Internet-less p2p Wi-Fi connection manually). Don’t let this make you think I’ve messed up the setup – in other tests, I’ve restarted it so that it received a real LAN IP address. Then, it didn’t work either.)

2.1 (Pure) Servers (MediaServers)

2.1.1 TVersity

Along with Sling (which I haven’t been able to test because it’s still not available in Europe, except for the U.K.) and Orb, TVersity is the most popular remote (WAN; that is, non-local (LAN) UPnP) streaming server, allowing for a lot of niceties; for example, dynamic radio / media transcoding. If you already know this app (because, for example, you’ve used its streaming capabilities over remote mobile networks), you’ll certainly welcome its UPnP capabilities.

(the share config screen; the second tab, with the list of the contents on the server, looks like this – as can clearly be seen, it’s pretty complicated to navigate between the server multimedia contents as there’s no scrollbar. A screenshot of browsing TVersity on a Symbian device is HERE)

TVersity, of course, has its own discussion forum; of it, I recommend THIS thread.