Assign a media with maximum number of times it should be played in a certain period and in random

Feature Requests
1

Introduction

Assign a maximum number of times a media can play in a certain period of times inside a region/layout. When it reach its target number of successful play within its period, it will not be aired anymore for the remaining period inside its schedule. But when it doesn’t it will increase its probability it should be played.

Random playing of media inside a playlist.

User Story

I am assigning a media in a layout but I only need to play it about 30 times per day. Doing this takes a lot of time per media. The sequence should be very scripted.

When I do this I have to monitor if it reach its target number of time it should play. If it did reached the target that will be great but when it didn’t, I have to adjust the schedule and increase the number of times it should play. Means increase in number of target.

So I think playing it randomly and assigning it to a “playlist” will be a great feature.

Detailed Description

Needed feature is related to Playlists Blueprint

  • Number of medias(Ticker, Image, Local Video, Mp3 etc.) will be assigned to a “playlist” inside a region/layout.

let’s say:
Image A, B and C will be assigned inside a playlist called “Images” in Region 1
500 videos will be assigned inside a playlist called “Local Videos” in Region 2
Region 1 and 2 are inside Layout 1

  • Medias will play inside that region/layout “Randomly” but needs to be cautious in each media’s target number of plays.
    Does it reach its target number of play(with respect to smallest time-resolution;an hour or a day)?
    ->Yes, Don’t play anymore for the rest of the hour/day/period. But will keep on playing for the next (hour/day/period).
    ->No, Increase probability that the media will play in the next hour/day/period.

let’s say:
All medias inside “Images” playlist are assigned to play 30 times a day for 2 months.
All medias inside “Local Videos” playlist are assigned to play infinite(no limit in terms of number of time it should play) but in “random” for 2 months.

Operating hours: 9am to 12nn
From 9am-11am:

Image A reached 28 times
Image B only reached 23 times
Image C got 25 times
The system should increase the probability Image B should play vs A and C to reach its target.

1 Like
2

Thanks for this feature request - I understand what you are trying to achieve.

We will have to consider how this might be implemented in Xibo (there are two options as far as I can see)

  • Script it using the API (1.8)
  • Implement it directly into Xibo (version tbc)

We will need to be cautious how it is administered and try not to make it too complicated (which is why I am leaning to the API route at present).

We shall discuss!

1 Like
3

Thanks for the info, Dan. I agree. In your perspective, how long will be our lead time for this feature.

4

You could look at doing it with the API when 1.8 is released (alpha will be end of next month).

To get it included into core - I can’t answer that at the moment - it may not get approved for inclusion.

3 Likes
5

:smiley: We are waiting anxiously

1 Like
6

Hello, Dan, do you have projection when is the next release?

7

You can install it from the repository already, but its not quite ready to be released yet - we are trying to finalise the last few issues.

Details are on the readme page.

The API documentation is available via Swagger - you can download SwaggerUI from their website and point it at our Swagger.json file for details.

Full release is now targeted for 1st Oct.

8

Just wondering if a decision on direction of how this can be done, has been made?

Currently on my to do list I am looking to randomize the widgets on a play list manually, but the number of playbacks in a given amount of time seems… well complicated.

9

I know you are busy Dan, but I was just wondering about this again.

10

I don’t have news on this yet and to be totally honest I am not sure how it will work. Altering the design of the layout depending on the feedback received via the proof of play statistics is going to be difficult no matter which way it is tackled.

I think this would drive an improvement to the statistics collection at the very least - perhaps with those statistics being recorded against the event that caused them so that it would be easier to calculate how often something played…

After we know how many times a widget has been played on a layout we then need to adjust the XLF accordingly - using some algorithm to determine how these widgets are spaced within the playlist…