Open HandwerSTD opened 8 months ago
Can you provide the URL in order to reproduce the issue? There are instructions on this.
I think the code can be improved if I have an example to test with, although in the meantime, you can pass your preferred cache file name/path into the constructor.
Personally, I don't get why there's a file extension, because there's no need for humans to read the cache file extension, while machines read by file header, not extension. IMO Removing the extension would be the best choice.
On iOS, the correct extension is required in order to play audio from a file directly. Since some people are playing from the file directly after it is downloaded, that would not work if the extension were ignored. What I could do instead of copying the extension from the URL is to infer the extension from the content type.
Links like "www.example.com/aaa.bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(...more than 192 chars behind the dot)" should reproduce the error. I simply deleted the extension and solved the problem because I only use Android. Maybe it's worth a try to detect the extension from the content type for iOS.
Which API doesn't behave as documented, and how does it misbehave? The
LockCachingAudioSource
API stores cache files in a very long filename which may cause FileSystemException when the URL itself becomes too long.Minimal reproduction project Provide a link here using one of two options: Link
To Reproduce (i.e. user steps, not code) Steps to reproduce the behavior: Just play the audio as usual.
Error messages
Expected behavior The audio player should work well as usual.
Screenshots N/A
Desktop (please complete the following information): Not running on Desktop / Web
Smartphone (please complete the following information):
Flutter SDK version
Additional context I've looked into this problem and found that it's because there's a
.
(dot) in my URL, which was recognized as the file extension incorrectly by function_getCacheFile
, and thus the very-long URL was wrongly included in the filename. The problem was because of+ p.extension(uri.path)
in the function.In short, there's an edge case where the file extension name in the URL becomes too long (more than 192 chars), and then the cache filename will become too long as well, which causes the error.
Personally, I don't get why there's a file extension, because there's no need for humans to read the cache file extension, while machines read by file header, not extension. IMO Removing the extension would be the best choice.