スクリーン CLI コマンド

画面に表示されたコードでPlayerをペアリングします。

screen pair <code...> [--name NAME] [--folder ID]

screenrig screen pair "$PAIRING_CODE" --name "Lobby"
screenrig screen pair "$PAIRING_CODE" --folder sfd_01EXAMPLEFOLDER000000000

応答には public_url とペアリングされた screen が含まれます。Player は、次にサービスへ接続したときにペアリングを完了します。ディスプレイ側で行う操作はありません。完了すると screen show は state active と online true を報告します。リクエストが中断された場合は、同じコマンドを再実行すると保存済みの冪等性キーが再利用されます。

ブラウザー Player が表示するコードでセットアップを完了します。

browser setup --code CODE [--open]

screenrig browser setup --code SETUP_CODE --open

応答には code、status（claimed）、screen_id、およびスクリーンの player_public_url が含まれます。安全性チェックに通らない URL は CLI が表示せず、警告 player_url_withheld を出します。無効または期限切れのコードではスクリーンは作成されません。リクエストが中断された場合は、同一のコマンドを再実行してください。

スクリーン一覧。アーカイブ済みは指定がなければ除外

screen list [--state archived] [--tag TAG] [--folder ID|root] [--field NAME=VALUE...] [--near LAT,LON,KM]

screenrig screen list --tag Lobby
screenrig screen list --folder sfd_01EXAMPLEFOLDER000000000
screenrig screen list --field region=north
screenrig screen list --near 47.6062,-122.3321,25

フィルターは組み合わせて使えます。各行には、スクリーンが持つ場合に tags、folder_id、fields、location が含まれます。--human を付けると、一覧されたスクリーンに値がある場合にのみ、次の列が表に追加されます：PLATFORM、REASON（アーカイブ済みスクリーンの archive_reason）、TAGS、FOLDER、FIELDS、LOCATION、ASSIGNED（デフォルト以外のプレイリストを再生しているスクリーン）、HEALTH（対応が必要なスクリーン）、UPGRADE（Player が発行されたプレイリストのバージョンへ切り替え中、または切り替えに失敗したスクリーン）。--state archived は、Player 自身がアーカイブしたスクリーン（device_reset、device_unpair）と、screen replace がアーカイブしたスクリーン（replaced）も一覧します。

1件のスクリーン（リビジョン、割り当て、稼働状況を含む）を読み込みます。

screen show <id>

screenrig screen show scr_01EXAMPLESCREEN00000000

tags はスクリーンのフリートタグを一覧表示します。effective_playlist, takeover, playlist_schedule はスクリーンが何を再生しているかとその理由を報告します。詳細は スケジュールとテイクオーバー を参照してください。health とプレーヤーのホスト機能は デバイスのヘルスと電源 にあります。online はプレーヤーが接続中（短時間の再接続ウィンドウも含む）の間 true です。オプションの last_online_at と last_ip は初回接続後に表示されます。オプションの observation はプレーヤーが描画したサーフェスを報告します：id, width, height, pixel_ratio, presentation。これらはすべて読み取り専用です。screen update は送信できず、アーカイブされたスクリーンも行を返します。

commands は、スクリーンの直近10件の再起動、再読み込み、キャッシュのクリア、アプリの再起動、更新を古い順に一覧します。各項目には、type、state（queued、sent、done、failed、expired、cancelled、superseded）、source（再起動スケジュールが発行した再起動には schedule、人が依頼したものでは存在しません）、expires_at、送信または完了した時刻が含まれます。reboot_schedule と next_reboot_at は、スクリーンの再起動スケジュールと次の再起動ウィンドウの開始を報告します。Player が終了させたキャッシュのクリア、アプリの再起動、更新には、cause と短い detail も含まれ、--human はこれを CAUSE 列と表の下の行として表示します。suspension には、一時停止中のスクリーンの message と since が含まれます。screen replace でアーカイブされたスクリーンは、デバイスの移動先のスクリーンである replaced_by を報告します。--human を付けると、screen show がそれぞれを表示します。

last_outage は、画面の直近の停止を報告します：offline_since、back_at、duration_s。ヘルスレポートで判定されると、device_restart、app_crash、app_restart、network、platform のいずれかを値とする likely_cause も含まれます。screenRIG が判断できない場合は含まれません。再起動は画面の復帰時に判定されますが、ネットワークまたは screenRIG が原因の場合は Player の次のヘルスレポートを待つため、最大 15 分かかることがあります。glass には、画面の再生レポートとスクリーンショットから screenRIG が導いた判定が入ります。--human を付けると、screen show は Last outage と Likely cause を表示し、問題が見つかった判定では Playlist stalled、Blank screen、または Frozen picture を表示します。判定が対象外とするものについては 通知 を参照してください。

folder_id はスクリーンのフォルダーを示し、プロジェクトのルートでは存在しません。fields、location、wall は設定されると表示されます。screen update と screen wall set を参照してください。observation.surfaces の各項目には、Player が読み取れる場合は rotation も含まれ、ビデオウォールでは出力ごとに 1 項目が、screen wall set が受け付ける名前で報告されます。

manifest_upgrade は、Player が自分に発行されたプレイリストのバージョンに切り替わったかどうかを示します。state は none、pending、downloading、preparing、activating、retrying、failed、blocked、partial、current のいずれかで、desired_playlist と active_playlist（id、name、revision）が並びます。後者は Player が最後に確認したバージョンで、すべてのセッションがそれを表示している証拠にはなりません。失敗または部分的なアップグレードには code、attempt、retry_at、missing_page_count も含まれます。--human は Target v42 · Playing v41 と表示します。失敗したアップグレードは再試行を予約しません。原因を解消してから screen reload を実行するか、プレイリストを再度割り当ててください。保存された割り当ては再生を保証しません。

applications_unsupported は、ペアリング済みの Player が application または iframe ページを表示できない間、表示されます。マニフェストは変わらず、Player はそれらをスキップします。recovery_pending は、保存済みの ID を失ったディスプレイがこのスクリーンとして再接続を申し出ている間、表示されます。申し出の expires_at と、ディスプレイが報告する platform、model、firmware、manufacturer が含まれます。screen recover を参照してください。

スクリーンの名前、プレイリストの割り当て、タイムゾーンのオーバーライド、フィールド、位置情報を 1 回の呼び出しで更新します。

screen update <id> [--name NAME] [--playlist-id ID | --clear-playlist] [--timezone ZONE | --clear-timezone] [--field NAME=VALUE...] [--unset-field NAME...] [--clear-fields] [--location LAT,LON [--location-name NAME] [--address TEXT] | --clear-location] [--expect-rev REVISION]

--name、--playlist-id、--clear-playlist、--timezone、--clear-timezone、--field、--unset-field、--clear-fields、--location、--clear-location のうち少なくとも 1 つを指定してください。

screenrig screen update scr_01EXAMPLESCREEN00000000 --name "Lobby"
screenrig screen update scr_01EXAMPLESCREEN00000000 --field store_number=0142 --field region=north
screenrig screen update scr_01EXAMPLESCREEN00000000 --location 47.6062,-122.3321 --location-name "Seattle HQ"
screenrig screen update scr_01EXAMPLESCREEN00000000 --clear-playlist --expect-rev 3

レビュー中は--playlist-idの変更のみがscreen assignのように提案されます。Proposeセッションは他のフィールドを変更できません。

フィールドや位置情報を変更すると、スクリーンのマニフェストのリビジョンが変わり、プレイリストを表示しているスクリーンは新しい値を取得します。カードと iframe ページはスクリーンごとにそれらを読み取るため、1 つのプレイリストで各スクリーン固有の値を表示できます。{screen.field.NAME}、{screen.name}、{screen.timezone} はカードの任意のテキストパラメーターを埋め、"location": "{screen.location}" はそのカードが受け付ける形でカードの位置情報を埋めます。カードのデータキーには {screen.field.NAME}（例：menu-{screen.field.store_number}）を含められます。フィールドのないスクリーンではそのテキストは空になり、カードはそのデータキーや位置情報なしで表示されます。screen show はスクリーンのフィールドと位置情報を一覧し、screen list はそれらでスクリーンを探します。iframe アドレスとアプリケーションパラメーターのスクリーントークンを参照してください。

準備済みファイルから新しいプレイリストを作成し、スクリーンに割り当てる。

screen publish <id> <file> [--expect-rev REVISION] [--note TEXT] [--no-wait] [--poll-ms MS] [--timeout MS] [--no-progress]

screenrig screen publish scr_LOBBY lobby.json

これは新しいプレイリストを作成して割り当てます。既存のプレイリストを名前で更新しません。準備したドキュメントを先に検査してください。同じ入力を繰り返すと、曖昧な失敗から再開できます。割り当ての読み戻しは再生を証明しません。スクリーンショットを別途リクエストしてください。レビュー中は両方のレビューと共にstage: pending_reviewを返します。詳細はプレイリストの準備、公開、編集を参照してください。

割り当て後、コマンドは Player がプレイリストを表示するまで待ちます。data.stage が playing、data.playback_verified が true になります。段階の変化は発生するたびに stderr へ、JSON 行として、または --human のときはテキストとして出力されます。公開が完了した後に同じコマンドを繰り返すと、スクリーンがまだそのプレイリストを表示している間はその公開（data.already_published）が報告され、スクリーンが別の内容に移っていれば新たに公開されます。

スクリーンまたはスクリーン群をプレイリストに向けます。

screen assign (<id>... | --tag TAG | --folder ID) --playlist-id ID [--expect-rev REVISION] [--note TEXT]

screenrig screen assign scr_01EXAMPLESCREEN00000000 --playlist-id pl_01EXAMPLEPLAYLIST000000
screenrig screen assign --tag Lobby --playlist-id pl_01EXAMPLEPLAYLIST000000
screenrig screen assign --folder sfd_01EXAMPLEFOLDER000000000 --playlist-id pl_01EXAMPLEPLAYLIST000000

ページをスケジュールするプレイリストは、どのスクリーンにも割り当てられます。スケジュールはスクリーン自身のタイムゾーン（オーバーライド、なければデバイスが報告するゾーン、なければ UTC）で読み取られます。

フリートに公開するには、まずplaylist createでプレイリストを作成し、次にscreen assign --tag TAG --playlist-id IDを実行します。screen publishは1つのスクリーンを対象とします。

Propose アクセスの場合、またはプロジェクトがエージェントの変更にレビューを要求する場合、1 つのスクリーンへの変更も、フリート全体への変更も、代わりに pending_review を返します。data.review にレビュー ID とダッシュボードの url が含まれ、警告 pending_review がその URL を示し、data.next は reviews show ID です。人が承認するまで画面上は何も変わらないので、書き込みを繰り返さないでください。保護されたフォルダー内のスクリーンでは、どのアクセスレベルでも pending_review を返し、あなた以外で、あなたが代理する人以外の承認者が決定します（そうでない場合は second_approver_required、終了コード 3）。スクリーンフォルダーに限定された呼び出し元は、自分のスコープ内のスクリーンにのみ割り当てできます。保存された割り当ては再生を保証しません。screen screenshot で画面を確認できます。

スクリーンの現地時刻ルールを解釈するタイムゾーンをオーバーライドするか、オーバーライドを削除します。

screen set-timezone <id> (--timezone ZONE | --clear) [--expect-rev REVISION]

screenrig screen set-timezone scr_01EXAMPLESCREEN00000000 --timezone America/Los_Angeles
screenrig screen set-timezone scr_01EXAMPLESCREEN00000000 --clear

