[Icecast] BUG ? - Metadata/tags NOT UPDATING - Python IceCast 2.3.2[3]

"Thomas B. Rücker" thomas at ruecker.fi
Tue Aug 5 14:14:51 PDT 2014

On 08/05/2014 01:47 PM, Dean Sauer wrote:
> On Tue, 29 Jul 2014 16:21:04 +0000, Thomas B. Rücker wrote:
>> Which version of Icecast is this?
>> I'm not quite sure how to read the above.
> That decodes as 2.3.2 or 2.3.3
> Right now I use 2.3.2 on *buntu based 12.04 
> The 2.3.3 version was on a centos6 box, but will be decommissioned 
> shortly as we want to move away from CentOS/Fedora/RH unless we 
> absolutely positively need it for some reason, and right now, only CPanel 
> based hosts need it... unless CPanel ever gets resolved why they can't do 
> this on Debian based ie: *buntu's...

Please note that 2.3.2 has an enormous amount of known bugs and some
security issues. I do not know which patches are applied by the
distributions to potentially mitigate some of the security issues.

>> As a side note: We released 2.4.0 recently, including packages for most
>> distros.
> Doesn't appear this is available to 12.04, or 14.04, as we only use 
> ESR's. 

Distribution packages and their versions:

Latest stable Icecast *buntu packages for the two LTS releases:

> But based on later info below... that may be an issue
>> Have you looked at the error.log yet?
>> Increase log level to 4 and check for differences.
>> Also I'm not sure if looking for the HTTP status code is sufficient. You
>> might need to evaluate the actual server response. I'd need to check the
>> source to be sure though.
> Since I got 200 OK.. I took it that IceCast accepted it and wouldn't 
> expect to see much different in the log... but...

Returning 200 instead of 403, in this case, might be a bug. This would
need further investigation. Thanks for bringing this to my attention.

> I'll have to change that to see.. and possibly tail it to watch the 
> updates to see what is going on.. unfortunately this is not really 
> something I can take down and up, and down, and up, unless these log 
> levels can be changed when the config is reloaded by
> kill -HUP IcecastPID

<snip />
I don't remember if we change log verbosity on a reload.
Surely you do have a test environment that you could use for your
testing purposes…

>> Are you by chance sending the updates from a different IP than the
>> source client?
>> There were frequent problems with two or more source clients "fighting"
>> for the mount and _both_ updating the metadata. This was disabled by
>> only allowing metadata updates from the same IP as the source client.
> At what point did this change occur? As this may be related partially...

"Only allow raw metadata updates from same IP as connected source
(unless user is admin). This addresses broken client software that
issues updates without being connected."

> I develop on one system which is definitely a different IP than the 
> source... BUT as I recall, I'd have to re test it... 
<snip />
> We have certain metadata/tags info updates from "HIGH COMMAND" […]
> These would come from a central point, […]
> but could come from a "MASTER HIGH COMMAND 
> POINT" elsewhere in some cases...

If you use 2.3.3, then using admin credentials is your only option to
update metadata from a different IP address.
Unless you patch and rebuild Icecast.

> Yes we are aware of the potential 
> collisions in data... 

Yes, also if the source client sends a metadata update half a second
later, nobody might notice the injected data.



More information about the Icecast mailing list