-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
listener_remove reliability #6
Comments
Difficult to come up with a simple way to spot any issue. Obviously updating to the latest on github is a good start as I'm in a slow-down to release, but I'm not aware of any listener_remove issue in recent times. There has been cases of a stuck listener which is where a lack of writing did not trigger a termination and therefore the auth trigger. You could in the listener_add script query the global listeners count (a custom xsl could make it simple) from icecast and compare that number with the row count in your table. karl. |
since i do something similar, i will try to confirm if this happens to me too in the next weeks |
hu i was sure i had reply to this one again....well... |
On 29/03/12 05:38, Allmoz wrote:
Can you tells me what your configuration is like and what requests are karl. |
hum for some time was whit / so it got all the trafic. icecast.xml
8000stream.xml
and the listener_end SQL
one option is that in rare cases the end ip is different from the start one, here is the entries tell me what more should i seek for ^^ |
On 29/03/12 12:28, Allmoz wrote:
If you use the /* matching then you can exclude certain requests by
What is fallback (file or stream) and are these listeners getting to I'm just wondering if there were any rejections after auth that caused karl. |
nice, anyway i need to add
to certain mount point, so i need to configure them anyway the /fallback is just a mount point
fallback is almost not used, since most of ppl dont know that exist, or how to use it that are the only 2 mount points configurated... also the fallback configuration is only working after y separated the mount to the include path, cose that info whas after the /* match. whit 4xx there are hundreds.. cose ppl leave winamp trying to conect... every 1 second after the stream ends.... |
if ti help for the missing listener_remove on ip 201.215.228.235 there is no access error in the log whit that ip |
I do not have access to your logs, what messages appeared at the time that IP connected, did you see the listener count increasing? karl. |
Can you check against kh32. I did fix a case where a listener_remove may not of been done karl. |
yups, im testing that since moonday, already got 3, listener add, whiout their listener remove 2012-04-17 21:35:52 14 radio.xxx.yyy 8000 /stream 64.76.13.x Argentina 2012-04-18 00:04:36 3 radio.xxx.yyy 8000 /stream 189.183.172.x Mexico 2012-04-18 02:28:26 - radio.xxx.yyy 8000 /stream 201.102.92.x Mexico the ones whitout duration are the issues... now in kh32 |
well... when a conection is refused for a add_listener |
On 18/04/12 16:46, Allmoz wrote:
If the listener_add rejects the listener then listener_remove will not karl |
ok... is fine that if it is rejected then there is no listener_remove, |
¿there is a time limit for the response for listener_add ? |
1 week |
shall we close this for now if the issue looks to be resolved. karl. |
ok, but i will keep an eye on it, since there is not too much trafic on my server ( max 15 listener lately ) |
I intend to update tonight and flush the database. I'll let you know in a couple days how it goes. |
I've been running kh32 for about a week now. |
just to keep track i will start listing the circunstances of the my lost listeners_remove: 1 - d59776c - type=.flv - inestable source & 10 minutes before mount_remove (4 listeners_remove effective) |
i did just realize that.... i get extra listener remove.... from the source.... action=listener_remove&server=radio.xxxxx.com&port=8000&client=3473&mount=/stream&user=source&pass=xxxxxxxxxxx&ip=201.157.xxx.xxx&duration=0 afther some action=stream_auth&mount=/stream&ip=201.157.xxx.xxx&server=radio.xxxxxx.com&port=8000&user=source&pass=xxxxxxi&admin=1 but not always |
The duration of 0 may be of interest here, what can you tell me about client 3473 (or any others in a similar position) what reason led them to disconnect immediately? The second URL is an admin request wanting verifying, probably /admin/metadata karl. |
well... je is the source.... and the id it should be the one of that action=stream_auth |
it has happend 14 times, of.... 46,017 calls to the auth |
24 listener_remove whit source logging data on a laggy (20 reconnections, over 3g internet) the client id "12740" seems to be in order whit normal listener_add client id.. the last id before that is added 40 second before "12736" then a admin=1 source_auth, after that happens especially on laggy source connections i will keep an eye if it happens too whit 619ae4a |
ok... so.. it seems to be related to metadata update, and disconnection by no data from the source.... beside that, no listener_remove missing yet |
A typical non-ogg metadata update does need to authenticate as the update is based on a GET request on /admin/metadata, you should be able to see it on the access log. The &admin=1 is there just so that you know that it's authenticating from /admin requests and not SOURCE. karl. |
hum.... all of them are &sent=59 |
sent is supposed to be the bytes sent to that client. It could be down to a stalled stream but the size wouldn't indicate that. I think it may be down to a 64bit issue. Mines ok and that was ok for the prople reporting it, but if you are on a 32bit setup then that may be the cause. Fix committed for that, but should be no impact otherwise. How are we about the reliability of these being called now? karl. |
ok :D! find in which case a listener_remove whit source data is generated! there is a stream in /stream <-- just fine some ones try to conect as source at /stream ♪that's the way you doit!♫ |
fixed in github. The source attempt passed url auth as expected but as there was no hijack set then the connection failed because the stream was active. This case then drops via the 403 handler which triggered the listener_remove. I've no expanded the test on that to make sure it only applies to GET requests and therefore you should be ok on that. |
nice, i will give feedback as soon as i can |
just release kh7 so if you are to confirm a fix then this would be the one to try. karl. |
i'm still having a few of listener_remove duplicated |
make sure you are on kh7 and then let me know what happens for the duplicated case, just like you did for the source client triggering listener_remove. karl. |
ok, im on that 👍 |
up to now :3 perfect record |
size of the data send by that source both times 0 ( stream dump files are size 0 ) |
I see there is a mount_remove event at the same time, can you find out in what way the mount terminated, was it a normal close or a timeout for example. Just wondering if there was any odd error case leading to it. karl. |
it only triggers if there is a listener on that empy mount after 10 seconds is "kicked"
stoped the servers, cleaned al log started, trigered, closed the servers... y didnt see anything suspicius in the logs but here thay are |
190.160.242.44 - - [30/Apr/2013:22:15:38 -0400] "GET /stream HTTP/1.0" 404 105 "-" "WinampMPEG/5.63, Ultravox/2.1" 0 |
[2013-04-30 22:15:33] INFO thread/ lock abort set to 0 |
huu! found it! [2013-04-30 22:15:54] WARN source/source_read Disconnecting /stream due to socket timeout |
ok, found the trigger case. Because the stream dies without sending content, the listener does not get to send anything so the first time through a 404 is issued but it still classed as authenticated so when it completes the 404 response it tries to run the listener remove again. I've now drop that classification the first time through so no auth should be considered. fixed in git |
nice! working as expected, thanks! |
perfect score :D! |
has that been 2 weeks now without failure karl. |
yeps,it has been! and the two kinds extra data are fixed send=59 --> source_auth on a used mount ... :3 so anything that happens from now is new |
we will take that as issue closed now. I'll be cutting a kh8 release shortly so that should keep things up to date. karl. |
Add missing makefile
My icecast setup is pretty vanilla - the only real difference from the norm is that I have listener_add and listener_remove calling a PHP script which adds and removes a row to a MySQL database for that listener's session.
The script is really basic, and I'm very confident it's not to blame here. The MySQL database is also local, using a stable build, etc., etc.
Quite rarely, listener_remove somehow won't call the PHP script when a listener drops. I haven't been able to replicate the situation where this occurs. It might happen once every couple weeks, but it's enough to throw off my stats.
I rarely restart Icecast itself, but I do kill -HUP every couple weeks for config changes.
Any pointers on where I should be looking to recreate this issue so it can get fixed?
The text was updated successfully, but these errors were encountered: