Cantieri aperti - Cronologia

WikiBot: handoff automatico

2026-08-16T14:34:37Z

handoff automatico

Mostra modifiche

WikiBot: handoff automatico

2026-08-16T14:01:38Z

handoff automatico

Mostra modifiche

WikiBot: handoff automatico

2026-08-16T13:48:56Z

handoff automatico

Mostra modifiche

WikiBot: handoff automatico

2026-08-16T13:34:35Z

handoff automatico

← Versione meno recente		Versione delle 13:34, 16 ago 2026
Riga 8:		Riga 8:
	== Cantieri attivi ==		== Cantieri attivi ==
	=== video-proxy-pipeline ===		=== video-proxy-pipeline ===
	''Aggiornato 2026-08-16 13:03 UTC'' — dominio: video / infrastruttura		''Aggiornato 2026-08-16 13:34 UTC'' — dominio: video / infrastruttura

	; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload su Storage Box + Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo		; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload su Storage Box + Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo
Riga 49:		Riga 49:
	* Marco valuta secondo PC.		* Marco valuta secondo PC.
	* v3.8 ATTIVA (terzo push riuscito, proxy->StorageBox da ora). v3.9 PUBBLICATA (sha 26e7b459): ANTI-STANDBY Windows via SetThreadExecutionState - il PC non va a riposo finche' l'agente e' aperto (schermo puo' spegnersi), elimina il rischio principale del PC-sempre-acceso. Strategia Marco confermata: priorita' INTENSO (~10TB recenti). Stima INTENSO: ~460h video 4K -> proxy ~410GB (sta nel 1TB attuale senza upgrade), audio ~10GB, ~27 giorni di lavoro a ritmo attuale.		* v3.8 ATTIVA (terzo push riuscito, proxy->StorageBox da ora). v3.9 PUBBLICATA (sha 26e7b459): ANTI-STANDBY Windows via SetThreadExecutionState - il PC non va a riposo finche' l'agente e' aperto (schermo puo' spegnersi), elimina il rischio principale del PC-sempre-acceso. Strategia Marco confermata: priorita' INTENSO (~10TB recenti). Stima INTENSO: ~460h video 4K -> proxy ~410GB (sta nel 1TB attuale senza upgrade), audio ~10GB, ~27 giorni di lavoro a ritmo attuale.
			* CENSIMENTO DRIVEUPLOADER COMPLETATO (richiesta Marco): 45 cartelle radice, 190 cartelle totali, 2668 video = 3.19TB su Drive isicnv, con md5 e path, in BQ isicnv_workflows.drive_video_census (script VM census_driveuploader.py, token root bucket NON tokens/). Incrocio col catasto: solo 39 match sui 2 dischi finora catastati (Maxtor) -> il grosso dei video Drive viene da dischi non ancora analizzati, come previsto da Marco. Vista permanente v_drive_vs_dischi: ogni NUOVO disco catastato si confronta da solo (match nome+size, md5 disponibile per verifiche forti). USO: prima di caricare/processare un disco si vede subito cosa esiste gia in cloud
			* i 3.19TB su Drive sono anche processabili DALLA VM senza disco fisico (opzione futura per proxy/trascrizioni di materiale non piu su disco).
	; 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 54:		Riga 56:
	* 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) ~~verificare~~ primi ~~'caricato su StorageBox' con~~ MB/s ~~da casa 2~~) svuotamento coda ~~proxy 3~~) cron trascrizioni autonomo 4) vision -> video_scenes 5) ~~upgrade BX21 solo se~~/~~quando la riga rossa lo dice~~		* 1) primi MB/s StorageBox (v3.8 attiva) e svuotamento coda 2) cron trascrizioni autonomo 3) vision -> video_scenes 4) opzione: processare i video Drive direttamente da VM (niente disco fisico) 5) ogni nuovo disco: query v_drive_vs_dischi per skip/conferme

	=== benchmark-visibilita-ai ===		=== benchmark-visibilita-ai ===

WikiBot: handoff automatico

2026-08-16T13:03:07Z

handoff automatico

