Increase the post cloaking threashold, or check first if media is playing before cloaking a post on scroll


(Adrian D'atri Guiran) #1

A lot of posts on my forum are mixes. If the mix is posted at the top of the thread, and the user hits play, and then scrolls down the page to join the discussion and read the responses, eventually the player is unloaded, and this causes the mix to stop playing. Not ideal.

Is there a way to either specify how many posts before posts are unloaded, or remove this feature entirely?

Example here:
http://bassmusic.io/t/kissee-shhhh-its-a-silent-disco/20322

Hit play and start scrolling.

Thanks,
Adrian

Edit: possibly related similar case for youtube instead of soundcloud:

Edit2: if this is not possible with stock discourse, I am open to hiring someone to program a discourse plugin that adds this feature. I have hired programmers from this forum in the past and always pay a fair rate, and pay deposit in advance, and final payment immediately upon completion.

Edit3: Possibly also related:


Want to hire a developer to make a post cloak filter plugin
(Erlend Sogge Heggen) #2

Interesting use case. You definitely don’t want to stop Discourse from offloading any posts, as this is core functionality intended to prevent browser crashes and computers catching on :fire: and such.

But maybe it’d be possible to prevent a single post from being offloaded, while ditching the rest like normal.

Another possible way to solve this might be to prevent only the music player from being unloaded, conserving that stream somehow.


(Rafael dos Santos Silva) #3

I was thinking here, would never offloading the OP (the first post of the topic) work for you use case?


(Adrian D'atri Guiran) #4

I don’t believe this is the correct solution. It is just a bit of a hack. What if there is another post in the thread with a media player?


(Adrian D'atri Guiran) #5

Honestly, i feel like this is a bit extreme. The way that system unloads posts is immediately when the go out of view. A browser can definitely handle having a bit of post history. I understand the need for cloaking with a really long thread, of 100s of posts, but I don’t see the need to begin cloaking after only 1 post has scrolled out of view.


(James Kiesel) #6

Maybe something like facebook’s new ‘Magical floating video which follows you everywhere’ feature?


(Jeff Atwood) #7

Sweet Jesus please no


(James Kiesel) #8

As a plugin naturally, I find fb’s implementation pretty annoying too since it’s on all the time. But the only thing worse than having sound cut out when you scroll away from the player is having sound playing in your browser and not knowing where it’s coming from. :ghost:


(Adrian D'atri Guiran) #9

Well i’m not advocating for auto playing hidden audio, this is audio the user interaction requested to start playing. I’m only trying to avoid a sudden stop of this audio on scroll.

I agree with @codinghorror though, that floating video thing just seems like a bit much. It’s something i would expect to see on a really spammy news website. I would prefer if the post just stayed where it was, and simply did not cloak on scroll.

Is this something that could be accomplished with discourse’s plugin functionality? or would this involve some hacks to discourse core to accomplish it?


(Sam Saffron) #10

We are fine with core Discourse to have the smarts not to cloak posts with oneboxes that have currently playing sound.

Technically, there is no simple way to ask the DOM: “hi DOM is anything playing in element #t” so this means we need to be a specific change to various oneboxes to add this info so we could decide if to unload or not.

If you can get someone to build it cleanly we would be more than happy to consider the PRs required.


(Adrian D'atri Guiran) #11

Yeah, now that i think about it, i don’t think you could ever know if a soundcloud player is playing, those are usually iframes, and therefore part of the shadow dom, and completely out of scope. But I think perhaps a suitable work around would be exposing an admin interface that had a bunch of settings like:
[ ] never cloak posts with youtube oneboxes
[ ] never cloak posts with soundcloud oneboxes
… etc

unless you are suggesting an alternative that is more elegant than this?

@gdpelican is this something i could hire you to build? I was quite happy with your work last time.


(Sam Saffron) #12

YouTube communicates the fact it is playing via APIs, in fact we don’t cloak YouTube already due to these kind of hacks.

Soundcloud has them as well Widget API - SoundCloud Developers

If wiring all the APIs is too hard I would be fine with a site setting of “don’t cloak posts with potentially playing media”, since the count is so low it probably makes no diff. Then all onebox needs to do is surface the fact that a onebox is “playable” by adding something like a playable class to the element.


(Adrian D'atri Guiran) #13

Very good point, i overlooked the fact that discourse uses the HTML5 widget and not the iframe player for soundcloud. This is definitely the more correct solution, and i think with these types of things it is best to take the most accurate approach. My main focus here is with the soundcloud onebox, but perhaps it will lay the groundwork to have other one boxes added along the way in the future.

@sam can i hire you to add this feature for me?


(Sam Saffron) #14

If you sign up for our business plan we can swing the soundcloud thing for you :slight_smile:

In general core team does not do any kind of contracting to non-customers (and only when it aligns with our goal to yes-customers)


(Adrian D'atri Guiran) #15

I appreciate the offer, but that forum does not make anywhere near that kind of money in a year, so it is simply not realistic for me to make that kind of decision, unfortunately.


(Adrian D'atri Guiran) #16

To be honest my current ad revenue doesn’t even cover my hosting costs, that forum is mostly a hobby dedicated to my interest in electronic music.


(Sam Saffron) #17

We will eventually get to this, it’s just not in the high priority bucket now

In the mean time if any of your forum users happens to be a dev they can contribute a patch


(James Kiesel) #18

I’m no good for custom Discourse contracts at the moment, although I’m happy to revisit a bit later on if you’re still looking for someone.


(Adrian D'atri Guiran) #19

Thats the problem with ruby. php devs are a dime a dozen. i’m sure there’s plenty on my forum. But ruby? ruby devs are like a rare gem. Infact i’m personally a developer full time, i work mostly with python and javascript. I’ve dabbled a bit with ruby, but i’m no where near good enough to consider submitted a PR. If i did i think it would be best described as a steaming pile of monkey :poop: and immediately rejected.


(Adrian D'atri Guiran) #20

What if i sign up for 1 month. but don’t really use it, so you don’t actually have to actually set up the site, just make this patch. @codinghorror