<html><head></head><body>It seems to me that the only entity that can identify a unique listener, and remember the last time they visited to only transmit the preroll outside of a timeframe - and that's icecast itself. <br><br>But even identifying listeners by IP to know when to run a preroll would not really suffice since those on flakey networks are probably on cell networks and moving around and they may jump around IPs anyway.<br><br>This issue is probably unfixable without ipv6<br><br><br><div class="gmail_quote">On 21 November 2020 1:36:08 PM NZDT, Geoff Shang <geoff@QuiteLikely.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On Fri, 20 Nov 2020, Yahav Shasha wrote:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">You could simply serve your pre roll at the client side, eg, your player.<br>This way you can detect the mentioned situation and decide whether or not<br>to serve the pre roll.<br></blockquote><br>The trick here is to find a way of serving the preroll without everyone <br>hearing it.<br><br>I guess you could use some on connect logic to determine if it should be <br>played, fire up a command line streamer which would stream it to its own <br>mount point which is set to fall back to the main stream, then move the <br>listener to that mount. They would hear the preroll then drop back to the <br>main stream when the streamer exits and drops off.<br><br>And of course there's the whole logic of when and when not to stream the <br>preroll.<br><br>Cheers,<br>Geoff.<hr>Icecast mailing list<br>Icecast@xiph.org<br><a href="http://lists.xiph.org/mailman/listinfo/icecast">http://lists.xiph.org/mailman/listinfo/icecast</a><br></pre></blockquote></div></body></html>