Print

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

[klapaciuss]

Hello.

I am using MC20 as well as DLNA Renderer. I noticed poor JRiver compatibility with some DLNA applications (e.g. AirAudio and AllStream for Android). AirPlay developer provided me info about bug on JRiver side.

"JRiver is sending a HTTP-header "Icy-Metadata: 1" which means: "I can handle track-informations between the actual song-data".. but that was a false information of JRiver. AirAudio is able to send song-informations via the "Icecast"-protocol.. that's why it was just not working with AirAudio"

Is it possible to repair it or make some comment about this behavior? Thanks in advance.

[funtax]

Hi,

I'm the developer of AirAudio.

To be more detailed: JRiver also sends the "Icy-Metadata: 1"-header in case of LPCM, but JRiver doesn't care about the Shoutcast-metadata in case the audio-format is not MP3.
If AirAudio sends the data with MP3 instead of LPCM, JRiver can actually handle the Shoutcast-metadata.

For now, AirAudio includes a blacklist for JRiver and only sends the Shoutcast-metadata in case of MP3, but never with LPCM.

So, JRiver might need some fix:

1. either only send the "Icy-Metadata: 1"-header in case of MP3-format
2. or also handle the Shoutcast-metadata for other formats, like for MP3

Cheers & kind regards,
Martin

[JimH]

Welcome and thanks for the report.  We will investigate.  It should take about a week if we can fix it.

I've just sent you a license for MC.  Please feel free to post about your software on our Third Party board here.

[AndrewFG]

I can confirm that MC does indeed send an Icy header in all its HTTP GETs. But I never tested whether MC can actually honor Icy meta data if the server includes such in its response (since none of my own applications is capable of sending such Icy meta data..)

[funtax]

Thanks for your investigation and the license 

As mentioned, MC successfully handles the Icy-Data in case the audio is send as MP3.

If you have an Android-device and need a sender to test with, you can use "AirAudio" (https://play.google.com/store/apps/details?id=eu.airaudio) for this.

You don't need to root your device for this but simply use the "microphone-mode" instead.. that should be good enough to check the Shoutcast-metadata. Just connect to JRiver, start a music-app on your Android and play a song.

Please be aware that with the next update (>5.2.4) AirAudio will NOT send the shoutcast-data to JRiver, if the selected audio-format (AirAudio's DLNA-settings) is not MP3.

------------

Another problem by the way: May it be possible that MC downloads a file completely before starting the playback, in case the audio-format is "WAV"? LPCM and MP3 work fine for streaming, but I had no luck with WAV yet.

[bob]

The ICY metadata will be fixed in the next build.
The problem with wave files is verified. Looking into it...

[bob]

The problem with wave files not playing before conversion is finished is ONLY true when the renderer is MC linux (or perhaps some third party devices).

The file is being streamed from MC instantly, it's the renderer that's deciding not to play it right away.

Linux MC (and Mac for that matter) have a different networking layer than the Windows version. The problem seems to be related to that. If you are having this issue on a third party renderer, there is probably nothing you can do short of using L16 instead of wave.

[klapaciuss]

The problem with wave files not playing before conversion is finished is ONLY true when the renderer is MC linux (or perhaps some third party devices).

The file is being streamed from MC instantly, it's the renderer that's deciding not to play it right away.

Linux MC (and Mac for that matter) have a different networking layer than the Windows version. The problem seems to be related to that. If you are having this issue on a third party renderer, there is probably nothing you can do short of using L16 instead of wave.

Problem with WAV described by Funtax refers to situation where MC20 is in renderer role. For example when Android AirAudio or AllStream apps are used.

[bob]

Problem with WAV described by Funtax refers to situation where MC20 is in renderer role. For example when Android AirAudio or AllStream apps are used.

In that case we've only been able to reproduce this when the renderer is LINUX MC.
It's not an issue with Windows or Mac MC here.

If you are seeing this as an issue with Windows or Mac MC and a third party DLNA server, it's more likely the third party server is in error.

[gabeg]

The problem with wave files not playing before conversion is finished is ONLY true when the renderer is MC linux (or perhaps some third party devices).

The file is being streamed from MC instantly, it's the renderer that's deciding not to play it right away.

Will this be fixed in the next beta for the ID?  I think this accounts for the issues i've had.

[bob]

Will this be fixed in the next beta for the ID?  I think this accounts for the issues i've had.

It's in the queue...