Configuring Timeslot Scheduler for Your Playback Server

Timeslot Scheduler is designed to generalize scheduling so the same workflow can be used with any playback server. Functions for specific playback servers are handled by submodules that are included with Timeslot Scheduler. Currently Timeslot Scheduler only includes support for Telvue Princeton and Tightrope Cablecast servers.

To register a playback server go to Create content > Playback Server

Server Name: This is a human readable name.

Server Type:Currently Scheduling is only supported on Telvue Princeton or Tightrope Cablecast servers. This requires the appropriate submodule be enabled.

Channel: This lists displays the channels registered in your Channel vocabulary. Playback servers are NOT required to be registered to a Channel. Multiple servers can be registered to the same channel. If you register multiple servers to a channel, any scheduling activity will happen on both servers. This is helpful when transitioning to a new playback server. Playback servers DO NOT need to be the same type to be registered on the same channel. Similarly, a single server can be registered to multiple channels.

URI: This is the URL or IP address of the server. The playback server specific submodules are configured to use the correct port. So if you access a Princeton using http://123.ourchannel.org:3000, you'd enter 123.ourchannel.org.

Mount: These are mounted shares directly from a playback server or to another server the playback server is connected to. Mounts are created as part of the Video Configuration.

Username: If the playback server requires a username to access its status or add scheduling information. This is not the connection information for the Mount. That information should be stored in the web server's fstab file.

Password: Password for the Username entered above. WARNING: This is currently stored in cleartext.

Database Settings: These settings are optional. Only use them if your playback server allows direct connectivity to the database.

Creating a Timeslot Event

A Timeslot Event can be scheduled to occur every Wednesday or with a pattern like the first Friday of every month. A Timeslot Event requires a Title. The Title only appears on calendars used by the scheduling staff so it should be something useful to them to refer to like Sunday Morning International Issues Timeslot. Timeslots are normally tied to a specific Channel or a Timeslot could be shared between multiple Channels.

Timeslot Theme

Timeslot Themes are used to group similar content. Users select from the Timeslot Themes when creating new Project and Shows. The shows that are selected for Timeslot Event are based on the rules applied to the Autoscheduler and whether the Timeslot Event is user schedulable. User-schedulable timeslots can be filled on a first come, first served basis when users add a new Show as that Show's first run. Once the first run has been scheduled, the Airing date and time will appear on the Show and Project pages.

Administering Your Timeslot Events

When logged under an administration account, one can create a Timeslot event. When you are on the webpage (shown exactly above) you can enter your desired timeslot name, theme, date and time. You can always refer back to the main calendar in order to see whether your timeslots and themes are correct and if you are entering them correctly. It is helpful to keep a separate tab open that shows your updated calendar and that you can continously refresh as you go through the scheduling process. This helps avoid mistakes and overlooked details.

When entering a Themeslot name, it is easier to organize your timeslots by their specific time of day in which they are being aired and the subject it is under. For example, Monday Early Am International Issues Timeslot or Friday Evening Music Timeslot. This helps organize scheduled programs according to the time of day and it's theme. You then have the choice of placing it under a specific channel and specific theme. For example, Moday Early Am International Issues Timeslot can be placed under channel 57 and under the theme "International Issues." This helps out with the scheduling and organization of the calendar and the shows.

You then must fill out what exact time the Timeslot will be scheduled to air and it's date. Timeslot Events use the 24 hour time format for their From date and To date. The Timeslot Event will likely start at an hour like 14:00:00 and end at 14:29:59. The allows the next Timeslot to start the following second at 14:30:00. Becareful with placing your timeslot in the correct time, it is crucial when scheduling out your events in your calendar.

A Timeslot Event can be scheduled to occur every Wednesday or with a pattern like the first Friday of every month. An Until time must be added for repeating Timeslot Events. For example, if one of your timeslot events happen to occur every Monday, Tuesday, and Wednesday, you can highlight those days in the "Advanced" section, so that you do not have to manually schedule it in each time. It makes life easier when organizing a large schedule and is easy to use. Make sure you fill in the section that asks you until what date you want this program to run in the course of the year.

It is always good to keep open several tabs, so that you can go back and forth when checking the schedule.  These tips only help make the process less tedious and quick!

Under Scheduling, a Timeslot can be configure as User Scheduled AND Auto Scheduled OR tied to a specific Project. The Rules for which Show airs when a Timeslot is tied to a specific Project are configured on the Project.

Defining Permissions

Designing a Theme Based Schedule

Timeslot Themes enable the audience of the station to maintain some level of consistency and predictability in programming, while allowing for diverse content to always have a place on Public Access.  Viewers will not always know exactly which show will be on at a given time, but they can always know what thematic category is on. This also enables us to send consistent info to TV Guide and other Electronic Programming Guides such that the EPG does not simply read "Public Access Programming".

The duration of each themed Timeslot Event should relate, in-part, to the total number of hours of content submitted in that category, which ensures that shows in popular categories have as much repeat airings as shows in categories/themes with minimal submissions.  Because the amount of content in a given theme/category can vary significantly over relatively short periods of time, Timeslot Themes can be grouped in pairs using the Timeslot Pairing submodule, which ensures more consistency in the daily schedule. In this manner, the total time allocated for the pair is consistent, while the distribution between the two paired themes can change.

Pairs are set up with a minimum of 2 hours, and the switch from the first to the second category in each pair must take place on the hour or half-hour, to improve the viewer experience. With the Open Media system, this information can be exported for Electronic Programming Guides and for dynamic interstitial content that announces the beginning and end of each theme/category slot.

FOLLOWING IS STILL DOM SPECIFIC

Following is the logic of the code which distributes time within each theme block pair.
-Calculate the total duration of content in each category annually.
The category with the most combined duration (most hours of content, not most shows) becomes "category1" and is paired with the shortest category (in DOM's case, "Category 12")

On the Premium Channel, blocks are divvyd up as such:
Because we are on the premium channel, and we only want to show videos above average for that category, we ask.
-what is the ratio of
"the combined duration of all content in category 1 with a Score/rating above "R"(The variable defined in the bayesian equasion below)"
to
"the combined duration of all content in category 12 with a score/rating above R"?

Being that this is a 2-hour slot, shared between the two categories, if the ratio is less than .25, the slot is split up 25/75 with (in this case) 30 mins allotted to Cat1 and 90mins allotted to cat2.  If the ratio is between .25 and .75, the slot is split in half, 60-mins each.  If the ratio is over .75, the slot is split up with 90mins allotted to cat1 and 30mins allotted to cat b.

Then, in scheduling the "Featured" day for that group/pair, we take the top-rated show in cat 1.
Is it marked for late-night airing?  If yes, place it first in the 11pm slot for that day. 
If no, determine the remaining time allotted for cat1 in the first time slot (taking into account anything that is already programmed in the princeton server). Is the available time is greater than show's duration?
If yes, schedule the show at the first available slot. 
If no, skip the show.

Do the same for the second rated show in that category, and so on.

In filling a block, the system should not stray from the selected category, and can be set to use shows listing the category as a "secondary" category, or based on other metadata, repeat shows, or even switch to continuity files.

Any open time on the basic channel 56 can be autoscheduled following the same rules, but without the requirement that the rating is above "R", so whereas on 57 we start repeating shows once we hit shows with a rating below the average for the category, on 56 we don't start repeating until we run out of shows.

Playback Server Specific Submodules

Rule-Based Scheduling and Programming

The Open Media Project Timeslot Scheduler Module is designed to simplify or democratize the scheduling process for any noncommercial media operation.  The system is flexible enough to enable the station director to apply any mix of rules (from freshness to popularity to theme) to automatically generate the programming schedule.

One of the most innovative and democratic variables stations can use to drive the program schedule is viewer ratings.  Votes or ratings can be generated on the website or via phone or SMS, then applied together with other variables set by the station to determine the programming schedule.  Because the options and variables are so extensive, we'll explain one way this system can work by explaining the structure in one station, Denver Open Media.

Denver Open Media's Rule-Based Scheduling:

To give viewers a more stable and predictable viewing experience, all scheduling is done within theme-blocks. In Denver, when a producer submits a show the producer selects the theme block (also known as category or Daypart), along with all other metadata.

Denver has 12 theme blocks, though we recommend 10 categories, which is easier to distribute fairly across weekdays.  Themes are paired, with the theme block containing the most hours of content paired with the theme block containing the fewest hours of content, and so on.

On our basic channel, theme blocks are distributed such that they appear 4 times during the weekedays (one early morning, one late morning, one early afternoon, and one late-night) and one weekend slot. Every show is guaranteed to air once on this basic channel, with producers free to select an open time-slot for the theme block they've selected for the initial airing.  On the day when the theme block does not appear on our basic Channel, that theme pair is "featured" on our premium channel 57, with the morning and evening prime-time, and late-night slot (which has proven to be the most popular viewing time for Public Access) filled with that theme pair.

Time within the theme pair is split between the two theme categories based on the compared amount of total content in each category.  The slot is divided into 30-minute blocks, with the blocks being distributed in a ratio matching the ratio of content for each category in the pair.  A more detailed description of this 30-minute chunk distribution can be found in the Developer Notes.

Scheduling Within ThemeBlocks:

When desiging a user-driven scheduling system, it was important to us that the viewers have as much control as possible.  At the same time, we want to ensure that there is room for everything on the channel.  So, while we wanted viewer votes/ratings to drive the scheduling on our "premium" channel 57, we designed the system such that videos are only competing within their theme-block, and thus a video about child abuse need not compete with a rock video.  This approach has ensured that there is room available for the different types of content that may be less popular, but deemed significant to the community.  The theme-blocks are to be reviewed by a community board each year.

While many video sites use a straight-average rating system, this results in misleading ratings, where a show with a single perect review has a higher average than a show with hundreds of perfect ratings and one low rating.  Thus, instead of a straight average, we use what is called a "Bayesian Estimate".  The equasion is borrowed from IMBD's rating system.

Show Score= (v / (v+m)) * R + (m / (v+m)) * C
where:
R = average for the show (mean) = (Rating)
v = number of votes for the show= (votes)
m = minimum votes required to be listed in top 25 (currently 6)
C = the mean for that Theme/category
This formula normalizes scores, that is it pulls a particular score (R) to the mean (C) if the number of votes is not well above m. In other words, if a particular design has only a few votes above the minimum required votes to be listed in top 25 (m), the average score is decreased a little if it is above the mean, or increased a little if it is below the mean in accordance with the normal distribution rule of statistics.

Improvements to this system include series or producer scores, which are averaged with show scores to ensure that new shows from producers or series with a strong track-record have preference.  We also hope to date votes, where in scheduling for the premium channel, recent votes carry more weight than older votes.

Sample Timeslot Rules

Timeslot Rules fall somewhere between normal SQL and Views.  After the list of the shows that could potentially be scheduled is generated, additional processing is done to rule shows out from the list to be scheduled based on other settings like it aired since the Days Since Last Airing setting, a show from the same project had already been scheduled, or this show is rated Adult and being scheduled within a block that airs at a time adult content isn't allowed.

Before reading the rest of this page, it would be helpful to read Wikipedia article about JOINS.

Many of the example queries use the {tablename} syntax.  This isn't required.  The reason is for compatibility with Drupal's Database Abstraction Layer.  If you want to preview the query using a tool like phpmyadmin, you would need to remove the {} before running the query.

POST SQL PROCESSING OPTIONS:

Days Since Last Airing - This eliminates shows as candidates to be scheduled based on the latest om_airing nodes.  This will eliminate both shows that have aired X days ago as well as shows scheduled to air in the future.

Do Not Air Shows from the Same Project Concurrently - This prevents shows form the same project from running back to back.  Useful when ordering by the date the show was added.  If a member adds 10 shows at once, only the one show would air each time the Rule was processed.  If another member added show after the first 5, the 6th show from the first project would air as well.

Adult Content - The hours adult content is removed from the pool of schedulable shows isn't configured on Timeslot Rule or Events, but is processed if hours are set in the Admin > Open Media > Scheduling Configuration.

If the Limit Pool by Rating, this must be included in the SQL result.  Add this join to your SQL...

JOIN content_field_om_rating  ON content_field_om_rating.vid = <vid of original table>

Do Not Air Shows from the Same Project in Rule - This is a more restrictive configuration and should only be used by stations with a large archive.

If the Limit Rules to Scheduling by Project the Organic Group must be included in the SQL result.  Add this join to your SQL...

JOIN {og_ancestry} ON og_ancestry.nid = <nid of original table>

Custom Variables:

Anyone familiar with Views will recognize this syntax.  While the longer term goal is to generate Rule from Views, this release of om_timeslot_scheduler lays the foundation for that development.

***CURRENT_THEME*** - When the Rule is processed, this code is replaced by the nid of the Theme (or Paired Theme when using om_timeslot_pairings) Attempting to Preview a Rule that utilizes this variable directly will return this error...

This Rule utilizes a Theme. Results can only be previewed from a Timeslot Theme or Event.

It will also return a list of Timeslot Themes that can be used to preview the Rule's results.

***NOW_-7_DAYS*** - This variable will be converted to a time using PHP's strtotime function.  Any string PHP can process can be used; -1_Week, Last_Monday, ect.

SQL to Order by Alternative Ratings:

Rules using the Bayesian score provided by alternative_ratings module should add this SQL...

JOIN {alternative_rating} ON alternative_rating.nid = node.nid

and...

ORDER BY score

SQL to Order by Voting API averages:

This SQL will return the shows rated 5 of 5 if you are using five stars or thumbs up/like with that configuration where the vote was made in the last 7 days.  This creates a nearly immediate feedback for viewers who rate shows.  If they rate a show, it will very likely be scheduled the next time Rule is processed.

WHERE field_om_show_theme_nid = ***CURRENT_THEME*** AND value = 100 AND votingapi_vote.timestamp > ***NOW_-7_DAYS*** GROUP BY nid ORDER BY total_votes

SQL for Limits:

Limiting the number of results is important for performance.  The number of shows that should be returned in a query varies based on the duration of the Timeslot Event, number of Rules applied to an Event, and amount of content matching that criteria that will be ruled out based on post SQL processing.  The SQL for a limit is...

LIMIT 0, 100

SQL for Random:

When getting started with Rule based scheduling, Random is useful option to add variety to a small amount of content.  To randomize the results, simply add this ORDER BY statement to your query...

ORDER BY RAND()

SAMPLE RULES:

Locally Produced - Top-rated by Alternative Rating

SELECT *  FROM {content_field_om_locally_produced}
JOIN {node} ON content_field_om_locally_produced.vid = node.vid
JOIN {og_ancestry} ON og_ancestry.nid = node.nid
JOIN {alternative_rating} ON alternative_rating.nid = node.nid
WHERE field_om_locally_produced_value = 1 AND status = 1
ORDER BY score DESC
LIMIT 0, 100

Because that Rule doesn't rely on a theme, it is standard SQL.  A more complicated Rule would be...

Most Popular for Theme That Hasn't Aired in 14 Days

SELECT * FROM {content_field_om_theme}
JOIN {node} ON content_field_om_theme.vid = node.vid
JOIN {og_ancestry} ON og_ancestry.nid = node.nid
JOIN {alternative_rating} ON alternative_rating.nid = node.nid
WHERE field_om_theme_nid = ***CURRENT_THEME*** AND status = 1
ORDER BY score DESC
LIMIT 0, 100

This Rule utilizes both the Days Since Last Airing option and the ***CURRENT_THEME*** variable in the SQL.  The same SQL could be used with a higher Days Since Last Airing number and run after the 14 day version.  Because using the Days Since Last Airing option rules out shows based on both past and future airings, shows scheduled in the first rule would not be scheduled by the 21 or 30 day version of the Rule.

Random Shows in Theme

SELECT * FROM {content_type_om_show}
JOIN {node} ON node.vid = content_type_om_show.vid
JOIN {content_field_om_theme} ON content_field_om_theme.vid = content_type_om_show.vid
WHERE field_om_show_mpeg2_fid IS NOT NULL AND node.status = 1 AND field_om_theme_nid = ***CURRENT_THEME***
ORDER BY RAND()

Timeslot Pairings

Timeslot Pairings are an attempt to give equal access to the channel to all types of content.  Popular Themes are "paired" with less popular themes.