Print

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

[davidw55]

I'm using MC 18 with two DLNA audio renderers, a WDTV Live (using digital passthrough to a Yamaha amp) and a Pioneer A4 wireless speaker.

It all works rather well and the JRemote app on my iPhone makes this setup pretty nice to use.

The only wrinkle in this occurs when I start streaming internet radio to either of these devices.   Neither of them will display the current song title or album metadata (when viewed using MC or JRemote as controllers).  (OTOH both devices will display song metadata when playing a file).   
I know the radio sources I'm using are sending metadata because MC's builtin renderer will happily show updated song titles (as will iTunes).

Is it just a fact that DLNA support on these "low-end" media players is incomplete or buggy with regard to handling radio metadata ?

Perhaps I should just step up and buy a 'serious' media player  (assuming that more money will fix the problem ?).  If so, what should I buy ?

I don't suppose that MC can influence what these renderers do with regard to radio metadata ?

Lots of questions
Opinions or advice welcome

Dave

[davidw55]

Anyone ?

Maybe if I knew how internet radio sites encode their song titles ... does anyone here know the protocol used to show song name, artist etc ?

[bob]

I don't think the ICY-METADATA is being sent with the stream to the DLNA device.
We'd have to parse it and repackage it in the format DLNA metadata uses.
If you look at the stream in MC's list while it's playing locally, that is what is sent to the renderer when playing via DLNA.

[AndrewFG]

I don't think the ICY-METADATA is being sent with the stream to the DLNA device.
We'd have to parse it and repackage it in the format DLNA metadata uses.

Hi bob.

I don't think there is any evidence that current UPnP DLNA renderers could parse icy meta data (aka shoutcast meta data) anyway.

As we all know, most renderers are quite sparing in selecting those parts of the UPnP DLNA specifications that they deign to support, and icy/shoutcast is not part of the specification at all, so IMHO such support would be doubly unlikely.

Furthermore if a renderer would support icy/shoutcast it would be difficult for it to determine whether to use the meta data embedded in the stream or the meta data sent by the UPnP SOAP methods.

And finally, if MC were to embed icy blocks in its output stream, you can be sure that you would choke all those existing renderers out there who don't understand icy. On such renderers you would hear an audible click (or dropout) for every icy/shoutcast meta data block sent...

[bob]

Good points Andrew, thanks!

[davidw55]

Thanks for the that info

MC's renderer does handle the radio metadata which tells me that its technically possible.

One question, when a renderer is playing a radio URL, it receiving data via the MC server or is the rendered directly reading the radio URL ?

[AndrewFG]

MC's renderer does handle the radio metadata which tells me that its technically possible.

It is of course technically possible. But it is not part of the UPnP specification, nor indeed part of the DLNA specification. So if a device would implement it, (when playing or serving tracks in UPnP / DLNA mode), then that device would be non compliant with that specification.

One question, when a renderer is playing a radio URL, it receiving data via the MC server or is the rendered directly reading the radio URL ?

I don't know the answer to this, so someone at JRiver needs to give you a precise response. But in principle both options are feasible; in one case MC would pull the stream from the radio station server and the render would pull it from MC (a kind of proxy server function), and in the other case the renderer would pull the stream direct from the radio station server. Obviously the latter case uses less bandwidth, and I suppose that is the way that MC does it.

[davidw55]

I might wireshark my renderer (a Pioneer A4 active speaker) to see where its getting its data from when playing a radio URL.   I would assume that if transcoding is necessary then MC must be involed.

[AndrewFG]

I might wireshark my renderer (a Pioneer A4 active speaker) to see where its getting its data from when playing a radio URL.   I would assume that if transcoding is necessary then MC must be involed.

Please keep us posted; personally I managed to control my enthusiasm myself to do a wireshark

As you imply, my bet is on MC telling the renderer to pull direct when no transcoding is involved, and only proxying when transcoding is required. (That is the way I do it in Whitebear).

Actually a large proportion of radio streams are MP3 so I suppose the renderer would be told to pull direct in most cases. But obviously if you have MC set to Always Convert to LPCM then it might have to proxy the stream in up sampled PCM (even though it is simply burning bandwidth)...

[bob]

We currently don't transcode streams.

[AndrewFG]

^

I will declare that as me having won the bet then...

[bob]

I will declare that as me having won the bet then...

[davidw55]

Bob ..just so I understand.

When you say you that MC doesn't currently transcode streams, I think you mean ...

MC doesn't transcode a stream URL;  it 'always' forwards the URL to the renderer and take no further part.

This is different from the way a song file is handled.  For a song file, MC can, depending on how its configured, either send the renderer a local URL for the song file, or it can transcode the song file and stream that to the renderer.

Did I get that right ?

Dave

[bob]

Yes Dave, that is a perfect description of the way it works.