AndrewFG wrote:
> More thoughts on this:
>
> Most App plug-ins in LMS expose urls with a custom protocol scheme (e.g.
> aardvark://... instead of http://... ) and the plugin includes a
> protocol handler that knows how to interpret this protocol scheme; i.e.
> it knows how authenticate the user, fetch track meta data and cover art,
> and download the music stream.
>
> Therefore I am pretty sure that a UPnP CP served by Whitebear would be
> able to navigate down such an App's browse tree until it reaches a leaf
> containing such a custom track url; and it would then be able to handle
> a UPnP Play To command to play such track on a Squeeze player, since the
> plug-in's protocol handler could handle all the mechanics.
>
The problem is that Spotify doesn't allow anyone to send their streams
unencrypted over the network.
- Logitech's Spotify plugins solves this by letting the player access
libspotify API and stream to the player directly from Spotify.
- Triode's Spotfy can transcode it but to avoid licensing troubles it
doesn't permit an unknown software player to play the transcoded
streams, so I don't think you will be able to use that to send it to a
random UPnP playback device.
So basically, I guess it means that if a UPnP solution should support
online streaming services like Spotify the UPnP player (MediaRenderer)
will have to have native support for calling libspotify API ?
The issue with this is that Spotify isn't alone that works this way,
many online streaming services are forced by the recording companies to
protect any stream they expose to ensure it isn't possible to rip it,
basically ensure it's not possible to send it to a playback device which
haven't been explicitly authenticated with the streaming service. So
since online streaming services is the future, it feels like UPnP has to
have support for things like this if it want to be the future solution
for music streaming. Else it will only be the future for locally stored
music and that's something that's likely going to be less and less
common, especially among the masses.
And for it to work in an environment with UPnP devices from various
manufacturers, there has to be a standard definition to how Spotify
streams should be exposed, because the above means that the media server
must expose them in such way that they can be understood by a player
from another manufacturer. If it's not in the standard it's simply not
going to work in an environment with UPnP devices from multiple
manufacturers.
AndrewFG wrote:
>
> { note: the current Whitebear release is hard coded to reject non
> http://... urls, so I would have to adapt it to be more generous about
> accepting such custom schemes... }
>
No problem, I was wondering more about what's possible through UPnP than
what works specifically in Whitebear, thanks for the information, I
appreciate it.
------------------------------------------------------------------------
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=95603
_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/discuss
