What causes "Invalid index {index}, size is {size}" in google/ExoPlayer?

Use size() in loop bounds: for (int i = 0; i < arr.size(); i++) — never <=, never a cached length

google/ExoPlayer · error · IndexOutOfBoundsException

Invalid index {index}, size is {size}

Error message

Invalid index {index}, size is {size}

What it means

LongArray is ExoPlayer's auto-growing primitive long[] wrapper; get(index) throws IndexOutOfBoundsException when index is negative or >= size(). The message reports both the requested index and the actual size so off-by-one or stale-index bugs are immediately visible. It behaves exactly like standard collections: a get can only succeed for 0 <= index < size().

Source

Thrown at library/common/src/main/java/com/google/android/exoplayer2/util/LongArray.java:69

   */
  public void add(long value) {
    if (size == values.length) {
      values = Arrays.copyOf(values, size * 2);
    }
    values[size++] = value;
  }

  /**
   * Returns the value at a specified index.
   *
   * @param index The index.
   * @return The corresponding value.
   * @throws IndexOutOfBoundsException If the index is less than zero, or greater than or equal to
   *     {@link #size()}.
   */
  public long get(int index) {
    if (index < 0 || index >= size) {
      throw new IndexOutOfBoundsException("Invalid index " + index + ", size is " + size);
    }
    return values[index];
  }

  /** Returns the current size of the array. */
  public int size() {
    return size;
  }

  /**
   * Copies the current values into a newly allocated primitive array.
   *
   * @return The primitive array containing the copied values.
   */
  public long[] toArray() {
    return Arrays.copyOf(values, size);
  }
}

View on GitHub (pinned to dd430f7053)

Solutions

Use size() in loop bounds: for (int i = 0; i < arr.size(); i++) — never <=, never a cached length
Re-derive or re-validate the index right before get(): if (index >= 0 && index < arr.size()) arr.get(index);
Recompute stored indexes after any operation that can clear or trim the LongArray (seek, reset, format change)
Harden parsers: bounds-check against both size() and the underlying data's declared count before indexing

Example fix

// before
for (int i = 0; i <= chunkStarts.size(); i++) {
  long ts = chunkStarts.get(i); // throws at i == size
}
// after
for (int i = 0; i < chunkStarts.size(); i++) {
  long ts = chunkStarts.get(i);
}

Defensive patterns

Strategy: validation

Validate before calling

if (index < 0 || index >= longArray.size()) {
  // skip or clamp instead of calling get
}

Try / catch

Not recommended: IndexOutOfBoundsException from LongArray.get signals a logic bug; bounds-check before the call.

Prevention

Always bound loops with size(), re-read at call time
Invalidate cached indexes whenever the array is cleared or rebuilt
Prefer binary-search helpers that return negative 'not found' and check the sign before get

When it happens

Trigger: Calling get(i) with i == size() (classic off-by-one in a <= loop), using an index captured before the array was cleared/rebuilt (e.g. across a seek or stream reset), or a negative index from arithmetic like index - 1 when index == 0. Internal users include subtitle/chunk scheduling caches and seek maps that store timestamps by index.

Common situations: Custom MediaSource/Metadata parsers built on LongArray that compute positions from 'lastIndex + 1'; iterating while concurrently modifying (another thread clears), and porting code from arrays (where length was constant) to LongArray whose size shrinks after clear().

Related errors

AI-assisted analysis of google/ExoPlayer@dd430f7053 (2026-08-14). Data as JSON: /api/errors/1d0f6bab06dc68c7. Report an issue: GitHub.