← Versione meno recente		Versione delle 13:03, 16 ago 2026
Riga 8:		Riga 8:
	== Cantieri attivi ==		== Cantieri attivi ==
	=== video-proxy-pipeline ===		=== video-proxy-pipeline ===
	''Aggiornato 2026-08-16 13:01 UTC'' — dominio: video / infrastruttura		''Aggiornato 2026-08-16 13:03 UTC'' — dominio: video / infrastruttura

	; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload su Storage Box + Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo		; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload su Storage Box + Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo
Riga 48:		Riga 48:
	* MILESTONE: PRIME TRASCRIZIONI AUTOMATICHE end-to-end. 10 audio su Yandex (priorita v3.7 funziona), trascrivi_yandex manuale: ok=5 skip=5 err=0, lingue auto (IT/EN), 267 e 364 segmenti temporizzati, BQ trascrizioni_index +5. Il ciclo disco->proxy->audio->Yandex->Groq->testo+tempi->BQ e' VIVO. 24 miniature su Yandex. v3.8 in attesa del confine clip (clip 12/1437 gigante in corso, v3.7 batte regolare). Calcolo fattibilita consegnato: proxy 0.9GB/h video, scenari 1.7-4.5TB per 40TB, 3.5-10 mesi su 1 PC, box 1TB regge ~2 mesi poi BX21		* MILESTONE: PRIME TRASCRIZIONI AUTOMATICHE end-to-end. 10 audio su Yandex (priorita v3.7 funziona), trascrivi_yandex manuale: ok=5 skip=5 err=0, lingue auto (IT/EN), 267 e 364 segmenti temporizzati, BQ trascrizioni_index +5. Il ciclo disco->proxy->audio->Yandex->Groq->testo+tempi->BQ e' VIVO. 24 miniature su Yandex. v3.8 in attesa del confine clip (clip 12/1437 gigante in corso, v3.7 batte regolare). Calcolo fattibilita consegnato: proxy 0.9GB/h video, scenari 1.7-4.5TB per 40TB, 3.5-10 mesi su 1 PC, box 1TB regge ~2 mesi poi BX21
	* Marco valuta secondo PC.		* Marco valuta secondo PC.
			* v3.8 ATTIVA (terzo push riuscito, proxy->StorageBox da ora). v3.9 PUBBLICATA (sha 26e7b459): ANTI-STANDBY Windows via SetThreadExecutionState - il PC non va a riposo finche' l'agente e' aperto (schermo puo' spegnersi), elimina il rischio principale del PC-sempre-acceso. Strategia Marco confermata: priorita' INTENSO (~10TB recenti). Stima INTENSO: ~460h video 4K -> proxy ~410GB (sta nel 1TB attuale senza upgrade), audio ~10GB, ~27 giorni di lavoro a ritmo attuale.
	; 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 53:		Riga 54:
	* 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) verificare ~~v3.8 attiva +~~ primi 'caricato su StorageBox' con MB/s ~~reali~~ 2) svuotamento coda ~~149~~ proxy 3) cron trascrizioni autonomo ~~ogni 6h~~ 4) vision -> video_scenes ~~(classificare thumb con AI Gateway, demo detection)~~ 5) ~~eventuale secondo PC~~ quando ~~Marco decide~~		* 1) verificare primi 'caricato su StorageBox' con MB/s da casa 2) svuotamento coda proxy 3) cron trascrizioni autonomo 4) vision -> video_scenes 5) upgrade BX21 solo se/quando la riga rossa lo dice

	=== benchmark-visibilita-ai ===		=== benchmark-visibilita-ai ===

WikiBot: handoff automatico

2026-08-16T13:01:36Z

handoff automatico

← Versione meno recente		Versione delle 13:01, 16 ago 2026
Riga 8:		Riga 8:
	== Cantieri attivi ==		== Cantieri attivi ==
	=== video-proxy-pipeline ===		=== video-proxy-pipeline ===
	''Aggiornato 2026-08-16 12:40 UTC'' — dominio: video / infrastruttura		''Aggiornato 2026-08-16 13:01 UTC'' — dominio: video / infrastruttura

	; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload su Storage Box + Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo		; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload su Storage Box + Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo
Riga 46:		Riga 46:
	* i proxy sono comunque rigenerabili dagli originali (dati derivati, non preziosi)		* i proxy sono comunque rigenerabili dagli originali (dati derivati, non preziosi)
	* lo script VM spinge backup VERSO la box, non fa immagini della box. Dashboard: aggiunta riga 'Storage Box (proxy + backup): usati X su 1TB' con allarme rosso a 78% e nota upgrade BX21 (fix parsing df: shell ristretta box a volte ignora il pipe tail, ora si parsa l'ultima riga non-header). Verificata pubblica: 7.1G/1TB (1%). Agente ancora v3.7 su clip lunga: v3.8 attesa al prossimo confine clip.		* lo script VM spinge backup VERSO la box, non fa immagini della box. Dashboard: aggiunta riga 'Storage Box (proxy + backup): usati X su 1TB' con allarme rosso a 78% e nota upgrade BX21 (fix parsing df: shell ristretta box a volte ignora il pipe tail, ora si parsa l'ultima riga non-header). Verificata pubblica: 7.1G/1TB (1%). Agente ancora v3.7 su clip lunga: v3.8 attesa al prossimo confine clip.
			* MILESTONE: PRIME TRASCRIZIONI AUTOMATICHE end-to-end. 10 audio su Yandex (priorita v3.7 funziona), trascrivi_yandex manuale: ok=5 skip=5 err=0, lingue auto (IT/EN), 267 e 364 segmenti temporizzati, BQ trascrizioni_index +5. Il ciclo disco->proxy->audio->Yandex->Groq->testo+tempi->BQ e' VIVO. 24 miniature su Yandex. v3.8 in attesa del confine clip (clip 12/1437 gigante in corso, v3.7 batte regolare). Calcolo fattibilita consegnato: proxy 0.9GB/h video, scenari 1.7-4.5TB per 40TB, 3.5-10 mesi su 1 PC, box 1TB regge ~2 mesi poi BX21
			* Marco valuta secondo PC.
	; 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 51:		Riga 53:
	* 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) verificare ~~arrivo~~ v3.8 e primi 'caricato su StorageBox' con MB/s 2) svuotamento coda proxy ~~(151 in attesa)~~ 3) trascrizioni ~~al primo audio~~ 4) vision -> video_scenes 5) ~~monitor box su dashboard gia' attivo~~		* 1) verificare v3.8 attiva + primi 'caricato su StorageBox' con MB/s reali 2) svuotamento coda 149 proxy 3) cron trascrizioni autonomo ogni 6h 4) vision -> video_scenes (classificare thumb con AI Gateway, demo detection) 5) eventuale secondo PC quando Marco decide

	=== benchmark-visibilita-ai ===		=== benchmark-visibilita-ai ===

WikiBot: handoff automatico

2026-08-16T12:40:11Z

handoff automatico

← Versione meno recente		Versione delle 12:40, 16 ago 2026
Riga 8:		Riga 8:
	== Cantieri attivi ==		== Cantieri attivi ==
	=== video-proxy-pipeline ===		=== video-proxy-pipeline ===
	''Aggiornato 2026-08-16 12:32 UTC'' — dominio: video / infrastruttura		''Aggiornato 2026-08-16 12:40 UTC'' — dominio: video / infrastruttura

	; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo		; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload su Storage Box + Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo
	; Vincoli in vigore :		; Vincoli in vigore :
	* i 40TB non si muovono mai, solo proxy		* i 40TB non si muovono mai, solo proxy
