
app-inventor-for-android - issue #2463
Skipping sound files after five to seven minutes of operation
My app is a simple app that plays random combinations of commands for the user. It is written for my tae kwon do school to help students drill their review steps. Each belt level has six attack combinations that the student memorizes and must be able to execute on command for tests and review.
For this app, the student selects their current belt level and starts the drills. It then begins calling random belt levels (up to and including their current level), random step numbers, and a command to begin ('shechalk'), then waits eight seconds and calls another one.
"gold belt...number two...shechalk........" "green belt...number six...shechalk........" "purple belt...number four...shechalk........"
I have a short mp3 for each of these commands, and a sound object for each one for which I execute the play() method.
The app works fine. Programmatically, it does exactly what it's supposed to do...for five to seven minutes.
then it begins skipping some of the sound files "gold belt... - ...shechalk........" "green belt...number six... - ........" "purple belt... - ... - ........"
Eventually it just breaks down and stops working entirely. I have to kill the app and open it back up again, then it's ok for another five to seven minutes.
I've tried this app on a Galaxy S II, Galaxy S III (4.1.2), Galaxy Tab 8.9 (4.0.2), Nexus 7 (4.2.2), Kindle Fire, and Kindle Fire HD. They all exhibit the same behavior; it works fine for 5-7 minutes then starts to tank.
AppInventor : v133 PC: Windows 7 Browser: Chrome 25.0.1364.152.
I don't know that this is a programming issue since it's working the way it's supposed to for a period of time before it starts to have issues. I wondered if maybe having all of those individual sound objects for each command was a problem so I rebuilt it to have a single sound object and when the app selected a new command at random, it would just change the source property of the sound object before playing it (change it from 'goldbelt.mp3' to 'purplestripe.mp3',) but that actually made the behavior worse.
I wanted to bring this up as in issue in case there's a problem with how the apps compiled from the app-inventor manage media files and sounds in memory. Perhaps the problem is that after a certain period of time, the app has a boatload of soundfiles filling up the memory and it's running out of swap space or something. Seeing as I don't have controls to 'unload' stuff from memory via the editor, it's not the kind of thing I can check through the tools available to me.
If I stop the app (by clicking the stop button in the app) it stops all of the timers. Once I start it again, if it was having the problem, it'll just start having it again. It doesn't get better until I actually kill the app and re-launch it.
I've attached the .apk in case you want to test it on other devices. Just set it to something like purple-belt / steps and hit the green logo. After about 5-7 minutes you'll notice long pauses as it starts missing commands.
Thanks for entertaining this submission.
- KKC_Digital_Dojang_v_8.apk 3.25MB
Comment #1
Posted on Mar 9, 2013 by Quick RabbitHi Andy,
thanks for your report. Have you tried looking at the logs when the app fails? Have a look at the 'System Logs' section of the debugging guide: http://appinventor.mit.edu/explore/learn/live-development-testing-and-debugging.html
If the app is crashing, it should state why in the logs.
Comment #2
Posted on Mar 9, 2013 by Swift PandaWell, it doesn't 'crash' per-se. It just deteriorates to the point that it's not playing enough of the sounds to be usable (e.g. playing one out of four sounds). I've 'watched' some of the methods and procedures in the blocks editor and have watched it run through the steps all the way, even reporting 'done' on a sound.play() block but the sound doesn't actually play.
I've verified that all of the timers and code-blocks are executing...they just stop playing after 5-7 minutes. This kind of behavior doesn't show up in the logcat dump. Is there a way to monitor the memory usage during the app's operation?
Comment #3
Posted on Mar 9, 2013 by Swift PandaI also just ran this in an emulator with the SDK debug monitor going but didn't see any memory spikes. The CPU utilization was always around 3%, and the memory usage was also steady (around 3-4%.) It's pretty consistent though, at about 5 minutes (sometimes seven) it starts to skip.
Comment #4
Posted on Mar 10, 2013 by Quick RabbitHi there,
if there's nothing in the logs, and the app does not crash, simply 'misbehaves', then the problem might be in the code. I don't really know how to debug this; maybe creating a very simplified version of the app and seeing if that passes the 5 (or 7) minutes mark?
Comment #5
Posted on Mar 10, 2013 by Swift PandaYeah...quite possible, but it's odd because it works fine for 5-7 minutes. Using elementary blocks, like those provided in the appinventor, I don't understand how I could write an app that misbehaves in this fashion after working for such a long period of time.
After watching the blocks editor during operation and seeing the app go through the logic like it should but then just...not play a sound (especially after it reported that it did play the sound...or that it at least executed the method) makes it seem like the compiled app isn't managing the media files right or something (like it's outpacing the loading of the sounds.)
I could try changing the quality of the mp3s so the media files aren't as heavy, but it seems like that would just be addressing a symptom.
I appreciate your attention to this; there's only so much you can do with the blocks and I just want to make sure this behavior isn't completely unexpected.
Comment #6
Posted on Mar 16, 2013 by Swift PandaWell, I spent some time redoing this. I reprocessed all of the sound files, exported them at a much lower bit-rate, dropped the size of each file down to about 1/3 of what they were (they were only about 46k in the first place) and replaced them all in the system.
On an up note, on the devices I own it took about 18 minutes for it to start skipping sounds...that's an improvement. Not optimal but there's nothing else I can do via the app that can help with this. Pro grammatically it's working fine. It registers that all of the sounds are playing and keeps processing the app's logic with no hangups. I just eventually have to quit the app and re-launch it.
On a down note, this now performs worse than ever on 1st Gen Kindle Fires. It starts having problems less than two minutes into the program. I have no idea what's going on here.
I'll make a checkpoint and get rid of some of the logic and see if that helps it go farther but, like I said, it's not the logic that appears to be failing; the app just doesn't play the sounds periodically (it reports executing the play() method but never plays the sound.)
Comment #7
Posted on May 29, 2013 by Quick KangarooHello,
I'm unfortunately having the same problem as Andy. My app also has a large number of mp3 files. After a period of time the audio files stop working and I have to kill the app and re-launch to get it working again. The app is for language learning so I don't want to reduce the quality of the audio files. I would really appreciate a response from a Project Member as it seems this is an ongoing issue. I have also attached my apk.
Thanks
- KeyWords.apk 4.91MB
Status: Investigating
Labels:
Bug