Se la guida canali del tuo IPTV mostra i programmi giusti ma gli orari sbagliati — ogni programma sfalsato di un'ora o due rispetto a quando va in onda davvero — ti sei imbattuto in uno dei bug XMLTV più ostinatamente comuni che si trovino in circolazione. La soluzione è di solito una sola riga di URL da cambiare. Capire in che direzione spostare richiede circa cinque minuti.

Questa guida ti accompagna a vedere dove vive davvero il bug, come capire l'offset che ti serve e come applicarlo. Lo shift del fuso orario EPG su questo sito fa il vero spostamento; questo articolo spiega come usarlo correttamente.

Due linee temporali: la riga dell'orologio reale segna BBC News alle 18:00; la riga dell'EPG mostra lo stesso programma alle 16:00, poi anima uno spostamento di +2 ore per allinearsi all'orologio reale.

Stesso programma, due orologi: l'EPG sta due ore indietro rispetto all'orologio reale finché lo shifter non lo riallinea.

Perché succedono i bug di fuso orario in XMLTV

XMLTV è un formato vecchio di 25 anni. Ogni programma ha un attributo start e stop che si presenta così:

<programme start="20260507180000 +0000" stop="20260507190000 +0000" channel="bbc1">

Le 14 cifre sono l'ora dell'orologio; il +0000 finale è l'offset del fuso orario in cui sono espresse quelle cifre. Quindi 20260507180000 +0000 significa "18:00 UTC del 7 maggio 2026". Il player legge entrambe le cose, converte nel tuo fuso locale e mostra "20:00" se sei in CET.

Funziona se il file XMLTV è internamente coerente. Ma l'XMLTV è generato da una lunga catena di programmi:

  1. Il sistema di palinsesto dell'emittente originale, nel suo fuso locale.
  2. Un aggregatore regionale che magari lo converte in un fuso regionale.
  3. Lo scraper del provider IPTV, che probabilmente lo arrotonda di nuovo.
  4. L'esportatore XMLTV del tuo provider, che ci schiaffa un +0000 in coda che le cifre siano davvero in UTC o meno.

Uno qualsiasi di questi passaggi può introdurre un errore di fuso, e il formato non offre alcun checksum. Il file in output sembra ben formato. Il player non può capire che le cifre al suo interno non corrispondono all'offset dichiarato. Il risultato è una guida sicura di sé e sbagliata di un numero intero di ore.

Una seconda classe di bug è quando il file XMLTV omette del tutto l'offset:

<programme start="20260507180000" stop="20260507190000" channel="bbc1">

Senza l'offset, il player deve tirare a indovinare. La maggior parte dei player presume "le cifre sono nel tuo fuso locale"; alcuni presumono UTC. Se il provider intendeva UTC e il tuo player presume locale, ogni programma sarà sfalsato del tuo offset locale.

In entrambi i casi i dati sottostanti sono giusti — basta sommare o sottrarre numeri per farli atterrare al posto corretto.

Capire qual è l'offset che ti serve

La soluzione è "aggiungi N ore a ogni timestamp del file XMLTV". Per scegliere N:

Passo 1: scegli un canale di cui sai cosa c'è in onda adesso

Apri il player. Trova un canale che sta trasmettendo contenuto in diretta di cui sai davvero cosa sia — il telegiornale locale alle 18:00, il BBC News allo scoccare dell'ora, il prime time su un canale importante. L'obiettivo è avere un ancoraggio certo: "questo canale sta mandando X adesso, a questo preciso orario sul mio orologio".

Passo 2: guarda cosa dice l'EPG

Guarda la voce "in onda ora" dello stesso canale nel tuo player. Annota l'ora di inizio che indica. Se dice che il programma è iniziato alle 16:00 ma in realtà è iniziato alle 18:00, l'EPG è indietro di due ore — devi aggiungere 2 a ogni timestamp.

Se l'EPG mostra che il programma "inizia tra due ore" ma in realtà sta andando in onda adesso, l'EPG è avanti di due ore — devi sottrarre 2.

Passo 3: conferma che lo stesso offset valga su più canali

Scegli un secondo e un terzo canale e verifica che l'offset sia coerente. Se il canale A è sfalsato di +2 e il canale B di -3, non hai un problema di fuso orario; hai dati incoerenti canale per canale e uno shift fisso non risolverà entrambi. (Un'incoerenza tra canali è rara e di solito significa che il provider ha unito feed di più fonti senza armonizzare i fusi — l'unica soluzione lì è chiedere al provider di pulire i dati.)

Nel 95%+ dei casi l'offset è coerente su tutti i canali e il valore è uno di questi: ±1, ±2, ±3, a volte ±5 o ±8 per utenti in fusi orari lontani da quello in cui ha origine il feed sorgente del provider.

