Jeśli twój program kanałów IPTV pokazuje właściwe audycje, ale złe godziny — każda audycja przesunięta o godzinę albo dwie względem tego, kiedy faktycznie idzie na antenie — trafiłeś na jeden z najbardziej upartych częstych błędów XMLTV. Naprawa to zwykle zmiana jednej linijki URL-a. Diagnoza, w którą stronę przesunąć, zajmuje jakieś pięć minut.

Ten przewodnik tłumaczy, gdzie naprawdę siedzi błąd, jak ustalić potrzebne przesunięcie i jak je nałożyć. Przesuwacz stref czasowych EPG na tej stronie wykonuje samo przesunięcie; ten artykuł pokazuje, jak go używać poprawnie.

Dwie osi czasu: górna z zegarem ściennym zaznacza BBC News o 18:00; dolna z EPG pokazuje tę samą audycję o 16:00, a potem animuje przesunięcie o +2 godziny, by zrównać się z zegarem ściennym.

Ta sama audycja, dwa zegary: EPG siedzi dwie godziny za zegarem ściennym, dopóki przesuwacz tego nie wyrówna.

Skąd biorą się błędy stref czasowych w XMLTV

XMLTV to format mający 25 lat. Każda audycja ma atrybuty start i stop, które wyglądają tak:

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

14 cyfr to czas ścienny; końcowe +0000 to przesunięcie strefowe, w którym ten czas ścienny jest podany. Czyli 20260507180000 +0000 znaczy „18:00 UTC, 7 maja 2026”. Odtwarzacz odczytuje oba kawałki, konwertuje na twoją strefę lokalną i wyświetla „20:00”, jeśli jesteś w CET.

To działa, jeśli plik XMLTV jest wewnętrznie spójny. Ale XMLTV powstaje w długim łańcuchu programów:

  1. System programowy oryginalnego nadawcy, w jego lokalnej strefie czasowej.
  2. Regionalny agregator, który być może konwertuje na strefę regionalną.
  3. Scraper dostawcy IPTV, który prawdopodobnie zaokrągla to jeszcze raz.
  4. Eksporter XMLTV twojego dostawcy, który dokleja na końcu +0000, niezależnie od tego, czy cyfry są naprawdę w UTC.

Każdy z tych kroków może wprowadzić błąd strefowy, a format nie zawiera żadnej sumy kontrolnej. Plik wyjściowy wygląda poprawnie. Odtwarzacz nie wykryje, że cyfry w środku nie pasują do deklarowanego przesunięcia. Efekt: program pewnie podaje godziny przesunięte o jakąś całkowitą liczbę godzin.

Druga klasa błędu to gdy plik XMLTV w ogóle pomija przesunięcie:

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

Bez przesunięcia odtwarzacz musi zgadywać. Większość zakłada „cyfry są w twoim czasie lokalnym”; niektóre zakładają UTC. Jeśli dostawca myślał o UTC, a odtwarzacz zakłada czas lokalny, każda audycja będzie przesunięta o twoje lokalne przesunięcie.

W obu przypadkach dane bazowe są poprawne — wystarczy dodać albo odjąć liczby, żeby trafiły we właściwe miejsce.

Jak ustalić, jakie przesunięcie ci potrzebne

Naprawa to „dodaj N godzin do każdego znacznika czasu w pliku XMLTV”. Żeby wybrać N:

Krok 1: Wybierz jeden kanał, na którym wiesz, co teraz leci

Otwórz odtwarzacz. Znajdź kanał, który teraz pokazuje treść na żywo, którą faktycznie znasz — lokalne wiadomości o 18:00, BBC News o pełnej godzinie, prime time na dużej stacji. Chodzi o znany punkt odniesienia: „ten kanał pokazuje teraz X, dokładnie o tej godzinie na moim zegarku”.

Krok 2: Spójrz, co mówi EPG

Spójrz na wpis „teraz na antenie” tego samego kanału w odtwarzaczu. Zanotuj, jaką godzinę startu deklaruje. Jeśli mówi, że audycja zaczęła się o 16:00, a faktycznie zaczęła się o 18:00, EPG jest dwie godziny do tyłu — musisz dodać 2 do każdego znacznika.

Jeśli EPG pokazuje, że audycja „zaczyna się za dwie godziny”, a faktycznie idzie właśnie teraz, EPG jest dwie godziny do przodu — musisz odjąć 2.

Krok 3: Potwierdź, że przesunięcie jest takie samo na kilku kanałach

Wybierz drugi i trzeci kanał i sprawdź, czy przesunięcie jest spójne. Jeśli kanał A jest przesunięty o +2, a kanał B o -3, to nie masz problemu ze strefą czasową; masz niespójne dane na poszczególnych kanałach i stałe przesunięcie nie naprawi obu naraz. (Niespójność między kanałami jest rzadka i zwykle oznacza, że dostawca scalił feedy z kilku źródeł bez ujednolicenia stref — jedyne rozwiązanie to poprosić dostawcę o uporządkowanie danych.)

W ponad 95% przypadków przesunięcie jest spójne na wszystkich kanałach, a wartość to jedna z: ±1, ±2, ±3, czasem ±5 lub ±8 dla osób w strefach odległych od źródła feedu dostawcy.

