Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[csimon]

See http://www.whathifi.com/news/cambridge-audio-stream-magic-6-and-np30-get-gapless-playback.

I don't know if anyone has one of these machiens, but they're the ones I've got my eye on. Been holding back because they don't have seek controls, but anyway it would be nice to know if MC's gapless feature plays along with these machines.

[bob]

I wonder what they used to test it with? There aren't many controllers that support gapless playback and there are 2 really different methods of doing it.

[AndrewFG]

...there are 2 really different methods of doing it.

Just so ypu know: I just messaged the guy at Cambridge Audio asking how they achieved the gapless play function (i.e. using SetNextAvTransportUri vs. using a playlist)...

[doulos]

(i.e. using SetNextAvTransportUri vs. using a playlist)...

please excuse my chiming in.. but how do you achieve gaplessness using a playlist?

also, have you heard of DLNA_playcontainer? It supposedly also enables gaplessness, along with delegating playback to the server/renderer combo, vs. having to keep the controller alive to do SetNextAVTransportURI at appropriate times.. I hear that the raumfeld system (www.teufel.de/Raumfeld) implements this capabiliy.

[csimon]

I assume it's when an entire playlist is downloaded to the renderer so that the renderer is in charge of playback sequencing rather than the controller.

I have posted a question to the C.A. Facebook page!

[doulos]

I assume it's when an entire playlist is downloaded to the renderer so that the renderer is in charge of playback sequencing rather than the controller.

huh? How do you upload a playlist file to the render via UPnP? What you describe sounds like what DLNA_playcontainer is doing, but that is hardly ever implemented

[csimon]

See http://yabb.jriver.com/interact/index.php?topic=58847.msg398376;topicseen#msg398376 and http://yabb.jriver.com/interact/index.php?topic=69102.msg465037#msg465037, and there are probably others.

[doulos]

See http://yabb.jriver.com/interact/index.php?topic=58847.msg398376;topicseen#msg398376 and http://yabb.jriver.com/interact/index.php?topic=69102.msg465037#msg465037, and there are probably others.

ok, got it, thanks. There is something about a "Linn DLNA extensions for on-device playlist", and about sending "(say) an .m3u or a .pls file as the track to be played". I wonder how the latter works in reality, whether the devices supporting it will send correct CurrentTrack information etc. If so, I dont understand why it is classified as a kludge by AndrewFG.

[bubbleguuum]

One way to achieve on-device playlists:

http://www.openhome.org/wiki/OhMedia

These are the original Linn Playlist extensions formalized in the OpenHome standard.

What devices implement it besides Linn DS hardware products ?

With BubbleUPnP Server (which I wrote) any regular UPnP AV renderer can be augmented with these extensions.
It addresses problem 2 and 3 in document above.

Of course theses devices require an OpenHome Control Point.
Theres Linn Kinsky (iOS, Windows, Mac), various 3rd party Linn control points on iOS (largely untested), BubbleUPnP on Android, foobar2000+foo_upnp on Windows.

[csimon]

Got this reply:

quite simply it works by a big buffer so the playback engine has time to finish, and work out the next thing to play before the buffer drains.

Still none the wiser though!

[csimon]

I added a response:

So that means it should work with any media server? I guess it basically requests the next item from the server (or sends a "finished playing" event) before it needs to, so the server is "tricked" into sending the next track earlier than it would normally do?

and got the reply

You're absolutely correct - it will work with any media server as the software will request the next track from the server before the audio from the last track has been output from the buffer.

So does anyone want to be brave enough to buy one and try it?!

From what they're saying, it sounds like there may be a control issue towards the end of a particular track when the controller thinks the renderer has finished playing it, but apart from that does this sound like it could work?

[JimH]

