Possible Bug? Logging incomplete

[ben-xo]

Hi,

I have set up a shoutcast server for a client which is deliberately limited to only 3 hours per week in order to make sure that they don't wildly abuse their bandwidth quota by accident, and i've written some lovely startup/shutdown/log parsing scripties to go with it.

The problem is, when i kill sc_serv with SIGTERM, the logging is left sorely incomplete:

<07/15/03@16:09:09> [source] connected from 217.39.150.57
<07/15/03@16:09:09> [source] icy-name:Live! (Kaizen Radio) ; icy-genre:Drum & Bass
<07/15/03@16:09:09> [source] icy-pub:0 ; icy-br:64 ; icy-url:http://www.kaizenrecords.com/
<07/15/03@16:09:09> [source] icy-irc:N/A ; icy-icq:N/A ; icy-aim:N/A
<07/15/03@16:09:16> [dest: 217.39.xx.xx] starting stream (UID: 0)[L: 1]{A: WinampMPEG/2.8}(P: 0)
<07/15/03@16:11:47> [main] SIGTERM; exiting!

Notice that 217.39.xx.xx starts streaming at 16:09:16.
217.39.xx.xx clearly must have stopped streaming by 16:11:47, as that is when the stream shuts down, BUT there is no corresponding "connection closed" line, which means that parsing the logs to determine the total amount of bandwidth consumed will not include anyone who attempted to stay listening longer than the server was up for. As closing connections is a natural part of shutting down, i feel that this is a bug in sc_serv.

I cannot think of any viable work-arounds at the moment and i'd like some suggestions if anyone can think of any!

I suppose it might be possible to dynamically switch config files (to one which has 0 listeners maximum), SIGUSR1 to reload, and then boot everyone off the stream 1 by 1 before shutting down... ughhh...

[ben-xo]

additional to this, the *_w3c.log which goes with the *.log file doesnt include the info either.

[ben-xo]

Forgot to mention Shoutcast server version is 1.9.2

[ben-xo]

Bumping - need confirmation if it's bug or not, and if it is where i should report it if not here.

[DJ AmPs]

I use a script that pings my servers on the number of listeners in regular intervals. Yo ucan do this without the admin password, just call 7.html and parse it in 5 minute intervals or so. You can calculate 'true' bandwidth by multiplying the listeners by the bitrate (both available) and adding a small fudge factor for overhead.

Otherwise, make your parsing script assume there are no connections after a sigterm. I don't think there is anything wrong with SC_SERV. Think about it, if a server had 600 listsners and you killed the DNAS is would be REALLY ANNOYING to see 600 lines of "disconnecting" each time.

[Jay]

yea I will back that, i think that showing a disconnect is not neccessary, if you see the term exiting it's quite obvious that all previous connections are now disconnected, just use that.

[ben-xo]

guys, you missed my point. There's no record of the number of bytes sent up to the point that the server was killed for all people who were still logged on when it was killed. Looks like i'm going to have to actually kick everyone automatically before i shut the server down - what a pain in the ass.

The log file format could easily be adapted to print a summary line like

<07/15/03@16:41:38> [shutdown] all connections closed (28746 listener-seconds) (UID: *)[L: 600]{Bytes: 3923763296}(P: 0)

or something, instead of 600 closed-lines. Calculating the number of bytes listened when you don't know the bitrate of the stream is impossible using the other obvious method (which is to multiply the listening times by the bit rate "and add a bit" like someone suggested). The stream bitrate is not logged either -- in fact what happens if it's a VBR stream????? (please don't reply saying "well having a VBR stream would be stupid", that's not productive.)

Also, reading the log file to figure out who was still on when the stream died is marginally harder work.

I'm of the opinion that this information should be summarised by the server, instead of me having to guess it.

[Jay]

the bitrate is logged, however VBR would be a problem, just look at the connection point for the bitrate. Who says having a VBR stream is stupid?? It's actually quite a good idea. saves bandwidth and sounds good.

One thing you might do is kick the source and set autodumpusers up to kick immediately. when the server empties out, shutdown the server.

[ben-xo]

Originally posted by KXRM
the bitrate is logged, however VBR would be a problem, just look at the connection point for the bitrate. Who says having a VBR stream is stupid?? It's actually quite a good idea. saves bandwidth and sounds good.

One thing you might do is kick the source and set autodumpusers up to kick immediately. when the server empties out, shutdown the server.

great idea, i'll look into that.

i agree that having a VBR stream would be smart (having 128 max instead of 128 solid, say). I was just anticipating the kind of response technical queries like this usually get when you're on IRC .. ;)