EPG per tutti i paesi su GitHub: Fonti& Guida all'installazione

Se stai cercando epg per tutti i paesi github, conosci già le basi: la tua playlist M3U carica i canali correttamente, ma ogni lettore mostra "Nessun dato EPG" accanto a ogni singolo canale. Questa guida copre le vere soluzioni: dove si trovano i migliori aggregatori XMLTV open-source, come integrarli correttamente nel tuo lettore e perché la maggior parte delle configurazioni fallisce in un passaggio specifico di cui quasi nessuno parla.

Cos'è un EPG e perché GitHub ospita le migliori fonti gratuite

Definizione: formato XMLTV e come i lettori lo utilizzano

Una Guida Elettronica ai Programmi (EPG) è un file strutturato che il tuo lettore IPTV legge per visualizzare "cosa c'è ora" e "cosa c'è dopo" accanto a ciascun canale. Il formato che quasi tutti i lettori accettano è XMLTV: uno standard aperto che esiste dal 2000 e non ha bisogno di molte aggiornamenti perché svolge bene il suo lavoro.

I file XMLTV sono semplicemente XML. Due elementi principali contengono tutto:<canale> definisce una stazione con un ID unico, un nome visualizzato e un URL icona opzionale.<programma> associa un intervallo di tempo a quell'ID di canale con un timestamp di inizio e fine nel formatostart="20260511180000 +0000" — quello èYYYYMMDDHHmmss seguito da un offset UTC. I lettori analizzano questi elementi in sequenza e costruiscono la griglia della guida sullo schermo da essi.

Niente di esotico, niente di proprietario. Se il tuo lettore dice che supporta XMLTV, legge questi tag.

Perché gli EPG mantenuti dalla comunità su GitHub superano le alternative estratte

La maggior parte dei "servizi EPG" che vendono o regalano URL EPG stanno essi stessi estraendo siti web di broadcaster e rivendendo i dati senza alcuna trasparenza riguardo a freschezza, copertura o metodologia. Vanno giù senza preavviso, cambiano il loro formato URL o abbandonano silenziosamente certe regioni.

I progetti open-source ospitati su GitHub sono diversi. Puoi vedere il codice dello scraper, il flusso di lavoro CI che lo esegue, quando è avvenuto l'ultimo aggiornamento e se il lavoro è effettivamente riuscito. Questa è vera responsabilità. Quando qualcosa si rompe, qualcuno segnala un problema e qualcun altro lo risolve — a volte entro poche ore.

I manutentori della comunità tendono anche a preoccuparsi dei casi limite: script non latini, canali che trasmettono in più fusi orari, varianti regionali dello stesso broadcaster. I fornitori di EPG commerciali raramente si preoccupano di quel livello di dettaglio.

Come i repository degli aggregatori estraggono da siti ufficiali dei broadcaster

La maggior parte dei progetti di aggregatori seri non inventa dati. Scrivono scraper che accedono a pagine pubbliche ufficiali — la sezione "Programma" di un broadcaster, la loro guida web o l'API della loro app mobile — e trasformano qualsiasi HTML o JSON che ricevono in XMLTV valido. Gli scraper vengono eseguiti automaticamente, di solito tramite GitHub Actions su un programma cron. I file XMLTV freschi vengono impegnati nel repository (o caricati in una release) ogni 6-24 ore.

Questa è l'intuizione chiave: i dati provengono dai sistemi pubblici del broadcaster stesso. Il progetto GitHub è un standardizzatore e aggregatore, non un fabbricante di dati.

Principali aggregatori EPG open-source su GitHub

Repository che aggregano fonti da oltre 100 paesi

I progetti più utili per trovare copertura epg per tutti i paesi github sono i grandi aggregatori multi-paese. Questi repository contengono tipicamente file guida separati per paese o regione (ad es.,guides/us.xml,guides/de.xml,guides/ar.xml) più un file combinato che unisce tutto. La copertura spesso spazia da 80 a 150 paesi, aggiornati quotidianamente o più frequentemente.