If the manufacturer is willing to test, we could send them a free license.  Just ask them to contact jimh at jriver.   (Please don't post my full e-mail address.)

[doulos]

From what they're saying, it sounds like there may be a control issue towards the end of a particular track when the controller thinks the renderer has finished playing it, but apart from that does this sound like it could work?

I dont see the problem here. The way I understand (and have implemented) gapless, the control point will do the following:

• issue SetAVTransportURI for the first track
• receive a "playing" event. If the playing track is the last one scheduled, go to next step
• while the first track is still playing, issue a SetNextAVTransportURI for the next track
• repeat the last 2 steps until all tracks have played

where would there be a control issue with this? In addition, I would consider any device that doesnt implement it that way not relevant. My Sony CMT-G2NiP certainly does.

chris

[csimon]

where would there be a control issue with this?

I didn't say there was.  I haven't been able to get from them whether they are using SetAVTransportURI or not.  If they're not, then there might be a control issue because they have seemed to imply that the renderer issues a "finished playing" event before it needs to.  But maybe it's just a clumsy way of describing SetAVTransportURI.

[doulos]

I didn't say there was.  I haven't been able to get from them whether they are using SetAVTransportURI or not.  If they're not, then there might be a control issue because they have seemed to imply that the renderer issues a "finished playing" event before it needs to.  But maybe it's just a clumsy way of describing SetAVTransportURI.

there isnt much for the renderer to do anyway. All they have to do is implement SetNextAVTransportURI in addition to  SetAVTransportURI. The rest is up to the control point.

[csimon]

Yeah, that's my issue really, they are saying it will work with any server.  For example, does Windows Media Player handle gapless by using SetNextAVTransportURI?  I don't know, but I was under the impression that this is not something that's widely implemented at the moment in players and control points.

[doulos]

technically, saying it will work with any server, is meaningless anyway, because gaplessness, if implemented through SetNextAVTransportURI, is between the renderer and the control point. Of course, some servers do integrate control point functionality

[bubbleguuum]

My guess is that it will play gaplessly only when operated from whatever UI they have on the front panel to
browse and enqueue tracks. Forget SetNextAvTransportUri or anything else here.

[csimon]

That's what I'm thinking.  They have their own iOS/Android app that works like Gizmo or My JRiver in that it's a remote control for the player as opposed to being a UPnP control point, but it can indeed connect to a UPnP/DLNA server.  But I guess the playing protocols are their own and is not based on UPnP, but that's how they can claim it works with any server, as long as their own remote control app is used.

[bob]

technically, saying it will work with any server, is meaningless anyway, because gaplessness, if implemented through SetNextAVTransportURI, is between the renderer and the control point. Of course, some servers do integrate control point functionality

Right, the server really don't have to be any different. The renderer and control point do all of the work. Now some devices, notably the Sony media player and the Sony NX8 TV we have implement SetNextAVTransportURI but don't request the next file soon enough to play it gaplessly (even though they have the URL long before they need to request it). The renderering device probably needs to keep the connection to it's audio device open and just start playing the next track. It feels like the Sony closes then re-opens the audio device causing a small gap (it's much better than a lot of devices that do the regular DLNA track transitions, but still audible).

[AndrewFG]

My guess is that it will play gaplessly only when operated from whatever UI they have on the front panel to
browse and enqueue tracks. Forget SetNextAvTransportUri or anything else here.

Yes that is possible. One way to do it would be as follows (but it is not pretty):

- wait for the incoming SetAvTransportUri
- do an HTTP GET to download the full track into a memory buffer; and start playing it
- respond to GetTransportInfo and GetPositionInfo as if playing normally; until (say) 5 seconds before the end of the track, whereupon...
- kludge the responses to GetTransportInfo and GetPositionInfo to indicate the track has finished; even though actually still playing the last 5 secs
- this forces the CP to send another SetAvTransportUri; whereupon jump to step 1 above, and continue...

[AndrewFG]

There is something about ... sending "(say) an .m3u or a .pls file as the track to be played". I wonder how the latter works in reality, whether the devices supporting it will send correct CurrentTrack information etc. If so, I dont understand why it is classified as a kludge by AndrewFG.

Hmmm. I don't recall why I said it was a kludge, so I take back that comment. Indeed the specifications do very specifically cover this possibility:

2.2.18. AVTransportURI

Reference, in the form of a URI of the resource controlled by the AVTransport instance. This URI may refer to a ‘single’ item (e.g., a song) or to a collection of items (e.g., a playlist). In the single item case, the AVTransport will have 1 ‘track’ and AVTransportURI is equal to CurrentTrackURI. In the ‘collection of items’ case, the AVTransport will have multiple tracks, and AVTransportURI will remain constant during track changes.

So to summarise: there are two ways of doing gapless playback, namely 1) using SetAvTransportUri plus SetNextAvTransportUri, or alternatively 2) using SetAvTransportUri only and passing a playlist. In both cases, it requires that both CP manufacturers and Renderer manufacturers must support that respective feature. Today, in my experience, most CP and Renderer manufacturers support neither. And obviously it won't work if the CP supports only method 1) and the Renderer only supports method 2) or vice-versa...

So the conclusion is clear: Lobby your CP and Renderer manufacturers to force them to support both methods 1) and 2)...

[doulos]

Yes that is possible. One way to do it would be as follows (but it is not pretty):
- respond to GetTransportInfo and GetPositionInfo as if playing normally; until (say) 5 seconds before the end of the track, whereupon...
- kludge the responses to GetTransportInfo and GetPositionInfo to indicate the track has finished; even though actually still playing the last 5 secs
- this forces the CP to send another SetAvTransportUri; whereupon jump to step 1 above, and continue...

I dont understand why that would be needed. In the control point I imeplemented (MediaSteersman for Android, soon to be released), I wait for the TransportStatus to switch to "PLAYING" for the current scheduled URI, and then immediately call SetNextURI. Works with all renderers I have tested so far (provided they support SetNextURI)..

[bubbleguuum]

So the conclusion is clear: Lobby your CP and Renderer manufacturers to force them to support both methods 1) and 2)...

At this point it is a lost cause. SetAVTransportURI exists since forever and see the support it got.
Not surprising: harwdware manufacturers are known to cut every corner they can, and you can bet that gapless is the latest
of their concern (for consumer cheap hardware, less so for high end audio gear). Let alone that having a robust gapless decoder
is not that easy to implement.

And SetAVTransportURI doesn't address the ability to leave a renderer doing playlist track advance on its own without leaving a CP running.
Something OpenHome address.

[AndrewFG]

And SetAVTransportURI doesn't address the ability to leave a renderer doing playlist track advance on its own without leaving a CP running.

I suppose that you meant SetNextAVTransportURI rather than SetAVTransportURI? In which case your point is valid...

Note however that the alternative method (2) where in SetAVTransportURI you give the url of an .m3u or .pls playlist, does allow the renderer to continue working through that playlist even though the CP goes offline.

Something OpenHome address

Hmmm. If you think it is hopeless to try to get manufacturers to implement the existing UPnP specifications fully, then how can you hope that they will adopt OpenHome instead  ;-)

[AndrewFG]

I dont understand why that would be needed. In the control point I imeplemented (MediaSteersman for Android, soon to be released), I wait for the TransportStatus to switch to "PLAYING" for the current scheduled URI, and then immediately call SetNextURI. Works with all renderers I have tested so far (provided they support SetNextURI)..

Yes, that is indeed the correct way of doing it (with SetNext...)

My post was speculating about how a renderer manufacturer might attempt a "kludge" implementation of gapless playback without implementing SetNext... -- However obviously it is better to do things right in the first place.

[bubbleguuum]

I suppose that you meant SetNextAVTransportURI rather than SetAVTransportURI? In which case your point is valid...

Yes of course, SetNextAVTransportURI.

Note however that the alternative method (2) where in SetAVTransportURI you give the url of an .m3u or .pls playlist, does allow the renderer to continue working through that playlist even though the CP goes offline.

That requires the renderer to support .m3u or .pls which is not a given, far from it. This requires such support in the CP as well. In other words, it is inexistent and not practical (pretty much like SetNextAVTransportURI). And it doesn't address a third problem which is multiple control points connected to the same renderer without turbo-fighting each other for control :p.

Hmmm. If you think it is hopeless to try to get manufacturers to implement the existing UPnP specifications fully, then how can you hope that they will adopt OpenHome instead  ;-)