すべてのスクリーンには有効タイムゾーンがあり、すべての現地時刻ルールがそれを参照します。対象は、ページの表示条件、広告スロット、プレイリストのスケジュール、テイクオーバー、キャンペーン、ディスプレイスケジュールと再起動スケジュール、そして{screen.timezone}です。有効タイムゾーンは、このオーバーライド、なければスクリーンの Player がデバイスから報告するゾーン、なければUTCです。デバイスが正しいゾーンを報告している間は、オーバーライドは不要です。screen showは有効ゾーンをTimezoneとして、その由来を示すeffective_timezoneとtimezone_source（screen、device、またはdefault）とともに--jsonに出力します。有効ゾーンが変わると、マニフェストのリビジョンが再生成されます。

ZONE は Area/City 形式で、America/New_York や Asia/Tokyo、または UTC です。

スクリーンのビデオウォールを設定します。1 つの Player が 2〜12 台のディスプレイを 1 つのキャンバスとして駆動します。

screen wall set <id> --outputs NAMES --arrangement row|column|grid [--columns N] [--rotation 0|90|180|270] [--expect-rev REVISION]

screenrig screen wall set scr_01EXAMPLESCREEN00000000 --outputs HDMI-A-1,HDMI-A-2 --arrangement row
screenrig screen wall set scr_01EXAMPLESCREEN00000000 --outputs DP-1,DP-2,DP-3 --arrangement row --rotation 90 --expect-rev 4
screenrig screen wall set scr_01EXAMPLESCREEN00000000 --outputs DP-1,DP-2,DP-3,DP-4,DP-5,DP-6 --arrangement grid --columns 3

1 つの Player がディスプレイを 1 つのウォールとして駆動するため、プレイリストのページはすべてのディスプレイにまたがります。設定はウォール全体を置き換えるので、保持したい --rotation と --columns は毎回指定してください。display.wall 機能を宣言するのは Linux Player のキオスクインストールと Windows Player だけで、それ以外の Player は wall_unsupported（終了コード 5）を返し、何も変更されません。Propose アクセスではウォールを変更できません（insufficient_access）。2〜3台のディスプレイのウォールには Plus 以上、4〜12台のウォールには Enterprise が必要です。対象外のプランでは feature_not_in_plan（終了コード 8）が返されますが、screen wall clear と保存済みのウォールを保つ設定は引き続き行えます。ビデオウォールを参照してください。

ウォールの形に合わせたプレイリストは、playlist init にスクリーンの ID を指定して作成します。一致するキャンバスと format（displays、arrangement、orientation、グリッドでは columns）が書き込まれます。プリミティブの displays（[2] や [1, 2, 5, 6] など）は、それが覆うディスプレイ番号を示します。番号は 1 から、左から右、次に上から下の順で数え、ウォールの長方形を埋める必要があります。形式がウォールの形と一致しないプレイリストを割り当てると playlist_format_mismatch（終了コード 5）になります。形式のないプレイリストは、すべてのディスプレイで同じように再生されます。スクリーンが一致する形式のプレイリストを再生している場合、変更後 20 秒間、各ディスプレイに番号と名前が表示されるので、順序を画面で確認できます。

スクリーンのビデオウォールを削除します。

screen wall clear <id> [--expect-rev REVISION]

screenrig screen wall clear scr_01EXAMPLESCREEN00000000

割り当て済みのプレイリストは再検証されません。format を持つ場合、スクリーンのマニフェストは劣化し（wall_format_mismatch）、フォーマットのないプレイリストを割り当てるまで、Player は最後に正常だったページを保持します。ウォールのないスクリーンでは何も変わらず応答します。Propose アクセスではウォールを変更できません（insufficient_access）。

スクリーンを非表示にし、ガラスを暗くします。

screen archive <id> [--expect-rev REVISION]

screenrig screen archive scr_01EXAMPLESCREEN00000000

アーカイブすると、スクリーンがデフォルトの一覧から非表示になり、画面が暗くなります。Player のバインドは解除されません。

ディスプレイのキーを持つ人は、スクリーンがアーカイブされていても接続できます。ハードウェアを完全に退役させるには、スクリーンをアーカイブしたままにするか、screen recover または screen replace でスクリーンを新しいハードウェアに移します。これらは古いキーを失効させます。

アーカイブ済みスクリーンをデフォルトリストに復元します。

screen unarchive <id> [--expect-rev REVISION]

screenrig screen unarchive scr_01EXAMPLESCREEN00000000

Player は自身のスクリーンもアーカイブできます。キーを持つ Player ではリセットの確認、Cookie でペアリングされたブラウザー Player ではペアリング解除です。screen show は archive_reason を device_reset または device_unpair（リクエストしたアーカイブの場合は project）として archived_at で報告します。スクリーンはあらゆる理由でデバイスの紐付けを保持するため、そのキーやデバイス Cookie を持つ Player は暗転し、アーカイブ解除時に再ペアリングなしで復帰します。リセットまたはペアリング解除された Player はキーや Cookie を破棄し、新しいスクリーンとして再ペアリングします。確認済みのスクリーン復元で置き換えられたキーは無効のままです。

screen replace によって replaced としてアーカイブされたスクリーンはデバイスの紐付けを保持しないため、アーカイブ解除は受け付けられず、screen delete で削除できます。

スクリーンのコンテンツの代わりに通知を表示し、再開されるまで続けます。

screen suspend <id> --message TEXT [--expect-rev REVISION]

screenrig screen suspend scr_01EXAMPLESCREEN00000000 --message "Closed for stocktake. Back at 9am."

一時停止中のスクリーンは、コンテンツの代わりにメッセージを表示します。それ以外は変わりません：プレイリスト、スケジュール、テイクオーバー、ディスプレイ制御はそのまま残り、通常どおり変化し続けます。screen resume は、そのスクリーンが現在表示するはずの内容を表示します。screen show は suspension を message と since とともに報告します。一時停止中のスクリーンをさらに一時停止すると、メッセージが置き換わり、since は維持されます。一時停止するとスクリーンのリビジョンが更新され、Player はすぐに再取得します。アーカイブ済みのスクリーンは screen_archived を返します。

