### Description
When generating a show that contains a playlist with dynamic blocks, the
show will be incorrectly under scheduled because the fade time was added
onto the total track length. Fade should not add time to an overall
track length as then it wouldn't be a fade.
**This is a new feature**:
No
**I have updated the documentation to reflect these changes**:
No, none needed.
### Testing Notes
**What I did:**
I created a playlist with 3 dynamic blocks:
1. 10 minute length dynamic block
2. 1 item dynamic block
3. fill rest of show dynamic block
I then created a show with the defined auto loading playlist. I then saw
that on auto-load the show was not under scheduled.
**How you can replicate my testing:**
See testing notes
Co-authored-by: Kyle Robbertze <paddatrapper@users.noreply.github.com>
### Description
In the existing logic of `retrieveMediaFiles`, the time remaining in
show is calculated incorrectly in some scenarios. Each time a duration
is subtracted from `showLimit`, 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:
1. a 5 minute track
2. another 5 minute track
3. smart block, set to time remaining in show
When item 1 is added, `showLimit` is reduced by 5 minutes as expected.
When item 2 is added, `showLimit` is 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 `showLimit` from 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:**
- On a dev environment, set up a playlist as described above.
- Before applying this PR, created a show and scheduled playlist, and
confirmed issue was reproducible
- Applied PR and repeated, and confirmed show was filled completely.
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.
Co-authored-by: Kyle Robbertze <paddatrapper@users.noreply.github.com>
* fix(deps): update dependency friendsofphp/php-cs-fixer to <3.17.1
* style(legacy): format using php-cs-fixer
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: jo <ljonas@riseup.net>
