Documentazione

Collegamenti flotta: comandi CLI

Crea collegamenti flotta per i gestori di dispositivi e sposta media, playlist, programmazioni e schermi di un’altra piattaforma di signage in screenRIG.

Ogni comando funziona come descritto nel riferimento CLI: flag globali, output JSON, codici uscita, revisioni e ritentativi.

Migrate

migrate sposta nel progetto i media, le playlist, i layout, le programmazioni e gli schermi della tua precedente piattaforma di signage. Viene eseguito nella CLI sul tuo computer: la chiave della piattaforma viene letta da un --credentials FILE di righe NAME=VALUE, va solo a quella piattaforma e non viene mai memorizzata, stampata, registrata nel log né inviata a screenRIG, che vede soltanto normali scritture di media, playlist, collegamenti alla flotta, campagne e schermi. migrate vendors elenca le piattaforme che legge, e l’alternativa files legge una cartella o un .zip di media da qualsiasi altra piattaforma.

Esegui i passaggi in ordine: migrate vendors (che cosa accetta una piattaforma), migrate scan (leggi l’account e riporta che cosa può e non può essere trasferito; non richiede alcun accesso a screenRIG), migrate apply --dry-run (il piano), migrate apply (richiede l’accesso Manage), poi migrate pair per ogni schermo.

--dir DIR è la directory di migrazione, ./screenrig-migration-VENDOR per impostazione predefinita, creata con permessi 0700. Contiene scan.json (la scansione e il suo report), map.json (quale oggetto è diventato ogni vecchio elemento, legato a questo URL API, progetto, fornitore e account di origine) e staging/ (i download in corso). apply e pair usano l’unica directory screenrig-migration-* nella directory di lavoro, oppure accettano --dir; in una directory se ne esegue uno alla volta.

Codice problemaEsciSignificato
migration_dir_mismatch2La directory è stata creata per un altro progetto, URL API, fornitore o account di origine. Usa un altro --dir.
vendor_refused3La piattaforma ha rifiutato la chiave. Crea una chiave di sola lettura (migrate vendors VENDOR mostra come), correggi il file --credentials ed esegui di nuovo lo stesso comando.
vendor_not_found4La piattaforma ha risposto 404. Di solito --url è sbagliato.
vendor_rate_limited7La piattaforma sta limitando la frequenza delle richieste della chiave. Esegui di nuovo il comando più tardi.
vendor_file_gone8L’indirizzo di un file media è scaduto o è protetto. Eseguire di nuovo migrate scan lo aggiorna, e --files fornisce un file che continua a fallire.
vendor_file_stalled8Un download di media non riceve più dati. Esegui di nuovo apply.
vendor_bad_response9La piattaforma ha inviato una risposta che la CLI non può usare.
vendor_unavailable9 o 10Non è stato possibile raggiungere la piattaforma, oppure continua a fallire.

migrate vendors#

Elenca le piattaforme che migrate legge, che cosa accetta ciascuna e come creare la sua chiave di sola lettura.

migrate vendors [VENDOR]
ParametroTipoObbligatorioPredefinitoNote
VENDORstringnoogni piattaformaL’id di una piattaforma. Un id che non elenca è usage_error (exit 2) e indica gli id esistenti.
screenrig migrate vendors
screenrig migrate vendors files

Funziona offline e non richiede alcun accesso. data.vendors contiene, per ogni piattaforma, id e name; inputs, con i flags che accetta (ciascuno con flag e required, e values per una regione) e le righe credentials che il suo file chiave contiene (name, secret, required e help); connect, i passaggi per creare una chiave di sola lettura; maps, ciò che viene trasferito; skips, ciò che non viene trasferito; docs; e example, un comando migrate scan funzionante. Le piattaforme sono ordinate per id con files per ultimo. files accetta una cartella o un .zip e un fuso orario facoltativo, e non richiede alcuna chiave.

migrate scan#

Leggi un account di signage e riporta che cosa può e che cosa non può essere trasferito. Scrive scan.json e non invia nulla a screenRIG.

migrate scan --from VENDOR [--url ADDRESS] [--region REGION] [--timezone ZONE] [--files PATH]
    [--credentials FILE] [--dir DIR]
