I scheduled a YouTube stream and started it some time later.
I expected a stream alert when I started the stream.
There was no alert neither when I made the schedule nor when I actually started the stream. This happens because we check if the stream is actually live when it shows up in RSS feed and if it's not, we treat the scheduled stream as non-stream and no longer check for it.
https://www.youtube.com/feeds/videos.xml?channel_id=CHANNEL_ID_HERE)[p]streamset timer)[p]streamset timer)There's no perfect way for solving this problem, from discussion with Draper, the possible solutions we came up with are:
a) Post info about the scheduled stream as soon as we get info about it (so after number 3 in repro steps) and add info in embed that it's a scheduled stream, not live stream
b) Save info about the scheduled stream and send the alert at the time when it was supposed to start
c) Same as b) but before sending the alert, check that the stream isn't rescheduled/check that it's live (this will make it use more quota which we might really want to avoid)
d) Do both a) and b) (or a) and c))
e) Something we haven't thought of yet?
Just for wider visibility:
Im personally in favour of D,
Doing both A and B, to be specific.
A and C would profile more accurate thing but would also expanentially increase quota usage, since vast majority if Red users only get a 10K quota, we should accept that streams in core should only show basic info thats allowed with the current quota queries as the 10K quota can be used very fast if you use audio and stream.
IMHO, I think this leaves room for a 3rd party stream cog where said cog could have a more more indepth detailed embeds which users can "opt-in" to use it if they have the quota allowance and are okay loading this cog (this would be similar to modlog and extendedmodlog by Trusty), because it doesnt make sense having a core cog that the vast majority of Red users cant use properly due to the crappy quota given to users.
To give readers an idea, prior to the latest update, we would use about 600K quota per day per channel, after the most recent update this has been significantly cut down, but iirc this number still around 600/channel/day, so that only leaves room to 16 channels registered across the whole bot assuming audio is not used for spotify.
So the Red team need to decide whether is worthwhile making and maintaining a complex/in-depth cog that most users cant use due to quota limitations, or make a simpler core cog that most users can use and delegate a in-depth/detailed cod to the community.
I personally like option D.
Maybe it would be best to offer a switch between A and B or A and C which could also warn the end user about quota limits being reached more easily.
No matter what part of D gets chosen, I think an option to switch off A is important for users that only want notifications when the stream actually goes live.
Looks like this has been forgotten a bit and has the discussion label for way too long. Since this needs to finally move forward, I'm gonna be welcoming PRs for this in a week if I don't get any more feedback here.
Here's how I see this should be approached based on current feedback:
When Streams cog sees a new video in the channel's RSS feed, it should first check for the existence of actualStartTime and if it doesn't exist, check for scheduledStartTime and save it (as well as send the message, if the new setting for sending alerts about scheduled streams is enabled).
This way, Streams cog can be edited to treat the video as a live stream and report the channel as online, when the scheduled start time is reached.
As for:
Maybe it would be best to offer a switch between A and B or A and C which could also warn the end user about quota limits being reached more easily.
I think it might not be a bad idea, but since it adds on complexity, IMO we should not be doing this until we get feedback suggesting that this is actually needed.
YT Stream notifs are still pretty much useless :(
Fixed by #4615
Most helpful comment
Just for wider visibility:
Im personally in favour of D,
Doing both A and B, to be specific.
A and C would profile more accurate thing but would also expanentially increase quota usage, since vast majority if Red users only get a 10K quota, we should accept that streams in core should only show basic info thats allowed with the current quota queries as the 10K quota can be used very fast if you use audio and stream.
IMHO, I think this leaves room for a 3rd party stream cog where said cog could have a more more indepth detailed embeds which users can "opt-in" to use it if they have the quota allowance and are okay loading this cog (this would be similar to modlog and extendedmodlog by Trusty), because it doesnt make sense having a core cog that the vast majority of Red users cant use properly due to the crappy quota given to users.
To give readers an idea, prior to the latest update, we would use about 600K quota per day per channel, after the most recent update this has been significantly cut down, but iirc this number still around 600/channel/day, so that only leaves room to 16 channels registered across the whole bot assuming audio is not used for spotify.
So the Red team need to decide whether is worthwhile making and maintaining a complex/in-depth cog that most users cant use due to quota limitations, or make a simpler core cog that most users can use and delegate a in-depth/detailed cod to the community.