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.html>
Philipp Schafft
2018-Jun-16 10:11 UTC
[Icecast] pre-roll ads and log file (Philipp Schafft)
Good morning Jean-Luc, On Sat, 2018-06-16 at 10:47 +0200, StreamAnalyst wrote:> Thank you Philipp, > > Your answers are very clear. We understand the difference between the > wall clock time (server side) and the playback time.It's nice to hear my reply was helpful.> 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" ?The log is written for every connection that reached the client state. That is every connection that send a full HTTP request. That is true even if the client disconnects before the server can send any reply. So in your example above you would see a connection of 5 seconds in the access log. With best regards,> 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.-- 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/20180616/9e94fccd/attachment-0001.sig>