Metadata not showing in VLC

[DJones]

I upgraded to v2.2.2 and now I'm not seeing metadata when playing the stream in VLC. Was there a change I missed or is this an issue specifically with VLC?

[DrO]

it depends on what it's requesting when connecting to the DNAS and how it's handling the 2 protocols supported, though i don't think it has any support for the v2 protocol and so is relying on the old v1 protocol and it's quirks (see below)

as we changed the default behaviour of the DNAS to run in an HTTP compatible mode instead of using the ICY protocol which resolves issues with playing streams via flash / html5.

guess will need to re-think that change... in the meanwhile you can change back to disableicy=0 to get the DNAS running in ICY mode instead of HTTP mode by default.

[DJones]

Ok, I thought maybe it had something to do with that particular change. But I'm no programmer so it was merely a guess. Thanks, as usual.

[DrO]

with one hand it giveth and the other hand it taketh

as the title updates and ICY protocol is what causes playback failures / stuttering in flash / html5 audio playback. with v2.2.x if icy=http is passed on the tune-in url then it'll force the mode change but that is only something we can do via the Directory tune-in links, for anything else it's not going to be applied, hence changing it by default to run in that mode for all of the cases where people are listed in other directories / platforms.

so we might need to revert that change or just find a better way of getting non-flash/html5 players to have the change enabled for them but without causing some issues with other true clients (though it'd be better if they were able to use the v2 protocol as that sends the metadata irrespective of that parameter as the v2 protocol splits audio and metadata up nicely).

something for me to have a proper think over once i've had some sleep.

[edit]
fb2k seems to be seeing part of the details now (all of the - separated parts is confusing it) and VLC is just showing the title as-is from the DNAS page. as i assume you've bounced the change (as my two connections dropped) and now things are showing.

[aron9forever]

Originally Posted by DrO

it depends on what it's requesting when connecting to the DNAS and how it's handling the 2 protocols supported, though i don't think it has any support for the v2 protocol and so is relying on the old v1 protocol and it's quirks (see below)

as we changed the default behaviour of the DNAS to run in an HTTP compatible mode instead of using the ICY protocol which resolves issues with playing streams via flash / html5.

guess will need to re-think that change... in the meanwhile you can change back to disableicy=0 to get the DNAS running in ICY mode instead of HTTP mode by default.

I highly doubt VLC has a specific protocol for each stream. I think it's a generalized one, since it supports pretty much every streaming type, and it's probably the same for all of them.

[DrO]

which means it would be working as a v1 protocol client in that case and so has to deal with the quirks that protocol has. and as is able to pull the in-stream metadata, it's not as generic as you mention.

[DrO]

Originally Posted by DrO

so we might need to revert that change or just find a better way of getting non-flash/html5 players to have the change enabled for them but without causing some issues with other true clients (though it'd be better if they were able to use the v2 protocol as that sends the metadata irrespective of that parameter as the v2 protocol splits audio and metadata up nicely).

something for me to have a proper think over once i've had some sleep.

the change which was made for 'disableicy' will not be reverted as there is a way to maintain the desired effect of the change whilst allowing things to work ok with the clients mentioned in this thread (and anything that attempts to connect and indicates it knows how to handle SHOUTcast streams).

that change will be rolled into the next build (not sure when that'll be released as it depends on when we can get the pre-existing crash issues which are being reported solved).

in the meanwhile, setting disableicy=0 will provide the prior behaviour and any clients which have issues with playback should probably have ?icy=http appended to their tune-in url.

[DJones]

I added disableicy=0 to my config for the time being. Titles are showing in VLC no problem again and also in xiialive (Android). Both of them show as v1 clients. I think I can safely say everyone appreciates the effort. Thanks for taking the time to look into it.

[anaxagora2]

Hello,

I also added disableicy=0 in my config and restarted. Still the titles are not shown in some players. I have 2 streams defined. Do I need to enter disableicy_1=0 and disableicy_2=0 ?

Anyway, this last I also tried, but without success.

stream url: http://stream.gothville.com:8000

[anaxagora2]

Hello Again,

I needed to restart shoutcast complete, the update or forced in the admin interface wasn't enough it seems. So also here this advice solved my issue with titles showing up.

Originally Posted by anaxagora2

Hello,

I also added disableicy=0 in my config and restarted. Still the titles are not shown in some players. I have 2 streams defined. Do I need to enter disableicy_1=0 and disableicy_2=0 ?

Anyway, this last I also tried, but without success.

stream url: http://stream.gothville.com:8000

[DrO]

that option requires a full restart as previously mentioned (though it will be able to be changed on the fly with the next update though by then it shouldn't be needed as it should work as required based on what the client asks for instead of the incorrect assumption that was made).

[WizardX]

For everyones information:

We had complaints of several users using a squeezebox, running into the same problem, not being able to get metadata.

[DrO]

even when the configuration change had been applied ?

[WizardX]

I have not tested it with the disableicy statement, but in my opinion I prefer the new-style http 200 replies and being more compatible with modern websites instead of being compatible with about 3% of our listeners using a device.

[DrO]

right, so your prior post is then providing the wrong impression of things.

and yes the dropping of the ICY protocol is better in the long run, but as it's clearly causing issues for your users (which is the whole point of streaming), wouldn't changing it back to the prior mode for a small while be better. plus you can force it when using the existing behaviour by adding ?icy=http to the requested stream url.

[WizardX]

Do you have an idea of the impacted browsers which need the http instead of icy? I will change config and will restart during off-peak hours to minimize impact on listeners. We will see if it fixes the metadata for those devices.

[DrO]

i know it prevents IE working without the ?icy=http param, otherwise Chrome and Firefox are ok (i've not tried anything else so it might affect more, i just don't know without trying).

it would have been better if i'd added 'disableicy' to the reloadable config options (already done for the next build) as that would have made it simple to check *shrugs*

[WizardX]

Last night I restarted and indeed the squeezeboxes work, but also a mobile app called tunein works again. I didn't realize the impact it would have. Anyways, whenever I encounter issues in webplayers I'd consider adding the ?icy=http statement.

Thanks!

[DrO]

that is why i said to make the config change early on as i've no definitive list of clients which do and do not natively support SHOUTcast streams and the in-stream v1.x protocol metadata, hence it's better to be a bit less HTML5 audio compatible (or use the workarounds) then annoying users until the new DNAS is released next month with the appropriate fixes in place (at which point the disableicy config option can be removed again as the DNAS will pay more attention to what the client requests to ensure it's providing the in-stream metadata if the client indicates it supports it - which should then allow for everything to work as wanted without having to force things).