Stuttering la7 live su android tv (philips ambilight)

[lpuglia]

Ciao, prima di tutto grazie mille per il plugin,

Sono da poco passato da kodi su raspberry pi 4 a kodi su android tv (philips ambilight), il plugin funziona bene ma ho un problema di stuttering con il live stream:

lo stuttering diventa piu' pronunciato con le risoluzioni piu' alte (960x540, 1.7 Mbs). Dato che cio' non succede con i programmi on demand credo sia un problema dovuto al decrypt del live stream (inputstream.adaptive plugin), da notare che lo stuttering e' assente sul pi4.

Ho l'impressione che il decrypt dello stream avvenga in software senza sfruttare l'accelerazione hardware. Sul raspberry non ho mai osservato il problema dato che il processore e' molto piu' potente di quello della TV. Ho provato altri plugin (Netflix) che utilizzano inputstream.adaptive a risoluzioni full HD e non ho notato nessun problema, questo mi fa pensare che sia una questione risolvibile con la giusta configurazione del plugin, puoi darmi delucidazioni a riguardo?

[Testato]

Interessante test, grazie del report.

Il problema, imho, non è fa ricercare in inputstream.adaptive ma in Widevine. Widevine si comporta in modo diverso anche in base all'hw su cui gira. Ci sono delle certificazioni che l'hw deve possedere per attivare o meno la decodifica hw. È suddiviso in livelli, e ad esempio puoi scaricarti una app e verificare il tuo telefono quale livello ha e quindi sapere se sarà abilitata decodifica widevine in hw o sw.

Io non so come è la situazione sulla rpi4, posso pensare a questi scenari: 1- la rpi4 è certificata per avere il livello widevine atto ad abilitare la decodifica hw 2- la rpi non ha i giusti livelli quindi decodifica via sw, però essendo molto potente non ha problemi a farlo.

Ad esempio io consiglio di prendere le firestick proprio perché ufficialmente supportate per la decodifica hw widevine

Infine i programmi ondemand di La7 non sono criptato, per questo li vedi sempre bene Alcuni, un paio, lo sono, ad esempio drop dead diva. Prova con quello.

L'unico modo per risolvere, è abbassare la risoluzione finché non vedi bene. Puoi dire ad inputstream adsptive di farti vedere sempre la risoluzione X

P.s. dici che netflix va a 1080p ? Sul tv ? Non so come funziona sui tv, forse hanno giri diversi sull'uso di widevine. Su Rpi3 sia netflix sia la7 sono decodificati via sw, e non ce la fa a farmi vedere bene il 1080p. Vedo bene La7 perché non è mai fullHD e Netflix l'ho settato a 720 e a volte meno

[lpuglia]

cerco di essere un po' piu' chiaro con le mie osservazioni (e' un paio di settimane che ci smanetto):

Device	Plugin	InputStream.adaptive	Stuttering
RaspPI	Netflix	✔️	❌
RaspPI	RivediLa7.live	✔️	❌
RaspPI	RivediLa7.onDemand	❌	❌
Android TV	Netflix	✔️	❌
Android TV	RivediLa7.live	✔️	✔️
Android TV	RivediLa7.onDemand	❌	❌

Dato che:

• Raspberry non e' certificato (solo decodifica SW)
• La TV e' certificata (decodifica HW a disposizione)
• Il processore del Raspberry e' piu' potente del processore della TV

La mia personale conclusione e' che Kodi sulla TV e' in grado di usare l'accelerazione HW attraverso il plugin inputstream.{adaptive, helper} (infatti il plugin di Netflix https://github.com/CastagnaIT/plugin.video.netflix non ha stuttering) ma il plugin di rivediLa7 non configura inputstream in modo da usarlo.

[Testato]

Il plugin va solo a chiamare inputstream, è inputstream che si occupa di gestire il flusso. Ad esempio la Live la7 non funziona su un cellulare (hai provato ?) e non posso farci nulla lato plugin la7, ho aperto issue a inputstream senza risposta

Inoltre La7 ha dei problemi di stuttering anche normalmente via web su chrome, quindi diventa poi difficile capire in quel momento se è lato la7 o tuo, quindi tienilo presente durante i test.

Puoi installare App su questo tv ? Ci sono le app che ti dicono che livello widevine hai, così almeno abbiamo le prove di come stanno le cose

[Testato]

[lpuglia]

Non ho esperienza di programmazione di plugin kodi quindi immagino quanto frustrante possa essere cercare di avere risposte chiare su codice in cui la documentazione e' il codice stesso :D

La TV ha livello 1:

Per quanto riguarda lo stuttering di La7 ne sono a conoscenza: il fatto e' che mentre sul web/pi/app capita una volta ogni mezz'ora, sulla TV succede ogni 30 secondi, e' evidente che non sia dovuto a fluttuazioni dei server di La7 o velocita' di connessione (decoding h264 che non ha abbastanza dati) ma a qualche processo interno alla TV (velocita' di decrypt).

Come puoi notare dal plugin di Netflix: https://github.com/CastagnaIT/plugin.video.netflix#reference-table-of-high-resolutions questo mi fa pensare che esista un modo per selezionare/forzare la decodifica HW

[lpuglia]

Credo di aver individuato la magia: https://github.com/CastagnaIT/plugin.video.netflix/blob/Leia/resources/lib/common/device_utils.py#L77 https://github.com/CastagnaIT/plugin.video.netflix/blob/Leia/resources/lib/config_wizard.py#L34

[sowdust]

Non so se possa essere utile, ma purtroppo io da qualche tempo ho diversi problemi del genere (fino al blocco totale del video) solo su La7 diretta live su LibreElec ultima versione, Rpi3. Nel mio caso tutto potrebbe essere cominciato con l’aggiornamento all’ultima versione di LibreElec, ma non ci giurerei

On 6 Jan 2021, at 12:30, Luca notifications@github.com wrote:

 Ho individuato la magia: https://github.com/CastagnaIT/plugin.video.netflix/blob/Leia/resources/lib/common/device_utils.py#L77 https://github.com/CastagnaIT/plugin.video.netflix/blob/Leia/resources/lib/config_wizard.py#L52

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Testato]

1) Nell'immagine che metti, widevine android hw/sw sta ad indicare che se hai un android certificato puoi sfruttare la decodifica hw. Ma ho sempre immaginato che fosse una cosa scelta in automatico da inputstream, non da verificare lato plugin. Quindi la cosa è molto interessante, va approfondita appena ho tempo.

2) vedo che il tuo widevine è ver.14, sul mio telefono è 15. Posta anche le altre info come sul mio screenshot.

3) @sowdust su Linux, come da tabella, Widevine non può funzionare in hw perché non certificato, quindi non dovrebbe influire il fatto che il plugin vada o meno a verificare il livello di certificazione widevine

[lpuglia]

1. Mi sarei aspettato anche io che la selezione fosse automatica e trasparente, infatti prima di aprire l'issue ho chiesto delucidazione qui: https://forum.kodi.tv/showthread.php?tid=359620&pid=3001207#pid3001207 E qui: https://github.com/peak3d/inputstream.adaptive/issues/582 La risposta nel forum di kodi mi ha fatto pensare che la selezione e' non e' automatica, infatti una volta che ho provato il plugin di Netflix ne ho avuto conferma

2. vendor: Google
   Description: widevine CDM
   Version: 14.0.0
   Algorithm: AES/CBC/NoPadding,HmacSHA256
   Security Level: L1
   Max number of sessions: 80
   Number of open sessions: 4
   Oem crypto api version: 14
   Max HDCP level supported: no digital output
   Current HDCP level: no digital output

[Testato]

Nel frattempo per caso ho controllato su Windows, premendo "O" sulla tastiera per chi non lo sapesse, è le due Live vengono decodificate in Hw 🤪

Questo ci fa saltare tutti gli schemi, è normale ?

[lpuglia]

a questo riguardo ne sto discutendo sul plugin di inputstream.helper: https://github.com/emilsvennesson/script.module.inputstreamhelper/issues/419

Sono quasi sicuro che l'informazione mostrata in quella Tab si riferisca al decoder video che è ben tutt'altra cosa rispetto al decrypter, infatti il Raspberry Pi usa la libreria widevine.so per il decrypting, ma se premi ctrl+o ti esce il decoder hw per il video

[lpuglia]

Extra info: Questo plugin: https://github.com/enen92/plugin.video.rtpplay non mi dà problemi nonostante la risoluzione dello stream sia più alta di quella di LA7 (presumo un bitrate più alto ma non ne ho conferma). Ho dato un occhiata al codice ma non vede differenze eclatanti (a parte un user-agent più nuovo).

