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.
Legacy upstream had a weird way of doing this that could lead to empty files being requested with a range header that did not match what was available on the server. I'm assuming this code used to work aroud some media-monitor feature that has been since refactored into analyzer which handles these cases properly.
This is a workaround to make updating easier for folks who do not re-install. A proper solution would get rid of most of the Config class and use something based on Zend_Config_Ini instead. It would also have some sensible defaults in the code and nor error when new values get added.
This is part 2 of fixing ecasound recordings from line-in. Part 1 restored the User-Interface, part 2 takes care of getting to the point where ecasound gets started, records something and uploads it through rest when done. Part 3 will take care of making sure that the recorded file is mapped to the show and not just stored as a new track.
I refactored api_clients to not use urllib2 for posting multipart data since I was loosing my sanity over it and requests seems to have a modern approach to doing this compared to what api_clients was previously doing.
The user object was triggering the creation of a user context that tried to grab something from the session. The later code never tried to use this due to the checkPerm flag.
I'm assuming the user model used to have a sane constructor w/o side effects in the times where this code had it's heyday.
Basically I switched to the dev_tools dir and ran "bash update_po_files.sh". A quick check with the german translation shows me that they have about the same amount of missing strings.
