Here is an example file:
https://res.cloudinary.com/dpre0hbbw/video/upload/v1688155659/1688155657_cbbcgu.m4a
Here are the code blocks:
Here is the component used for the “upload file” block above (that is an advanced version of the component):
As a paying customer, I have an app on Thunkable which is not working because of this. Please fix this asap.
It’s important to walk through these blocks step by step to see where the error is occurring. You’ve made a programming mistake by assuming the “return” block is needed; it’s not. But I’m not convinced that that is causing the problem for you.
Looking at those blocks, I think to myself:
You’re recording a sound but that requires two parts: starting the recording and stopping the recording. See Sound - Thunkable Docs. So, did you start the recording elsewhere on that same screen?
After the recording stops, are you able to play it back in Thunkable? You’re immediately uploading it to Cloudinary but… can you remove that “upload file” block and just see if it plays back. That will help determine if the problem is with the recording or with the uploading. I believe it’s with the recording.
Then, when you upload the file to Cloudinary, those blocks return a green “url” block which is a text string containing the download link from Cloudinary. You’re "return"ing it but that doesn’t actually do anything because the “return” block is for custom functions; built-in functions like “upload file” don’t use “return” blocks. The green blocks are the way that function provides values you can use.
If you set a Text Input’s text to the green url block, what do you see? Is it the same link as your example file above? It should be.
You’re not doing any error checking. You should be displaying those green “error” blocks in labels to see if they contain any information that might help you troubleshoot this.
This is not a “how to?” topic, this is a critical-priority bug report.
I’ve done everything right. Also, all this used to work just fine until recently, and there were zero changes made between now and then. Moreover, launching this same code in the web emulator instead of iOS uploads a correct file to Claudinary, which is not broken. You can find the example here.
The return block has nothing to do with this bug at all — it is there for the function that wraps this code, see the screenshot below. However, that doesn’t matter what it’s for because the uploading happens before the return block, so it can’t be affected by the block. There are no mistakes here. Everything is in place in accordance with what I need from the code.
Do you know how to bring this bug the the Thunkable dev team’s attention? Bugs is not what I’m paying for …
I made an assumption based on the limited information you provided but it sounds like you’ve identified a bug and are certain it’s not your code.
As a customer, I only know of two ways to submit bug reports: here as you’ve done (although they will likely need a link to your project) and through the chat button at the bottom-right of the project page.
Hello @konyaevartyomizo
Thank you for sharing all the details and I am sorry to hear about your issue.
Just to clarify, do you mean that the upload file block didn’t upload the audio file when you tested it on iOS?
After we define exactly the issue so that I can replicate it, I will escalate it to the engineers.
Hello @ioannis
Thank you for your response. I didn’t say that uploading doesn’t happen on iOS. It’s just that there is something wrong with the file uploaded. You can find it by following the link in the upper part of the post.
I talked to Cloudinary’s support, quoting our conversation below:
Me:
The problem of the file not being playable appears when the link is opened in the latest desktop version of Google Chrome on Mac OS.
There is one other way to notice that something is wrong with how the uploaded file of this type is processed:
- Open the transformation page for this file (link)
- See the red text “Invalid Transformation"
- Change the format field to MP3 and click “Refresh Preview”
- See the red text “Cannot decode the file.”
I think it’s possible that we are looking at a bug that somehow leads to altering m4a files on upload in a way that they can still be played in some browsers, but are still damaged. This is unfortunately a critical issue for my use case.
Cloudinary:
The real ‘format’ is ipcm (
pcm_s16le) which is a non-compressed stream format.
Cloudinary-supported formats are:
Audio Transformations | Cloudinary
It seems that this format is not supported.
So, according to Cloudinary, what is being uploaded is not M4A in spite of the file name in the link.
Hope this helps. It’s upsetting to have the integration but not be able to use it.
Hello @konyaevartyomizo
Thank you for sharing more information
I created an example project: Thunkable
As you said I couldn’t play the sound via Cloudinay but the play sound component works and I can hear the sound from the app.
Could you please explain your use case?
What do you want to do with this sound file?
Thank you for your reply @ioannis.
Try to copy that link from the label block on an iPhone. Actually, you need to switch that label block it a Text Input to be able to copy the link. Then, follow the link in the Google Chrome browser on Mac and try to play it. You will notice that it’s not possible. It’s important that you use Google Chrome on Mac to confirm this issue. The problem and the reason of that is the format of recorded file — ipcm (pcm_s16le). It is not widely supported, and is hard to convert as it is not widely supported by audio file converters either. It is not supported by Cloudinary too, which tremendously limits the options of how I can use a recorded file.
Do you think you could do something about it and change the current recording format on iOS to some other one?
Hello @konyaevartyomizo
Thank you for briefly describing the issue.
But still, I don’t understand why you need to play the sound on the Cloudinary platform or on the Google Chrome browser.
This is an issue with Cloudinary which doesn’t support the file.
On Thunkable we support this file, as you can see in the project I created for you here: Thunkable
After recording the sound on iOS and uploading it on Cloudinary, then I can play it and it works.
Could you please describe the app functionality you would like to build and where you are blocked?
Thank you for your reply @ioannis
If you look up lists of audio formats supported by most speach2text solutions, you will notice that m4a (pcm_s16le ) that Thunkable outputs is not among them.
In my case, Cloudinary is just a way to upload a file to my server. I pass the link that I get from Cloudinary in an http request, then on the server side I retrieve the audio from Cloudinary and proceed with further manipulations.
Hello @konyaevartyomizo
Thank you for sharing more info.
Just to clarify, this file is not uploaded to your server when you tested through iOS?
I am experiencing the same issue.
I have a similar setup to konyaevartyomizo (OP) where I upload audio files to cloudinary, then access the cloudinary URL via a seperate backend I have setup. This was working for across all platforms and their native file types, IOS (M4a), android(3gp) and Web (webm).
Currently the IOS functionality is broken. When the upload event happens, cloudinary will produce an file URL (like OP has shown) but the URL is not playable or useable. Thus, my backend when retrieving this URL has empty audio data.