I file combinati sono enormi — facilmente 100-300 MB non compressi per un'intera finestra di 7 giorni. Ma la maggior parte di questi repository pubblica anche file individuali per paese e varianti gzipped che si aggirano tra i 10 e i 30 MB. Usali ogni volta che puoi.

Un buon progetto multi-paese avrà un badge CI attivo nel suo README, un programma di aggiornamento chiaramente documentato e una struttura di cartelle organizzata che rende ovvio quale file copre quale regione. Se nulla di tutto ciò è presente, sii scettico — potrebbe essere un fork non mantenuto.

Repository per singolo paese e regionali per mercati di nicchia

Alcuni paesi sono ben coperti da progetti dedicati a singoli paesi. Questi spesso hanno una maggiore accuratezza per quel mercato specifico perché il manutentore guarda effettivamente quei canali e nota quando uno scraper smette di funzionare. Per regioni come il Sud-est asiatico, i paesi MENA o l'Europa dell'Est, un progetto regionale dedicato avrà solitamente una migliore copertura dei canali rispetto all'aggregatore multi-paese generico.

Cerca su GitHub termini come "xmltv [nome paese]" o "epg [nome paese] iptv" e li troverai. Controlla quando è stato l'ultimo commit — qualsiasi cosa oltre 6 mesi senza attività è probabilmente morta.

Come valutare un repository: stelle, ultimo commit, stato CI, licenza

Le stelle sono una metrica di vanità, ma poche stelle su un progetto con commit molto recenti potrebbero significare che è nuovo e buono. Molte stelle su un progetto senza commit dal 2023 significano che è morto e popolare. La data dell'ultimo commit è il vero segnale per i progetti attivi: vuoi attività negli ultimi 2-4 settimane almeno.

Clicca sulla scheda Azioni. Se c'è un workflow chiamato qualcosa come "Aggiorna EPG" o "Esegui scraper" in esecuzione su un programma, e l'ultima esecuzione ha avuto successo (segno di spunta verde), i dati sono attivamente mantenuti. Se l'ultima esecuzione del workflow mostra una X rossa ed è stata tre mesi fa, vai oltre.

Per la licenza: MIT e GPL vanno bene per uso personale e self-hosting. Se non c'è affatto un file LICENSE, tratta il progetto con cautela: legalmente significa che non hai diritti espliciti per utilizzare o ridistribuire i file.

Come aggiungere un EPG ospitato su GitHub al tuo lettore IPTV

Localizzare l'URL XMLTV raw su GitHub (raw.githubusercontent.com)

Il visualizzatore di file regolare di GitHub avvolge il contenuto in HTML: il tuo lettore non può utilizzare quell'URL.Hai bisogno del file raw. Naviga al file nel repository, poi clicca su "Raw" nell'angolo in alto a destra della visualizzazione del file. L'URL cambierà inraw.githubusercontent.com/username/reponame/branch/path/to/guide.xml. Questo è l'URL di cui ha bisogno il tuo lettore.

Alcuni repository pubblicano i loro file EPG come asset di rilascio di GitHub. Controlla nella sezione Rilasci nella barra laterale destra. Gli URL degli asset di rilascio seguono il modellogithub.com/username/reponame/releases/download/tag/guide.xml.gz — link di download, non link di contenuto raw. Entrambi funzionanoper IPTV lettori che supportano HTTP.

Aggiungere l'URL EPG in lettori che supportano input XMLTV

Ogni lettore principale gestisce questo in modo leggermente diverso, ma l'impostazione è solitamente chiamata "URL EPG", "URL XMLTV" o "Fonte della Guida Programmi". Tivimate, Kodi (con PVR IPTV Simple), OTT Navigator e Spark Player supportano tutti questo. Incolla l'URL raw, salva e attiva un aggiornamento.

Se il lettore accetta file gzipped (la maggior parte lo fa), preferisci sempre il.xml.gz variante. Un file di 200 MB compresso a 18 MB fa una vera differenza su connessioni lente o scatole Android TV con RAM limitata.