Comunque oggi sono riuscito a fare il sideload di kiwi browser android app, con questo sono in grado di vedere LA7 alla massima risoluzione senza stuttering. Ovviamente è molto meno comodo aprire un browser, cliccare sui segnalibri e premere tutto schermo rispetto all'opzione kodi, però è stranissimo che sul browser vada bene nonostante tutto l'overhead del engine.

[Testato]

In realtà esiste anche una app ufficiale, però è solo una webview, non ci hanno investito niente. Comunque fai una prova

[lpuglia]

L'app ufficiale l'ho provata come prima opzione, sulla TV crasha non appena premi play

[Testato]

Ricapitolando (a beneficio dei posteri): Lo stream live dei due canali La7 sono protetti con Widevine. Il provider può decidere cosa bisogna usare per decrittare/decodificare. Sappiamo che La7 usa l'impostazione SW_SECURE_CRYPTO perché in Kodi con il tasto "O" appare HW, questo significa che sia la decrittazione che la decodifica avviene in HW senza aver bisogno che il dispositivo sia certificato L1. Questo è molto positivo, vuol dire che abbiamo decodifica+decrittazione in HW su Windows e su Linux, indipendentemente dal pc usato (linux su pc fisso o linux su rpi). Diversamente Netflix usa l'impostazione SW_SECURE_DECODE che permette la decrittazione/decodifica in HW solo su dispositivi certificati L1, mentre obbliga su tutti gli altri di lavorare in SW (quindi su pc fisso o rpi lavorerà sempre in SW perché non sono L1)

Sullo stream La7 tutto questo avviene in modo trasparente, io non vado a passare nessun settaggio che ha a che fare con i livelli L1, L3, ecc, eppure ci ritroviamo a lavorare correttamente in HW.

È la variabile Android che incasina le cose. Essendo comunque una versione Linux mi aspetterei che funzionasse in HW in automatico ma così non sembra essere. Su Android la lib Widevine non viene scaricata dal plugin, quindi va ad usare sempre quella integrata (infatti sul mio S9+ è ver15 mentre sul tuo Tv è ver14). Qui si deve capire che succede. Sul tuo TV almeno parte in SW, sul mio telefono c'è schermo nero, infine su Firestick funziona in HW (credo, visto che non ho glitch, ma questo confermerebbe che anche su Android io lato plugin non devo fare nulla per attivare HW).

Una cosa utile è capire come possiamo premere il tasto "O" su Android, così abbiamo conferma di HW o SW Ci sarà un modo per premere il tasto "O" su android ?

[lorenzos]

Ci sarà un modo per premere il tasto "O" su android ?

Tastiera fisica con adattatore USB OTG? Sembra una cazzata, ma a me ha sempre funzionato, sia su smartphone che su TV (tastiera, mouse, joypad, etc). Detto questo, purtroppo non posso darvi una mano perché uso Kodi solo su RPi.

[lpuglia]

Ah mi ero perso la ricapitolazione, settimana scorsa ho fatto questo screenshot (sul telecomando ho tutti i tasti):

il video e' evidentemente decodificato in hardware, la mia idea rimane che il decrypt venga effettuato in software ma non sembra esistere modo di verificarlo senza una conoscenza profonda di inputstream.adaptive, ovviamente potrei sbagliarmi, magari e' un bug di kodi risolto nella versione 19 (python3 only). @Testato quando farai il porting per la 19 saro' lieto di riprovare.