Riga 42:		Riga 42:
	* STORAGE BOX ESISTENTE TROVATA (Marco aveva ragione): u649132.your-storagebox.de, BX11 1TB usata 7GB (backup CC/BQ, cron storagebox_backup.py). NIENTE UPGRADE ORA: 1TB copre mesi (proxy totali stimati 1.6TB a fine 40TB)		* STORAGE BOX ESISTENTE TROVATA (Marco aveva ragione): u649132.your-storagebox.de, BX11 1TB usata 7GB (backup CC/BQ, cron storagebox_backup.py). NIENTE UPGRADE ORA: 1TB copre mesi (proxy totali stimati 1.6TB a fine 40TB)
	* upgrade BX21 con un click quando serve. Setup: chiave dedicata sb_agent_ed25519 generata su VM e autorizzata sulla box (separata dalla chiave backup), cartella isicnv_proxy creata, test scp reale 30MB in 2s (15MB/s). Creds agente su https://wiki.marcoparet.com/agent/k_sb_7hq4x9m2vt.json + GCS tokens/tokens-storagebox-agent.json. v3.8 PUBBLICATA: PROXY -> Storage Box via scp Windows OpenSSH (mkdir -p remoto con cache, quoting spazi testato sui path RUSSIA TORINO, ACL icacls sulla chiave, timeout by-size, fallback Yandex se scp assente), audio+thumb restano su Yandex (trascrittore gia' li'). encoder BQ scp-sb vs webdav.		* upgrade BX21 con un click quando serve. Setup: chiave dedicata sb_agent_ed25519 generata su VM e autorizzata sulla box (separata dalla chiave backup), cartella isicnv_proxy creata, test scp reale 30MB in 2s (15MB/s). Creds agente su https://wiki.marcoparet.com/agent/k_sb_7hq4x9m2vt.json + GCS tokens/tokens-storagebox-agent.json. v3.8 PUBBLICATA: PROXY -> Storage Box via scp Windows OpenSSH (mkdir -p remoto con cache, quoting spazi testato sui path RUSSIA TORINO, ACL icacls sulla chiave, timeout by-size, fallback Yandex se scp assente), audio+thumb restano su Yandex (trascrittore gia' li'). encoder BQ scp-sb vs webdav.
			* Chiarito tema snapshot/backup-del-backup: snapshot Hetzner sono copy-on-write - i proxy write-once costano ~0 byte negli snapshot
			* costo solo su modifiche/cancellazioni future
			* i proxy sono comunque rigenerabili dagli originali (dati derivati, non preziosi)
			* lo script VM spinge backup VERSO la box, non fa immagini della box. Dashboard: aggiunta riga 'Storage Box (proxy + backup): usati X su 1TB' con allarme rosso a 78% e nota upgrade BX21 (fix parsing df: shell ristretta box a volte ignora il pipe tail, ora si parsa l'ultima riga non-header). Verificata pubblica: 7.1G/1TB (1%). Agente ancora v3.7 su clip lunga: v3.8 attesa al prossimo confine clip.
	; 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 47:		Riga 51:
	* 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) v3.8 ~~si installa da sola (push) -> verificare~~ primi 'caricato su StorageBox' con MB/s ~~nel log remoto e~~ svuotamento coda proxy 2) ~~monitorare spazio box dal battito, avvisare Marco per upgrade BX21 verso 800GB usati~~ 3) trascrizioni al primo audio ~~Yandex~~ 4) vision -> video_scenes 5) ~~Fase 2: media server monta la~~ box ~~(stessa rete Hetzner)~~		* 1) verificare arrivo v3.8 e primi 'caricato su StorageBox' con MB/s 2) svuotamento coda proxy (151 in attesa) 3) trascrizioni al primo audio 4) vision -> video_scenes 5) monitor box su dashboard gia' attivo

	=== benchmark-visibilita-ai ===		=== benchmark-visibilita-ai ===

WikiBot: handoff automatico

2026-08-16T12:32:26Z

handoff automatico

← Versione meno recente		Versione delle 12:32, 16 ago 2026
Riga 8:		Riga 8:
	== Cantieri attivi ==		== Cantieri attivi ==
	=== video-proxy-pipeline ===		=== video-proxy-pipeline ===
	''Aggiornato 2026-08-16 09:14 UTC'' — dominio: video / infrastruttura		''Aggiornato 2026-08-16 12:32 UTC'' — dominio: video / infrastruttura

	; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo		; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo
Riga 40:		Riga 40:
	* (2) FILTRO FILE FANTASMA: scan_videos salta ._* (AppleDouble macOS, causavano ERRORE transcodifica su Maxtor) e file <64KB. Include tutte le migliorie v3.5 (dedup ENQ, rilascio chiavi, skipped auto-dimenticato = plug-and-play). Dashboard rigenerata OK 101.		* (2) FILTRO FILE FANTASMA: scan_videos salta ._* (AppleDouble macOS, causavano ERRORE transcodifica su Maxtor) e file <64KB. Include tutte le migliorie v3.5 (dedup ENQ, rilascio chiavi, skipped auto-dimenticato = plug-and-play). Dashboard rigenerata OK 101.
	* PUSH VERIFICATO FUNZIONANTE: agente auto-aggiornato v3.4->v3.6 nella notte senza mani. Avanzamento 16/08: INTENSO 72/1526 (4.7%), Maxtor 119/2944 (4%), ~50 clip/notte. PROBLEMA APERTO: upload Yandex ancora in read-timeout anche con timeout 3600s (289 in coda, solo 4 proxy passati) - non e' questione di timeout ma di banda/WebDAV. v3.7 PUBBLICATA (sha in wiki): coda upload a PRIORITA by-size (audio e thumb passano davanti ai proxy -> trascrizioni e strato semantico fluiscono anche se i proxy arrancano) + METRICHE velocita (MB/s e durata su ogni successo/fallimento nel log remoto, e nell'ultimo errore heartbeat). Assert passati (priorita, dedup, rilascio).		* PUSH VERIFICATO FUNZIONANTE: agente auto-aggiornato v3.4->v3.6 nella notte senza mani. Avanzamento 16/08: INTENSO 72/1526 (4.7%), Maxtor 119/2944 (4%), ~50 clip/notte. PROBLEMA APERTO: upload Yandex ancora in read-timeout anche con timeout 3600s (289 in coda, solo 4 proxy passati) - non e' questione di timeout ma di banda/WebDAV. v3.7 PUBBLICATA (sha in wiki): coda upload a PRIORITA by-size (audio e thumb passano davanti ai proxy -> trascrizioni e strato semantico fluiscono anche se i proxy arrancano) + METRICHE velocita (MB/s e durata su ogni successo/fallimento nel log remoto, e nell'ultimo errore heartbeat). Assert passati (priorita, dedup, rilascio).
			* STORAGE BOX ESISTENTE TROVATA (Marco aveva ragione): u649132.your-storagebox.de, BX11 1TB usata 7GB (backup CC/BQ, cron storagebox_backup.py). NIENTE UPGRADE ORA: 1TB copre mesi (proxy totali stimati 1.6TB a fine 40TB)
			* upgrade BX21 con un click quando serve. Setup: chiave dedicata sb_agent_ed25519 generata su VM e autorizzata sulla box (separata dalla chiave backup), cartella isicnv_proxy creata, test scp reale 30MB in 2s (15MB/s). Creds agente su https://wiki.marcoparet.com/agent/k_sb_7hq4x9m2vt.json + GCS tokens/tokens-storagebox-agent.json. v3.8 PUBBLICATA: PROXY -> Storage Box via scp Windows OpenSSH (mkdir -p remoto con cache, quoting spazi testato sui path RUSSIA TORINO, ACL icacls sulla chiave, timeout by-size, fallback Yandex se scp assente), audio+thumb restano su Yandex (trascrittore gia' li'). encoder BQ scp-sb vs webdav.
	; 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 45:		Riga 47:
	* 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) ~~leggere le metriche MB/s dai primi upload~~ v3.~~7 per diagnosi definitiva banda vs Yandex 2~~) ~~se anche i file piccoli falliscono~~ -> ~~passare da WebDAV a API REST Yandex (upload href) o valutare Hetzner Storage Box (gia in orizzonte~~) 3) al primo audio su Yandex ~~partono le trascrizioni~~ 4) vision -> video_scenes		* 1) v3.8 si installa da sola (push) -> verificare primi 'caricato su StorageBox' con MB/s nel log remoto e svuotamento coda proxy 2) monitorare spazio box dal battito, avvisare Marco per upgrade BX21 verso 800GB usati 3) trascrizioni al primo audio Yandex 4) vision -> video_scenes 5) Fase 2: media server monta la box (stessa rete Hetzner)

	=== benchmark-visibilita-ai ===		=== benchmark-visibilita-ai ===

WikiBot: handoff automatico

2026-08-16T09:14:16Z

handoff automatico

← Versione meno recente		Versione delle 09:14, 16 ago 2026
Riga 8:		Riga 8:
	== Cantieri attivi ==		== Cantieri attivi ==
	=== video-proxy-pipeline ===		=== video-proxy-pipeline ===
	''Aggiornato 2026-08-~~15 18~~:44 UTC'' — dominio: video / infrastruttura		''Aggiornato 2026-08-16 09:14 UTC'' — dominio: video / infrastruttura

	; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo		; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo
Riga 39:		Riga 39:
	* v3.6 PUBBLICATA (sha 1aad55e7, supera v3.5 mai installata - l'agente v3.4 in esecuzione su Maxtor salta direttamente a v3.6 al confine clip): (1) LOG REMOTO: ogni riga log() bufferizzata e spedita a BQ isicnv_workflows.agent_log col battito ogni 5 min (sanificata, testata con INSERT reale), visibile a Claude via BQ e sulla dashboard (sezione 'Ultime righe di log')		* v3.6 PUBBLICATA (sha 1aad55e7, supera v3.5 mai installata - l'agente v3.4 in esecuzione su Maxtor salta direttamente a v3.6 al confine clip): (1) LOG REMOTO: ogni riga log() bufferizzata e spedita a BQ isicnv_workflows.agent_log col battito ogni 5 min (sanificata, testata con INSERT reale), visibile a Claude via BQ e sulla dashboard (sezione 'Ultime righe di log')
	* (2) FILTRO FILE FANTASMA: scan_videos salta ._* (AppleDouble macOS, causavano ERRORE transcodifica su Maxtor) e file <64KB. Include tutte le migliorie v3.5 (dedup ENQ, rilascio chiavi, skipped auto-dimenticato = plug-and-play). Dashboard rigenerata OK 101.		* (2) FILTRO FILE FANTASMA: scan_videos salta ._* (AppleDouble macOS, causavano ERRORE transcodifica su Maxtor) e file <64KB. Include tutte le migliorie v3.5 (dedup ENQ, rilascio chiavi, skipped auto-dimenticato = plug-and-play). Dashboard rigenerata OK 101.
			* PUSH VERIFICATO FUNZIONANTE: agente auto-aggiornato v3.4->v3.6 nella notte senza mani. Avanzamento 16/08: INTENSO 72/1526 (4.7%), Maxtor 119/2944 (4%), ~50 clip/notte. PROBLEMA APERTO: upload Yandex ancora in read-timeout anche con timeout 3600s (289 in coda, solo 4 proxy passati) - non e' questione di timeout ma di banda/WebDAV. v3.7 PUBBLICATA (sha in wiki): coda upload a PRIORITA by-size (audio e thumb passano davanti ai proxy -> trascrizioni e strato semantico fluiscono anche se i proxy arrancano) + METRICHE velocita (MB/s e durata su ogni successo/fallimento nel log remoto, e nell'ultimo errore heartbeat). Assert passati (priorita, dedup, rilascio).
	; 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 44:		Riga 45:
	* 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) ~~verificare primo push riuscito (battito~~ v3.~~6) e agent_log popolato~~ 2) ~~verificare~~ upload ~~proxy su Yandex col timeout dinamico~~ 3) ~~trascrizioni~~ al primo audio 4) vision -> video_scenes ~~5) demo detection~~		* 1) leggere le metriche MB/s dai primi upload v3.7 per diagnosi definitiva banda vs Yandex 2) se anche i file piccoli falliscono -> passare da WebDAV a API REST Yandex (upload href) o valutare Hetzner Storage Box (gia in orizzonte) 3) al primo audio su Yandex partono le trascrizioni 4) vision -> video_scenes

	=== benchmark-visibilita-ai ===		=== benchmark-visibilita-ai ===

WikiBot: handoff automatico

2026-08-15T18:44:35Z

handoff automatico

← Versione meno recente		Versione delle 18:44, 15 ago 2026
Riga 8:		Riga 8:
	== Cantieri attivi ==		== Cantieri attivi ==
	=== video-proxy-pipeline ===		=== video-proxy-pipeline ===
	''Aggiornato 2026-08-15 18:41 UTC'' — dominio: video / infrastruttura		''Aggiornato 2026-08-15 18:44 UTC'' — dominio: video / infrastruttura

	; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo		; Obiettivo : Fase 1: proxy 1080p dei 40TB con upload Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo
