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
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...
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....
> I was able to reproduce the problem even with just one or two GD download links.
Is this fact really compatible with a restriction on the part of Google to limit the large number of downloads?
> In addition, after the problem appeared with Number ~40, I tried another GD link of my own. The same problem arose with this too.
For my part, I observe the opposite (see the video): my test application is blocked, but WhatsApp manages to download the same links without problem... If I come back to my app right after, it is still blocked ...
> The problem also occurs with Niotron; so it is not limited to AI2.
This can help, provided that Niotron has not taken the code from "App Inventor" to do the same thing... they look very similar...
> The same thing happens with my DownloadToASD extension.
Also interesting, if the Java code generated by "DownloadToASD" is different from that generated by "Web".
> will they be providing their own audio files on a google drive as well, or using the same ones you are testing with ?
Each teacher would use their own Google account as they wish. However, I am trying to see if it would be possible to find other accommodation options later...
> ...which then ensures the download action is generated by the file owner, which may overcome any restrictions...
I just did the test: I read a file several times on the GD of the same Google account as my phone this time. And the blockage happened around 50 downloads.
> 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...
Anything that adds manipulation will result in teachers not wanting to use the application... The simple use of a link to share a file on a shared folder of a GD is already a lot for some...
You only need to change the blocks a bit to handle this, the files are already being downloaded, just only download them once, if they already exist on the device, then just call the local filename. I will do some blocks for this if I get time....bear in mind that most mobile phones these days have plenty of storage space.
Yes of course, I could still access the GD links via my PC or another external application.
But that's not the question, but whether it depends on the DG source. And that doesn't seem to be the case. Whether I retrieve the files from an external GD account or my own doesn't matter.
This system could at least limit the number of downloads, that's still it... Is there a way to make App Inventor just keep the name of the original files like "GI.mp3" or "GUE.mp3 “?
