The real error was PypoMessageHandler wasn't consuming messages from RabbitMQ, thus schedules were only updated on PypoFetch time out.
Proably queue is in a stale state because it didn't recover from a broken connection.
The issue is a SimpleQueue was being used, which's 'python-like' *get* method apparently doesn't handle recovery.
Consumers are the way to go instead.
this is apparently the reason why schedules don't get pushed after a silence
producing desynchronization between the mvc and liquidsoap and cannot catch up until pypofetch times out.
(ON AIR turns off and there's a mess until the schedule is fetched. sometimes it even continues playing the wrong tune)
((logging inside the while True loop produces no output, probably it is locked on the queue?))
Config file getting is allowed to fail. I didn't realize that it
would not just use the default instead of excepting and getting
caught. Sorry for that.
1st- Changes the file permissions of cache files from 444 to 644
2nd- Put the host variables into a single array, this way we can pass the full variable to the report_file_size_and_md5_to_airtime function.
This adds TLS support to pypo when downloading files from the REST
API. I previously fixed some similar issues in the api_client and
wasn't aware that pypo isn't using it for every URL..
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.
It took me way too long to figure this one out it wasn't logging nicely. With this ecasound actually gets called again. It's still failing on my install but I'm not yet sure why exactly.
The quite ugly hack with std_err_override seems to have been made for python < 2.7. Since all major distros
have al least python 2.7 installed we can stop using the std_err_override hack.
This removes it from pypo, media-monitor still uses the module and we can completely delete it when we have
remove media-monitor after having maybe backported the watched folders feature to analyzer.
Kyle Robbertze
Keoni Mahelona
Jérôme Lebleu
Roberto Soto
Lucas Bickel
Lucas Bickel
Xabi Spacebiker
Robb Ebright
Robb Ebright
Albert Santoni
Duncan Sommerville