ParametroTipoObbligatorioPredefinitoNote
--from VENDORstringsìnessunoLa piattaforma da leggere: un id da migrate vendors, oppure files.
--url ADDRESSstringper piattaformanessunoL’indirizzo di una piattaforma self-hosted.
--region REGIONstringper piattaformanessunoLa regione di un account ospitato, per una piattaforma che ha regioni.
--timezone ZONEstringnonessunoUn nome di fuso orario IANA come America/Toronto, impostato su ogni schermo la cui vecchia piattaforma non ne indica nessuno. Senza di esso uno schermo segue la zona che il suo Player riporta.
--files PATHpathper piattaformanessunoUna cartella o un .zip. Con --from files contiene i media; con un’altra piattaforma contiene gli originali che l’API di quella piattaforma non può fornire, abbinati ai suoi media in base al nome file.
--credentials FILEpathper piattaformanessunoIl file chiave: righe NAME=VALUE con i nomi che migrate vendors VENDOR elenca. Le righe vuote e i commenti # vengono ignorati, e un valore può stare tra una coppia di virgolette. Un nome obbligatorio mancante nel file è usage_error (exit 2) che lo nomina.
--dir DIRpathno./screenrig-migration-VENDORLa directory di migrazione.
screenrig migrate scan --from files --files ./signage-media
screenrig migrate scan --from files --files ./signage-media.zip --dir ./old-signage --timezone America/Toronto

Un’opzione che la piattaforma non accetta, o una necessaria che manca, è usage_error (exit 2) e indica che cosa accetta la piattaforma. Nessuna opzione accetta la chiave stessa. Una nuova scansione sostituisce scan.json e conserva map.json, e termina con 0 quando si completa, anche se alcuni elementi non possono essere trasferiti.

data è il report: vendor, label, scanned_at, found e importable (conteggi di media, playlists, layouts, schedules, groups e screens), not_imported (ciascuno con kind, source_id, name, un reason e di solito un passaggio next), lossy (ciascuno con kind, source_id, name e il change che avviene lungo il percorso), notes, dir e scan_file. Un file che la piattaforma fornisce viene scaricato in apply. Un file che non fornisce, o che fornisce solo come copia ricodificata, viene abbinato per nome in --files; senza corrispondenza, o con più corrispondenze, si trova in not_imported o lossy con il passaggio che lo risolve.

--from files non richiede alcuna chiave. Legge ogni file immagine, video e audio in base al contenuto, non all’estensione. Un playlists.csv facoltativo nella radice ha le colonne playlist, file (un percorso o un nome file univoco), duration (secondi) e order; senza di esso ogni cartella che contiene media diventa una playlist in ordine naturale dei nomi file, e i file nella radice ne formano una che prende il nome della cartella o dello zip. Un screens.csv facoltativo ha name, group (più valori separati da ;), playlist e timezone, e ogni riga diventa uno schermo in attesa con i suoi gruppi come tag. Gli altri file e le voci zip cifrate sono in not_imported. Una scansione files non ha programmazioni: creale con campaign create quando le playlist esistono.

migrate apply#

Importa ciò che la scansione ha trovato: media, playlist e layout, schermi in attesa e campagne. Si può rieseguire senza rischi.

migrate apply [--dir DIR] [--dry-run] [--only KINDS] [--folder ID] [--canvas WIDTHxHEIGHT]
    [--credentials FILE] [--concurrency N] [--no-transcode]
ParametroTipoObbligatorioPredefinitoNote
--dir DIRpathnol’unica directory ./screenrig-migration-*La directory di migrazione che contiene scan.json.
--dry-runbooleannospentoLeggi il progetto e stampa il piano. Non scrive nulla e non richiede alcuna chiave.
--only KINDSstringnotutti e quattroSeparati da virgola, ciascuno al massimo una volta: media, playlists, screens, schedules.
--folder IDstringnouna nuova cartella chiamata Imported from più il nome della piattaformaUna cartella media esistente (mfd_…) per i media importati.
--canvas WIDTHxHEIGHTstringno1920x1080Il canvas delle playlist semplici, con ogni lato di almeno 16 pixel. Un layout mantiene le proprie dimensioni.
--credentials FILEpathnonessunoIl file chiave, letto solo quando un file media viene scaricato dalla piattaforma.
--concurrency Nintegerno4Media importati contemporaneamente, da 1 a 8.
--no-transcodebooleannospentoCarica i byte sorgente senza modificarli, come fa media upload.
screenrig migrate apply --dry-run
screenrig migrate apply --dir ./screenrig-migration-files
screenrig migrate apply --only media,playlists --concurrency 2

apply importa in quest’ordine: i media in una cartella, le playlist e i layout, uno schermo in attesa per ogni vecchio schermo e una campagna per ogni programmazione che le campagne sanno esprimere. Rilegge la piattaforma solo per scaricare i file media. Una playlist ha una pagina per elemento: immagini e video riempiono il canvas, un indirizzo web diventa una pagina iframe, l’audio diventa la traccia audio e una playlist annidata viene inclusa direttamente. Un layout diventa una playlist sul proprio canvas con una pagina per ogni elemento della sua zona principale. Una programmazione che si ripete per mese, anno, ora o minuto, o in un giorno della settimana numerato del mese, non può diventare una campagna: scan la elenca in not_imported.

