sintonia/legacy
Rob Hailman 2b43e51ed1
fix: playlist allocates inaccurate time to smartblocks (#3026)
### 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

![image](https://github.com/libretime/libretime/assets/8541186/f91849fb-606f-410e-bef5-a7abc8e7b7f4)
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:

![image](https://github.com/libretime/libretime/assets/8541186/e9d46fbb-50e6-4859-a3de-f5a90a6021c0)
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>
2024-06-05 17:01:57 +01:00
..
application fix: playlist allocates inaccurate time to smartblocks (#3026) 2024-06-05 17:01:57 +01:00
build feat(legacy): move session store to database (#2523) 2023-05-30 22:25:50 +02:00
install feat: add container setup 2022-09-14 11:09:52 +02:00
locale chore(legacy): update locales 2024-05-06 01:56:09 +00:00
public refactor(legacy): remove unused waveform related code (#3003) 2024-05-05 21:15:11 +02:00
tests fix(deps): update dependency friendsofphp/php-cs-fixer to <3.26.1 (main) (#2677) 2023-09-08 15:45:24 +02:00
tools chore(deps): update dependency friendsofphp/php-cs-fixer to <3.56.2 (#3008) 2024-05-11 11:10:18 +02:00
.gitignore ci(legacy): catch syntax errors on older php versions 2022-08-24 12:18:40 +02:00
.php-cs-fixer.php chore(legacy): set format rules based on version 2022-09-12 14:15:50 +02:00
Makefile fix(legacy): remove composer superuser warning (#2515) 2023-04-19 16:15:15 +01:00
composer.json Merge branch '3.0.x' into main 2023-02-26 20:16:38 +01:00
composer.lock chore(deps): lock file maintenance (legacy/composer.json) 2024-06-05 15:55:53 +00:00
packages.ini chore: list distribution releases by release date 2022-10-10 20:11:33 +02:00