I do not expect anything, that's why I'm doing it for them (http://www.bubblesoftapps.com/bubbleupnpserver/).
It doesn't do gapless yet but it is definitely on the todo list although not exactly trivial to implement.

[bob]

Thanks for this discussion people!

We started down the path of implementing the OpenHome playlists but realized there doesn't seem to be much in the way of renderer support and it is fairly complex to implement (though a usable subset for gapless playback would be easier). On the other hand, there are some renderers that support SetNextAVTransportURI in addition to WhiteBear. Some of the renderer support is buggy but some of those problems can be worked around. There are even a couple of android renderers that claim to support it (though the implementation seems incomplete).

Now the SetNext... method doesn't cover all issues but it does allow gapless playback and is pretty easy to implement compared to the OpenHome playlists. Renderer support for any gapless method is rare and it often seems that the renderer device firmware is buggy, never updated, an afterthought from the manufacturer, etc. It seems like the most likely method the device manufacturers will implement for gapless playback is the one that easiest for them (or they'll just blow it off).

[AndrewFG]

That requires the renderer to support .m3u or .pls which is not a given, far from it. This requires such support in the CP as well. In other words, it is inexistent and not practical (pretty much like SetNextAVTransportURI).

I know it. However I have decided that I at least shall try to set a good example to others by implementing .m3u support on SetAVTransportURI (and indeed on SetNextAVTransportURI) in Whitebear. Who knows, but perhaps I can motivate a certain CP manufacturer (don't mention the name "bob") to implement it too. Perhaps we can start a virtuous circle...

And it doesn't address a third problem which is multiple control points connected to the same renderer without turbo-fighting each other for control :p.

Yeah. That is probably why I earlier called method (2) a kludge. However, to be honest this problem of multiple CPs has no possible solution. The only possible outcome is that "the last command always wins". This is not unique to UPnP, it would be exactly the same with any other architecture.

[bob]

I know it. However I have decided that I at least shall try to set a good example to others by implementing .m3u support on SetAVTransportURI (and indeed on SetNextAVTransportURI) in Whitebear. Who knows, but perhaps I can motivate a certain CP manufacturer (don't mention the name "bob") to implement it too. Perhaps we can start a virtuous circle...

Are you going to be keying off of the mimetype or file extension?

Yeah. That is probably why I earlier called method (2) a kludge. However, to be honest this problem of multiple CPs has no possible solution. The only possible outcome is that "the last command always wins". This is not unique to UPnP, it would be exactly the same with any other architecture.

As a controller, when we haven't sent a transport command (like Play or Stop) we just passively display the information from a renderer if they are the current zone in our playing now.

[AndrewFG]

Are you going to be keying off of the mimetype or file extension?

Yes ;-) ...

... in fact Whitebear first looks at the extension on the url (if it has one), and then if the format is unknown (or non existant) it does an HTTP GET to fetch the mime-type.

[bob]

...
It doesn't do gapless yet but it is definitely on the todo list although not exactly trivial to implement.

The Bubble UPnP renderer on my android looks like it supports SetNextAVTransportURI and it appears to work except that it's not gapless. And that is the tricky part I presume, since I get the same results from our Sony DLNA TV and the Sony Networked Media Player. The functions works but there is still a small gap. It looks like the underlying player (VLC or whatever) has to finish before it can request the next file. I don't know how Andrew does it but our renderer starts pulling the next file as soon as it gets the URL and doesn't close the audio channel between tracks (of course we aren't using a third party app to play the stream).

[AndrewFG]

I don't know how Andrew does it ...

Well actually I can't claim the credit for this; the Logitech / Squeezebox Server does all the work for me; its built in architecture includes functionality for pushing bits gaplessly to the Squeezeplayer; it even has an optional crossfade setting so that the end of the first track will fade over to the beginning of the next one...

[bubbleguuum]

The Bubble UPnP renderer on my android looks like it supports SetNextAVTransportURI and it appears to work except that it's not gapless. And that is the tricky part I presume, since I get the same results from our Sony DLNA TV and the Sony Networked Media Player. The functions works but there is still a small gap. It looks like the underlying player (VLC or whatever) has to finish before it can request the next file. I don't know how Andrew does it but our renderer starts pulling the next file as soon as it gets the URL and doesn't close the audio channel between tracks (of course we aren't using a third party app to play the stream).

