Purpose: enable longer descriptions that can be used as content in the YouTube and Internet Archives.

Details:

• Change label of current "Description" input to "Title"
• Add an input field with a label of "Description detail". Allow for this as an extended field (maybe 1000 character limit?)
• Modify backend storage so that the new description field can be extracted with the archive process

API keys for web clients will have less privileges. For example, the streams list and detail endpoints won't return private fields, like the stream key or the performer's email.

Using muxy-frontend, if you are an elite gamer and click super fast you can create multiple streams for the same slot. You then get multiple emails with different stream keys. This happened with three out of 144 people for the upcoming solstice stream.

As part of the registration process allow users to denote their own list of tags for their performance. These will be used during the archiving process to ensure that their performance video will be tagged accordingly.

If timezone is avaiable and is valid, also show datetimes in that timezone.

An API endpoint for predefined slots: This would allow the frontend to easily see all free and occupied slots, while keeping the flexibility of the current Stream model.

SlotInterval

• An Event has one or more SlotIntervals
• A SlotInterval defines an interval (has a start and end datetime), and a fixed slot duration (eg. 20 minutes)
• If not specified, an Event has a SlotInterval that spans the whole event
• SlotInterval start and end datetime must be within its related Event start and end datetimes

Configure hosts with an .env variable

It'd be nice to have a way to send custom emails to all participants of an event (emails that signed up a Stream for an Event) from the admin.

Right now we have this management command script, only usable from the terminal of the server hosting muxy.

For example:

https://www.youtube.com/eulerroom/live
https://www.twitch.tv/eulerroom

Currently, using the API, anyone could see the users emails and anyone can add/remove slots. I’d like to implement something like @mashaal did on the web site, that is, when the user takes up a slot, the web site returns a auto-generated password/token that they can use to modify/remove their slot afterwards. That way, only the user that registered a slot can modify or remove it.

I think it's a clearer name.

we're currently brainstorming some post-event display stuff in muxy-frontend, and thought it'd be handy to link to the archived performance (on youtube.com/archive.org) from the performer card on night.tidalcycles.org (for example)

The place to keep that info of course is here, and sfradkin can add/update the links via the api when doing the video processing/upload

key should be optional, or not present at all in the POST payload. key should be autogenerated on creation.

Hey, just seeing some weird behaviour, I currently have these two empty streams in Muxy:

I'm trying to update some fields via a put request:

        fetch(muxyStream.url, {
            method: 'put',
            headers: new Headers({
                "Authorization": `Api-Key ${muxyApiKey}`,
                "Content-Type": "application/json",
                "Accept": "application/json"
            }),
            body: JSON.stringify({
                publisher_name: "joel",
                publisher_email: "[email protected]",
                description: "hello there",
                location: "Australia",
                timezone: "Australia/Sydney",
                event: "http://localhost:8000/events/1/",
                starts_at: muxyStream.starts_at,
                ends_at: muxyStream.ends_at
            })
        })

for which the payload looks like:

description: "hello there"
ends_at: "2021-12-01T06:00:00Z"
event: "http://localhost:8000/events/1/"
location: "Australia"
publisher_email: "[email protected]"
publisher_name: "joel"
starts_at: "2021-12-01T00:00:00Z"
timezone: "Australia/Sydney"

And I'm seeing this error returned:

{
   "non_field_errors":[
      "overlaps with other streams: ['Longest Night:  (2021-12-01 00:00:00+00:00 - 2021-12-01 06:00:00+00:00)']"
   ]
}

Which can't be the case, as there are no overlapping streams in my muxy instance.

Any ideas on why this might be happening?

Thanks,
Joel

Some improvements @sfradkin asked:

• Order the results array from earliest time to latest time: Right now it appears that all the entries in the json array are in reverse order.
• Ordering the recordings array: There aren't too many instances where there's more than one recording file, but in the case that there are, it appears that the filenames are not in correct date order.