Icecast - Nov 2020 - Pre-roll playing every time user disconnects and connects

On Fri, 20 Nov 2020, Yahav Shasha wrote:
> You could simply serve your pre roll at the client side, eg, your player.
> This way you can detect the mentioned situation and decide whether or not
> to serve the pre roll.
The trick here is to find a way of serving  the preroll without everyone 
hearing it.

I guess you could use some on connect logic to determine if it should be 
played, fire up a command line streamer which would stream it to its own 
mount point which is set to fall back to the main stream, then move the 
listener to that mount.  They would hear the preroll then drop back to the 
main stream when the streamer exits and drops off.

And of course there's the whole logic of when and when not to stream the 
preroll.

Cheers,
Geoff.

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.

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.

This issue is probably unfixable without ipv6


On 21 November 2020 1:36:08 PM NZDT, Geoff Shang <geoff at
QuiteLikely.com> wrote:
>On Fri, 20 Nov 2020, Yahav Shasha wrote:
>
>> You could simply serve your pre roll at the client side, eg, your
>player.
>> This way you can detect the mentioned situation and decide whether or
>not
>> to serve the pre roll.
>
>The trick here is to find a way of serving  the preroll without
>everyone 
>hearing it.
>
>I guess you could use some on connect logic to determine if it should
>be 
>played, fire up a command line streamer which would stream it to its
>own 
>mount point which is set to fall back to the main stream, then move the
>
>listener to that mount.  They would hear the preroll then drop back to
>the 
>main stream when the streamer exits and drops off.
>
>And of course there's the whole logic of when and when not to stream
>the 
>preroll.
>
>Cheers,
>Geoff.
>
>_______________________________________________
>Icecast mailing list
>Icecast at xiph.org
>http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20201121/3721efbd/attachment.html>

Youve over-complicated my suggestion.
No need to have icecast handle this mechanism, simply have the required
logic at the front-end - the actual player.

As for unique listeners detection and flapping ips as Jack mentioned, this
can be solved by some sort of tokenization mechanism based on local storage
or session.


בתאריך שבת, 21 בנוב׳ 2020, 02:36, מאת Geoff Shang ‏<geoff at
quitelikely.com>:
> On Fri, 20 Nov 2020, Yahav Shasha wrote:
>
> > You could simply serve your pre roll at the client side, eg, your
player.
> > This way you can detect the mentioned situation and decide whether or
not
> > to serve the pre roll.
>
> The trick here is to find a way of serving  the preroll without everyone
> hearing it.
>
> I guess you could use some on connect logic to determine if it should be
> played, fire up a command line streamer which would stream it to its own
> mount point which is set to fall back to the main stream, then move the
> listener to that mount.  They would hear the preroll then drop back to the
> main stream when the streamer exits and drops off.
>
> And of course there's the whole logic of when and when not to stream
the
> preroll.
>
> Cheers,
> Geoff.
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20201121/de4e0f85/attachment.html>

I think what Geoff is suggesting is a server-side solution, whereas 
yours is client-side. Both seem valid routes to me.

Of course, what do you do when you're not in control of the listener client?


Cheers,
Jordan


On 11/21/20 3:24 AM, Yahav Shasha wrote:
> Youve over-complicated my suggestion.
> No need to have icecast handle this mechanism, simply have the required 
> logic at the front-end - the actual player.
> 
> As for unique listeners detection and flapping ips as Jack mentioned, 
> this can be solved by some sort of tokenization mechanism based on local 
> storage or session.
> 
> 
> בתאריך שבת, 21 בנוב׳ 2020, 02:36, מאת Geoff Shang 
> ‏<geoff at quitelikely.com <mailto:geoff at quitelikely.com>>:
> 
>     On Fri, 20 Nov 2020, Yahav Shasha wrote:
> 
>      > You could simply serve your pre roll at the client side, eg, your
>     player.
>      > This way you can detect the mentioned situation and decide
>     whether or not
>      > to serve the pre roll.
> 
>     The trick here is to find a way of serving  the preroll without
>     everyone
>     hearing it.
> 
>     I guess you could use some on connect logic to determine if it
>     should be
>     played, fire up a command line streamer which would stream it to its
>     own
>     mount point which is set to fall back to the main stream, then move the
>     listener to that mount.  They would hear the preroll then drop back
>     to the
>     main stream when the streamer exits and drops off.
> 
>     And of course there's the whole logic of when and when not to
stream
>     the
>     preroll.
> 
>     Cheers,
>     Geoff.
> 
>     _______________________________________________
>     Icecast mailing list
>     Icecast at xiph.org <mailto:Icecast at xiph.org>
>     http://lists.xiph.org/mailman/listinfo/icecast
>     <http://lists.xiph.org/mailman/listinfo/icecast>
> 
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>