P.S. stavo controllando il sito di origine degli stream che utilizzano inputstream.helper senza creare stuttering (https://github.com/enen92/plugin.video.rtpplay) ma non sembra usare nessun DRM dato che funziona anche se disattivo l'opzione su firefox.

[lpuglia]

Attenzione, ho appena fatto una scoperta interessante che potrebbe scagionare il decrypt dello stream, questa e' la tab che appare premendo O su un video on demand:

Come e' ben notabile la risoluzione e' inferiore rispetto alla diretta: 960x540 > 720x576

inoltre andando a controllare gli stream disponibili nei video setting e' mostrato anche come il bitrate sia piu' alto:

Il problema dello stuttering e' evidente solo con la risoluzione piu' alta della live, magari e' veramente un problema di kodi

[Testato]

Si sapevo che la live è migliore in qualità. Scaricando gli m3u8 degli stream ci sono dentro tutte le risoluzioni. Il sistema sceglie in automatico lo stream più adatto proprio per permettere la visione anche a chi ha una connessione lenta.

Il fatto che sia decrypt che decodifica avvengano in hw la prendo per buona, perché non mi sono mai imbattuto in discussioni dove dividevano le due cose, ed anche perché altrimenti kodi stesso avrebbe magari messo nella funzione "O" le due informazioni.

la conferma che anche sul tuo TV tutto è gestito in HW lo conferma il fatto che nello screenshot tutti i core della cpu sono a 0%

Chi di voi ha un telefono Android, può controllare che anche a voi si sente solo l'audio mentre il video è nero ?

[lpuglia]

Diario di Debug # 1:

Ho impostato un web server sul mio computer in modo da poter servire un video stream mpeg-dash (mpd file esattamente come fa la7), dopo di che ho creato un addon di kodi in grado di connettersi al mio server dalla TV, ecco il risultato:

Volevo testare se fosse un problema di bitrate troppo alto, la7 ha una live stream con un bitrate di 1.7Mb/s, piu' alto persino di netflix a 1080p. Per testare le capacita' della tv ho creato uno degli stream a 3.3Mb/s, risultato: nessuno stuttering.

L'unica differenza tra il mio stream e la live e' il DRM widevine. Purtroppo su lato server ci sono delle licenze da pagare per utilizzare questa tecnologia, quindi non sono in grado di testare questa opzione.

Almeno pero' adesso sappiamo che il decoder hw fa il suo dovere. Continuo ad essere sempre piu' convinto che il problema sia dovuto al decrypt software impostato da inputstream.adaptive.

to do:

• controllare se su kodi 19 il problema non e' presente ❌ appena provato, stesso problema
• scrivere una app android in grado di forzare il deconding sw e hw
• spulciare inputstream.adaptive alla ricerca delle opzioni di decrypt

[lpuglia]

Diario di debug # 2:

ho fatto un po' di debug di inputstream adaptive, in particolare questa stringa e' sempre presente nel log:

DEBUG: AddOnLog: InputStream Adaptive: Found decrypter: /data/app/org.xbmc.kodi-4we2fgtcBZsS1icd7sfk2g==/lib/arm/libssd_wv.so

indipendentemente dal plugin. non credo di poter fare molto di piu' di cosi'.

Ho scritto una app per android per vedere la live di la7 (basata su exoplayer https://github.com/google/ExoPlayer), non c'e' stuttering, funziona benissimo senza problemi, dato che e' un ottimo workaround non credo ci sia altro da aggiungere, l'issue e' WON'T FIX.

[Testato]

Wont fix da parte di chi intendi ?

Passa il link github alla tua app

[lpuglia]

Essendo il bug (a sto punto non so se possa essere considerato un bug) ristretto ad un solo device e non avendo ricevuto supporto dalla parte di inputstream.adaptive non credo esista un modo per risolvere.

Per quanto riguarda l'app, appena creo il repository metterò il link qui.

[Testato]

Sarebbe interessante testarlo su un altro androidtv per capire se è un problema del modello di Tv o di AndroidTv in generale ma io non ho nessun Android tv a disposizione

[lpuglia]

Ciao! non ho trovato molti volontari per testare il plugin su altre televisioni, in compenso ho potuto constatare come sia un problema legato agli stream mpeg-dash, infatti il plugin di Discovery+ ha lo stesso problema: piu' e' alta la risoluzione e piu' e' pronunciato lo stuttering, credo che la nuova versione di kodi abbia migliorato la situazione ma il problema e' ancora evidente.

La mia app e' quasi pronta per la prima release, ho anche introdotto la possibilita' di proxare i singoli stream video in modo completamente transparente per l'untente (una funzionalita' molto utile per chi vive all'estero e vuole vedere RAI, Mediaset ecc)

[Testato]

Quindi intendi allargarla a piu canali, non solo la7 ? Perché su la7 non serve il proxy, non ha blocchi geografici

[Testato]

Se vuoi provare, giusto per scrupolo, ora che è uscito Kodi19 ufficiale ed ho aggiornato il plugin ;-)

[lpuglia]

Purtroppo avevo già provato a fare un mini-porting del codice della live su kodi 19 ma non ho avuto successo. È un problema intriseco al player, forse qualche ottimizzazione che manca.

In compenso ho fatto il primo commit della mia app: https://github.com/lpuglia/ExtTv/tree/master

È ancora in stato embrionale, mi sono fatto prendere la mano e ho scritto un framework estensibile che può accettare diversi scraper per diversi siti, praticamente un kodi basilare. Rispetto a kodi però ha l'accesso tramite VPN e integrazione sulla home di android tv. Il player che utilizzo è ExoPlayer di Google e non presenta stuttering:

[Testato]

Bellissimo, lo proverò. Ma ci sono già tutti i canali ?

[Testato]

Nell'ultima versione forzo l'utilizzo del decoder drm L1, prova se cambia qualcosa nel tuo caso. Sul mio telefono Samsung, dove non partiva proprio il video, ora funziona

[Testato]

@lpuglia Ho fatto delle prove ed ho anche io stuttering vari. Secondo me potresti agganciarti su questa mia issue su IA e illustrare i tuoi test su AndroidTV, perché qualcosa da sistemare nella gestione del discorso L1 su IA c'è di sicuro https://github.com/xbmc/inputstream.adaptive/issues/638

[lpuglia]

qualcosa si muove: https://github.com/xbmc/inputstream.adaptive/pull/662 dita incrociate

[Testato]

yes.

E sono due rpoblemi diversi, il rpimo bug è che su alcuni device L1 IA non gestisce bene l'attivazione del decoder integrato in android (e questo è il caso del mio telefono dove ho schermo nero, mentre il tuo TV non ne soffre). Mentre il secondo probelma è quello che hai tu ma che ho anche io sul telefono una volta che forzo l'abilitazioone del secure decoder

https://github.com/xbmc/inputstream.adaptive/issues/638

[CastagnaIT]

@lpuglia ciao ti rispondo qui per non andare troppo OT sul PR e cosi ti rispondo in italiano in pratica se vuoi evitare di rimuovere il flag SSD_SECURE_DECODER hai due modi:

• impostando la proprietà nel listitem che verrà riprodotto listitem.setProperty('inputstream.adaptive.license_flags', 'force_secure_decoder')

• impostando tramite manifest all'interno del ContentProtection <widevine:license robustness_level="HW_SECURE_CODECS_REQUIRED" /> esempio:

  <MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:cenc="urn:mpeg:cenc:2013" mediaPresentationDuration="PT6234.00S">
  <Period start="PT0S" duration="PT6234.00S">
      <AdaptationSet mimeType="video/mp4" contentType="video">
          <ContentProtection schemeIdUri="urn:mpeg:dash:mp4protection:2011" cenc:default_KID="00000000-05a5-e322-0000-000000000000" value="cenc" />
          <ContentProtection schemeIdUri="urn:uuid:EDEF8BA9-79D6-4ACE-A3C8-27DCD51D21ED" value="widevine">
              <widevine:license robustness_level="HW_SECURE_CODECS_REQUIRED" />
              <cenc:pssh>AAAANHBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAABQIARIQAAAAAAWl4yIAAAAAAAAAAA==</cenc:pssh>
          </ContentProtection>

ma secondo me dovresti provare a impostare sul manifesto robustness_level vuoto <widevine:license robustness_level="" /> almeno in passato avevo risolto cosi i problemi di schermo nero su alcuni dispositivi android cinesi

[lpuglia]

@CastagnaIT Grazie per la risposta! riguardo la seconda soluzione (dato che la prima e' gia' implementata ma non mi ha risolto lo stuttering), stai per caso dicendo di modificare il manifest al volo invece di usarlo cosi' com'e'? al momento questo plugin setta l'url del manifest qui: https://github.com/luivit/plugin.video.rivedila7/blob/master/resources/lib/plugin.py#L175

usando:

listitem.setPath(mpdurl)

dove mpdurl e' l'URL del manifest dello stream. Quello che proponi tu e' leggere il manifest remoto, modificarlo al volo come descritto, salvarlo su disco e usare il path di questo nuovo file dentro setPath?

Ho capito bene oppure sto travisando completamente?

[Testato]

@CastagnaIT con la tua esperienza sul plugin netflix, ritieni che sono legati i problemi di schermo nero e di stuttering ? forzare il secure decoder come ho fatto su questo plugin risolve i problemi di schermo nero ma lo stuttering resta, ed il mio è un samsung s9+ quindi niente magheggi cinesi sui certificati

[CastagnaIT]

Quello che proponi tu e' leggere il manifest remoto, modificarlo al volo come descritto, salvarlo su disco e usare il path di questo nuovo file dentro setPath?

sarebbe meglio utilizzare utlizzare un proxy https://github.com/xbmc/inputstream.adaptive/wiki/How-to-provide-custom-manifest-and-license assicura dati affidabili senza ricorrere a file fisici, però il vostro addon non ha un'istanza di servizio quindi, rozzamente puoi fare una cosa del genere, più che altro farlo al volo senza perderci tempo perchè rispondendo anche a @Testato la mia soluzione sarebbe per lo schermo nero (impossibilità di decodifica) in quanto i glitch sembrano derivare da altri problemi, con netflx non ricordo di avere mai avuto feedback dagli utenti di glitch di questo tipo su android, invece è accaduto su linux con il codec VP9 in quanto distribuzioni linux più vecchie non supportavano questo codec correttamente

se non lo avete gia fatto verificate se con i glitch ci sono warnings particolari abilitando il log verboso ffmpeg e video component

comunque per aprire la barra delle info del codec senza la tastiera quando il video è in playback eseguite il json-rpc Input.ExecuteAction con {'action': 'codecinfo'} anche da codice

sarebbe utile cmq avere un mpd di un video con glitch e anche uno screenshot di un video con il glitch con la finestra codec info attiva

nota a parte: sul callback play_dirette non è gestito l'annullamento del playback nei casi in cui setResolvedUrl non viene eseguito dovete inserire: xbmcplugin.endOfDirectory(PLUGIN_HANDLE, succeeded=False) in ogni "punto morto" ed eliminare exit() che non è corretto forzare l'uscita in questo modo

[lpuglia]

@CastagnaIT ci ho lavorato un po' e non sembra risolvere il problema, invece di usare un proxy uso una istanza di BaseHTTPRequestHandler per servire il file modificato ad IA. Nel manifest non ci sono ContentProtection con value widewine,

Esempio di manifest non modificato: https://controlc.com/4eca64bc

modificato: https://controlc.com/82873dd8

ho provato sia con HW_SECURE_CODECS_REQUIRED che senza, lo stuttering non e' scomparso :/

[Testato]

Questo conferma che lo stuttering è una questione diversa dallo schermo nero. @CastagnaIT grazie dei consigli, mica vuoi farci direttamente una PR ? 😅

[lpuglia]

Il log verboso di ffmpeg sarebbe molto utile per capire la provenienza dei glitch, come si abilita? Guardando i miei log non mi sembra che sia attivato

[Testato]

Ma noi non usiamo ffmpeg no ? inputstream.adaptive non sostituisce ffmpeg ?

[lpuglia]

Ffmpeg viene usato comunque come front end per la decodifica dello stream MP4 che viene generato da IA a partire dal file MPD

[CastagnaIT]

@lpuglia come sospettavo... vedo inoltre che l'mpd supporta due DRM playready e widevine non so ISA quale da priorità nel vostro caso, ma se usa playready farei anche il tentativo di eliminare il ContentProtection playready, non penso cambia qualcosa ma un tentativo lo farei

ffmpeg dovrebbe essere sempre utilizzato in kodi per i flussi audio/video, ISA fa solo la decriptazione in tempo reale dei dati video prima di passarli al core kodi i componenti log specifici sono qui:

[Testato]

IA al momento gestisce solo widevine, quindi usa widevine for sure

[CastagnaIT]

pardon non mi ricordavo più una cosa è impostato su inputstream.adaptive.license_type quindi sicuramente ora usi widevine

ma su android ISA supporta anche Playready quindi prova cambiarlo con "com.microsoft.playready"

[lpuglia]

appena controllato per warning di ffmpeg durante lo streaming, non esce niente oltre ai soliti (infiniti) messaggi di Debug.

[Testato]

@lpuglia sembra abbiano trovato il vero problema, succede quando un canale, come nel caso di LA7, cripta sia il video che l'audio. Ho provato la versione di test sul mio samsung s9+ ed effettivamente ora funziona. Puoi provare anche sulla tua tv ? https://github.com/xbmc/inputstream.adaptive/issues/693

[Testato]

@lpuglia Sei riuscito a fare la prova ? La PR è stata accettata quindi basta che aggiorni all'ultima versione di IA e fai una prova.

[lpuglia]

si, purtroppo niente da fare :(

[lpuglia]

Appena riprovato stamattina, sembra essere risolto dopo che ha fatto qualche aggiornamento inaspettato!