Bench: Changing the name of a broadcast creates a new variable

[ao-david]

Since broadcasts are stored in variables, they are referenced based on the broadcast name. This means that when a broadcast has its name changed we lose reference to the old name, and hence we cannot access the old variable, instead creating a new variable.

This means that we effectively create a duplicate broadcast when we save a broadcast with a new name.

To avoid this, we could associate some randomly generated ID with a broadcast so that we can keep track of a broadcast even if its name changes.

[scruzin]

Good find! Yes, we need an immutable broadcast identifier, similar to the MAC address for a device or a site key for a site. We could use a UUID. See github.com/google/uuid.

Alternatively, and probably preferably, we can generate a unique string similar to how we generate site keys. Since broadcasts are scoped per site, we don't need a globally unique ID.

[saxon-milton]

When you change the name of a broadcast, you're just creating a new broadcast with all the field values of the old broadcast but a different name. We shouldn't be loosing reference of the old broadcast; when we reload the page, broadcasts for that site should be searched for and found, and then the old broadcast should be presented in the drop down just as another broadcast.

I think this behaviour is actually correct at least in part, because AFAIU you can't change the name of a broadcast object that already exists on youtube, so we're mirroring this behaviour in a way.

However, we could make the behaviour a little more intelligent, i.e. if the broadcast object corresponding to that name doesn't exist on youtube, we can delete the old broadcast. Furthermore, we should clear the BID and SID fields of the new broadcast, because it should no longer be associated with the broadcast/stream objects in youtube.

[ao-david]

I am not all over the broadcast API side of things, but from the YouTube Live API docs:

The broadcast's title, description, and privacy status, and other metadata fields that are part of the broadcast's video resource, can be updated at any time.

I think from one of our users perspective they are not expecting changing the broadcast name to create a new stream, and this will most likely end up with them creating two broadcasts that may have race conditions accessing the same hardware, and cause issues streaming?