We just upgraded to 2.4.0. Before that we were getting correct numbers. I
listened for about 10 seconds and got this log entry:
70.197.160.90 - - [12/Oct/2014:11:07:32 -0400] "GET /music HTTP/1.1"
200
372827 "(null)" "http://blueecho.unca.edu/" 16563752
Here is the log part of icecast.xml:
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<!-- <playlistlog>playlist.log</playlistlog> -->
<loglevel>3</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1
Error -->
<logsize>10000</logsize> <!-- Max size of a logfile -->
<!-- If logarchive is enabled (1), then when logsize is reached
the logfile will be moved to
[error|access|playlist].log.DATESTAMP,
otherwise it will be moved to [error|access|playlist].log.old.
Default is non-archive mode (i.e. overwrite)
-->
<logarchive>1</logarchive>
</logging>
Thanks,
Drew
On Sat, Oct 11, 2014 at 11:23 PM, <thomas at ruecker.fi> wrote:
> Hi,
>
> On 10/11/2014 12:25 AM, Drew Proctor wrote:
> > I am having an issue with access.log. The listen time is way too
> > large. I am getting lines such as:
> > 10.120.34.31 - - [29/Sep/2014:00:12:03 -0400] "GET /music
HTTP/1.1"
> > 200 8827 "(null)" "-" 16099200
> >
>
> "Interesting"
>
>
> > 16099200 is way too large for a listen time. I am using Icecast 2.4.0
> > on Windows Server 2012 R2.Does anyone know why this is happening?
>
> I poked our Windows person, but he didn't know off hand. We'll have
to
> look into it.
> Is there anything particular about your setup? What was the approximate
> real listening duration?
>
>
> Cheers
>
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20141012/11fd8348/attachment.htm