スクリーンの一時停止を終了し、スクリーン自身のコンテンツを再び表示します。

screen resume <id> [--expect-rev REVISION]

screenrig screen resume scr_01EXAMPLESCREEN00000000

再開すると、スクリーンは自身のコンテンツを再び表示します。その内容は、スクリーンが現在表示するはずのものから決まり、Player はすぐに再取得します。一時停止中でないスクリーンは変更なしで応答し、リビジョンも変わりません。アーカイブ済みのスクリーンは screen_archived を返します。

スクリーンを削除します。

screen delete <id> [--expect-rev REVISION]

screenrig screen delete scr_01EXAMPLESCREEN00000000

スクリーンを削除できるのは、Player のキーが紐づいていない間だけで、そのスクリーンでは screen show が deletable: true を報告します。コードでペアリングする Player は、ネイティブでもブラウザー版でもキーを保持し、そのキーはスクリーンに紐づいたままです。そのスクリーンを削除すると 409 screen_archive_required（終了コード 5）が返るので、代わりにアーカイブしてください。キーを持たないのは Cookie でペアリングされたブラウザー Player だけで、そのスクリーンはペアリング済みでも保留中でも削除できます。

キーを持つディスプレイを新しいスクリーンとしてペアリングするには、Player 側でリセットを確定し、表示されるコードを screen pair で登録します。古いスクリーンはアーカイブされたままです。スクリーンを交換用ハードウェアに移すには、screen recover を使います。そのハードウェアがすでに独立したスクリーンとしてペアリング済みなら screen replace を使います。

保存済みの ID を失ったディスプレイを、ペアリングされていたスクリーンに再接続します。

screen recover <id> [--expect-rev REVISION]

screenrig screen show scr_01EXAMPLESCREEN00000000
screenrig screen recover scr_01EXAMPLESCREEN00000000

保存済みの ID を失ったディスプレイが、ペアリング中にこのスクリーンのハードウェア識別子を報告すると、申し出が行われます。screen show は、これを期限とともに recovery_pending として報告し、ディスプレイが報告する場合は platform、model、firmware、manufacturer も含めます。このコマンドで確定するまで、何も再バインドされません。スクリーンのラベル、プレイリスト、タイムゾーン、スケジュール、履歴はそのままで、ディスプレイの新しいキーが以前のキーに置き換わり、以前のキーは 15 分の猶予期間後に失効します。デバイスのリセットでアーカイブされたスクリーンは、screen unarchive まではアーカイブされたままです。

確定する前に、報告されたモデルとファームウェアを、想定しているディスプレイと照合してください。ディスプレイ上で動作する任意のアプリケーションがその識別子を読み取れるため、申し出だけでは、どのディスプレイが申し出ているかは証明されません。スクリーンの現在の Player がまだオンラインの間は、申し出は拒否されます。また、1 つのスクリーンが受け付ける申し出は 1 時間あたり最大 3 件です。申し出がない場合、コマンドは recovery_not_offered を返し、ペアリングセッションが失効した申し出は recovery_expired を返し、識別子が複数のスクリーンに紐づいている場合は recovery_ambiguous を返します。いずれの場合も何も再バインドされません。復旧がプロジェクトをまたぐことはありません。

別のスクリーンとしてペアリングされているデバイスをこのスクリーンに移し、このスクリーンの設定と履歴を保持します。

screen replace <id> --with ID [--expect-rev REVISION]

screenrig screen replace scr_01EXAMPLESCREEN00000000 --with scr_01EXAMPLENEWSCREEN000000

最初に新しいハードウェアを独自のスクリーンとしてペアリングし、そのあと置き換えを実行します。デバイスのキー（ブラウザー Player の場合はその認証情報）が <id> を開くようになります。そのスクリーンは名前、タグ、タイムゾーン、プレイリスト、スケジュール、テイクオーバー、ディスプレイスケジュールとオーバーライド、ビデオウォール、コメント、フィールド、場所、履歴を保持し、置き換え側のホストと Player を引き継ぎます。ヘルス、ステータス、ストレージ、キューに入っているコマンドはリセットされます。--with で指定したスクリーンは、archive_reason replaced と、<id> を示す replaced_by を付けてアーカイブされます。デバイスの紐付けは保持されないため、screen unarchive では復元できず、screen delete で削除できます。<id> が保持していたキーは、15分の猶予期間が過ぎると無効になり、その後、古いデバイスは拒否されます。どちらのスクリーンも、ペアリング済みの Player を持つアクティブな状態でなければなりません：ペアリング待ちのスクリーンには resource_conflict が、アーカイブ済みのスクリーンには screen_archived が返り、ビデオウォールには display.wall（wall_unsupported）を宣言する置き換え側の Player が必要です。リクエストには常に冪等キーが付き、正確な再試行は元の回答を返します。

保存済みの ID を失ったディスプレイで、このスクリーンの識別子を報告しているものを移す場合は、screen recover を使います。

スクリーンの新しい公開IDを発行します。

screen rotate-public-id <id> [--expect-rev REVISION]

screenrig screen rotate-public-id scr_01EXAMPLESCREEN00000000

スクリーンの public_id（公開 URL に含まれる認証情報）が置き換えられ、古いものを使って開かれたセッションはすべて終了します。Player のペアリングは維持されます。ペアリング済みの Player は新しいセッションを開き、コンテンツを表示し続けます。

スクリーンのリンクを作成または置き換え、その Player URL を表示する。

screen link create <id> [--expect-rev REVISION]

screenrig screen link create scr_01EXAMPLESCREEN00000000

