Intelligent Dynamic Scheduling

[alphabitnz]

Currently, Dynamic Selections are unaware which media has already played prior to their own instance in a playlist.

Some use cases where this is not ideal would be:

• Stations that run ads, news bulletins or other content periodically between Dynamic Selections, and don't want any songs that were played recently in previous Dynamic Selections to be played again so soon
• Back-to-back Dynamic Selections in a single playlist (essentially same as above)
• Applying the same logic, but widening the scope from "Same media" to "Same artist" & any other logic that might have a use case

My concept to solve this problem would be to develop 'Intelligent Dynamic Scheduling', addressing not only the above issues but also introducing the ability to set some Rotation

A draft formula to populate a Dynamic Selection from eligible media would be: [item selection score] = [rotation weight] - [match result] + [popularity score]

Terms:

• rotation weight: a value >0 and <=2, (default=1) as defined in unique metadata for each media item
• match result: evaluate the Dynamic Selection candidate against the schedule "from its position in the future looking backward", through a user-defined set of rules. e.g. **if** [same item found] **or** [same title found] **or** [same artist found] **or** [specific Regular Expression found in <field>] **then** [match result] = 1 **else** [match result] = 0
• popularity score: similar to item rotation weight, but a slightly different purpose allowing for a "public vote" feature to use the API to influence the 'potential item score'. e.g. [popularity score] = (([count item votes] + [sum all votes]) / [sum all votes]) / 2

Operation:

• When a Dynamic Selection is populating its "run sheet", each time a new item is to be added to the queue all of the Dynamic Selection's items would be evaluated as above, and given an [item selection score].
• Users can define an "item selection score ceiling" (e.g. 1.5), meaning any scores above the ceiling value are treated as a "tie" and one of them is selected randomly to be queued.
• If no items are above the ceiling threshold, then the same logic applies to the item(s) with the highest score - and in the instance of a tie a random winner is selected as usual.
• Once the item is added to the queue, the next item to be added to the queue should be determined by a new cycle of this algorithm to ensure the Dynamic Scheduling Criteria is upheld.

[radiorob]

• Ability to change an existing dynamic selection from the selection in a playlist. Clicking on a dynamic selection will bring up the search criteria allowing the user to modify the parameters of that selection.
• Adding the ability for the user to save a dynamic selection to be able to use it in other playlists.

[btelliot]

Could the resolve function of the playlists_module.php be modified so that it checks the overall playlist for duplicate media items on resolve?

For each item in the $result array, add a variable to show if the item was manually put there, if its a station id, or if its from a dynamic selection.

Example $result array: [Media ID, TYPE] [127, SYSTEM] [124, MANUAL] [144, DYNAMIC] [144, DYNAMIC] [169, DYNAMIC]

Then when resolving the $result array at the end, purge duplicates. Or replace it with a song that's not in the playlist.

[Media ID, TYPE] [127, SYSTEM] [124, MANUAL] [144, DYNAMIC] [144, DYNAMIC] [169, DYNAMIC]

This would at least prevent the same song from getting added to a playlist twice from dynamic selections.

https://github.com/openbroadcaster/observer/blob/a73f3be560cd1ce9bc8ffdff7acebebecd87d046/models/playlists_model.php#L702-L950