Problem: assert() is Language construct in php 7 and not a function anymore. It also seems to behave silghtly differently with regards to what kind of side effects assertions are allowed to have. This leads to all of the rest endpoints being broken in php 7 since the assertion silently fails and the routes never really get added to the front controllers router.
Solution: Don't wrap the addRouter call in assert(). The way assert was being uses was rather unusual for php code this age. It was also mostly checking zf1 rather than guarding against errors in LibreTime itself.
The php manual clearly states "As a rule of thumb your code should always be able to work correctly if assertion checking is not activated." giving even more reason to ot wrap critical paths in assertions.
There are some other instances of `assert()` being used in non test code, those don't seem to have any negative effects on php7.
"What's with cue-In/Out points and silan?" is a frequently asked question that currently has multiple possible fixes and a couple of open tasks (not only "Why is it broken?" but also "Where is the cue-point editor?").
I added current infos to the release notes and was thinking this should be pointed out in the FAQ until we have a stable solution ready.
The /Schedule/set-time-scale/format/json was being hit every time a new calendar page was displayed. The isn't good for performance reasons and also makes race conditions like #210 much more likely.
With this change the preference is only updated on the server when the GUI state changes because the user clicked on one of the "Day", "Week", or "Month" buttons.
This does not fix the locking issue completely, but it should help because the cc_prefs time-scale row in the database will get locked much less often. After applying this I wasn't able to reproduce #210 any more on an install with an extensive schedule.
The script was logging "Script failed with status 127". It seems that this is due to release.sh not being executable and not being referenced with a path starting with ./.
* [x] explain semver since this upgrade cases are when this applies
* [x] links to different parts of manual
* [x] move backup section to the top
* [x] add "real" git pull example
* [x] rename install script to plain ./install
* [x] remove very old monit upgrade help
This gets the mime type using file-magic in a most minimal way. Since the python bindings have been available as a distro package for quite a while it is written in a way so it should also run on pre pypi installs of file-magic. This means not being able to use nice things like magic.detect_from_filename due to the fact that they where added rather recently (with recently being 2 years ago).
As the mime type is only used to check for wav files that mutagen can't handle it only reads the mime type and ignores the charset and other attributes that magic can find.
Due to the fact that file-magic is not properly unicode safe I'm checking the file based on it's first 2048 bytes as per <http://stackoverflow.com/questions/34836792/python-magic-cant-identify-unicode-filename#comment57418632_34838355>. This is not an issue since wav files need to start with a wav header by definition anyway.
I tested this sucessfully on both CentOS and Debian with files containing Unicode in their names.