Abbinare i canali per tvg-id tra M3U ed EPG

Qui è dove il 90% delle configurazioni EPG fallite si interrompe realmente. Iltvg-id attributo nella tua playlist M3U deve corrispondere esattamente alid attributo sul corrispondente<elemento channel> nel file XMLTV. Sensibile al maiuscolo. Carattere per carattere.

Se la tua M3U hatvg-id="BBC.One.uk" e il file EPG haid="bbc1.uk", il lettore non ottiene nulla. Non corrispondono. Niente corrispondenza fuzzy, nessun fallback intelligente nella maggior parte dei lettori: solo silenzio.

Per fare debug, apri entrambi i file in un editor di testo. Cerca un nome di canale di cui sai che dovrebbe avere dati. Controlla quale ID utilizza l'XMLTV per quel canale, poi trova la riga corrispondente nella tua M3U e aggiornatvg-id per corrispondere esattamente. Alcuni fornitori di playlist M3U pubblicano un documento di mappatura che mostra quali ID EPG utilizza la loro lista di canali: controlla prima quello prima di modificare manualmente.

Una variante particolarmente fastidiosa: alcuni progetti EPG usano ID in stile slug comebbc-one mentre le playlist M3U usano ID numerici come70400. Questi non possono mai corrispondere senza uno strato di traduzione — o modifica l'M3U, trova un EPG che utilizza lo stesso schema ID, o scrivi un breve script per generare una mappatura.

Intervalli di aggiornamento e impostazioni della cache

Imposta l'intervallo di aggiornamento dell'EPG del tuo lettore per corrispondere a quanto spesso la sorgente si aggiorna realmente — non più spesso. Se il repository invia nuovi dati ogni 12 ore, aggiornare ogni ora consuma banda, spreca memoria e occasionalmente colpisce i limiti di velocità di GitHub per il tuo IP (particolarmente rilevante se molti dispositivi sulla stessa rete richiedono tutti lo stesso file raw simultaneamente). Ogni 12–24 ore è di solito corretto.

Quando l'EPG sembra errato nonostante un aggiornamento recente, il problema è solitamente la cache lato lettore. La maggior parte dei lettori ha un'opzione "Cancella cache EPG" o "Forza aggiornamento" sepolta nelle impostazioni. Usala prima di assumere che i dati della sorgente siano rotti.

Struttura del file XMLTV e problemi comuni

Anatomia di un'entrata del programma: titolo, sottotitolo, descrizione, categoria, icona

Un elemento di<programma>di base appare così:

<programma start="20260511190000 +0000" stop="20260511200000 +0000" channel="bbc1.uk">  <titolo lang="en">The Nine O'Clock News</titolo>  <sottotitolo lang="en">Edizione di lunedì</sottotitolo>  <descrizione lang="en">Notizie nazionali e internazionali.</descrizione>  <categoria lang="en">Notizie</categoria>  <icona src="https://example.com/posters/news.jpg" /></programma>

Iltitoloè l'unico campo obbligatorio. Tutto il resto è facoltativo, madescrizione ecategoriarendono la guida molto più utile. L'iconamostra l'arte dello spettacolo nei lettori supportati — alcuni repository la includono, molti no.

Gestione dei fusi orari e bug di offset

L'offset UTC nel timestamp (+0000,+0200,-0500, ecc.) è come il tuo lettore traduce l'orario di trasmissione nel tuo orologio locale. Se un scraper codifica in modo rigido+0000 per un canale che in realtà trasmette in+0200, ogni programma appare 2 ore prima di quando viene effettivamente trasmesso.

Le transizioni DST rendono questo peggio. Uno scraper che gestisce correttamente+0100 per il CET in inverno ma dimentica di passare a+0200 per il CEST in estate mostrerà programmi spostati di un'ora per circa 6 mesi dell'anno. Questo è uno dei bug più comuni negli scraper EPG: se noti che il tuo EPG è sfasato di esattamente un'ora dopo un cambiamento dell'orologio, questo è il motivo. Apri un problema nel repository con il canale specifico e l'offset che stai vedendo.

