Ah that is it. I was too impatient to wait the 2s, so especially for those actively playing sound I kept going back up to immediately stop those, before scrolling down and continuing.

It’s a conundrum b/c the UX “model” here is different (I am not a UI/UX developer though so just a thought:-P): on the Loops single-video pages the videos constantly loop forever, and that’s fine, but if you are scrolling through and want to watch many, then I was thinking that it taking 2 clicks (once anywhere on the video to bring up the controls at the bottom, and the second has to land right onto the pause button) is a bit of a barrier. Theoretically then, for an embed you could have it play only once perhaps? Assuming you had control over that (I see that I can right-click and choose that as an option, but then if I scroll away and return, it returns to the default setting of infinite looping; so here I mean to facilitate the playing in an embed as opposed to a dedicated page of its own, to change the default setting as you load it). Or perhaps for super-short ones below some threshold, allow it to restart but then for longer ones halt after a single play? Either way its nice that the user can still change the behavior for a single video, e.g. in case they wanted to listen to some music on repeat forever. I suppose another way that they could do the latter is, once the video has been “discovered” in this manner (with the embed in the community), to click to the single-video page and THAT one will Loop forever. So: different UX behavior for a different purpose in the embed vs. on the actual individual video page.

In any case, the halt upon scroll model definitely seems a good one too, though at first I did not realize that it really would pause if I simply waited? Perhaps you can reduce the wait time - would 0.1 seconds work? 0.5? (to not cause the browser resize issue I mean) If all it did was pause the video rather than stop it - and therefore it could resume at any time - then it would be no loss at all to do so. Except that ofc would require more memory. As it is now, where it truly stops it… well, nothing can be perfect, but I still think it’s not so bad to stop it upon a scroll? Someone can either watch the video, or indicate their readiness to move on, but if they stop it that way, that’s on them for sending the wrong signal, by scrolling rather than watching patiently?

So, you are the expert here, but if it helps to receive that kind of feedback, my preference probably would be to have the video stop after one play-through, and second place preference would be to halt upon scroll with a shorter delay. Also I would guess that you’d need the second one either way, for memory reasons? (or if it were possible perhaps you could kill not the last video but the second-to-last, thereby leaving the last one in memory to resume quicker if someone decided to do that - thereby enhancing the feeling of “snappiness” of the interface, without compromising much in terms of memory since these are all fairly short videos:-).

I hope this text isn’t all too much. I already think it’s fantastic just the way it is, and all the more so now that I know that it will halt upon scrolling, though the above changes I think would act as improvements to make it more intuitive. Do as you please of course, and I will be interested to see how it turns out!:-)