[Wed May 30 13:19:59 2012] [error] [client ***.***.***.49] request failed: error reading the headers
[Wed May 30 17:42:14 2012] [error] [client ***.***.***.59] PHP Notice: Undefined variable: validateStartTime in /usr/share/airtime/application/controllers/ScheduleController.php on line 771, referer: http://192.168.1.127/Schedule
[Wed May 30 17:50:59 2012] [notice] caught SIGTERM, shutting down
[Wed May 30 17:52:38 2012] [notice] Apache/2.2.17 (Ubuntu) PHP/5.3.5-1ubuntu7.8 with Suhosin-Patch configured -- resuming normal operations
[Thu May 31 01:21:54 2012] [error] [client ***.***.***.68] request failed: error reading the headers
[Thu May 31 06:28:58 2012] [error] [client 127.0.0.1] PHP Notice: Undefined offset: 2 in /usr/share/airtime/application/models/Schedule.php on line 368, referer: http://localhost/Schedule
[Thu May 31 06:28:58 2012] [error] [client 127.0.0.1] PHP Notice: Undefined offset: 2 in /usr/share/airtime/application/models/Schedule.php on line 375, referer: http://localhost/Schedule
[Thu May 31 06:28:58 2012] [error] [client 127.0.0.1] PHP Notice: Undefined offset: 1 in /usr/share/airtime/application/models/Schedule.php on line 377, referer: http://localhost/Schedule
In looking at the zend log I'm not seeing anything odd
In the icecast log I'm seeing this quite a bit
INFO util/util_conv_string converting metadata from UTF-8 to ISO8859-1
Today i spent my day checking on airtime. Here is what i came up with:
General: Ubuntu 12.04, fresh installation of the deb package of 2.1 RC. Used airtime player to check it out (using the "listen" button)
1. During installing (which i have to say the deb package was easier comparing to the "easy ubuntu way", two weeks ago i gave up installing airtime with the "easy ubuntu way" and never installed it up until today when i found the deb package of the 2.1 version) i was asked for the admin password. I made a mistake which made me install it from the beginning. I suggest a password confirmation during installation would avoid (stupid) things like mine ;)
2. when preferences (system -> streams) where changed, a message came up saying what will and what will not be affected. In the message it was said that in some cases listeners would listen to silence for 5 to 10 secs. Well in my case, when i changed the genre and url something else happened.
Well instead of silence i listened to what (i think) was buffered to the player for the previous list.
3. One more with two concurent lists. One can make a list lets say for Saturday from 18:00 until 19:00. But he/she can also make a new list for 18:30 until 20:00. What is more, the duration of each list can be different to the airtime scheduler.
There is an amount of time where both lists are "online"... In my opinion, airitme should be able to check this.
In this case it took the player about 5 minutes to understand the "mistake" and move to the second list which was the case in the airtime stats (during this check the airtime upper left corner showed what was supposes to be on air). And a minute later it went back to the first one.(i would say it was at the beginning of the list meaning that it could be what had been buffered from the previous list - the stats in airtime was about the second list). When the second list ended (when was expected to end) it moved back to the second list and in another minute back to the first list.
My exact example (will be easier to understand, since english is not my mother tongue)
19:40 - 20:00 playlist (however this list exceeded the 20:00 (airtime scheduler) limit by 17 min and 11 seconds, this means that if there wasn't the 20:00 limit it would end at 20:17:11, for the convinience i will name this list as LIST#1)
20:00 - 20:30 playlist (this time the list is whithin the (airtime scheduler) limit, it will end at 20:23:40, for the convinience i will name this list as LIST#2)
in the above example even though the airtime scheduler distinguishes the lists at 20:00, the lists i made do not. The result was that it took airtime about 5 minutes to understand the "mistake" and move from LIST1 to LIST2 (this was made at about 20:05:00). However about a minute later it moved back to LIST1 (about 20:06:00). When LIST1 ended (at 20:17:11) airtime moved to LIST2. But this was only for a minute, since it moved again back to LIST1 (about 20:18:00). This moving to LIST1 could be what was buffered in the player but can not say for sure.
What i did forget to do was to reload the player and see what happens.
However my opinion is that airtime should forbid overlaping playlists.
p.s. this is the support list, should i move my post to the development list whithin "airtime 2.1.0 rc" post?
We allow shows to overlap because it is sometimes useful to do this as an intermediate step when rearranging shows. However I agree that overlapping shows should somehow warn users. We'll take a look into this.