Summary
The LingQ Android app (phone and tablet) fails to play audio for lessons whose audio is supplied as an external Buzzsprout MP3 URL, while the same lessons play correctly in LingQ Web and in a web browser on Android.
The LingQ Android app displays:
“Audio generation failed. Please try again later.”
This message appears misleading in this case because the lesson already contains an audio file; no audio generation/TTS should be necessary.
Reproduction
Example Buzzsprout audio URL:
https://www.buzzsprout.com/2531655/episodes/17728751-e17-mexico-sin-censuras-con-los-chicos-de-mextalki-espanol-avanzado.mp3
I created a LingQ lesson manually by supplying text and this audio URL.
The resulting lesson:
https://www.lingq.com/en/learn/es/web/reader/46202228
Results
| Client | Result |
|---|---|
| LingQ Web | Works |
| Android phone browser accessing Buzzsprout URL | Works |
| LingQ Android app | Fails |
curl downloading the URL with appropriate headers |
Works |
The same problem occurs with other lessons created using external Buzzsprout URLs.
For comparison, lessons created by uploading the mp3 file directly have consistently worked in the Android app.
HTTP investigation
The supplied Buzzsprout URL returns a redirect:
HTTP/2 302
location: https://audio.buzzsprout.com/jzd4c9q1xwr3flo0tngv1va0cqz8?response-content-disposition=inline
The final URL serves the actual MP3:
HTTP/2 200
content-type: audio/mpeg
content-length: 27726199
accept-ranges: bytes
The audio file is a valid MP3:
/tmp/test.mp3: Audio file with ID3 version 2.3.0
The file downloads successfully with curl when using a browser/Android-like User-Agent.
The endpoint also supports HTTP range requests, e.g.:
HTTP/2 206
content-range: bytes 0-1023/27726199
content-length: 1024
Therefore the Buzzsprout server supports the normal mechanisms expected by an audio player, including redirects and byte-range requests.
Client-dependent behavior
For the same Buzzsprout URL:
curl/8.5.0 → 403
Mozilla/5.0 → 200
Dalvik/2.1.0 → 200
okhttp/4.12.0 → 403
ExoPlayerDemo/1.0 → 200
This suggests that the exact HTTP request characteristics may matter.
The final audio.buzzsprout.com URL also returns 403 with no User-Agent but 200 with an Android-like User-Agent.
Hypothesis
The evidence suggests an issue in the LingQ Android external-audio fetching/caching path. The underlying audio itself appears valid and accessible.
I can provide additional affected LingQ lesson URLs if needed