### Description
When running a radio station it is generally a good idea to reduce dead
air time. The current algorithm for adding tracks to a block/show can
leave a lot of dead air time at the end as it doesn't use a very good
algorithm. Adding tracks to a show until it is full while making it as
full as possible is a well known problem in computer science. It is the
[Subset Sum Problem](https://en.wikipedia.org/wiki/Subset_sum_problem).
This PR implements a Randomized Greedy with Local Improvement (RGLI)
approximation solution for the Subset Sum Problem. The new algorithm is
only used when sort type is random and overflow is not enabled and there
is no limit on the number of tracks that can be used.
**This is a new feature**:
Improvement on an existing feature.
**I have not updated the documentation to reflect these changes**:
I did not update the documentation because the current scheduling
algorithm is not currently documented and its existing features have not
changed.
### Testing Notes
**What I did:**
I first attempted a fully polynomial time approximation scheme solution,
however it is really bad at finding good solutions for high density
values and can kinda slow the more tracks/time you have. So I instead
implemented an RGLI which is O(nlogn) and has been giving much better
results.
I implemented the solution in a separate project and tested it and timed
the values with a normal distribution of 500 songs with a mean of 3
minutes and a standard deviation of 1 minute. With a show size of 1 hour
the algorithm took around 10-15 ms to run. When adjusting the block size
and track size the algorithm still was pretty quick to run. Am going to
be testing on an instance with lots of tracks later, will update PR when
I have done that.
**How you can replicate my testing:**
_How can the reviewer validate this PR?_
### **Links**
Closes#3018
### Description
It is good to have a deterministic order when doing explicit file
sorting. This sorts by filename when last played time is null. I would
expect filename to be the next sort after last played time in case of a
tie, and was surprised to find it was not explicit. It should not break
any existing use cases.
**This is a new feature**:
Kind of?
**I have updated the documentation to reflect these changes**:
I did not update any documentation as this way seems like the logical
expected way to do the sort.
### Testing Notes
**What I did:**
I loaded up some tracks into a local libretime instance, let some of
them play, and tested that all the old sorts worked as before as well as
tracks getting sorted by filepath in case of a last played time
### Description
The filename criteria searched the full file path and as such does not
work as expected.
**This is a new feature**:
No
**I have updated the documentation to reflect these changes**:
No docs changes are required as this is fixing a bug to make things work
as expected and documented.
### Testing Notes
**What I did:**
I uploaded some files, and tested that the file name criteria worked as
expected.
**How you can replicate my testing:**
Spin up the stack, upload some files and make sure the filename criteria
works as expected.
### Description
It is useful to be able to automatically filter tracks to a certain date
or day when scheduling tracks for playback. This adds the ability to do
just that in any string filter with the `date{format}` macro.
Closes: #3012
### Description
Closes#2798
COALESCE last played null values with date -infinity, to ensure newly
added files are found by the last played smart block criteria.
* fix(deps): update dependency friendsofphp/php-cs-fixer to <3.41.2
* style: format files using php-cs-fixer
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: jo <ljonas@riseup.net>
* 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>
