Gemini-3.8-flash: HTTP 200 with promptFeedback.blockReason=OTHER, zero candidates on long audio (100–195 min M4A via Files API); intermittent even at 29 min

Gemini API
1

Hi Gemini API team,

We’re building a meeting transcription system for a construction company in Taiwan (Mandarin Chinese meetings, typically 3–3.5 hours). We’re seeing reproducible empty, blocked responses on long audio and would appreciate help diagnosing the cause.

Setup (identical across all tests)

  • Model: gemini-3.8-flash (Gemini Developer API, not Vertex AI)
  • Endpoint: v1beta/models/gemini-3.8-flash:generateContent, direct REST (Python urllib, no SDK)
  • Audio uploaded via Files API (resumable), referenced with file_data, MIME audio/m4a (AAC)
  • temperature=0, maxOutputTokens=65536

Results

Input Input tokens Requests Non-empty
29 min (1,753 s) 44,164 22 12 (5× OTHER, 4× STOP with empty text, 1× MALFORMED_RESPONSE)
30 min chunks of the 195-min file 45,178 3 1 (2× OTHER)
100 min segments (×2) ~150,000 2 0 — both OTHER
195 min full file ~292,600 6 0 — all OTHER
195 min file, prompt asks for one 30-min window 292,548 2 1 (window 1 OK; window 2 OTHER)

All failures: HTTP 200, promptFeedback.blockReason=OTHER, zero candidates, no finishReason, no safetyRatings in the response.

The strongest comparison: the 195-min full-file runs (5 attempts) used the same prompt hash as the successful 29-min runs, so model, prompt, MIME, Files API and generation settings were held constant; only audio duration/input size differed.

Questions

  1. What service-side conditions produce HTTP 200 + blockReason=OTHER with zero candidates for audio input? Can you tell whether these were policy/safety blocks, media-processing limits, or inference failures?
  2. Is there a practical audio duration or audio-token limit for gemini-3.8-flash that is lower than the nominal context limit? Is a ~3h15m recording expected to work in one request?
  3. Is “upload the full file once, then request separate time windows (00:00–00:30, 00:30–01:00, …)” a supported pattern? Are there known limits on time-range accuracy or speaker-label consistency across requests?
  4. Even at 29–30 min, about 45% of calls with identical inputs returned OTHER, MALFORMED_RESPONSE, or finishReason=STOP with no text (only thought tokens counted). So this does not look like a pure duration limit. Is this a known issue?
  5. For multi-hour meetings, does Google recommend a specific architecture (chunk length, separate diarization)?

Sample responseIds (OTHER):

  • 195 min full file: FGzAapPMKP__qtsP_bWC.., 8GzAauezEICoqtsP3L2Pq.., 1dXiaovxNJO6juMPiaL.. (2026-10-03 ~02:48–03:03 UTC)
  • 100 min segments: KdjiauqQObin694Pkrzsi.., VNniavD4G56DjuMP7f-I..
  • 195 min file, late window: WN7iaqu8DNbKmNMP3t3zm.. (early window succeeded: ut3iarvoJtXu694P-ffqq..)
  • 29 min: 9Hu_aryZApmy9tMP3ZPZcA, kXy_arz4NZbu2roPuYGN0.. (2026-10-02 ~09:40 UTC)

We have full sanitized metadata for 35 requests. Original audio and transcripts are confidential and can’t be shared.

Thanks!

2

Hello @Jessen_Hsieh,

  • Per the API reference, blockReason=OTHER means the prompt was blocked for unknown reasons, so no candidates are returned. Safety-filter blocks report SAFETY with safetyRatings instead. The troubleshooting guide says the query may violate the terms of service or be otherwise unsupported.
  • A 3h15m file is within the documented audio limit of 9.5 hours per prompt and the 1,048,576-token input limit. The docs list no lower practical limit, but output is capped at 65,536 tokens, including thought tokens. A full multi-hour transcript must fit within that output budget.
  • Analyzing specific segments with timestamps is a documented use case in the Audio understanding guide. Uploaded files are stored for 48 hours, per the Files API guide. The docs publish no accuracy figures for time ranges or speaker labels across requests.
  • temperature is silently ignored on Gemini 3.6 Flash and newer, so temperature=0 does not make identical requests deterministic. Please remove it and define explicit rules in a system instruction, per the Gemini 3.6 API changes.
  • For transcription, the Audio transcription guide documents gemini-3.5-transcribe with up to 1 hour of audio per request. With speaker diarization or word-level timestamps, the limit is 30 minutes. Diarization supports up to 8 speakers, and attribution for 3 or more is experimental.
  • If OTHER or empty STOP responses continue, please reproduce the issue with non-confidential audio, since your recordings are confidential. Then send a shareable Google Drive link to that audio, the full responseIds, timestamps, and project number via direct message.