Cantieri aperti: differenze tra le versioni
| [versione verificata] | [versione verificata] |
handoff automatico |
handoff automatico |
||
| (2 versioni intermedie di uno stesso utente non sono mostrate) | |||
| Riga 8: | Riga 8: | ||
== Cantieri attivi == | == Cantieri attivi == | ||
=== video-proxy-pipeline === | === video-proxy-pipeline === | ||
''Aggiornato 2026-08-18 22: | ''Aggiornato 2026-08-18 22:23 UTC'' — dominio: video / infrastruttura | ||
; Obiettivo : Fase 1: proxy 1080p dei 40TB (locali, upload auto-adattivo) + significato su cloud; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; estrazione WeVideo | ; Obiettivo : Fase 1: proxy 1080p dei 40TB (locali, upload auto-adattivo) + significato su cloud; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; estrazione WeVideo | ||
| Riga 69: | Riga 69: | ||
* control.json azzerato. 2 assert (priorita aggiornamento su riavvio, errore visibile su PermissionError). NOTA: il .bat di avvio scarica sempre l'ultima versione -> un chiudi/riapri manuale porta comunque all'ultima. ERRORI TRANSCODIFICA MASSIVI su Maxtor (MTS e anche MP4 di altre cartelle, quindi NON e' il formato): sospetto forte DISCO PIENO | * control.json azzerato. 2 assert (priorita aggiornamento su riavvio, errore visibile su PermissionError). NOTA: il .bat di avvio scarica sempre l'ultima versione -> un chiudi/riapri manuale porta comunque all'ultima. ERRORI TRANSCODIFICA MASSIVI su Maxtor (MTS e anche MP4 di altre cartelle, quindi NON e' il formato): sospetto forte DISCO PIENO | ||
* la v4.6/4.7 mostra il motivo ffmpeg reale e dirotta i proxy su C: sotto i 25GB liberi. | * la v4.6/4.7 mostra il motivo ffmpeg reale e dirotta i proxy su C: sotto i 25GB liberi. | ||
* CAUSA ERRORI TRANSCODIFICA TROVATA (grazie a v4.7 in produzione + screenshot Marco): MAXTOR PIENO 0.0GB. Causa di design MIA: i proxy si scrivono in _proxy SULLO STESSO disco letto e non venivano mai cancellati (dovevano sparire dopo l'upload, ma gli upload erano fermi). Nessun dato di Marco toccato. Anche C: ha solo 23GB. Inoltre v4.7 ha mostrato il vero motivo del tachimetro fallito: la shell della Storage Box non digerisce le virgolette (scp: dest open: No such file or directory). v4.9 PUBBLICATA (sha b21b1525): (1) upload proxy via SFTP BATCH in una sola sessione - crea tutti i livelli con -mkdir (errori ignorati) e fa put, gestisce spazi nei path | |||
* PROVATO REALMENTE sulla box (cartella 'TEST SPAZI' creata + 8MB caricati) | |||
* (2) CLEANUP: proxy locale cancellato subito dopo upload riuscito -> il disco si libera da solo | |||
* (3) fallback proxy su C: gia con 15GB liberi. FUNZIONANTI in v4.7: esclusioni (891 video estranei saltati, 8.2GB), cartelle_dubbie (72 da confermare: videos/congres pavlina/ULTIMO GIORNO/OTHER 39, testimonial 8, recastly 5...), guardia spazio, allerte v4.8. Wi-Fi ora 866Mbps. | |||
* CAUSA ERRORI TRANSCODIFICA CONFERMATA dal log v4.7: 'spazio quasi esaurito (0.0GB sul disco)' - i proxy venivano scritti in _proxy SULLO STESSO disco letto e mai cancellati (dovevano esserlo dopo l'upload, ma gli upload erano fermi) -> Maxtor saturato. Nessun file di Marco toccato. Trovato anche il perche' upload/speedtest fallivano: la shell della Storage Box non digerisce mkdir con virgolette su path con spazi. v4.9+v5.0 PUBBLICATE (sha b21b1525 -> nuova): (1) upload via SFTP BATCH (una connessione: -mkdir per livello + put, spazi gestiti) - PROVATO SUL CAMPO dalla VM: cartella 'TEST SPAZI' creata e 8MB caricati | |||
* (2) PULIZIA proxy locale dopo upload riuscito (cleanup_after_upload) -> il disco si libera da solo | |||
* (3) REGOLA MARCO: in emergenza spazio la scala e' disco origine -> ALTRO DISCO ESTERNO collegato (>50GB, es. INTENSO) -> PC di Marco SOLO se tutti pieni, con allerta email | |||
* (4) sistema ALLERTE v4.8: agent_alerts BQ + email isicnv@gmail.com + flush log immediato su primo errore, 3/10/30 errori consecutivi, spazio esaurito, aggiornamento fallito, 5/25/100 upload falliti (anti-ripetizione 2h). Assert passati su tutto. Wi-Fi ora 866Mbps (5GHz). Saltati 891 video estranei (8.2GB) su Maxtor + 72 clip in 8 cartelle dubbie registrate. | |||
* INCIDENTE E RIPARAZIONE: mia sostituzione di codice in v4.9 aveva cancellato net_diag e speed_loop -> agente CRASH all'avvio (NameError, fermo ~40 min). v5.1 ripristino + ASSERT ANTI-REGRESSIONE ora in pipeline di deploy (AST: nessuna chiamata a funzione inesistente, blocca la pubblicazione). DECISIONI MARCO 19/08: (1) cartelle dubbie CONFERMATE TUTTE (72 su Maxtor: videos/congres pavlina, testimonial, recastly, ANEB/DORA, enneagramma PNL3, GOOGLE DRIVE, fotosequenze HANA) - si lavorano tutte, restano solo tracciate in BQ cartelle_dubbie | |||
* (2) REGOLA DI CANCELLAZIONE codificata: l'agente puo' rimuovere SOLO file creati da se' (proxy/audio/thumb) e SOLO se l'originale sul disco esiste ancora (sono rigenerabili=temporanei) | |||
* mai file utente, mai i registri manifest/uploaded/media.csv | |||
* (3) PRIORITA SPAZIO: disco origine -> altro disco esterno (INTENSO) -> PC di Marco solo ULTIMA RISORSA con email. v5.2 PUBBLICATA (sha 1a579beb) con libera_spazio() che pulisce Maxtor automaticamente sotto i 25GB liberi (target 45GB), assert stringenti superati (file con originale mancante NON toccato, registri intatti). | |||
; Provato ed escluso : | ; Provato ed escluso : | ||
* Storage Box Hetzner rimandato: nessun token API esiste e Marco preferisce Yandex gia pagato | * Storage Box Hetzner rimandato: nessun token API esiste e Marco preferisce Yandex gia pagato | ||
| Riga 74: | Riga 86: | ||
* la lentezza 1.1x della v2.4 era DOPPIA ISTANZA, non hardware | * la lentezza 1.1x della v2.4 era DOPPIA ISTANZA, non hardware | ||
; Prossimo passo : | ; Prossimo passo : | ||
* 1) | * 1) verificare v5.2 attiva, spazio liberato su Maxtor e ripresa transcodifiche 2) primo Test velocita via sftp (metodo verificato sulla box) -> possibile auto-attivazione proxy 3) allerte email al primo errore (v4.8+) 4) trascrizioni/vision | ||
=== harness-standard === | === harness-standard === | ||