Riga 37:		Riga 37:
	* ora dinamico 600-3600s in base alla size), errori upload VISIBILI (contatore+ultimo errore nel heartbeat con colonne up_err/last_err via ALTER, riga upload_err in tracking alla prima occorrenza per clip), check aggiornamenti anche AL CONFINE TRA CLIP (senno mai idle su dischi da 450h e il push non scattava mai), GUARDIA disco staccato (stop pulito, clip error ritentate al ricollegamento - verificato: pending esclude solo status done). Dashboard aggiornata con riga rossa errori upload. NOTA: v3.3 in esecuzione si aggiorna solo da idle: lo swap dischi di Marco (chiudi-riapri contestuale) carica v3.4.		* ora dinamico 600-3600s in base alla size), errori upload VISIBILI (contatore+ultimo errore nel heartbeat con colonne up_err/last_err via ALTER, riga upload_err in tracking alla prima occorrenza per clip), check aggiornamenti anche AL CONFINE TRA CLIP (senno mai idle su dischi da 450h e il push non scattava mai), GUARDIA disco staccato (stop pulito, clip error ritentate al ricollegamento - verificato: pending esclude solo status done). Dashboard aggiornata con riga rossa errori upload. NOTA: v3.3 in esecuzione si aggiorna solo da idle: lo swap dischi di Marco (chiudi-riapri contestuale) carica v3.4.
	* v3.4 CONFERMATA VIVA post-swap (battiti regolari con clip corrente, fix heartbeat funziona). v3.5 PUBBLICATA (sha f4da4f50) - PLUG-AND-PLAY COMPLETO: (1) set ENQ anti-duplicati sulle code (le ri-scansioni ogni 30s duplicavano gli item non ancora caricati), (2) rilascio chiave su file mancante cosi al ricollegamento il backlog riaccoda, (3) skipped &= drives: un disco che dava errore veniva ignorato per sempre fino al riavvio, ora l'estrazione cancella l'errore e il reinserimento riparte pulito. 4 assert passati. E' il PRIMO deploy push reale: v3.4 la carichera al confine della prossima clip.		* v3.4 CONFERMATA VIVA post-swap (battiti regolari con clip corrente, fix heartbeat funziona). v3.5 PUBBLICATA (sha f4da4f50) - PLUG-AND-PLAY COMPLETO: (1) set ENQ anti-duplicati sulle code (le ri-scansioni ogni 30s duplicavano gli item non ancora caricati), (2) rilascio chiave su file mancante cosi al ricollegamento il backlog riaccoda, (3) skipped &= drives: un disco che dava errore veniva ignorato per sempre fino al riavvio, ora l'estrazione cancella l'errore e il reinserimento riparte pulito. 4 assert passati. E' il PRIMO deploy push reale: v3.4 la carichera al confine della prossima clip.
			* v3.6 PUBBLICATA (sha 1aad55e7, supera v3.5 mai installata - l'agente v3.4 in esecuzione su Maxtor salta direttamente a v3.6 al confine clip): (1) LOG REMOTO: ogni riga log() bufferizzata e spedita a BQ isicnv_workflows.agent_log col battito ogni 5 min (sanificata, testata con INSERT reale), visibile a Claude via BQ e sulla dashboard (sezione 'Ultime righe di log')
			* (2) FILTRO FILE FANTASMA: scan_videos salta ._* (AppleDouble macOS, causavano ERRORE transcodifica su Maxtor) e file <64KB. Include tutte le migliorie v3.5 (dedup ENQ, rilascio chiavi, skipped auto-dimenticato = plug-and-play). Dashboard rigenerata OK 101.
	; 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 42:		Riga 44:
	* 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) verificare ~~heartbeat v3.5 (~~primo push riuscito) 2) verificare upload ~~INTENSO~~ su Yandex col timeout dinamico ~~(stamattina 0 caricati)~~ 3) trascrizioni al primo audio 4) vision -> video_scenes 5) demo detection		* 1) verificare primo push riuscito (battito v3.6) e agent_log popolato 2) verificare upload proxy su Yandex col timeout dinamico 3) trascrizioni al primo audio 4) vision -> video_scenes 5) demo detection

	=== benchmark-visibilita-ai ===		=== benchmark-visibilita-ai ===