Applicare lo shift

Quando conosci l'offset, lo strumento di shift ti dà un nuovo URL che consegna l'XMLTV del tuo provider con ogni timestamp spostato esattamente di quel valore. Sostituisci l'URL EPG nel tuo player con quello nuovo e gli orari della guida tornano allineati.

Due note pratiche:

  • Lo shifter è un proxy, non un'operazione una tantum. Il tuo player aggiornerà l'EPG ogni qualche ora. A ogni aggiornamento, riscarica l'XMLTV del tuo provider tramite lo shifter e riapplica l'offset. Niente cache dalla nostra parte; i dati autorevoli a monte vincono sempre, semplicemente con gli orari spostati.
  • Le tue credenziali stanno nell'URL. La maggior parte dei provider IPTV pubblica l'XMLTV su un URL tipo http://server/xmltv.php?username=...&password=.... Lo shifter legge quelle credenziali solo al momento della richiesta per scaricare il file a monte — non le logga, non le memorizza, non le indicizza. La query string viene anche rimossa prima che i nostri log di accesso vengano scritti.

Cosa lo shifter non risolve

Alcuni problemi vicini sembrano bug di fuso orario ma non lo sono:

I programmi vanno in deriva e tornano a posto

Se l'EPG è a volte giusto e a volte no, non hai un problema di fuso. Le possibilità:

  • I dati del provider sono stantii. Le voci di programma più vecchie si aggiornano con cadenza lenta; quelle nuove arrivano da un feed più fresco. I due feed possono essere in fusi diversi, mescolati nello stesso XMLTV. Difficile risolvere senza collaborazione del provider.
  • Ora legale. Se il tuo fuso locale osserva l'ora legale ma l'XMLTV del provider no (o viceversa), l'offset cambia di un'ora due volte all'anno. Uno shift a offset fisso funziona solo per la metà dell'anno su cui ti stai calibrando.

Per i problemi di ora legale, in particolare, puoi tenere due URL con shift diversi — uno per ogni metà dell'anno — e cambiare la sorgente EPG del player due volte l'anno. Fastidioso, ma funziona.

La guida è vuota, non sbagliata

"Nessuna informazione" / guida in bianco è un problema diverso. Vedi come risolvere "EPG non si carica" — la causa lì è di solito un mismatch dei tvg-id tra playlist e XMLTV, non il fuso orario.

Canali specifici sbagliati, ma la maggior parte è giusta

Se tutto il resto è corretto e solo uno o due canali sono fuori, i dati sorgente di quei canali sono sbagliati a monte, dal provider. Lo shift fisso romperà i canali giusti per sistemare quelli sbagliati. O chiedi al provider di correggere i dati, o accetta che gli orari di quei canali specifici saranno approssimativi.

Perché non rileviamo l'offset in automatico

Lo shifter prende l'offset come parametro esplicito invece di cercare di indovinarlo. In teoria potremmo scaricare il file, confrontare gli orari di inizio dei programmi con "adesso" e tirare a indovinare. Non lo facciamo perché:

  • La "risposta giusta" dipende da quale canale prendi come ancora. Canali diversi potrebbero non concordare.
  • Una scelta automatica sbagliata è peggio del chiedere. Se shiftiamo silenziosamente del valore sbagliato, ottieni una guida coerentemente sbagliata di un altro valore, e perderai tempo a fare debug.
  • Il contesto ce l'ha l'utente. Tu sai che "il TG di BBC One delle 18:00 in questo momento è mostrato come 16:00 nella guida". Lo strumento può applicare questa conoscenza con un clic; ricavarla dall'osservazione di rete è inaffidabile.

Dopo la correzione

Verifica con un altro passaggio del Passo 1: canale noto, programma in corso, controlla l'ora "in onda ora" nel player. Adesso dovrebbe coincidere con l'orologio reale. Se è così, la correzione è permanente — il player continuerà ad aggiornarsi tramite l'URL dello shifter e l'offset rimane applicato.

Se c'è ancora qualcos'altro che non va (canali che non si sono spostati, ID disallineati, buchi di copertura), sono problemi separati e il passo successivo è puntare al validator EPG. Il validator analizza un file XMLTV e segnala problemi strutturali indipendenti dall'orario — utile quando vuoi sapere "il file in sé è ben formato?" piuttosto che "gli orari sono giusti?".

Per tutto il resto lato IPTV, la verifica credenziali Xtream e il tester per playlist M3U coprono i casi limite di playlist e credenziali. Insieme allo shift del fuso orario, questi quattro strumenti gestiscono la maggior parte della diagnosi che la gente finisce a fare al buio sui forum.