Nakładanie przesunięcia

Gdy znasz przesunięcie, narzędzie do przesuwania daje ci nowy URL, który dostarcza XMLTV twojego dostawcy z każdym znacznikiem czasu przesuniętym dokładnie o tę wartość. Zamień URL EPG w odtwarzaczu na ten nowy i godziny w programie się zgodzą.

Dwa praktyczne punkty:

  • Przesuwacz to proxy, nie jednorazowy strzał. Twój odtwarzacz odświeża EPG co kilka godzin. Każde odświeżenie pobiera XMLTV twojego dostawcy przez przesuwacz i ponownie nakłada przesunięcie. Po naszej stronie nie ma cache'owania; autorytatywne dane ze źródła nadal wygrywają, tylko z dosuniętymi godzinami.
  • Twoje dane logowania siedzą w URL-u. Większość dostawców IPTV wystawia XMLTV pod URL-em w stylu http://server/xmltv.php?username=...&password=.... Przesuwacz odczytuje te dane tylko w momencie żądania, by pobrać źródło — nie loguje ich, nie cache'uje, nie indeksuje. Query string jest też obcinany, zanim cokolwiek trafi do naszych logów dostępu.

Czego przesuwacz nie naprawi

Kilka sąsiednich problemów wygląda jak błąd strefowy, ale nim nie jest:

Audycje wchodzą i wychodzą z synchronizacji

Jeśli EPG czasem jest dobry, a czasem nie, nie patrzysz na problem strefowy. Możliwości:

  • Dane dostawcy są nieświeże. Starsze wpisy odświeżają się w wolnym rytmie; nowsze pochodzą ze świeższego feedu. Oba feedy mogą być w różnych strefach, wymieszane w tym samym XMLTV. Trudne do naprawienia bez współpracy dostawcy.
  • Czas letni. Jeśli twoja strefa stosuje czas letni, a XMLTV dostawcy nie (albo na odwrót), przesunięcie zmienia się o godzinę dwa razy w roku. Stałe przesunięcie działa tylko dla tej połowy roku, pod którą je skalibrowałeś.

Specjalnie dla problemów z czasem letnim możesz trzymać dwa przesunięte URL-e — po jednym na każdą połowę roku — i dwa razy w roku zmieniać źródło EPG w odtwarzaczu. Irytujące, ale działa.

Program jest pusty, a nie błędny

„Brak informacji” / pusty program to inny problem. Zobacz jak naprawić nieładujące się EPG — tam przyczyną są zwykle niedopasowane tvg-id między listą a XMLTV, a nie strefa czasowa.

Konkretne kanały są błędne, ale większość poprawna

Jeśli reszta jest w porządku, a tylko jeden czy dwa kanały są poprzesuwane, to dane źródłowe tych kanałów są błędne po stronie dostawcy. Stałe przesunięcie zepsuje poprawne kanały, żeby naprawić te błędne. Albo poproś dostawcę, żeby naprawił dane, albo pogódź się z tym, że godziny tych konkretnych kanałów będą przybliżone.

Dlaczego nie wykrywamy przesunięcia automatycznie

Przesuwacz przyjmuje przesunięcie jako jawny parametr, zamiast próbować je zgadnąć. Teoretycznie moglibyśmy pobrać plik, porównać godziny startu audycji z „teraz” i zgadywać. Nie robimy tego, bo:

  • „Prawidłowa odpowiedź” zależy od tego, na którym kanale się zakotwiczysz. Różne kanały mogłyby się nie zgadzać.
  • Zły strzał jest gorszy niż zapytanie. Jeśli po cichu przesuniemy o złą wartość, dostaniesz program, który jest spójnie błędny w inny sposób, a stracisz czas na debugowanie.
  • To ty masz kontekst. Wiesz, że „BBC One News o 18:00 pokazuje się w programie jako 16:00”. Narzędzie może zastosować tę wiedzę jednym kliknięciem; wyprowadzanie jej z obserwacji sieci jest niepewne.

Po naprawie

Zweryfikuj jeszcze raz, robiąc krok 1 powyżej: znany kanał, bieżąca audycja, sprawdź godzinę „teraz na antenie” w odtwarzaczu. Powinna teraz pasować do zegara ściennego. Jeśli pasuje, naprawa jest trwała — twój odtwarzacz dalej odświeża się przez URL przesuwacza, a przesunięcie zostaje nałożone.

Jeśli coś jeszcze jest nie tak (kanały, które się nie przesunęły, niezgodne identyfikatory, dziury w pokryciu), to są osobne problemy i następnym krokiem jest walidator EPG. Walidator parsuje plik XMLTV i raportuje problemy strukturalne niezależne od czasu — przydatny, gdy chcesz wiedzieć „czy sam plik jest dobrze sformułowany”, a nie „czy godziny są poprawne”.

Co do reszty po stronie IPTV — weryfikator danych Xtream i tester listy M3U pokrywają obrzeża związane z listą i danymi logowania. Razem z przesuwaczem strefy te cztery narzędzia łapią większość problemów, które ludzie po omacku rozgryzają na forach.