Feature Request: Scheduling & Commercials Dependent on Sequence Progression
I just learned about this project and I am definitely going to use it. Thank you so much to all the contributors for making this a reality.
I was reading the documentation about sequences and it struck me that with the sequence start and end points the way that they are, you will still have prime time premieres running in the daily "rerun" slots before they actually premiere in prime time unless you're changing your sequence start and end points after every premiere.
I think it would be great if a sequence's "inventory" of schedulable episodes could depend on the current progression of other sequences. If the prime time "new episode" sequence is only 50% through the series at X date, then the rerun sequences should not schedule episodes from 51%-100% of the series until X date has passed. I think this makes the sequences a little more robust and the scheduling more realistic. It would also be great if the schedule could see that there are fewer "allowable" rerun episodes in the daily sequence than some configurable threshold and have the ability to schedule other shows in that rerun slot to prevent repeats of the first few episodes playing over several days before prime time premieres have progressed enough to create a decent inventory of episodes to rerun. This should also be able restrict the inventory of episodes that are scheduled randomly, instead of serialized reruns that are in sequence.
Related to this, it would be nice to have support for promos for upcoming episode premieres that would air as commercials only in the timeframe between the last premiere and the upcoming premiere. For example, it wouldn't make sense to play this promo if that episode is not the next episode in the prime time sequence. With the way commercials are implemented I'm not sure how easy this would be, but perhaps a promo sequence inserted as commercials could be created with subfolders (for when single episodes have multiple promos) matched by show to their episode indices so that the correct promos play only before the corresponding upcoming episode premieres. Or perhaps scheduling hints could be expanded for this purpose? I'm just spitballing implementation approaches here.
Hey - thanks. I just added the sequence feature last week, so this is the initial view of it and still tons of things that could be done with it - so appreciate hearing how people want to use it. To clarify, you don't have to have overlap with your 'newer' episodes if you don't want them, if you set them with no overlap. From the docs:
"17": {"tags" : "xfiles", "sequence": "daily", "sequence_start": 0.0, "sequence_end": 0.75},
"21": {"tags" : "xfiles", "sequence": "prime", "sequence_start": 0.75, "sequence_end": 1.0},
Lets say there is 100 episodes - the daily sequence will go from sequence_start at episode 1 and play to episode 75 of the series - then it will start over at sequence_start. The prime-time showing once a week week will start at episode 75, play to the end and then start back at episode 75.
I'm looking at the daily as a syndication type scenario though - where entire previous years of the show are available (often on a different channel than the primetime original is airing even). This is the basic use case I was addressing with the initial implementation. Your questions are addressing the use case of how series premiers rolls out over a year and your suggestions would make robust progression, true. One of the issues though is that it starts changing the stateless nature of the configuration - its a weekly 'rhythm' schedule that isn't tied to dates or time of year (those are handled in with temporal hints). So, while I think being able to do this is a good idea and should go on the roadmap, it would need careful consideration because I think one of the things that makes this work is that its actually quiet simple to setup for simple scenarios. Adding temporal logic to them would need to be done right and supported in the catalog. There are also a few updates to the catalog that are needed for a few other things that would also be needed for this as well. I'll put this on the roadmap.