After a while, I realized what's going on.
Let's say that you have two players in a card. They are started via buttons that contains "start player...". When leaving this card (going to another card in the same stack, or to a card in another stack) the players must be stopped, so I put on closeCard a list of players of the card that should be stopped:
stop player whatever
stop player uglyStuff
If only one player is playing, no problem. Revolution happily closes it. But the problem arises when 2 or more players are playing...
Going to another card while 2 or more players are working, causes that only one player is closed, the other(s) will remain open as processes, as reported typing 'ps -aux' in a terminal. Sometimes it's not needed to leave a card while 2 or more players are working, Rev only closes one and the others are left opened, even when they finished playing.
Going to other cards in the same stack and playing their own players causes no issues, the problem could go undetected. The problem arises when the app tries to go to a card located in another stack: the app hangs. If I kill the non-defunct mplayer process in a terminal, the app comes back to life!
Since this bug seems to be caused by bad management of Revolution of multiple players playing at one, I designed a script as a harsh fix to this behavior.
on closeCard, I request stopping all the players contained in a card, no matter if they are playing or not, and then invoke the procedure cleanMess:
...
stop player whatever
stop player badStuff
cleanMess
...
cleanMess in the stack script contains the following:
on cleanMess
if the platform is "Linux" then
get shell("ps -ef | grep mplayer | awk '{print $2}' | xargs kill")
end if
end cleanMess
This allowed me to get rid of the freezes in my app, and also avoid getting undesirable processes open.
This seems to be a Linux-only related problem, tested my app on Mac OSX and no problems there, and I guess that the Windows folks don't have these problems either.
Buggy, buggy, bad, bad...
