In the real app, the value of global filename was set from the webservice call before the playpausebutton is made active. The value does not change when stopbutton is clicked so that the same sound can be played if the playpausebutton is subsequently clicked. The player can be paused, restarted, stopped, started as many times as the user cares to, with the same source value.
The value of fname is not changed unless the user leaves the detail and goes back to the list and picks a different (or the same) entry.
In my example app (referenced above) what happens is effectively what would happen if the same entry were clicked in the list of two set in the example app. That is, the player source would again be set to the same URL value.
What are you finding to be illogical? Perhaps I can clarify something specific.
BTW, in the stopbutton.Click block SoundPlayer.stop might not be needed.
You have obfuscated things by using a variable (and not showing the value set), and also you did not show the original setting of the sound source, and the value set.
The generally found scenario with larger sound files, is that the setting of the source does not have enough time internally to set itself before the download is completed, thus when a call to play the source is made the source is often not ready, generating the error.
I think that may be the race condition I reference. Make sure you understand that the file has begun to play and will continue to play until paused or stopped. It is then the runtime error is possible.
I'll change the example application to be more straightforward if that helps. It will take me a bit to go back to it. In the meantime, setting the source to https://xeno-canto.org/802220/download and cycling through play/pause/stop/stop gets me a runtime error. If I insert setting the source to the same https://xeno-canto.org/802220/download in the stop logic, I never get a runtime error.
Depending on the size of the sound file and the particular audio format (mp3, wav, m4a, ogg etc.) it may take a little (a few seconds) to buffer. On my test devices it only takes 1-2 seconds (for a 50MB mp3/wav) file.
ExoPlayer handles streams better than regular MediaPlayer. It has e.g. play method: "playWhenReady", and the caching is asynchronous, it doesn't block the UI.
Which ExoPlayer are we talking about here? About the outdated ExoPlayer version that Kodular still uses or any extension?
The fact that ExoPlayer differs from MediaPlayer in many ways is well known and has been discussed here and in the Kodular forum several times. For example also in the power user forum (note: only visible for PUs):
About the old discontinued version exoplayer2 v2.15.1. This is the last version from which I easily made an extension and probably Kodular uses this version. All newer versions where SimpleExoPlayer has been discontinued require many additional dependencies. I tried to make an extension with media3, the file was already over 10mb, and it was still throwing errors in appinventor. Unfortunately, appinventor uses the outdated androidx libraries and whatever we want to do with the newer androidx dependencies is difficult. In addition, the new libraries use lambdas from java8 which appinventor does not support and it is necessary to use Rush. In my opinion, the android x libraries should be updated with each release of AppInventor, and the ability to fully use java8 without de-sugar.
I see exoplayer in kodlar was added in 2019. So if they haven't updated this component then it's an even older version than my extension. v2.15.1 is from 20/09/2021.
Not made available yet. It now adds various functions and methods to the extension. Now it has basic control methods, returns time etc, and is working on metadata. Returns metadata from ICE streams and local id3 v2 files. Now he's working on changing the metadata to a dictionary. If you have any suggestions what should be included in the extension, you can suggest, I'll try to add it.
Whether something is missing or not working as expected, I can of course only say when I was able to test the extension. Is there already a pre-release version that you could send me via PM (just for testing purposes, of course).
The conversation seems to have arrived at a bug in player. If you need to see the issue first hand I updated my example app to narrow to the exhibited issue. I see the expected outcomes every time: source not set during stop -> runtime exception. Source set during stop -> works as expected. So setting the source seems to be a workaround until it is no longer needed.
As I have said several times, there are no problems if one uses a direct link to the MP3 file. I also tried it with an 80 MB MP3 file, among other things. No problem.
I have shown a solution for your case. You can also try the TaifunPlayer. Or wait until @Patryk_F will publish his ExoPlayer extension.
Your solution and my solution are both my original solution. The sequence I have works perfectly for me. Every time, on multiple devices.
I guess it might be possible that the client cares about the request string, but I cannot imagine the response stream would be any different. I would think the client does not care and just makes an HTTP request with appropriate headers and lets the web server suss things out by de-referencing the whatever the request string is to its local resource to build the response stream.
In any case, the service returns the https://xeno-canto.org/{i}/download (i is an identifier) to be used as the source string for the player, not a file name ending in a particular suffix, so the point is moot. The API does what the API does and I don't have any need to try to change it on the client side.
In any case, I have the problem and the solution in hand. I will take advantage of a fix to the Player component if and when it is available.
.
