TeamNewPipe/NewPipe · error · NoSuchElementException

expected {} found {}

Error message

expected {} found {}

What it means

WebMReader.readElement(expected) reads an EBML element and compares its type ID against the expected constant. If they differ (and expected != 0), NoSuchElementException 'expected X found Y' is thrown, naming both IDs in hex. This strict read is used where the next element must be a specific type; a mismatch means the element sequence diverged from expectations.

Source

Thrown at app/src/main/java/org/schabi/newpipe/streams/WebMReader.java:183

        }

        throw new IOException("Invalid encoded length");
    }

    private Element readElement() throws IOException {
        final Element elem = new Element();
        elem.offset = stream.position();
        elem.type = (int) readEncodedNumber();
        elem.contentSize = readEncodedNumber();
        elem.size = elem.contentSize + stream.position() - elem.offset;

        return elem;
    }

    private Element readElement(final int expected) throws IOException {
        final Element elem = readElement();
        if (expected != 0 && elem.type != expected) {
            throw new NoSuchElementException("expected " + elementID(expected)
                    + " found " + elementID(elem.type));
        }

        return elem;
    }

    private Element untilElement(final Element ref, final int... expected) throws IOException {
        Element elem;
        while (ref == null ? stream.available() : (stream.position() < (ref.offset + ref.size))) {
            elem = readElement();
            if (expected.length < 1) {
                return elem;
            }
            for (final int type : expected) {
                if (elem.type == type) {
                    return elem;
                }
            }

View on GitHub (pinned to 9e8be09156)

Solutions

1. Use untilElement(ref, expected...) which skips unknown elements instead of readElement(expected), matching the parser's own tolerant path.
2. Re-download the file; element-order corruption indicates a damaged transfer.
3. Re-mux with a conformant WebM muxer.
4. Validate the file with mkvinfo/ffprobe before parsing.

Example fix

// before — strict read fails on unexpected leading element
Element e = readElement(ID_SEGMENT); // throws if another element leads

// after — skip to the expected element
Element e = untilElement(null, ID_SEGMENT);
if (e == null) throw new IOException("segment element missing");

// Use untilElement(ref, expected...) which skips unknown elements instead of readElement(expected).
Element e = untilElement(parent, ID_SEGMENT);
if (e == null) throw new IOException("required Segment element missing");

public static boolean elementIsType(Element e, int expected) {
    return e != null && e.type == expected;
}

try {
    Element e = readElement(ID_SEGMENT);
} catch (NoSuchElementException ex) {
    if (ex.getMessage().startsWith("expected")) {
        // unexpected element — skip forward or re-mux the file
        Log.w(TAG, "element order unexpected: " + ex.getMessage());
    } else throw ex;
}

When it happens

Trigger: Calling readElement(expected) when the stream is positioned at an element whose type is not the expected one — e.g. expecting ID_INFO but finding ID_TRACKS. Occurs when an element is unexpectedly absent/extra/reordered or the parser is desynchronized.

Common situations: A malformed WebM with elements out of order; the parser desynchronized after a corrupt element; a non-conformant muxer emitting unexpected elements; a truncated stream where bytes decode to a wrong element ID.

Related errors

• Unsupported EBML data (WebM)
• Invalid encoded length
• Not a MPEG-4 DASH container, major brand is not 'dash' or 'i
• expected {} found {}
• Fragment element not found

AI-assisted analysis of TeamNewPipe/NewPipe@9e8be09156 (2026-08-14). Data as JSON: /api/errors/4737348b742b0982. Report an issue: GitHub.