My project is simple:
1- Download an .mp3 file from a folder on Google Drive (Shared with anyone who has the link)
2- Play this .mp3 file with "Taifun Player".
I've seen problems with ASD from Android 10 and above.
However, I'm not sure this is my case (although it looks like it) because:
1- My phone is running Android 9
2- It works fine at first, and only after a (variable) number of reads of different files, I get an error message and no more readings.
On my complete application, I get the following message: "Attempt to invoke virtual method 'void android.media.MediaPlayer.setAudioStreamType(int)' on a null object reference" "MIT App Inventor"
On a small test application (which uses the default "player" element instead of Taifun), I get the message: error 702 unable to prepare /storage/emulated/0/Android/data/edu.mit.appinventor.aicompanion3/files
When my full application starts to bug, the small test application becomes unusable.
--> Disconnecting "ai compagnon" then reconnecting it changes nothing.
Everything recovers itself later... I don't know how.
I have the impression that it's a saturation problem, my application can no longer write my temporary file after a while... But I don't understand why, because I systematically overwrite the previous temporary file...
I went to check out this temporary file: it's fine on its own and it's light... (Some .mp3 are under 3 seconds long.)
My guess is that the setting of the player source requires a little bit of time before it is ready . Add a clock timer with an interval of 500ms, and put player start in the clock timer event. Start the clock in your current block, and stop the clock in the clock timer event.
When my important program bugs, I disconnect "AI companion" because it crashed anyway. When I reconnect "AI companion" with my little test program, it no longer works either.
So there is always only one MP3 file in the ASD, which is constantly being overwritten.
On which device with which Android version are you testing? Does the problem also arise with Companion?
> But all MP3 files are saved with the same file name. So there is always only one MP3 file in the ASD, which is constantly being overwritten.
Yes, that's what I want. In the program that the children actually use, the links to the audios are given by QR codes that the children flash to listen to the audios. So, overwriting the downloaded files never overloads the parents' phone. This program that I am sending you is a smaller program that I use to isolate the bug.
> On which device with which Android version are you testing?
But it should be noted that the application encountered the same problem for all 17 of my students' Android phones, of which there are probably some variety of versions.
> Does the problem also arise with Companion?
I did some tests, the bug appears in the same way whether with AI companion or with the installed application.
If I trigger the bug with the test app and then immediately try the children's app, it also gets stuck. If I trigger the bug with the children's app and launch it right after I launch the test app, it too is stuck.
After a certain number (in my case 39) of downloads the MP3s are broken. This is why the error message occurs. I don't know if it's Google Drive, but I assume so. The problem arises with Companion & the APK.
In my case it is file number 39, but with another test it was 50.
Although we would like to get to the bottom of the problem, I suggest zipping all MP3s (MP3.zip), downloading this file, unzipping it into the ASD and then playing the MP3s from there. (To relieve the memory, you can delete the files again at the end.)
> I suggest zipping all MP3s (MP3.zip), downloading this file, unzipping it into the ASD
I can try that, however, this application if it works well should be used by other teachers who will find the process too complicated and ultimately will not use the application anymore.
I searched: it seems that Google Drive does not limit the number of downloads.
When the application my students use is blocked, so is the test application and vice versa. Could it be that Android itself considers this increase in downloads as abnormal behavior and blocks downloads?
This could also explain why the application starts working on its own after a while...
1- I downloaded / read files until they blocked (40 this time, but I replaced the long files with short ones...)
--> I get the same thing as Anke: corrupted file...
2- I sent myself the links of my list by WhatsApp: it manages to download and then read these same .mp3 files that MIT App Inventor is no longer able to download...
