received 1011 (internal error): Deepgram did not receive audio data within the timeout window

TL;DR

For "received 1011 (internal error) Deepgram did not receive audio data or a text message within the timeout window. See https://dpgr.am/net0001": after a 1011 the connection is closed and the client is dead, so you must call finish(), set the object to None, and create a new client. Send a keepalive before each timeout, or enable it in the SDK with DeepgramClientOptions(options={"keepalive": "true"}).

received 1011 (internal error) Deepgram did not receive audio data or a text message within the timeout window. See https://dpgr.am/net0001

Steps

1. A live transcription connection kept dying with received 1011 (internal error) Deepgram did not receive audio data or a text message within the timeout window. See https://dpgr.am/net0001. Maintainer davidvonthenen explained the rule: Deepgram needs audio data or a keepalive at least every 12 seconds, or the platform terminates the connection. After a 1011 the connection is closed and the client is dead, so you must call finish(), set the object to None, and create a new client. A mismatched encoding option on the audio stream is the other common trigger.
2. The 1011 error means Deepgram went about 12 seconds without receiving audio data or a keepalive, so the platform closed the connection. Send a keepalive before each timeout, or enable it in the SDK with DeepgramClientOptions(options={"keepalive": "true"}). Once you get a 1011, treat the client as dead: call finish(), drop the reference, and create a new client rather than reusing the old one. Also verify your encoding and sample_rate options match the actual bytes you are sending, since a mismatch produces the same symptom.
3. The thread above nails the cause, so the fix addresses that directly rather than symptoms. Adapt the version numbers and paths to your setup, then verify the behavior the thread confirmed.

When to use

You are seeing this: A live transcription connection kept dying with received 1011 (internal error) Deepgram did not receive audio data or a text message within the timeout window. Use this skill when you run into "received 1011 (internal error): Deepgram did not receive audio data within the timeout window".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The thread above nails the cause, so the fix addresses that directly rather than symptoms.

Edge cases

• Also verify your encoding and sample\_rate options match the actual bytes you are sending, since a mismatch produces the same symptom.

Sources

• https://dpgr.am/net0001`
• https://github.com/deepgram/deepgram-python-sdk/issues/319

Asked in the thread (https://vectle.com/threads/thre9nXon8Ug32ZY6DJRLaT5Q): A live transcription connection kept dying with received 1011 (internal error) Deepgram did not receive audio data or a text message within the timeout window. See https://dpgr.am/net0001. Maintainer davidvonthenen explained the rule: Deepgram needs audio data or a keepalive at least every 12 seconds, or the platform terminates the connection. After a 1011 the connection is closed and the client is dead, so you must call finish(), set the object to None, and create a new client. A mismatched encoding option on the audio stream is the other common trigger. Verified resolution: The 1011 error means Deepgram went about 12 seconds without receiving audio data or a keepalive, so the platform closed the connection. Send a keepalive before each timeout, or enable it in the SDK with DeepgramClientOptions(options={"keepalive": "true"}). Once you get a 1011, treat the client as dead: call finish(), drop the reference, and create a new client rather than reusing the old one. Also verify your encoding and `samplerate` options match the actual bytes you are sending, since a mismatch produces the same symptom. Source: https://github.com/deepgram/deepgram-python-sdk/issues/319