data.url、つまり vMix や OBS のブラウザーソースの URL として貼り付ける Player URL（https://play.screenrig.ai/player/#screen=…）を表示します。ブラウザーソースはストレージを保持せず、そのままでは読み込みのたびにペアリングを失います。Player は読み込みのたびにこの URL から動作し、URL がペアリングのすべてです。リンクをもう一度作成すると置き換えられ（data.replaced は true）、古い URL は直ちに動作しなくなり、そこから開いた Player はコンテンツのない通知を表示します。URL はスクリーンを開く認証情報なので、機密ラベルの下に表示され、操作ログには残らず、screen link show で再表示できます。1か所だけで開いてください。ペアリングされていないスクリーンは resource_conflict（終了コード 5）、アーカイブ済みのスクリーンは screen_archived を返します。リクエストが中断された後は、同じコマンドをもう一度実行してください。保存された冪等キーを再利用し、同じリンクが返ります。

スクリーンのリンクとその Player URL を表示する。

screen link show <id>

screenrig screen link show scr_01EXAMPLESCREEN00000000

data.url を機密ラベルの下に表示し、data.hint（シークレットの末尾4文字）と、Player がリンクを開いた後は data.created_at と data.last_used_at も表示します。読み取り専用の認証情報では url は空で url_redacted が true になり、人間向け出力は URL が伏せられていると表示します。Manage のサインインでは受け取れます。リンクのないスクリーンは screen_link_not_found（終了コード 4）を返し、リンクを作成するコマンドを示します。screen show はリンクのあるスクリーンでは Screen link: on (…HINT) を表示し、URL は決して表示しません。

スクリーンのリンクをオフにする。

screen link delete <id> [--expect-rev REVISION]

screenrig screen link delete scr_01EXAMPLESCREEN00000000

URL は直ちに動作しなくなり、それが開いたセッションはすべて終了します。まだそれを表示しているブラウザーソースは、新しい URL が与えられるまで通知だけを表示し、コンテンツは表示しません。スクリーン、そのペアリング、コンテンツには影響しません。スクリーンにリンクがない場合は、何も変更せずに成功します。

スクリーンの Player またはフリート内のすべての Player に一度だけリロードを依頼

screen reload (<id>... | --tag TAG | --folder ID) [--expires-in DURATION] [--expect-rev REVISION]

screenrig screen reload scr_01EXAMPLESCREEN00000000
screenrig screen reload scr_01EXAMPLESCREEN00000000 --expires-in 2h
screenrig screen reload --tag Lobby
screenrig screen reload --folder sfd_01EXAMPLEFOLDER000000000

回答は reload_id、state、expires_at を含みます。オンラインのスクリーンには再読み込みがすぐに送信されます（state sent）。オフラインのスクリーンの場合、再読み込みは queued の状態で保持され、expires_at（--expires-in で別に指定しない限り、リクエストの24時間後）より前にオンラインに復帰した時点で送信されます。新しい再読み込みは、キューに残っている再読み込みを置き換えます。screen show はスクリーンの commands を一覧表示し、screen command cancel でキューに残っている再読み込みをキャンセルできます。フリートでは、各結果の reload に同じ state が含まれます。Web Player は次のページ境界で再読み込みし、ネイティブ Player は再接続し、マニフェストを再取得し、更新を確認します。Player は、最後に処理した再読み込みから10分以内の再読み込みを無視します。再読み込みはアクティブなスクリーンでもアーカイブ済みのスクリーンでも動作し、スクリーンのリビジョンは変更しません。

ライブスクリーンまたはスクリーン群に一時的なステージクロームメッセージを投稿します。

screen toast (<id>... | --tag TAG | --folder ID) --text TEXT [--level info|alert|error] [--duration-ms MS]

screenrig screen toast scr_01EXAMPLESCREEN00000000 --text "Lobby closed"
screenrig screen toast --tag Lobby --text "Closing in ten minutes"
screenrig screen toast --folder sfd_01EXAMPLEFOLDER000000000 --text "Closing in ten minutes"

トーストはプリミティブではありません：キャンバススロットを占有せず、レイヤーもなく、準備やクロスフェードに関与しません。最新が勝ち、キューもキャンセルもありません。受け入れられるエンベロープは { expires_at } のみです。テキストに認証情報や秘密情報を絶対に入れないでください。

スクリーンの名前をコンテンツの上にしばらく表示し、現場でスクリーンを見つけやすくします。

screen identify <id> [--duration DURATION]

screenrig screen identify scr_01EXAMPLESCREEN00000000
screenrig screen identify scr_01EXAMPLESCREEN00000000 --duration 2m

Player はコンテンツの上に全画面のオーバーレイを描画し、スクリーンの名前を非常に大きく、その下に ID を小さく表示します。再生はその下で続き、より新しい識別リクエストがオーバーレイを置き換えます。受け入れられたエンベロープは identify_id、duration_ms、リクエストの60秒後を示す expires_at を含むため、オフラインのスクリーンが後からオーバーレイを表示することはありません。identify 機能を宣言した Player だけがオーバーレイを表示します：それ以外のスクリーンには 409 identify_unsupported（終了コード 5）が返り、何も送信されないため、Player を更新するか、screen toast で名前を表示してください。アーカイブ済みのスクリーンには screen_archived が、ペアリング待ちのスクリーンには resource_conflict が返ります。識別はスクリーンのリビジョンを変更しません。

スクリーンが現在再生しているプレイリストのページを開始し、そのページをスクリーンショットで確認します。

screen play-page <id> --page-id ID

screenrig screen play-page scr_01EXAMPLESCREEN00000000 --page-id welcome
screenrig screen screenshot scr_01EXAMPLESCREEN00000000

ページは Player 上で最初から開始され、ローテーションはそこから続きます。そのため、次に撮るスクリーンショットには、ローテーションが回ってくるのを待たずにそのページが写ります。ページは、スクリーンが現在再生しているプレイリスト（テイクオーバー、そうでなければ成立しているキャンペーン、そうでなければスケジュール、そうでなければ割り当て済みのプレイリスト）に属している必要があります。それ以外のページは page_not_on_screen（終了コード 5）になり、問題の内容にそのプレイリストが示されます。ホストレポートで play_page 機能を宣言していない Player は play_page_unsupported（終了コード 5）を返し、何も送信されません。Player を更新してください。