--dry-run legge solo il progetto e risponde con data.plan (per media, playlists, layouts, screens e schedules: i conteggi create, reuse, recreate, waiting e fail), data.items, data.bytes da scaricare, i conteggi data.placeholders e data.project, i collegamenti alla flotta e le campagne in uso rispetto ai massimi di 50 e 100. L’avanzamento va su stderr come righe JSON (migrate_progress con phase, done e total), oppure come testo con --human. Una nuova esecuzione riutilizza ciò che esiste ancora, ricrea ciò che hai eliminato e non modifica mai ciò che ha creato. Un’esecuzione reale risponde con data.applied (gli stessi conteggi), data.waiting (elementi che attendono un media o una playlist non importati, ciascuno con un reason), data.failed, data.placeholders (una voce per ogni vecchio schermo con i suoi source_id, name e state: linked, unlinked, paired, finished o waiting), data.tags e data.folder_id.

Un gruppo diventa un tag composto da lettere e cifre, numerato quando coincide con un tag che porta un altro schermo. Una campagna ha come destinazione i tag dei gruppi e degli schermi che la sua programmazione nomina, con le sue date, i suoi giorni, le sue ore e la sua priorità. Una campagna legge le sue date e le sue ore nel fuso orario proprio di ogni schermo e richiede una playlist predefinita (no_default_playlist): scan segnala gli schermi che ne sono privi, e screen assign la imposta dopo l’associazione.

Uno schermo in attesa è un collegamento alla flotta di un solo schermo che porta il vecchio nome, i gruppi come tag e la playlist. Un’organizzazione ha al massimo 50 collegamenti alla flotta in tutti i suoi progetti; gli altri sono unlinked in data.placeholders e attendono un codice Player (migrate pair). Un Player che apre un collegamento diventa uno schermo, ed eseguire di nuovo apply gli assegna il vecchio nome e il fuso orario ed elimina il collegamento. apply non stampa mai l’URL di un collegamento alla flotta: fleet-links show sì.

Un elemento che fallisce conserva ok true con data.failed (ciascuno con key, name, code, status e detail) e l’avviso migration_items_failed; gli elementi che ne dipendono restano in attesa, e il codice di uscita segue lo stato dell’ultimo errore. Un file media che fallisce da solo (un indirizzo scaduto, una risposta che non è un file, un download che non riceve più dati) fallisce solo quel media; per un indirizzo scaduto esegui di nuovo migrate scan. Un rifiuto che si ripeterebbe per ogni elemento (quota_exceeded, campaign_limit_reached, insufficient_access, pending_review, la piattaforma che rifiuta la chiave, una connessione persa) termina l’esecuzione con data.stopped (code, detail e next) e con il codice di uscita di quel problema. Correggi la causa ed esegui di nuovo lo stesso comando: riprende da dove si era fermato.

migrate pair#

Associa un codice Player a uno schermo in attesa, con il suo vecchio nome, la playlist, il fuso orario e i tag.

migrate pair <CODE...> --screen ID_OR_NAME [--dir DIR]
ParametroTipoObbligatorioPredefinitoNote
<CODE...>stringsìnessunoIl codice mostrato dal Player, come ABC 234: sei caratteri tratti da 23456789ABCDEFGHJKMNPQRSTUVWXYZ, in maiuscolo o minuscolo. Spazi e trattini tra di essi vengono ignorati, quindi non servono virgolette.
--screen ID_OR_NAMEstringsìnessunoLo schermo in attesa: il suo id di origine o il suo vecchio nome esatto. Un nome condiviso da due schermi ne elenca gli id.
--dir DIRpathnol’unica directory ./screenrig-migration-*La directory di migrazione.
screenrig migrate pair ABC 234 --screen "Front desk"
screenrig migrate pair ABC234 --screen 3 --dir ./old-signage

Esegui prima migrate apply: l’associazione richiede la mappa e la playlist che ha creato. pair rivendica il codice per lo schermo con il suo vecchio nome, imposta la sua playlist, il fuso orario e il campo migrated_from, imposta i suoi tag, elimina il collegamento dello schermo in attesa e registra il risultato. data contiene source_id, name, screen_id, steps (paired, updated, tagged, link deleted, recorded), next e, quando questa esecuzione ha rivendicato il codice, public_url. Ogni passaggio viene registrato man mano che si compie, quindi una nuova esecuzione completa ciò che un pair interrotto ha lasciato. Uno schermo già associato è resource_conflict (exit 5) che lo nomina. Il Player completa l’associazione al successivo contatto con il servizio; screen show riporta poi state active.

Altri gruppi di comandi