foo-webview-sdk
    Preparing search index...

    Interface PlaylistGetAutoplaylistQuerySuccess

    Successful response from playlist.getAutoplaylistQuery.

    interface PlaylistGetAutoplaylistQuerySuccess {
        isAutoplaylist: boolean;
        keepSorted?: boolean;
        lockName?: string;
        note?: string;
        playlist: number;
        playlistGuid: string;
        query: string | null;
        sort: string | null;
        source?: "sdk" | "dui";
        success: true;
    }
    Index
    isAutoplaylist: boolean

    Whether the playlist is an autoplaylist; keepSorted, source, note and lockName are present only when true.

    keepSorted?: boolean

    Whether the manager-backed autoplaylist keeps its tracks sorted. The false value for source: 'dui' is a placeholder for an unreadable lock configuration.

    lockName?: string

    Name of the playlist's lock, present when source is dui.

    note?: string

    Why query is null for an autoplaylist: the provider does not support reading, the configuration cannot be parsed, or the list is managed (use getAutoplaylistConfig). Absent when query was read.

    playlist: number

    Index of the playlist.

    playlistGuid: string

    Unique identifier of the playlist, formatted as {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}. Pass as playlistGuid to reliably target this playlist.

    query: string | null

    The list's query, read from foobar2000's built-in query/sort client. null when the provider is another one, the configuration cannot be decoded, or the playlist is not an autoplaylist; note says which for an autoplaylist.

    sort: string | null

    The independent sort expression, an empty string when none is set. null exactly when query is null. A host older than this field omits it, so test query first.

    source?: "sdk" | "dui"

    sdk identifies the autoplaylist-manager path, including third-party clients; dui identifies the existing automatic-lock name heuristic. Neither identifies the current UI or editor support.

    success: true

    Always true here; a failed call resolves with ApiFailure instead.