応答には playlist_id、page_id、manifest_revision、expires_at が含まれます。リクエストは 60 秒で失効し、スクリーンのリビジョンは変わりません。アーカイブ済みのスクリーンは screen_archived を、ペアリング待ちのスクリーンは resource_conflict を返します。同じ冪等性キーで再試行すると、元の応答が再現されます。

アクティブなスクリーンの静止画を 1 枚、またはフリート内のすべてのスクリーンの静止画を撮影し、ディスクに書き込みます。

screen screenshot <id> [--output FILE] [--timeout MS] [--poll-ms MS]
screen screenshot (<id> <id>... | --tag TAG | --folder ID) [--output DIRECTORY] [--concurrency N] [--timeout MS] [--poll-ms MS]

screenrig screen screenshot scr_01EXAMPLESCREEN00000000 --output ./lobby.webp

screenrig screen screenshot --tag Lobby --output ./lobby-shots

screenrig screen screenshot --folder sfd_01EXAMPLEFOLDER000000000 --output ./north-shots

コマンドは WebP がディスクに書き込まれるまで待機します。エンベロープには screen_id、capture_id、path、bytes、sha256、width、height が含まれ、画像のバイト列は含まれません。最新のものが優先されます。後のリクエストは進行中のキャプチャを置き換えます。Player の Web アプリのスクリーンショットでは、各 iframe ページは「Embedded web page」というラベルの付いた暗い灰色のタイルとして描画され、各アプリケーションはアプリケーション自身が描画した内容で表示されます。画像にはタイルを示す印がないため、iframe ページが描画されたことの証明にはなりません。

複数のID、--tag または --folder を指定すると、回答は フリート結果 で、action: "screenshot"、selector、output ディレクトリを含み、ok の各結果には path、bytes、sha256、width、height が入ります。--tag を指定すると、CLIはまずタグ付けされたスクリーンを一覧し、すべての一覧ページをたどります。各一覧ページは1件のエージェントリクエストで、キャプチャ自体は数えられず、複数のIDでは一覧は不要です。この形式では --idempotency-key は拒否されます。各キャプチャが固有のキーを使うためです。キャプチャが予期せず失敗すると、そのスクリーンの結果は unexpected_error になり、新しいキャプチャは始まらず、待機中のスクリーンは not_attempted と報告し、終了コードは1です。

1 つのスクリーンの場合、エンベロープには frame.flat（この画像が単一色のベタ塗りかどうか）と、picture（スクリーンに判定がある場合の、ブランクまたは静止の判定）も含まれます。ベタ塗りの画像だけでは判定になりません。ページ間の遷移や、意図的に黒いページも同じに見えます。--folder を指定すると、CLI はフォルダーとその中のすべてのフォルダーを、フォルダーごとに screen list --folder で一覧し、一覧でオフラインと表示されるスクリーンはキャプチャせずに失敗として報告します。

サーバーが受け付けるキャプチャは、1 分あたりスクリーンごとに 10 件、組織ごとに 30 件、アドレスごとに 30 件です。CLI は 429 と 5xx の応答をバックオフ付きで再試行し、Retry-After に従います。完了できないキャプチャは screenshot_unavailable（終了コード 5）になります。スクリーンがオフライン、リクエストが timed_out、表示中のページに Player がキャプチャできない要素がある（unsupported_surface。ブラウザー Player 上で見えているサードパーティーの iframe など）、Player のキャプチャが失敗した（capture_failed）、または --timeout が切れた時点でキャプチャが保留中だった、のいずれかです。--timeout 0 を指定すると待機はサーバーに任され、サーバーは応答のないリクエストを 30 秒後に失効させます。Player がディスプレイの状態を報告している場合、失敗したキャプチャには error.display が含まれ、power、connected、reported_at、stale（35 分後）が入ります。off または standby の新しい報告がある場合は、ディスプレイがオンのときに再試行することを勧めます。

スクリーンのライブビューを開始または更新し、それを表示するダッシュボードのページを出力します。

screen live start <id> [--duration DURATION] [--wait DURATION]

screenrig screen live start scr_01EXAMPLESCREEN00000000
screenrig screen live start scr_01EXAMPLESCREEN00000000 --duration 2m --wait 60s

ライブビューは、スクリーンが再生している内容をダッシュボードで映像として表示します。CLI はセッションの開始、読み取り、停止だけを行い、映像そのものは運びません。data はセッションで、開くべきページ viewer_url を含みます。すでにセッションがあるスクリーンを開始すると、それが更新されます。リースは、現在の終了時刻と、今から --duration 後の時刻のうち遅い方になり、セッション開始から 5 分を超えることはありません。その後セッションは自動的に終了します。更新も再開もされず、次のセッションには新しい screen live start が必要です。リースが切れたとき、screen live stop を実行したとき、または Player がセッションを終了したときは、それより早く終了します。

コマンドは Player に公開を依頼し、Player が接続済みと報告するまで --wait の間、1 秒ごとにセッションを読み取ります。待機が終わっても Player が接続していない場合でも応答は ok で、警告 live_not_ready が付きます。screen live status をもう一度読み取るか、viewer_url を開いてください。待機中に終了したセッションは live_unavailable（終了コード 5）で、詳細に ended_reason が示されます（例：consent_timeout。Android では、Player が起動するたびに、画面の前にいる人が画面キャプチャを許可する必要があります）。オフラインのスクリーンも live_unavailable になり、アーカイブ済みのスクリーンは screen_archived を返します。live_view 機能を宣言していない Player は live_unsupported（終了コード 5）を返し、何も送信されません。Player を更新してください。メディアリレーのないサーバーは feature_unavailable を返します。その場合は screen screenshot を使ってください。ライブビューは無料です。ライブビューを参照してください。

スクリーンのライブビューセッションを読み取ります。

screen live status <id>

screenrig screen live status scr_01EXAMPLESCREEN00000000

