[Icecast] pre-roll ads and log file (Philipp Schafft)

[StreamAnalyst]

Thank you Philipp,
 
Your answers are very clear. We understand the difference between the wall clock time (server side) and the playback time.
 
Just one more point. You wrote that the "into file" is sent to the listener before the listener is attached to the actual stream. If the server would take 20 seconds to send the "into file" and if the listener only remains connected 5 seconds, I guess that he will not connect to the actual stream: will this appear in the log file as a 5 seconds connections or will this be invisible in the log file? In other words, do we only see the accesses to the actual stream in the log file and can we assume that all entries in the log file are from users who received the complete "into file" ?
 
Best regards,
 
Jean-Luc, InternetOfficer SPRL
 
 
On vendredi 15 juin 2018 at 9:44 PM, icecast-request at xiph.org wrote:
Date: Fri, 15 Jun 2018 12:52:54 +0000
From: Philipp Schafft   <phschafft at de.loewenfelsen.net>
To: Icecast streaming server user   discussions <icecast at xiph.org>
Subject: Re: [Icecast] pre-roll ads   and log file
Message-ID:   <1529067174.2057.32.camel at de.loewenfelsen.net>
Content-Type:   text/plain; charset="utf-8"

Good afternoon,

On Fri, 2018-06-15   at 10:20 +0200, StreamAnalyst wrote:
> Are pre-roll ads supported by   Icecast? If so, how?

You can specify a into file. It is send to the   listener before the
listener is attached to the actual   stream.


> And will the log file tell me if the pre-roll ad was   completely
> listened to?

> Say the pre-roll ad lasts 15   seconds. If I see a connection of 15
> seconds in the log file, does it   mean that the listener stopped
> listening immediately after the ad or   that he listened to the ad and
> then to 15 seconds of music?

The   log reports the connection time in wall clock seconds. It does not
report   the playback time (Icecast has for multiple reasons no idea about
the   playback time).

For long running connections those are about the same.   However for short
connections they aren't. The reason for that the listener   client
prebuffers some amount of data before playback starts. Icecast has   no
control over this. Also Icecast sends a so called burst by default.   That
burst helps the client to fill the the buffer quickly.

In an   ideal world the two cancel out each other. However as Icecast has
no   control over the listener nor does know it's parameters there is   a
difference.

There is also some more noise like network latency and   jitter.

Generally speaking I would guess that abs(error) < 20s for   virtually all
sane setups.


> And if a player disconnects   because of a poor network and
> automatically reconnects, will the   pre-roll ad be sent again?

Yes. This is because Icecast is fully   stateless. To Icecast all
connections are independent.

With best   regards,

-- 
Philipp Schafft (CEO/Geschäftsführer) 
Telephon:   +49.3535 490 17 92

Löwenfelsen UG (haftungsbeschränkt)       Registration number:
Bickinger Straße 21                       HRB   12308 CB
04916 Herzberg (Elster)                   VATIN/USt-ID:
Germany                                   DE305133015
--------------   next part --------------
A non-text attachment was scrubbed...
Name:   signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc:   This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20180615/aaead187/attachment-0001.sig>

------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20180616/adc83e7c/attachment.htm>