|
|
inviato il 30 Aprile 2026 ore 18:46
Si, nel tab log. Se fa solo il filtro allora non fa quello che intendevo io. Intendevo proprio escludere la scrittura, oltre che del DEBUG anche dell' INFO. Magari da mettere nel tab configurazione anche quello |
|
|
inviato il 30 Aprile 2026 ore 18:55
Concordo, se si cominciano a fare elaborazioni pesanti conviene poter sfoltire più possibile cicli di elaborazione "di debug" o relativi a eventi puramente informativi. In quel caso warning ed errori, lato log, sono più che sufficienti.
E se posso anche azzardarmi a suggerire, verificherei e migliorerei anche le tracciature in tutti i metodi e funzioni che _non_ prevedono di farlo ma invece _dovrebbero_ ...
Intendo: ok il "pass" dove è funzionale (so cosa succede E me ne posso fregare dell'errore gestendolo), ma se c'è un pass che mi termina invece in una eccezione non tracciata, che fa chiudere l'applicativo con messaggio generico a console, che non fa emergere il reale problema, allora non va bene.
Mi è capitato diverse volte nel frangente che abbiamo discusso in canale privato Michele: prendevo schianti vari a livello di main, presumibilmente per shortage vari di memoria vram (troppi modelli infilati nella GPU e chiamati insieme), ma tutto ciò che succedeva era il messaggio dell'errore nel main nella console, dopo che si era chiusa la finestra del programma.
Un'altra cosa a cui pensare sarebbe scrivere comunque almeno gli errori in un log testuale su disco (se non addirittura anche gli warning) anche in caso se ne faccia il "pass": in tal modo, anche in caso di chiusura anormale finale nel ramo di elaborazione, si avrebbe uno stralcio di log cui appigliarsi per l'analisi e/o la soluzione del problema.
Pensieri sparsi di un sistemista nato programmatore. 
Buon primo maggio a tutti per domani!  |
|
|
inviato il 30 Aprile 2026 ore 19:48
ok aggiornate statistiche e controllo log in config.
esplorate un po, dovrebbe essere tutto a posto adesso.
con lo switch in config 'OFF', vengono zittiti i messaggi minori dei warning e da warning in su , vengono scritti su un file di log nella directory /Logs con la data del giorno.
Con l'occasione sto facendo rivedere a Mr. Claude TUTTI i punti critici e non , dove non sono ancora 'protetti' dai try e riorganizzando i log, modificando anche il livello in alcuni. Appena pronto faccio un push e vi informo.
...accipicchia, divora token come un frullatore... 
ok fatto:
commit a482bf3 — fix(robustness): logging completo su tutti i moduli
================================================================================
+---------------------+-------------------------------------------------------+
| Categoria | Intervento |
+---------------------+-------------------------------------------------------+
| VRAM fallback | Nuovo metodo _model_to_device() in |
| | embedding_generator.py: se .to(gpu) lancia OOM / |
| | RuntimeError VRAM, logga warning e riprova su CPU. |
| | Applicato a CLIP, DINOv2 e Aesthetic (erano gli |
| | unici senza questo meccanismo). |
+---------------------+-------------------------------------------------------+
| except: silenziosi | 30 bare except: convertiti in except Exception. |
| → loggati | Parsing triviali (shutter, rating, float) usano |
| | logger.debug(); errori operativi usano |
| | logger.warning(); crash modello usano |
| | logger.error(exc_info=True). |
+---------------------+-------------------------------------------------------+
| print() → logger | 5 print() in export_tab.py e main_window.py |
| | convertiti in logger.error(..., exc_info=True) — |
| | ora appaiono nel log su disco con traceback completo. |
+---------------------+-------------------------------------------------------+
| exc_info=True | Aggiunto agli outer catch di _init_clip, |
| | _init_dinov2, _init_aesthetic: il traceback completo |
| | finisce nel log file. |
+---------------------+-------------------------------------------------------+
| traceback.print_exc | Rimosso da xmp_manager_extended.py, sostituito con |
| | logger.error(..., exc_info=True). |
+---------------------+-------------------------------------------------------+
File modificati (10):
embedding_generator.py
raw_processor.py
xmp_manager_extended.py
gui/gallery_widgets.py
gui/gallery_tab.py
gui/export_tab.py
gui/main_window.py
gui/search_tab.py
db_manager_new.py
gui/splash_screen.py
Tutti i file compilano correttamente (py_compile su ciascuno). |
|
|
inviato il 01 Maggio 2026 ore 14:05
Ciao Michele, sono stato assente per una po' e sicuramente sono rimasto indietro...
Ho provato ad aggiornare la BETA e ricevo questo messaggio.
Avvio aggiornamento OffGallery BETA...
============================================================
OffGallery BETA - Aggiornamento automatico
============================================================
Versione installata : 519fe97
Controllo versione remota...
[ERRORE] Impossibile raggiungere GitHub. Verifica la connessione.
Premi INVIO per chiudere. |
|
|
inviato il 01 Maggio 2026 ore 14:52
ciao Ale.
adesso su beta ci sono solo i plugin e l'installer dei plugin.
puoi scaricare tutto dalla repo pubblica e poi scaricare i plugin per sicurezza, perche' in questi giorni non mi ricordo di averli modificati.
Inoltre, forse ti sei perso un aggiornamento da fare per chi ha archivi gia' scansionati con OffGallery. te lo mando con messaggio privato |
Che cosa ne pensi di questo argomento?
Vuoi dire la tua? Per partecipare alla discussione iscriviti a JuzaPhoto, è semplice e gratuito!
Non solo: iscrivendoti potrai creare una tua pagina personale, pubblicare foto, ricevere commenti e sfruttare tutte le funzionalità di JuzaPhoto.
Con oltre 259000 iscritti, c'è spazio per tutti, dal principiante al professionista. |
Metti la tua pubblicità su JuzaPhoto (info) |
JuzaPhoto contiene link affiliati Amazon ed Ebay e riceve una commissione in caso di acquisto attraverso link affiliati.
