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

["Thomas B. Rücker"]

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:
http://packages.ubuntu.com/search?keywords=icecast2

Latest stable Icecast *buntu packages for the two LTS releases:
http://download.opensuse.org/repositories/home:/dm8tbr/xUbuntu_12.04/
http://download.opensuse.org/repositories/home:/dm8tbr/xUbuntu_14.04/


> 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...

http://icecast.org/news/icecast-release-2_3_3/
"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.


Cheers

Thomas