Frequently Asked Questions (FAQ)#

Q1: What causes the “must specify the START flag on the first request of the sequence” error?#

Symptom#

Server logs show:

Root Cause#

The error occurs when:

A streaming sequence is idle (no audio chunks received) longer than the configured max_sequence_idle_microseconds timeout.
The server automatically releases the idle sequence.
The client sends a new audio chunk for the already-released sequence.
The server rejects the request because it expects a START flag for what it now considers a new sequence, but the client does not provide it.

Solutions#

Option 1: Implement Client-Side Mitigations (Recommended)#

A. Send Silence Buffers During Pauses#

If microphone is muted but stream should stay active:

def handle_mic_mute():
    while mic_is_muted and stream_is_active:
        send_silence_buffer(stream_id)
        time.sleep(30.0)  # Send every 30s

B. Stream Timeout Mechanism#

Implement a fail-safe to detect and handle idle streams:

STREAM_TIMEOUT = 30  # seconds

def monitor_stream_activity(stream_id, last_activity_time):
    idle_duration = time.time() - last_activity_time
    if idle_duration > STREAM_TIMEOUT:
        # Send finalization signal
        send_stream_end_signal(stream_id)
        # Start new stream if needed
        return new_stream_id()

Option 2: Increase Idle Timeout (Server-Side)#

During Model Build#

Set the parameter during riva-build:

riva-build ... --asr_ensemble_backend.max_sequence_idle_microseconds=120000000

Configuration Edit in the Existing Model Repository#

Edit models/conformer-<LANG>-asr-streaming-*-asr-bls-ensemble/config.pbtxt:

parameters: {
  key: "max_sequence_idle_microseconds"
  value: {
    string_value: "120000000"  # 120 seconds (doubled from default 60s)
  }
}

Restart the RIVA server after saving the configuration changes.

Q2: How do I fix “Too many open files” errors?#

Symptom#

Example error when starting the NIM container: OSError: [Errno 24] Too many open files: '/tmp/tmp64in_90a'

Root Cause#

The NIM container is starting with a too-low file-descriptor limit. This is because the correct ulimit was not propagated from the host system to the NIM container.

Solutions#

Add --ulimit nofile=2048:2048 to the docker run command, where 2048:2048 represents the soft and hard limits for the number of open file descriptors.

docker run --ulimit nofile=2048:2048 [other options] <image>

If you still encounter this error when starting the container, consider increasing this limit further (for example, 4096:4096), but be sure the host hard limit supports it.