Problemi di codifica con script non latini (cirillico, arabo, CJK)

Tutti i file XMLTV devono essere codificati in UTF-8 con la dichiarazione XML<?xml version="1.0" encoding="UTF-8"?> in cima. Quando uno scraper estrae i nomi dei programmi in arabo, cirillico, cinese o hindi da una fonte e non gestisce correttamente la codifica, i lettori visualizzano mojibake — caratteri spazzatura invece di testo leggibile.

Se vedi caratteri comeпÑогÑамма per quello che dovrebbe essere cirillico, il file è stato probabilmente codificato in Latin-1 o Windows-1252 da qualche parte nella pipeline. Un buon progetto avrà questo risolto; uno scritto in fretta no. Controlla se il repository ha problemi aperti che menzionano la codifica o lingue specifiche non latine prima di impegnarti in esso per quelle regioni.

Cosa fare quando la guida di un paese è mancante o obsoleta

Apri un problema nel repository descrivendo il problema: quale paese, quali canali, quanto tempo fa i dati sono diventati obsoleti. La maggior parte dei manutentori apprezza un rapporto di bug ben scritto molto più di una riga "questo non funziona".

Ancora meglio: invia una richiesta di pull. Se il progetto ha un framework di scraper e riesci a capire come funziona uno scraper di un paese esistente, replicarlo per un paese mancante è spesso semplice. Alcuni progetti hanno contribuito con scraper per oltre 30 paesi in questo modo. Se correggere il progetto esistente sembra troppo lento, cerca un fork regionale o un progetto di un singolo paese come soluzione temporanea — usalo come fonte EPG per quella regione mentre il progetto principale recupera.

Self-Hosting vs Consumo Diretto da GitHub

Scaricare il file XMLTV direttamente da raw.githubusercontent.com

Il consumo diretto è la configurazione più semplice. Incolla l'URL raw, fatto. Lo svantaggio è che sei dipendente da GitHub che rimanga attivo e dal repository che rimanga pubblico. GitHub è generalmente affidabile, ma i repository ricevono occasionalmente avvisi di rimozione DMCA — un progetto che era disponibile ieri potrebbe restituire un 404 oggi. È raro, ma succede.

C'è anche una considerazione sul limite di velocità. GitHub limita le richieste di contenuti raw per IP. Se sei su una rete condivisa (edificio di appartamenti, ufficio, dormitorio) con più utenti IPTV che scaricano tutti lo stesso file da 200 MB ogni 12 ore, potresti iniziare a vedere errori di richiesta. Per uso personale in una singola abitazione, di solito va bene.

Speculare il file sul tuo server con cron

Se hai un VPS, un Raspberry Pi che funziona 24 ore su 24, 7 giorni su 7, o anche un NAS con un pianificatore, puoi scaricare il file XMLTV in un lavoro cron e servirlo localmente. Un semplice comando wget o curl in un'entrata crontab, eseguito leggermente dopo il programma di aggiornamento del repository, significa che hai sempre una copia cache fresca:

0 6 * * * curl -s -o /var/www/html/epg/guide.xml.gz \

Il tuo lettore punta quindi ahttp://your-server/epg/guide.xml.gz invece di GitHub. Più veloce, più affidabile e immune ai limiti di velocità di GitHub. Tempo totale di configurazione: circa 10 minuti.

Filtrare grandi file multi-paese per i canali che guardi realmente

Un file XMLTV multi-paese da 200 MB è davvero doloroso su box Android TV di bassa gamma. Il lettore deve analizzare l'intero file per costruire la guida, e su dispositivi con 1–2 GB di RAM, ciò può causare rallentamenti o crash. Filtrare solo i canali nella tua playlist è la vera soluzione.