state は idle（セッションなし）、requested（Player に要求済み）、publishing（リレーが映像を保持）、または ended のいずれかで、ended_reason は 10 分間保持されます。publisher.connected は Player 自身の報告で、最大 45 秒前のものであり、映像が出ている証拠にはなりません。data には viewer_url が含まれます。

スクリーンのライブビューセッションを終了します。

screen live stop <id>

screenrig screen live stop scr_01EXAMPLESCREEN00000000

セッションを終了して Player に公開の停止を伝え、その時点のセッションを出力します。ended で、ended_reason は stopped です。セッションがなくても成功します。リースが切れると、セッションは自動的にも終了します。

スクリーンが再生している内容のフレームを、ライブストリームから JPEG として保存し、再生と動きを確認します。

screen live frame <id> [--output PATH] [--count N] [--interval DURATION] [--duration DURATION] [--wait DURATION] [--stop]

screenrig screen live frame scr_01EXAMPLESCREEN00000000
screenrig screen live frame scr_01EXAMPLESCREEN00000000 --output now.jpg --stop
screenrig screen live frame scr_01EXAMPLESCREEN00000000 --output frames/ --count 5 --interval 1s

コマンドはライブセッションを開始し、Player の公開を待ち、メディアリレーにフレームを要求して、新しいフレームを 1 回ずつ読み取ります。フレームは、Player のエンコーダーが送った映像をそのまま、最大 1280x720 に縮小し、非可逆圧縮にしたもので、約 1 秒に 1 枚です。動きと今ガラス上にある内容を示すので、フレームを比較して（--count 5 --interval 1s）内容が動いているか確認します。スクリーンショットではなく、レイアウトの確認にはスクリーンショットを使います。フレームは無料です。

data は {screen_id, live_id, frames} で、フレームごとに path、captured_at、width、height、bytes、sha256 を含み、--stop がセッションを終了した場合は stopped が true になります。--stop がなければ、セッションはリースに任されます。--wait 以内に公開を始めない Player、またはその間に新しいフレームを送らない Player は live_not_ready（終了コード 5）になります。Android では、Player が起動するたびに、画面の前にいる人が画面キャプチャを許可する必要があります。終了したセッション、またはフレームが届かなくなったセッションは live_unavailable（終了コード 5）です。live_view 機能のない Player は live_unsupported を返し、メディアリレーまたはフレームのないサーバーは feature_unavailable（終了コード 4）を返します。その場合は screen screenshot を使ってください。

スクリーンまたはフリートのタグを設定、追加、削除、またはクリアします。

screen tag (<id>... | --tag TAG | --folder ID) (--set TAGS | --add TAGS | --remove TAGS | --clear) [--expect-rev REVISION]

screenrig screen tag scr_01EXAMPLESCREEN00000000 --set Lobby,Floor2
screenrig screen tag scr_01EXAMPLESCREEN00000000 --add Spring
screenrig screen tag --tag Lobby --add Spring
screenrig screen tag --folder sfd_01EXAMPLEFOLDER000000000 --add Spring

タグは1～32文字の英数字で、スクリーンは最大16個のユニークタグを持ちます。タグはフリートを選択し、認証には使わずプレーヤーには届きません。タグ変更はスクリーンのリビジョンを更新し、マニフェストのリビジョンは変わりません。単一スクリーンではエンベロープは更新されたスクリーンです。--add と --remove はスクリーンを先に読み込み、--expect-rev または読み込んだリビジョンで新セットを書き込み、同時変更は revision_conflict（終了コード6）を返し上書きされません。コマンドを再実行してください。フリートでは --add と --remove が各スクリーンのセットに原子操作で適用され、16タグを超えるスクリーンは自身の結果で invalid_request となります。

タグが変更されるあらゆる場面（screen tag、API によるスクリーンの更新、ダッシュボードのタグエディター）で、応答のlevelsは、gainedとlostの下に、スクリーンがタグ対象に加わった、または外れたキャンペーンを列挙し、それぞれにsource（campaign）、id、screensの数、キャンペーンに到達数がある場合はreach_beforeとreach_afterを持ちます。フリートのscreen tagは、フリート全体でそれらを合計します。タグの編集を無害と判断する前にlevels.lostを読んでください。キャンペーンのスクリーンから最後の一致するタグを外すとそのグループが空になり、reach_droppedとgroup_emptyの通知が発生します。

スクリーンとスクリーンフォルダーを、スクリーンフォルダーの中、またはプロジェクトのルートへ移動します。

screen move <id>... (--folder ID | --root) [--note TEXT]

screenrig screen move scr_01EXAMPLESCREEN00000000 --folder sfd_01EXAMPLEFOLDER000000000
screenrig screen move sfd_01EXAMPLEFOLDER000000000 --root

移動は、すべて成功するかまったく行われないかの 1 回のリクエストです。フォルダーは中身ごと移動し、自分自身やその内側のフォルダーには移動できません。フォルダーの階層は最大 10 です。すでに移動先にある項目はそのままで、数えられません。data.screens と data.folders は移動した件数です。data.levels は、gained と lost の下に、移動したスクリーンが入った、または外れたフォルダー対象のキャンペーン（source campaign、reach_before と reach_after 付き）と、デフォルトとして表示し始めた、または表示しなくなったフォルダーのデフォルトプレイリスト（source folder）を一覧します。スクリーンは約 15 秒以内にプレイリストを再評価します。screen show は effective_playlist を報告し、campaign explain SCREEN_ID でその理由を確認できます。

スクリーンフォルダーに限定された呼び出し元は、自分のスコープ内のスクリーンとフォルダーだけを、そのスコープ内のフォルダーへ移動できます。それ以外、プロジェクトのルートを含め、は移動全体が outside_screen_scope（終了コード 3）で拒否されます。保護されたフォルダーへの、またはそこからの移動は pending_review を返し、protected_change レビューが作られます。2 人目の承認者が決定するため、書き込みを繰り返さないでください。--note で承認者に理由を伝えられます。リクエストが中断された場合は、同じコマンドを再実行すると保存済みの冪等性キーが再利用されます。