Hi Bob,

The BubbleUPnP renderer does not implement SetNextAVTransportURI. The action is there but it doesn't do anything.
It is somewhat in the todo list to implement it now that Android 4.1 makes gapless possible (without resorting to own media framework).

[bob]

Hi Bob,

The BubbleUPnP renderer does not implement SetNextAVTransportURI. The action is there but it doesn't do anything.
It is somewhat in the todo list to implement it now that Android 4.1 makes gapless possible (without resorting to own media framework).

Oh I guess MC's just falling back to SetAVTransportURI.
I had assumed it was supported since it shows up in the AVTransport functions list in device spy.

If we see that it exists, we do a few tests on it before using it but that's not fullproof.
Perhaps you don't want to expose the function if it's non-functional?

[bubbleguuum]

Perhaps you don't want to expose the function if it's non-functional?

Yes, I've changed it to not expose that action.

[bob]

Well actually I can't claim the credit for this; the Logitech / Squeezebox Server does all the work for me; its built in architecture includes functionality for pushing bits gaplessly to the Squeezeplayer; it even has an optional crossfade setting so that the end of the first track will fade over to the beginning of the next one...

That's pretty cool!

[GLXi95]

I have a Cambridge Audio NP30 and playing files via UPNP. After updating the FW to the latest it does gapless playback now..

[bob]

I have a Cambridge Audio NP30 and playing files via UPNP. After updating the FW to the latest it does gapless playback now..

Excellent, thanks for the report!

[GLXi95]

Excellent, thanks for the report!

No problem sir..

[bob]

I have a Cambridge Audio NP30 and playing files via UPNP. After updating the FW to the latest it does gapless playback now..

Oh, I should have asked you if you can play gaplessly when you push tracks to it from inside of MC as well as when you pull them from the NP30 through it's UI.

Thanks,
Bob

[GLXi95]

Oh, I should have asked you if you can play gaplessly when you push tracks to it from inside of MC as well as when you pull them from the NP30 through it's UI.

Thanks,
Bob

I havent tried pushing tracks to it from inside of MC.. but i will try later when i get home.

So far, Playing files via UpNp and via it's USB.. It's gapless..

Will test it later... Thanks.

[GLXi95]

I havent tried pushing tracks to it from inside of MC.. but i will try later when i get home.

So far, Playing files via UpNp and via it's USB.. It's gapless..

Will test it later... Thanks.

Finally able to test it..

Playing files via USB Gapless? - Yes
Playing files via Network Wifi and Hardwire Gapless - Yes
Pushing Tracks from Inside of MC Gapless - No

Though i dont know if there's a setting in MC that i need to configure..

[AndrewFG]

Though i dont know if there's a setting in MC that i need to configure..

Right click on the Player in MC and there is a sub menu that says something like "Disable SetNextAvTransportUri (for broken renderers)" -- make sure that this is not checked (i.e. not disabled).

[FrankP1953]

Right click on the Player in MC and there is a sub menu that says something like "Disable SetNextAvTransportUri (for broken renderers)" -- make sure that this is not checked (i.e. not disabled).

Help! Anything else to set on Stream Magic or MC? I've got all the firmware updates, but cannot push gaplessly from MC... And the Stream Magic interface is less than convenient.

Thanks

[bob]

Download the "developer tools for upnp" and use device spy to query the renderer.
Look under the AVTransport service for SetNextAVTransportURI.
If it doesn't exist, then the renderer can't play gapless uPNP with MC.

[FrankP1953]

Okay, the bad news is Stream Magic 6 doesn't have "SetNextAVTransportURI" - stuck with gapped playback unless I want to use Cambridge Audio's horrendous interface...

F

[bubbleguuum]

For any one interested, here's the device description XML, which confirms non standard UPnP services to achieve "Magic":

Code: [Select]

