Mi media center - Foro

... ne avevo già parlato e accennato in un'altro thread relativa a qualche versione fà............

La cosa non sembra creare problemi e sembra relativa alla prima procedura di avvio e alla procedura di aggiornamento dei canali/server.

Nel log compare questo: Questa cosa appare sia che sia attiva il "Wait for netword" in MyOSMC e sia senza........................
la procedura stessa degli aggiornamenti poi si completa ma non so se effettivamente qualcosa viene aggionato o meno............

Qualcuno ha mai notato problemi simili ?

Non ne sono sicuro, ma potrebbe essere che ci siano troppi thread aperti e raggiungiungendo il limite del Pi2 ti dia quell'errore (Come detto prima non ne sono sicuro).

Ciao,
tempo fa avevo fatto una modifica alla procedura di update per usare un pool di thread proprio per evitare questi problemi.
Quella modifica è stata tolta perchè ritenuta inutile.
@DjDiabolik se vuoi ti passo il file .py con questa modifica da sostituire in SOD per vedere se il problema rimane.

DrZ3r0 escribió:Ciao,
tempo fa avevo fatto una modifica alla procedura di update per usare un pool di thread proprio per evitare questi problemi.
Quella modifica è stata tolta perchè ritenuta inutile.
@DjDiabolik se vuoi ti passo il file .py con questa modifica da sostituire in SOD per vedere se il problema rimane.

Disponibile a qualsiasi prova senza il minimo problema.................... lo scopo del thread è prorio questo
Volendo si potrebbe creare un thread con un'allegato in modo che qualche altro utilizzatore di OSMC sullo Pi2 può sostituire il file diciamo a mano anche se poi la cosa andrebbe fatta ad ogni rilascio di una nuova versione del SOD stesso (almeno che non ci sia un modo per diversificare le diverse piattaforme dov'è che viene appunto usato il sod ma credo che sarebbe una cosa ardua da tirar su...) .....

Oppure se la cosa non crea problemi alla procedura stessa di update....... nel senso l'errore è ignorabile ?

MrTruth escribió:Non ne sono sicuro, ma potrebbe essere che ci siano troppi thread aperti e raggiungiungendo il limite del Pi2 ti dia quell'errore (Come detto prima non ne sono sicuro).

mmmmmmmmmmmmm.. ma questo limite è hardware o software ? Essendo OSMC su base debian è un limite impostato sull'OS stesso ?

DjDiabolik escribió: mmmmmmmmmmmmm.. ma questo limite è hardware o software ? Essendo OSMC su base debian è un limite impostato sull'OS stesso ?

Perdonami ... intendevo limite hardware.

MrTruth escribió:

DjDiabolik escribió: mmmmmmmmmmmmm.. ma questo limite è hardware o software ? Essendo OSMC su base debian è un limite impostato sull'OS stesso ?

Perdonami ... intendevo limite hardware.

mmmmmmmmmm..... perdona tu la mia ignoranza in merito alla conoscenza dell'hardware del Pi2 in generale ma vediamo se magari ci vado vicino ma vediamo:
Se ho capito bene in teoria il file .py del SOD va ad "interrogare" una libreria del phyton che fa parte del Debian base di OSMC e tale libreria in qualche modo non è ben progettata per "funzionare" nel processore arm dei raspberry in generale ?

Un pò come se su un processore X86 tentassimo di caricare una libreria progettata per strutture X64 ?


In attesa che @DrZ3ro hosti il .py perchè a questo punto cos'è da sostituire la libreria del phyton attuale o il .py dell'update di osmc ?

Perchè se si tratta della libreria non è che magari installando qualche altra libreria o magari versioni + adatte del phyton stesso risolvo cmq ?

DjDiabolik escribió: mmmmmmmmmm..... perdona tu la mia ignoranza in merito alla conoscenza dell'hardware del Pi2 in generale ma vediamo se magari ci vado vicino ma vediamo:
Se ho capito bene in teoria il file .py del SOD va ad "interrogare" una libreria del phyton che fa parte del Debian base di OSMC e tale libreria in qualche modo non è ben progettata per "funzionare" nel processore arm dei raspberry in generale ?

Un pò come se su un processore X86 tentassimo di caricare una libreria progettata per strutture X64 ?


In attesa che @DrZ3ro hosti il .py perchè a questo punto cos'è da sostituire la libreria del phyton attuale o il .py dell'update di osmc ?

Perchè se si tratta della libreria non è che magari installando qualche altra libreria o magari versioni + adatte del phyton stesso risolvo cmq ?

Nulla di tutto questo, quello che intendevo io è che magari vengono create richieste di nuovi thread maggiori ai thread che la CPU stessa può gestire, questo l'ho letto in un paio di forum su internet, quindi non sono sicuro che sia proprio questa la causa, comunque non so quasi nulla di questo "campo", quindi quello che sto dicendo potrebbe centrare poco.

MrTruth escribió:

DjDiabolik escribió: mmmmmmmmmm..... perdona tu la mia ignoranza in merito alla conoscenza dell'hardware del Pi2 in generale ma vediamo se magari ci vado vicino ma vediamo:
Se ho capito bene in teoria il file .py del SOD va ad "interrogare" una libreria del phyton che fa parte del Debian base di OSMC e tale libreria in qualche modo non è ben progettata per "funzionare" nel processore arm dei raspberry in generale ?

