fix: playlist allocates inaccurate time to smartblocks #3026
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I don't believe this check failure is a result of my changes - please let me know if anything further is required! |
|
It's not related - I'm about to merge the fix in #3027 |
paddatrapper
approved these changes
Jun 5, 2024
jooola
pushed a commit
that referenced
this pull request
Jun 22, 2024
🤖 I have created a release *beep* *boop* --- ## [4.2.0](4.1.0...4.2.0) (2024-06-22) ### Features * **legacy:** add current date macro to string block criteria ([#3013](#3013)) ([451652b](451652b)) * **legacy:** add filename block criteria ([#3015](#3015)) ([4642b6c](4642b6c)) ### Bug Fixes * pin pip version to <24.1 to allow installing pytz (celery) ([#3043](#3043)) ([646bc81](646bc81)) * playlist allocates inaccurate time to smartblocks ([#3026](#3026)) ([2b43e51](2b43e51)) ### Performance Improvements * optimize the api image health check ([#3038](#3038)) ([d99d6e1](d99d6e1)) * optimize the rabbitmq health check ([#3037](#3037)) ([9684214](9684214)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
In the existing logic of
retrieveMediaFiles, the time remaining in show is calculated incorrectly in some scenarios. Each time a duration is subtracted fromshowLimit, it is not the duration of the files just added, but instead the length of all files scheduled. This can cause cases where a smart block set to "time remaining in show" fails to completely fill the program.For example, given a 30 minute show, and a playlist like follows:
When item 1 is added,
showLimitis reduced by 5 minutes as expected. When item 2 is added,showLimitis reduced by 10 minutes (as both items 1 and 2 are counted). As a result, the smart block is only run to fill 15 minutes, leaving 5 minutes unfilled.This PR resolves this issue, by recalculating
showLimitfrom the original duration rather than subtracting from a running total.This change not does implement a new feature and should not require any changes to documentation.
Testing Notes
What I did:
Also repeated this testing with sample data from our production instance.
Here is a sample schedule of the "before" case with sample data, showing the issue
The smartblock that scheduled the music is set to allow last track to overflow, but 3m55s was left unscheduled.
Using the same playlist and same track library, here is a sample schedule after the PR applied:
As expected, the show is fully scheduled with the last track overflowing.
Additionally, I've applied this PR as a hot fix to our production instance, where it has been running for a week without issue.
Also performed spot tests of playlists without smart blocks, smart blocks scheduled directly (not in playlists) and autoloading playlists, with no change in behaviour observed as a result of this change.
How you can replicate my testing:
Same test steps as I followed should be able to reproduce issue & validate fix on any instance.
Links
Not directly related to issue fixed by #3019, but also addresses the issue of dead air left at end of blocks.