<?xml version="1.0" ?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:schemas-upnp-org:device:MediaRenderer:1</deviceType>
<friendlyName>Stream Magic 6VOE-Netplay</friendlyName>
<manufacturer>Cambridge Audio</manufacturer>
<manufacturerURL>http://www.cambridgeaudio.com/</manufacturerURL>
<modelName>Stream Magic 6</modelName>
<modelNumber>551</modelNumber>
<UDN>uuid:6d3c9058-68d0-4859-9a52-6ed261c68ed6</UDN>
<serialNumber>0008be1d</serialNumber>
<iconList>
<icon>
<mimetype>image/png</mimetype>
<width>48</width>
<height>48</height>
<depth>8</depth>
<url>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/CA-roundal-48x48.png</url>
</icon>
<icon>
<mimetype>image/jpeg</mimetype>
<width>48</width>
<height>48</height>
<depth>24</depth>
<url>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/CA-roundal-48x48.jpg</url>
</icon>
<icon>
<mimetype>image/png</mimetype>
<width>120</width>
<height>120</height>
<depth>8</depth>
<url>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/CA-roundal-120x120.png</url>
</icon>
<icon>
<mimetype>image/jpeg</mimetype>
<width>120</width>
<height>120</height>
<depth>24</depth>
<url>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/CA-roundal-120x120.jpg</url>
</icon>
</iconList>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType>
<serviceId>urn:upnp-org:serviceId:RenderingControl</serviceId>
<SCPDURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/RenderingControl/RenderingControl1.xml</SCPDURL>
<controlURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/RenderingControl/invoke</controlURL>
<eventSubURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/RenderingControl/event</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>
<serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId>
<SCPDURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/ConnectionManager/ConnectionManager1.xml</SCPDURL>
<controlURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/ConnectionManager/invoke</controlURL>
<eventSubURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/ConnectionManager/event</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType>
<serviceId>urn:upnp-org:serviceId:AVTransport</serviceId>
<SCPDURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/AVTransport/AVTransport1.xml</SCPDURL>
<controlURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/AVTransport/invoke</controlURL>
<eventSubURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/AVTransport/event</eventSubURL>
</service>
<service>
<serviceType>urn:UuVol-com:service:UuVolControl:3</serviceType>
<serviceId>urn:UuVol-com:serviceId:UuVolControl</serviceId>
<SCPDURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/RecivaRadio/RecivaRadio.xml</SCPDURL>
<controlURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/RecivaRadio/invoke</controlURL>
<eventSubURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/RecivaRadio/event</eventSubURL>
</service>
<service>
<serviceType>urn:UuVol-com:service:PlaylistExtension:1</serviceType>
<serviceId>urn:UuVol-com:serviceId:PlaylistExtension</serviceId>
<SCPDURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/UuPlaylist/Playlist.xml</SCPDURL>
<controlURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/UuPlaylist/invoke</controlURL>
<eventSubURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/UuPlaylist/event</eventSubURL>
</service>
<service>
<serviceType>urn:UuVol-com:service:UuVolSimpleRemote:1</serviceType>
<serviceId>urn:UuVol-com:serviceId:UuVolSimpleRemote</serviceId>
<SCPDURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/RecivaSimpleRemote/RecivaSimpleRemote.xml</SCPDURL>
<controlURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/RecivaSimpleRemote/invoke</controlURL>
<eventSubURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/RecivaSimpleRemote/event</eventSubURL>
</service>
<service>
<serviceType>urn:UuVol-com:service:StreamMagic6:1</serviceType>
<serviceId>urn:UuVol-com:serviceId:StreamMagic6</serviceId>
<SCPDURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/StreamMagic6/StreamMagic6.xml</SCPDURL>
<controlURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/StreamMagic6/invoke</controlURL>
<eventSubURL>/6d3c9058-68d0-4859-9a52-6ed261c68ed6/StreamMagic6/event</eventSubURL>
</service>
</serviceList>
<dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0">DMR-1.50</dlna:X_DLNADOC>
<dlna:X_DLNADOC xmlns:dlna="urn:schemas-dlna-org:device-1-0">M-DMP-1.50</dlna:X_DLNADOC>
</device>
</root>


[bob]

For any one interested, here's the device description XML, which confirms non standard UPnP services to achieve "Magic":
...

Well as you say, it looks like they named it aptly