Matter camera: device-initiated recording is rejected with 404 ClipRecordNotFound — the clip upload URL accepts only one session

[pokersfang]

Summary

Recordings initiated by the device itself (physical button press, and by extension motion) are rejected by the clip ingest endpoint with 404 ClipRecordNotFound. Recordings started from the SmartThings app succeed on the same device, fabric and session.

The cause appears to be that each clip upload URL is valid for exactly one CMAF session, while Matter defines it as a static publishing point that must accept many.

Observed vs expected

Recording initiated by	Observed	Expected
SmartThings app	Uploads, appears in app, plays	Same
Button press on the device	Every object rejected, HTTP 404	Uploads and appears in app

PUT  <upload-url>/session_5/index.mpd
HTTP/2 404
{"requestId":"<redacted>","error":{"code":"ClipRecordNotFound", ...}}

The manifest, both init segments and every media segment are rejected identically.

Analysis

Control traffic for two consecutive app-initiated recordings:

T+0s    ModifyPushTransport      URL = .../matter/clips/<clip-uuid-A>/
T+1s    ManuallyTriggerTransport → uploads session_N/…    accepted

T+65s   ModifyPushTransport      URL = .../matter/clips/<clip-uuid-B>/   ← new uuid
T+66s   ManuallyTriggerTransport → uploads session_N+1/…  accepted

A new clip UUID is issued roughly one second before each recording. A device that triggers itself cannot participate in this: it can only use the URL currently stored in its transport, which is the previously issued UUID. That UUID accepted an earlier session successfully but returns 404 ClipRecordNotFound for the next one, so each clip record appears to be consumed after a single session.

Motion-triggered recording uploads through the same data plane, so the same failure is expected there.

Spec basis — Matter 1.6 Application Cluster §11.7

§11.7.1.2 — the URL is a static, multi-session publishing point:

The first component of the POST_URL is a static value called the publishing_point_URL. […] Any publishing_point_URL issued to a Matter device SHALL allow for one or more Sessions.

§11.7.1.8.1 — the receiver is expected to learn of a new recording from the upload itself, so no pre-registration takes place:

…the attribute type set to the value "dynamic" indicates the start of a new CMAF Session. […] type set to the value "static" indicates the end.

§11.7.7.1.1 — device-initiated triggers are explicitly in scope:

This could be a ManuallyTriggerTransport command or an internally triggered command such as a physical button press.

§11.7.7.5 defines a dedicated activation reason for this case: 3 DoorbellPressed.

Suggested resolution

1. Issue a durable TransportOptions.URL that accepts multiple session_N prefixes for the life of the transport, rather than a per-recording clip id.
2. Leave the transport allocated and Active between recordings instead of reconfiguring it immediately before each one.
3. Create the clip record lazily on arrival of session_<N>/index.mpd with type="dynamic", keyed on the session number in the path, and close it on the type="static" manifest.
4. Subscribe to PushTransportBegin / PushTransportEnd to learn that a device-initiated recording occurred; both carry the activation reason and CMAF session number.

ManuallyTriggerTransport behaviour would be unchanged.

Scope

This is not a driver defect. Motion detection is handled correctly on the support-additional-camera-device-types branch — device_configuration.lua:304 uses device:get_endpoints(clusters.OccupancySensing.ID, ...), which searches the whole device and therefore finds an OccupancySensing cluster on a child endpoint of the camera, as required by Device Library §16.1.4.

Filing here because a post on the SmartThings Community forum was frozen and never became publicly visible, and I could not find a public tracker for the Matter camera cloud ingest. Please redirect if there is a more appropriate channel.

Environment

Device	Matter 1.6 video doorbell, own firmware
Device types	Video Doorbell 0x0143, Camera 0x0142, Doorbell 0x0148, Occupancy Sensor 0x0107 on a camera child endpoint
Cluster	Push AV Stream Transport 0x0555
Driver	matter-switch, support-additional-camera-device-types branch, installed to a v3 Hub via a developer channel
Cross-check	The identical upload sequence is accepted by the reference push_av_server in connectedhomeip running in strict mode

Full HTTP-level logs and the x-st-correlation ids for the failing requests are available on request.