Proposal: <podcast:liveSchedule> tag

[SilasVt]

Maybe this is a bad proposal, but in developing my app I believe I came on to a limitation while trying to make a weekly view. Bear with me or please tell me if i missed something else.

Live Schedule

One time set tags for scheduling recurring liveItems in advance.

This proposed tag is fairly similar to updateFrequency, except there can be multiple, dateTime is required now and there is a duration added. A Datetime being required seemed like the easiest to solution to tell apps actually when a timeframe starts and how to translate that to the users time and date. Just putting "weekly" does not cut it if the goal is to have people not miss livestreams.

Why

My goal with this is the ability to let apps generate a schedule/calender view for the day/week/month/whatever either for each show seperately or all shows someone is subscribed to for example.
This in theory can already be done with the liveItem tag, by creating a liveItem with a status = pending. That works fine for one off events, however when it comes to recurring livestreams this is a bad approach. Then Podcasters/hosting companies would have to add a (many) pending liveItems all the time. That seems error prone and just bad.

Streaming platforms like Twitch offer schedule features on peoples channels. You could put an image with times or put the times in your show notes. But that is also a bad solution as those are inconsistent and don't have the ability to easily translate the time and date to the users time and date.
People should have the ability to at a glance see when a show is likely going to be live, so they can keep the time free or who do not want to have notifications turned on for example.

Apps may choose to not display one of these tags if there is a liveItem live, pending or ended falling within the timeframe of one of these tags.

Parent

  <channel>

Count

  Multiple

Node value

  This is a free form string supplied by the creator to show the general intent of the stream planned then.

Attributes

• duration (required): how many seconds of length the planned livestream window is.
• dtstart (required): The datetime the recurrence rule begins as an ISO8601-formatted string. Allowing apps to place it in the context of time correctly. If the
  rrule contains a value for COUNT, then this attribute is required. If the rrule contains a value for UNTIL,
  then the value of this attribute must be formatted to the same date/datetime standard.
• rrule (recommended): A recurrence rule as defined in iCalendar RFC 5545 Section 3.3.10.

Examples

Every monday at 8 there is a 2 hour stream scheduled to discuss tech news live:

<podcast:liveSchedule duration="7200" rrule="FREQ=WEEKLY" dtstart="2023-12-23T08:00:00.000Z">Tech News Discussion</podcast:liveSchedule>

Every wednesday and friday there is game night:

<podcast:liveSchedule  duration="8000" rrule="FREQ=WEEKLY;BYDAY=WE,FR" dtstart="2023-12-04T20:00:00.000Z">Community Multiplayer Game Night</podcast:liveSchedule>

[redimongo]

I like the idea, but many radio stations for example have a JSON or XML schedule system already, I understand this is for podcasting.

I am wondering if we instead of having a new line for each schedule program. We look at doing what the RSS2.0 does with comments and off load it to a 3rd party XML or JSON?

It just keeps it a little cleaner in the publisher feed (I am assuming it could be used in that)

This also would allow for companies like radio stations who don't give the schedule to the podcast hosting provider to then link to their external system.

Would that work?

[samsethi]

Funny timing I was doing some work on our Radio Schedule tonight.

[SilasVt]

What if we have liveSchedule just point to a xml file formatted in something like xCal standard (RFC 6321) ? Or are there other standards already being used. I just surfed around a bit and looked at random specs for scheduling things in xml and json

[redimongo]

Many stations do end up using the Google Calendar to create the schedule which Wordpress sites tend to have a plugin which allows them to show it on their site.

Calendars are the best way forward with scheduling, as that is how PodToo does it for their radio show distribution clients. While internally it's got a start time we calculate the end time by the show length. We also look if the show is a weekly, fortnightly or monthly show based on data we have.

Going to a more calendar XML/JSON approach is recommended as that's basically already in use.