Un pò come se su un processore X86 tentassimo di caricare una libreria progettata per strutture X64 ?


In attesa che @DrZ3ro hosti il .py perchè a questo punto cos'è da sostituire la libreria del phyton attuale o il .py dell'update di osmc ?

Perchè se si tratta della libreria non è che magari installando qualche altra libreria o magari versioni + adatte del phyton stesso risolvo cmq ?

Nulla di tutto questo, quello che intendevo io è che magari vengono create richieste di nuovi thread maggiori ai thread che la CPU stessa può gestire, questo l'ho letto in un paio di forum su internet, quindi non sono sicuro che sia proprio questa la causa, comunque non so quasi nulla di questo "campo", quindi quello che sto dicendo potrebbe centrare poco.

Anche io sto tirando a caso...... però vediamo ancora
In teoria il numero dei thread equivale al numero dei processori che si ha al momento sotto mano....... ad esempio se un programma di codifica video su un pc con cpu 8 core riesce appunto a fare la stessa codifica sfruttando 8 thread contemporaneamente per fare la stessa codifica di fatto velocizzando l'operazione però a quel punto è lo stesso OS che si adatta e che di fatto comunica alla stessa app di codifica il numero massimo di processori disponibili a livello hardware. Per capirci in questo caso sotto windows ipotizziamo che tu stia usando windows 10 è lui che si adatta in base all'hardware dov'è eseguito sia che sia un quadcore o appunto un 8core

Ora sappiamo che OSMC si basa su debian e magari su debian non è cosi.............. boh........ come detto tiro a casaccio e sto tirando fuori possibili spiegazioni logiche in base alle tue affermazioni sia che siano vere o no, diciamo che potrebbero essere teorie.

A questo punto quindi possiamo teorizzare appunto che in fase di avvio siano già usati i 4 thread disponibili (essendo il processore del pi2 o del pi3 cmq dei quadcore) e al momento che lo script di aggiornamento di OSMC viene lanciato in fase di avvio ci sta che mandi appunto in crisi l'hardware che quindi comincia a dare i numeri.......
Per assurdo se fosse cosi ci sta pure che su altri Pi2 magari con installazioni "pulite" dell'OSMC stesso e magari con "boot" + puliti tale problemi non sia presente........ però è strano appunto che tutto l'hardware vada in crisi perchè se in teoria un processo che richiede + processi/thread di quelli effettivamente disponibili non dovrebbe portare al crash del processo stesso ma bensi il processo dovrebbe in qualche modo adattarsi e quindi limitarsi o cmq da se posticipare l'esecuzioni di nuovi processi finche altri sono in esecuzione......... non penso di essere stato troppo chiaro vista sopratutto l'ora

Dirrei che solo DrZ3ro a sto punto può spiegarci ciò che effettivamente accade in quando ci è stato detto appunto che in alcune versioni del SOD appunto si utilizzava un POOL di thread e ho provato a googlare e mica ho capito cos'è che significa effettivamente

Attendiamo novità a questo punto....... ora stacco e provo ad appoggiar la guancia........

Ciao,
attualmente l'update fa partire un thread per ogni canale e per ogni server: sono più di 100 threads in contemporanea e probabilmente il rpi non ce la fa.
Ho allegato lo zip con due .py da sostituire nella cartella core: questi creano un pool di 4 threads che si smazzano un po' alla volta tutti i canali e i server.
Fate delle prove e allegate il log con debug attivo se ci sono problemi.

A presto.

DrZ3r0 escribió:Ciao,
attualmente l'update fa partire un thread per ogni canale e per ogni server: sono più di 100 threads in contemporanea e probabilmente il rpi non ce la fa.
Ho allegato lo zip con due .py da sostituire nella cartella core: questi creano un pool di 4 threads che si smazzano un po' alla volta tutti i canali e i server.
Fate delle prove e allegate il log con debug attivo se ci sono problemi.

A presto.

Ok provo a sostituire............. se noto gli stessi errori senza il debug attivo nel log normale appunto provo ad attivare il debug e faccio un riavvio e posto il tutto qua.

Vuoi che usi il "Wait for network" o no ? Attualmente come detto attivata o meno non fa differenza perchè quando avevo accennato l'errore in un'altro thread m'era stato suggerito di provare con questa opzione attiva pensando appunto che sui rpi l'operazione di update partisse prima che la rete fosse completamente inizializzata e quindi magari che la cosa fastidisasse la procedura di update stessa.

Eventualmente poi in questi file si potrebbe creare tipo un check ? Ipotizzo semplicemente............tipo un check iniziale che controlli eventualmente su qualche hardware è eseguito il SOD stesso e se appunto trova che è eseguito sui pi utilizzare questa "alternativa" procedura di update rispetto a quella invece usata attualmente ?

Un'altra domanda stupida........ i file .pyo attuali ? Attualmente ho rinominato tutto......cioè ho rinominato quelli originali in "-orig" sia i .py che i .pyo e ho messo questi in allegato in core e gli ho impostato gli attributi a "644" cosi come gli altri.......... credo vada bene cosi......