Estrai gli ID dei canali dal tuo M3U (grep pertvg-id=), quindi usa quegli ID per filtrare il file XMLTV. L'approccio concettuale: leggi l'elenco dei canali, conserva solo<elementi channel> e<elementi programme> i cuiid ocanale l'attributo appare in quell'elenco. Un file di 200 MB spesso si riduce a meno di 5 MB quando filtrato su 100–150 canali specifici.

Generare un EPG più snello con strumenti da riga di comando

Per l'approccio da riga di comando,xmlstarlet è lo strumento giusto. Un passaggio di filtro appare grossomodo così:

xmlstarlet sel -t \> filtered.xml

Python'sxml.etree.ElementTree gestisce anche questo in modo pulito per chi si sente più a suo agio con la programmazione rispetto agli strumenti da shell. Crea un insieme dei tuoi ID desiderati, itera l'albero sorgente una volta, scrivi gli elementi corrispondenti. Per un elenco di 150 canali che guardi, il passaggio di filtraggio richiede meno di un secondo e il risultato si carica istantaneamente in qualsiasi lettore.

Considerazioni legali ed etiche

Dati di programmazione e copyright in diverse giurisdizioni

I programmi — nome del canale, nome dello show, ora di inizio, ora di fine — sono dati fattuali. Nella maggior parte delle giurisdizioni di common law (US, UK, Australia), i fatti grezzi senza paternità creativa generalmente non possono essere protetti da copyright. L'UE adotta un approccio leggermente diverso attraverso la direttiva sulle banche dati, che concede protezione alle banche dati che rappresentano un investimento sostanziale, anche se i programmi fattuali brevi spesso rientrano al di sotto di quella soglia.

Cosa porta copyright: sinossi degli episodi scritte dal team editoriale di un'emittente, immagini promozionali e testi descrittivi originali. I progetti EPG che includono descrizioni dettagliate degli episodi si trovano in un territorio più grigio rispetto a quelli che includono solo titolo, ora e categoria. Questo non è un consiglio legale — per un uso commerciale su larga scala, parla con un avvocato specializzato nella tua giurisdizione.

Perché la maggior parte dei progetti EPG pubblici opera sotto il precedente di uso leale

La maggior parte dei progetti EPG open-source ha operato pubblicamente per anni senza azioni legali. Il modello prevalente è che le emittenti traggono vantaggio dall'avere i loro dati di programmazione distribuiti accuratamente — questo aumenta la visione. I progetti comunitari che formattano e ripubblicano questi dati stanno facendo qualcosa di simile a ciò che le riviste di programmazione televisiva hanno storicamente fatto: aggregare programmi annunciati pubblicamente per comodità del pubblico.

Detto ciò, "non è stato ancora contestato" non è la stessa cosa di "legalmente chiaro". Comprendi la distinzione.

Rispetto dei termini di servizio dell'emittente sorgente

Alcune emittenti proibiscono esplicitamente lo scraping automatizzato nei loro termini di servizio. Gli autori di scraper EPG devono tenerne conto quando scrivono i loro strumenti. Come utente che consuma i file XMLTV risultanti, sei un passo rimosso da ciò — ma comprendere da dove proviene il dato è importante se intendi ridistribuirlo.

Controllare il README del repository per eventuali note sulla loro metodologia di scraping e sui termini di origine vale qualche minuto di lettura prima di costruire un prodotto o un servizio basato sui dati.

Contribuire nuovamente alla comunità open-source

L'ecosistema epg per tutti i paesi su GitHub funziona grazie allo sforzo dei volontari. Se trovi un bug — fuso orario errato, problema di codifica, uno scraper rotto per il tuo paese — la mossa giusta è contribuire con una correzione piuttosto che semplicemente lamentarsi o forkare silenziosamente. La maggior parte dei manutentori è genuinamente felice di ricevere un problema ben documentato o una richiesta di pull funzionante. I progetti che hanno la migliore copertura sono quelli con comunità di contributori attivi, non quelli con un singolo manutentore sovraccarico che cerca di mantenere 120 scraper funzionanti da solo.