⚙️ Diagnostica Server
🗄 DB Browser ⟳ Auto 30s
🟢 Node.js
Uptime processo
Heap usato
Heap totale
Utilizzo heap
RSS totale
📦 PM2
Stato
PID
Riavvii totali
In esecuzione da
CPU (monit)
RAM (monit)
🖥️ Sistema
Uptime OS
Piattaforma
CPU usata
RAM usata
RAM libera / tot.
Load avg 1m / 5m
💾 Disco /media
Spazio usato
Spazio libero
Totale partizione
Utilizzo disco
🗄️ Database MariaDB
Connessione
Players online ora
users
players
media_files
sessions
user_data
💽 Backup Database
Ultimo backup
Dimensione
Conservati
Spazio totale
Prossimo previsto
🔧 Manutenzione Player
Stato API /player/*
Scadenza
Blocca tutte le richieste dei player per 5 minuti — utile per testare il comportamento offline.
🔀 Git — vdjx-server
Ultimo commit
Hash
Data
Log (ultimi 15)
Modifiche non committate
🔀 Git — vdjx-tv-app
Ultimo commit
Hash
Data
Log (ultimi 15)
Modifiche non committate
📜
Caricamento log...
🛡️ Aggiornamenti OS (server)
SistemaVoid Linux
Kernel in esecuzione
Pacchetti aggiornabili
Aggiornamento kernel
Ultimo controllo
ⓘ Sola lettura. L'installazione degli aggiornamenti OS/sicurezza è a cura dell'IT manager (xbps-install -Su in finestra di manutenzione, con backup e reboot pianificato).
🧹 Manutenzione disco
Disco
📡 Rete
Oggi
Questo mese
Proiezione fine mese
Dati raccolti da
ⓘ Nessuna soglia di allarme impostata (limite del piano Linode non ancora specificato).
🔒 Certificato HTTPS
Dominio
Scade il
Giorni residui
Emesso il
Ultimo controllo di rinnovo
Esito
ⓘ Rinnovo automatico due volte al giorno (03:23 e 15:23) — /usr/local/sbin/vdjx-cert-renew.sh, log in /var/log/vdjx-cert-renew.log. Il certificato Let's Encrypt dura 90 giorni e il rinnovo parte quando ne restano meno di 30: sotto i 20 giorni qualcosa non sta funzionando.
Se scade, i player non riescono più a contattare il server (rifiutano un certificato non valido) e restano sui contenuti già in cache: gli schermi continuano a funzionare, ma nulla di nuovo arriva.
⏱️ Cadenze del sistema sola lettura
Player — daemon
Poll al server (programmazione)5 s
Controllo overlay LIVE5 s
Watchdog battito → riavvia Chromium2,5 min
Campionamento memoria (cron)10 min
Pulizia cache mediaa soglia spazio
vdjx-daemon.js
Player — pagina a schermo
/state (contenuto + stato + download)5 s
Battito verso il daemon30 s
Poll pairing (solo in abbinamento)3 s
Countdown pairing1 s
Scadenza codice pairing10 min
vdjx-daemon.js — pagine generate
Player — riproduzione
Riallineamento all'orologio (solo con sync)2 s
Guardia stallo video — controllo1 s
Guardia stallo — recupero a fine video2 s
Guardia stallo — recupero a metà video6 s
Guardia stallo — in attesa di dati30 s
portal/vdjx-player.js
Player — aggiornamenti OTA
Controllo manifest5 min
Timeout health-check90 s
rpi-config/vdjx-updater.js
Player — webapp
Controllo stato HDMI5 s
Push grabber (solo se attivo)1 s
rpi-config/webapp-server.js
Server
Cache meteo (TTL)10 min
Pausa dopo errore meteo5 min
Backup database03:30 · retention 14
Script firewall (cron sistema)5 min
Sincronizzazione NTP (chrony)~17 min
fail2ban: tentativi / finestra5 / 10 min → ban 1 h
vdjx-server.js · cron · /etc
Portale (nel browser)
Sync collezioni col server30 s
Stato player15 s
Refresh pagine di monitoraggio10 s
Anteprima compositore5 s
Orologi e countdown1 s
portal/*.html
Note
Il sync multi-player non ha un intervallo: ogni player calcola la posizione dall'orologio assoluto (adesso mod durata), quindi si allineano senza scambiarsi messaggi. La sincronizzazione NTP è ciò che tiene allineati gli orologi.
Battito e watchdog sono legati: il watchdog (2,5 min) deve restare almeno 4-5 volte il battito (30 s), altrimenti Chromium verrebbe riavviato per errore.
Attenzione al polling delle pagine: fino alla build 15 erano 3-4 cicli a 1,5 s con riscrittura del DOM a ogni giro, e costavano ~240 MB/ora di memoria per player. Non tornare a valori più frequenti né a scritture incondizionate.
La guardia stallo video controlla ogni secondo, ma è l'unica eccezione legittima al limite dei 5 s: non fa richieste HTTP e non scrive nel DOM, legge due proprietà del tag <video>. Le tre soglie di recupero non sono interscambiabili: 2 s a fine video (lì un tempo fermo non ha altra spiegazione), 6 s a metà con i fotogrammi già in buffer, 30 s quando il buffer è esaurito — perché in quel caso il video sta solo aspettando dati e riportarlo a zero farebbe danno.
📋 Backlog
Caricamento…