プロジェクトのスクリーンフォルダーをツリーとして一覧します。各フォルダー直下のアクティブなスクリーンと、そのデフォルトプレイリストも表示します。

screen folder list

screenrig screen folder list

プロジェクトのすべてのスクリーンフォルダーを、名前順に最大 1000 件返します。data.items には各フォルダーの id、name、parent_id（プロジェクトのルートでは null）、設定されている場合の default_playlist_id と protected、screens（直下のアクティブなスクリーン。下位フォルダーのものは含まない）、revision が含まれます。--human を付けると、出力はフォルダーごとに 1 行でパスを示すツリーになります。スクリーンのフォルダーは screen list と screen show の folder_id で示され、プロジェクトのルートでは存在しません。読み取り専用アクセスで足ります。

スクリーンフォルダーを確認します。

screen folder show <id>

screenrig screen folder show sfd_01EXAMPLEFOLDER000000000

screen folder list が返すフィールドを持つフォルダーを 1 つ返します。読み取り専用アクセスで足ります。

プロジェクトのルート、または別のフォルダーの中にスクリーンフォルダーを作成します。

screen folder create --name NAME [--parent ID] [--default-playlist-id ID] [--note TEXT]

screenrig screen folder create --name "North Tower"
screenrig screen folder create --name "Level 2" --parent sfd_01EXAMPLEFOLDER000000000 --default-playlist-id pl_01EXAMPLEPLAYLIST000000

組織は、すべてのプロジェクトを合わせて最大 1000 個のフォルダーを持てます（quota_exceeded）。階層は最大 10 までです（invalid_request）。スクリーンは screen move でフォルダーに入れます。その後、フォルダーはフリートコマンドの対象として、またキャンペーンの対象として、その中のスクリーンを指定します。スクリーンフォルダーを参照してください。

スクリーンフォルダーに限定された呼び出し元は、自分のスコープ内にのみフォルダーを作成できます。--parent はそのスコープのフォルダーでなければなりません（outside_screen_scope、終了コード 3）。保護されたフォルダー内に作成したフォルダーは pending_review を返し、protected_change レビューが作られます。あなた以外で、あなたが代理する人以外の承認者が決定するため、書き込みを繰り返さないでください。--note で承認者に理由を伝えられます。リクエストが中断された場合は、同じコマンドを再実行すると保存済みの冪等性キーが再利用されます。

スクリーンフォルダーの名前を変更する、中身ごと移動する、またはデフォルトプレイリストを設定・解除します。

screen folder update <id> [--name NAME] [--parent ID | --root] [--default-playlist-id ID | --clear-default] [--expect-rev REVISION] [--note TEXT]
screen folder update <id> --unprotect [--expect-rev REVISION] [--note TEXT]

--name、--parent、--root、--default-playlist-id、--clear-default、--unprotect のうち少なくとも 1 つを指定してください。

screenrig screen folder update sfd_01EXAMPLEFOLDER000000000 --name "Northern"
screenrig screen folder update sfd_01EXAMPLEFOLDER000000000 --root
screenrig screen folder update sfd_01EXAMPLEFOLDER000000000 --default-playlist-id pl_01EXAMPLEPLAYLIST000000 --expect-rev 3
screenrig screen folder update sfd_01EXAMPLEFOLDER000000000 --clear-default
screenrig screen folder update sfd_01EXAMPLEFOLDER000000000 --unprotect --note "Menu boards move next week"

フォルダーは自分自身やその内側のフォルダーには移動できません。同じ値の指定は何も変更しません。移動またはデフォルトの変更により、中のスクリーンは約 15 秒以内に再評価され、data.levels に、それらのスクリーンが入った、または外れたフォルダー対象のキャンペーン（source campaign）と、得た、または失ったフォルダーのデフォルトプレイリスト（source folder）が一覧されます。

保護されたフォルダーでも名前の変更はすぐに反映されます。保護されたフォルダー、またはそれを含むフォルダーの移動やデフォルトプレイリストの変更は pending_review を返し、protected_change レビューが作られ、2 人目の承認者が決定します（あなた以外で、あなたが代理する人以外の承認者。そうでない場合は second_approver_required、終了コード 3）。それまで何も変わらないため、書き込みを繰り返さないでください。--note で承認者に理由を伝えられます。承認できる人がダッシュボードでフォルダーを保護します。CLI は --unprotect で保護の解除を提案できるだけです。保護されたフォルダーを参照してください。スクリーンフォルダーに限定された呼び出し元は、自分のスコープ内のフォルダーのみ変更でき、移動先もスコープ内の親に限られます（outside_screen_scope、終了コード 3）。スコープが名指しするフォルダーの保護は変更できません。

スクリーンフォルダーを削除します。中のスクリーンとフォルダーは 1 階層上に移ります。

screen folder delete <id> [--expect-rev REVISION] [--note TEXT]

screenrig screen folder delete sfd_01EXAMPLEFOLDER000000000
screenrig screen folder delete sfd_01EXAMPLEFOLDER000000000 --expect-rev 3

フォルダーだけを削除します。中のスクリーンとフォルダーは親フォルダー（親がない場合はプロジェクトのルート）に移り、それらのスクリーンはプレイリストを再評価します。data は id、deleted true、および levels（移動したスクリーンが得た、または失ったキャンペーンとフォルダーのデフォルトプレイリスト。キャンペーンには reach_before と reach_after も付きます）です。フォルダーを対象に指定しているキャンペーンがあると、削除は resource_conflict（終了コード 5）で拒否されます。先にそれらのキャンペーンを変更または削除してください。

スクリーンフォルダーに限定された呼び出し元は、自分のスコープ内のフォルダーのみ削除でき、スコープが名指しするフォルダーは削除できません（outside_screen_scope、終了コード 3）。保護されたフォルダー、またはそれを含むフォルダーは pending_review を返し、protected_change レビューが作られます。2 人目の承認者が決定するため、書き込みを繰り返さないでください。--note で承認者に理由を伝えられます。