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.
Well, unfortunately, failure, in companion is ok, while the compiled apk is incompatible with prehistoric libraries in AppInventor. First, a problem with the guava library
