I must have forgotten to copy it because I typed it by hand while looking at the phone. I just reproduced the bug and it looks like this:
I just saw that I had forgotten the block that determines the name of the temporary file in my main code. 
I corrected.
However, bug remains...
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.
Do you still get the error?
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.
Nearly, but you need to separate setting the source with starting playback with the clock timer. Like so:
If this works, then try reducing the timer interval to 250ms, or 100ms, and see if that works as well....
I improved my program as you suggested, but the bug remains... I also modified it so that it can reproduce the crash more easily. I created a list of sounds for my students to listen to (I'm an elementary school teacher). Every time "Télécharger mp3" is pressed, it plays the next file in the list. After 2 or 3 readings of the complete list (it takes a little time...) it no longer reads the mp3 and the error message returns. My entire class was a victim of this bug, so it's the problem is present with a fairly wide variety of Android...
Here's where to download my corrected test program:
https://drive.google.com/file/d/1wlic0EsmXS0ek-vg51y_rGDL_rrVMWxC/view?usp=drive_link
Some sounds last 1 min, others 1 second.
Please provide the aia project here, it is impossible to debug a compiled project.
I have been unable to replicate your issue in my tests
No issues / bug with your APK on Android 13. 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.
On which device with which Android version are you testing? Does the problem also arise with Companion?
Hello
> Please provide the aia project here, it is impossible to debug a compiled project.
Ok :
Essai_DL_mp3_V2.aia (4.5 KB)
> No issues / bug with your APK on Android 13.
I took notes: the bug comes back each time after reading my list of 14 mp3s two and a half times = after 35 mp3 readings in a row.
> 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?
Android 9
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.
Two things:
-
Ensure that the player is stopped before fetching the next file ?
-
Try deleting the MAELtemp.mp3 before downloading the next one ?
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.
1 Like
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.)
1 Like
> 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...
I just did a new test:
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...
3- I go back to the test application: it can't read, I go back to WhatsApp, it can read...
So, I guess it's neither Google Drive nor Android itself...
> Ensure that the player is stopped before fetching the next file ?
I did it by hand, taking my time. So I think it was good.
> Try deleting the MAELtemp.mp3 before downloading the next one ?
I'll try that as soon as I have time.
That won't change anything, because I've already shown it by using different file names in each case.
I was able to reproduce the problem even with just one or two GD download links. In addition, after the problem appeared with Number ~40, I tried another GD link of my own. The same problem arose with this too. Only when I used a non-GD link did it work again. So there seems to be a limit to how often you can access GD (media file) links within a short period of time. The problem also occurs with Niotron; so it is not limited to AI2. It also has nothing to do with the Web component. The same thing happens with my DownloadToASD extension.
That link is for the Google Drive API, a different beast to simple "anyone with the link" sharing.
I do not believe this is the issue, but it does seem to be a google drive issue.
It might be overcome by using a google apps script, or service account (the above API, although this is tricky to setup), which then ensures the download action is generated by the file owner, which may overcome any restrictions.....
I do, however like the idea of downloading the whole lot on initialise (zipped or not), then playing back locally. The OP seems averse to this idea though....
will they be providing their own audio files on a google drive as well, or using the same ones you are testing with ?