Icecast - Mar 2005 - Statistics

> On Sat, 2005-03-05 at 23:52, Mihail Egorov wrote:
> > 1. How can I identify disconnect due to low <queue-size>.
Suppose, I
have
> > enabled loglevel=4 (debug). Suppose, I have network jam. What shall I
see at
> > error.log?
>
> There is a log message that signifies the removal of a listener for
> being too slow and that is
> "Client has fallen too far behind, removing"
>
> It currently appears at debug level (4)
It is not clear, what client has fallen too far behind, when reading error
log.

Could you add client IP and may be id also?

On Sun, 2005-03-06 at 03:01, Mihail Egorov wrote:
> Could you add client IP and may be id also?
raise a report on bugs.xiph.org

karl.

Hello

I've been experimenting with Icecast. Is there a way to obtain a 
timestamp of when a song was played, and how many seconds a listener was 
connected?

I ask because I'm starting a company (http://www.loudcity.net) that 
assists Internet radio stations with affordable royalty payment plans 
and music usage reporting. The reporting requirements for ASCAP, BMI, 
SESAC and SoundExchange are fairly thorough. So far we only support 
SHOUTcast, but hope to support Icecast as well.

Thanks,
Brandon

On Sun, 06 Mar 2005 00:27:04 -0500, Brandon <bcasci@runbox.com>
wrote:
> Hello
> 
> I've been experimenting with Icecast. Is there a way to obtain a
> timestamp of when a song was played, and how many seconds a listener was
> connected?
Icecast can (and does - in the access log file) log how many seconds a
listener has been connected for.

We don't log "when a song was played", though - because icecast
doesn't know anything much about the data being streamed at all. We
could consider any change in metadata to be a 'new song', but that's
not very accurate. The stats will show the current metadata, but we
don't log that in any permanent way.

Getting a list of songs (and timestamps to go with them) is something
much better done by the source client - because the source client
actually knows what the data being streamed is, and can easily log
this info (many already do). This would mean you'd have to combine
data from two places (source client for song info, icecast logs for
listener details), but that shouldn't be difficult.

You could modify icecast to log the metadata changes, but I wouldn't
really recommend that approach.

Mike

hi mikhail !


the attached patch might do what you want.
it's against icecast-2.1-khpre7, but should apply to icecast-2.2.0 as well.

mike, karl, please apply.


regards,

j?rn



Karl Heyes wrote:
> On Sun, 2005-03-06 at 03:01, Mihail Egorov wrote:
> 
> 
>>Could you add client IP and may be id also?
> 
> 
> raise a report on bugs.xiph.org
> 
> karl.
> 
> _______________________________________________
> Icecast mailing list
> Icecast@xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laglog.patch
Type: text/x-patch
Size: 470 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/icecast/attachments/20050307/d6bb73f9/laglog-0001.bin