Operate Imou Live Addresses Using Status, Plans and Insufficient-Traffic Signals

Operate live addresses with two separate status vocabularies. Current liveList documentation defines address-level liveStatus as 1 open, 2 pause, and 3 insufficient traffic. Current queryLiveStatus returns stream-level status: 0 live, 1 live with abnormal cover, 2 abnormal video source, 3 abnormal stream conversion, 4 abnormal cloud-storage access, and 10 paused. Preserve these exact values and inspect plan state separately.

Why it matters

A live URL existing in a database does not mean it is usable. The address can be paused, a schedule can be disabled, or an individual stream can report a source or conversion problem. If an operations system collapses all those states into healthy: true/false, it cannot route incidents or explain why viewers see no video.

There is a second trap: 3 means different things in different fields. Address-level liveStatus: 3 in liveList is documented as insufficient traffic. Stream-level status: "3" in queryLiveStatus is documented as abnormal stream conversion. Field name and source method are part of the meaning.

Approach / architecture

Maintain a live-address ledger keyed by liveToken:

Ledger field	Source	Purpose
Address identity	liveList / creation response	Stable lookup for lifecycle operations
Device and channel	liveList or getLiveStreamInfo	Asset relationship
liveStatus	liveList	Address-level state
Stream status by streamId	queryLiveStatus	Per-stream technical state
job.status, period, begin/end	liveList	Plan snapshot
Last observed time and method	Your backend	Freshness and diagnostics
Redacted address reference	Returned stream data	Controlled playback handoff

This schema is recommended operator design, not an Imou-prescribed database. Restrict full HLS/RTMP addresses as secrets or sensitive operational data.

Exact current status vocabularies

Address-level liveStatus from liveList

Value	Current documentation label
1	Open
2	Pause
3	Insufficient traffic

Stream-level status from queryLiveStatus

Value	Current documentation label
0	Live broadcast
1	Live broadcast, but the video cover is abnormal
2	Video source is abnormal
3	Stream conversion abnormal
4	Cloud storage access abnormal
10	Live broadcast is paused

These labels reflect the current live pages reviewed for this draft. They must be checked again on publication day. Do not transform nonzero values into one generic failure before storing the raw field and method.

Seven operational steps

1. Inventory created addresses. Call liveList with its documented range and paginate through the intended account scope. Record liveToken, device/channel where present, type, streams, liveStatus, and job.

2. Reconcile with your asset ledger. Identify addresses with no owning product record, assets expecting an address that is absent, and duplicate assumptions. Do not delete or recreate automatically before confirming ownership.

3. Read plan state independently. The returned job includes status and schedule information. A paused or out-of-plan experience is not automatically a stream-source incident. Preserve the values exactly and check the applicable plan method before writing changes.

4. Drill into stream state. For active or important addresses, call queryLiveStatus by liveToken. Save status per streamId; do not overwrite address-level state.

5. Route by documented category. Open, paused, insufficient-traffic, cover, source, conversion, storage-access, and stream-paused observations need different operator queues. The action and alert threshold are your policy.

6. Protect playback data. Return live addresses only after product authorization, avoid persistent client exposure where possible, and redact them from normal logs, dashboards, tickets, and screenshots.

7. Recheck after controlled change. Use documented methods such as modifyLivePlanStatus, modifyLivePlan, or batchModifyLivePlan only through an approved backend workflow. Read state again and record the result.

APIs / SDKs

The live module summary lists the live-address lifecycle:

• bindDeviceLive creates a device-source live address;
• unbindLive deletes a live address;
• liveList inventories addresses and address-level state;
• queryLiveStatus inspects stream-level state;
• modifyLivePlanStatus, modifyLivePlan, and batchModifyLivePlan manage plans;
• getLiveStreamInfo resolves live information by device and channel; and
• RTMP methods create, delete, and query RTMP live addresses.

The current liveList and queryLiveStatus pages require administrator accessToken. Keep it in the trusted backend. Method existence does not guarantee a live result for every device, channel, codec, account, region, or service.

Observability and incident records

Every sample should retain method name, request id, account region, redacted liveToken, device/channel reference, raw documented status, stream ID where applicable, plan snapshot, and observation time. Separate API-call failure from a successful response that reports a non-healthy state.

Do not label liveStatus: 3 with a price or billing conclusion. The verified statement is only the current page’s “insufficient traffic” label. Commercial interpretation, entitlement, replenishment, and account action require approved current sources.

Limits & pitfalls

• Never merge liveStatus and stream status; their value 3 has different meanings.
• Do not invent status values or rename them into unsupported diagnoses.
• Do not treat liveStatus: 1 as proof that every stream variant is healthy.
• Do not treat job.status as the same field as live or stream status.
• Do not infer timezone or recurrence semantics without reading the live plan-method page.
• Do not expose reusable live URLs, live tokens, administrator tokens, or AppSecret.
• Do not automatically recreate an address when status is abnormal; first preserve evidence and ownership.
• Do not invent pricing, quota quantities, SLA, recovery timing, or universal account actions for insufficient traffic.
• Do not promise every device supports every live protocol or stream.
• Revalidate all values and method permissions immediately before publication.

Use the current Imou live module documentation to build a status-aware ledger, then test each operator branch with a controlled live address.