Beiträge von niwi

    Mit den regel-basierten Timern kenne ich mich nicht aus. Ansonsten sollte dein Linux-System auf die korrekte lokale Zeitzone konfiguriert sein. Wie ich versucht hatte zu erläutern, läuft die interne Uhr oder die System-Uhr oder die BIOS Uhr normalerweise dennoch in UTC. Kann dir aber grundsätzlich egal sein. TVH zeigt dir dann alles in lokaler Zeit an (kommuniziert aber im Hintergrund dennoch mit UTC).

    Die EIT-Zeitzonen-Differenz aus dem Screenshot sollte auf UTC stehen in tvh (das ist auch Default so). Das hast du schon richtig verstanden, das ist nur, wenn Zeitangaben für EPG (durch EIT = Event Information Table oder durch xmltv oder auch andere Quellen) fehlerhaft sind. Ich habe das bei uns noch nicht gesehen (ASTRA, DVB-T2, DVB-C).
    EDIT: Was ist denn die Ausgabe von date auf der Linux Konsole?

    root@TVHeadend:/opt# date
    Sun May 4 08:01:10 CEST 2025

    Als das Problem noch bestand, war hier aber die UTC-Zeit angegeben. Ich habe dies dann mit
    timedatectl set-timezone Europe/Berlin
    geändert.

    Ehrlich gesagt musst du mal prüfen dann in welchen Netzwerken das nicht so klappt wie du möchtest.

    Noch ne tolle Frage: Stimmt die Zeit auf dem Kodi System?

    Bevor ich nun bei jedem Netzwerk einzeln prüfe, ob ich die UTC-Angabe korrigieren muss, prüfe ich erst einmal, ob die Änderung der Systemzeit auf lokale Zeit das Problem nicht global löst. Gerne lasse ich mich aber überzeugen, dass dies der falsche Weg ist.

    Mein Kodi läuft auf einem ForeTV. Kodi und FireTV nutzen korrekt die lokale Zeit.

    Möglicherweise liegt hier das Missverständnis. In der Tat ist das so, dass beispielsweise auf traditioneller PC-Hardware die Systemuhr (das ist die Uhr, die unabhängig und außerhalb vom Betriebssystem läuft) normalerweise in UTC läuft. Das Linux-Betriebssystem selbst nutzt intern auch UTC, für die Darstellung den Benutzter gegenüber und für Benutzereingaben wird dennoch lokale Zeit genutzt. Das date Kommando sollte dementsprechend auch die lokale Zeit ausgeben (und auch die Zeitzone).

    EPG-Informationen, die tvheadend verarbeitet, liegen normalerweise in der Tat auch in UTC vor. Im xmltv-Format stehen Zeitstempel in UTC zusammen mit einer Zeitdifferenz zu UTC (z.B. bei uns zur Zeit +2 h). Unabhängig von der lokalen Zeitzone, kann tvh diese intern als UTC verarbeiten, aber dir gegenüber halt wieder in lokaler Zeit anzeigen. Das stimmt dann auch für einen Fernsehsender aus Großbritannien, der eigentlich eine andere Zeitdifferenz zu UTC hat, als ein deutscher Fernsehsender.

    Danke für die Erklärungen. Aber wie helfen mir diese nun weiter? Und wer hat hier ein Missverständnis aus deiner Sicht? Meinst du, dass TVHeadend hier etwas falsch interpretiert oder ich? Was müsste ich den konkret anders machen bzw. verstehen? Ich bin doch schon korrekt davon ausgegangen, dass Linux auf Systemebene UTC benötigt und TVHeadend hatte mir das EPG und die laufende Uhrzeit doch bereits korrekt angezeigt. Nur gab es halt im Kontex tvon Timerregeln plötzlich diese merkwürdigen Verschiebungen um zwei Stunden.

    Du musst die Zeit nicht im Linux ändern sondern im TvHeadend.

    Folge den Pfeilen.

    https://i.imgur.com/7LcPsj5.png

    Sorry, hatte gestern kein Zugriff auf mein System um das zu zeigen.

    Danke für den Hinweis. Nachdem, was ich im TVHeadend-Forum zu diesem Lösungsansatz gelesen habe, ist diese Lösung eigentlich vorgesehen für den Fall, dass in einem Netzwerk die Zeitangaben lokal statt in UTC gesetzt sind. Dort geht es auch eher um falsche EPG-Zeiten. Zumindest die EPG-Zeiten stimmen bei mir aber.

    Woher weiß ich denn, für welche Netzwerke ich die UTC-Angabe in die lokale Zeit ändern soll? Und könnte es nicht sein, dass es in manchen Netzwerken unterschiedliche Zeiten je nach Sender gibt?

    Meine Ausgangsfrage war ja konkret zum heute journal vom ZDF als Beispiel:

    Das ZDF empfange ich mit höchster Priorität über DVB-T2 in Hamburg (da DVB-T2 die höchste Auflösung bietet). Wenn mein DVB-T2-Zuner belegt ist, stehen als Ersatz zwei DVB-S2-Tuner für Astra 19,2° Ost zur Verfügung. Sollten diese auch einmal belegt sein, hätte ich weiterhin zwei Instanzen mit der Telerising API für Zattoo Deutschland am Laufen. Müsste ich nun für alle fünf Netzwerke die lokale Zeit konfigurieren? Oder ist es vielleicht sogar der bessere Weg, einfach die lokale Zeit im Server zu konfigurieren? Der Server ist ein lokaler Proxmix-Container nur für TVHeadend. Es hat also keine großen Nachteile für mich, dort nicht UTC konfiguriert zu haben.

    Ich habe nun einmal testweise die Zeit auf dem Linuxserver auf die lokale Zeit statt UTC gestellt. Nun scheinen die Timer korrekt zu sein. Die Start -und Endzeitangaben in programmübersichtsbasierten Timerregeln funktionieren nun auch wie intuitiv erwartbar. Dennoch scheint mir diese Lösung nicht wünschenswert zu sein. Unter Linux ist eigentlich vorgesehen, dass die Systemzeit auf UTC eingestellt ist. Da es hier im Fourm keine Reaktionen gab, verfolge ich das Thema im TVHeadendforum weiter.

    Mittlerweile verstehe ich das Problem, glaube ich, etwas besser. Es sieht so aus, dass meine regelbasierten Timer in vielen Fällen automatisch eine zweistündige Verzögerung erhalten. Sendungen, die also z.B. eigentlich vom 19.30 Uhr bis 20.00 Uhr aufgezeichnet werden sollen, werden um 21.30 -22.00 Uhr aufgezeichnet. Das führt dann vermutlich dazu, dass meine Angaben zur Start- und Endzeit falsch interpretiert werden.

    Aber warum? Auf meinem TVHeadend-Server ist die Zeit korrekt für UTC konfiguriert. Auf der TVHeadend-Oberfläche wird mir auch die korrekte lokale Zeit angezeigt.

    Moin an alle,

    ich möchte gerne genauer lernen, wie beim Kodi-PVR die programmübersichtsbasierten Timer funktionieren. Hier ein konkretes Beispiel, welches ich nicht gelöst bekomme, damit es anschaulicher wird:

    Jeden Abend soll das Heute Journal vom ZDF aufgenommen werden. Hierbei gibt es zwei Herausforderungen:

    1. Die Sendung hat keine feste Startzeit. Ein einfacher Timer würde also nicht reichen.
    2. Es gibt auch die Sendung Heute Journal Update. Bei einem epg-basierten Timerregel (ohne detaillierte Konfiguration) würden beide Sendungen aufgenommen werden.

    Folgendes habe ich bereits probiert:

    1. Ich habe als Startzeit 21.00 Uhr und als Endzeit 22:45 Uhr eingegeben, in der Annahme, dass diese Konfiguration bewirken würde, dass dann nur Sendungen in diesem Zeitfenster aufgenommen werden. Dem ist aber nicht so. Eine Dokumentation dieser Einstellungen konnte ich nicht finden.
    2. Ich habe eingestellt, dass die Sendung nur einmalig aufgenommen wird. Das funktioniert aber deshalb nicht, weil das Heute Journal Update teilweise nach Mitternacht startet. Dann wird dieses statt dem eigentlichen Heute Journal aufgenommen.

    Eine Lösung könnte sein, Kodi mitzuteilen, dass der Sendungstitel mit dem Wort Journal enden muss. Wie mache ich das aber? Ohnehin würde diese Lösung aber nicht in anderen Fällen helfen, in denen die Sendung immer gleich lautet.

    Eine andere und bessere Lösung wäre, Kodi mitzuteilen, dass der Timer nur in einem bestimmten Zeitfenster täglich aktiv werden darf. Aber wie macht man dies?

    Ist vielleicht einfach ein Bug daran Schuld, dass es intuitiv nicht klappt?

    Hier ein paar Infos zu meinem System:

    • Kodi 21.2 auf einem FireTV
    • Im Hintergrund TVHeadend 4.3
      (in TVHeadend selbst könnte ich derzeit nur kompliziert Auto-Timer erstellen, weil dies in den meisten Browsern durch einen Bug nicht funktioniert)

    du brauchst die liste gar nicht scannen, du trägst einfach bei der Service ID eine 1 ein und du hast sofort alle Services ohne Prüfung und Scan zur Verfügung.

    Startup Scan, Initial Scan, etc auch alles deaktivieren.

    Das wusste auch ich so auch noch nicht, danke.

    Ich habe dies gerade probiert. Bei mir funktioniert dies allerdings nur, wenn ich das IPTV Automatic Network neu anlege. Bei einem bestehenden Network ist dennoch ein Scan nötig, oder?

    Und dann fällt mir noch auf, dass die Services bei einem Scan zwar sofort vorhanden sind. Sinnvoll ist dies aber je nach Szenario dennoch nicht. Es werden dann nämlich auch Kanäle eingetragen, die zwar in der m3u stehen, technisch aber dennoch nicht nutzbar sind (z.B. wegen Geoblocking). Wenn es also nicht um eine sehr gut kuratierte Liste geht (Kodinerds, Telerising API), lohnt ein Scan dennoch. Oder verstehe ich dies falsch?

    Ich nutze in Home Assistant folgende Actions in einer Automation, um auf meinem FireTV Kodi zu starten (falls noch nicht an) und den Kodi-Homescreen in den Vordergrund zu holen:

    actions:
     - data:
         command: am start -a android.intent.action.VIEW  -n org.xbmc.kodi/.Splash
       target:
         entity_id: media_player.fire_tv_192_168_1_179
       action: androidtv.adb_command
     - data:
         method: GUI.ActivateWindow
         window: home
       target:
         device_id:
           - abcdef1234567890
       action: kodi.call_method
       enabled: true

    Dies funktioniert zwar, führt aber sporadisch dazu, dass bei Videos/TV-Streams nur der Ton zu hören ist. Offenbar führt die zweite Action im Code oben dazu, dass das Videobild überlagert werden kann. Hat jemand eine Idee, wie ich den Home Bildschirm in den Vordergrund holen kann, ohne dass es zu diesem Problem kommt?

    Eine funktionierende Lösung wäre, z.B. 5x hintereinander den Befehl für die Zurück-Taste aufzurufen. Dies funktioniert aber nur verlässlich, wenn die Befehle nicht direkt in Folge kommen. Das dauert dann aber leider zu lang, um eine praktikable Lösung zu sein.

    Mir fehlt bei vielen Filmbeschreibungen (besonders von deutschen Produktionen) ein Rating. In der ToDo wird die Einbindung von TMDb genannt. Ist dies in nächster Zeit angedacht? Wenn nicht, würde ich ggf. einmal versuchen, die xmltv-Datei nachträglich mit einem Script anzureichern. Ich selbst kann zwar nicht richtig programmieren, aber vielleicht klappt es ja mit dem Bing Copiloten. Damit habe ich schon erstaunlich viel hinbekommen.

    Moin an alle,

    ich lebe in Deutschland und möchte RTL, Sat1 und Co über ein schweizer Zattoo free Konto einbinden. Prinzipiell geht dies auch dank dns4me. Allerdings habe ich alle paar Sekunden ein stockendes Bild und/oder kurze Tonaussetzer. Mit gleichen Einstellungen und einem deutschen Zattoo free Konto (dann natürlich ohne dns4me) habe ich solche Probleme nicht. Ich vermute daher, dass es nicht an ffmpeg oder zu ändernden Einstellungen in der Telerising API liegt.

    Geht dies andere Nutzern auch so? Oder gibt es einen dauerhaft stabil funktionierenden Weg?

    Ich bin an dem Punkt angelangt, dass ich erwäge eine Sat-Schüssel anzuschaffen, weil es einfach nicht gelingen will. Könnt ihr mich davon abhalten...?

    Moin an alle,

    ich schaue häufiger zwei TV-Sender, die nicht in TMS enthalten sind. Glücklicherweise gibt es jeweils eine externe Xmltv-Datei, die ich auch erfolgreich einbinden konnte. Allerdings werden immer nur die nächsten 4 Stunden angezeigt. Da easyepg in den Einstellungen minimal einmalig pro Tag automatisch eine Aktualisierung holt, habe ich aktuell immer erst ab 20 Uhr ein EPG. Ich vermute, dies ist so, damit der TMS-Server nicht überlastet wird. Bei den beiden externen XMLTV-Dateien hätte ich diese Sorge nicht. Die Person, die sie hostet, weiß, was sie tut.

    Gibt es einen Weg easyepg dazu zu bringen, alle vier Stunden die xmltv-dateien abzurufen? Oder ist es möglich, easyepg mehrfach parallel laufen zu lassen? Dann könnte jede Instanz einmal täglich mit sechsstündigen Versatz die xmltv-Daten abrufen.

    Falls es keine Lösung geben sollte, könnte ich immer noch in meinem Proxmox-Server für jede Instanz einen eigenen Container nutzen. Oder gibt es einen eleganteren Weg?

    Kannst ja checken, ob der Stream verfügbar ist oder nicht. Falls ja, dann verarbeiten, ansonsten nicht. Ganz simple. Mußte dir nur anpassen.

    Code
    import requests
    response = requests.get(stream_url)
    if not response:
        print("Stream offline")
    else:
        print("Stream online")

    Oder vielleicht besser mit Status Code.

    Code
    import requests
    response = requests.get(stream_url)
    if response.status_code == 200:
        print("Stream online")
    else:
        print("Stream online")

    Du meinst, ich soll solch einen Check in mein Script einbauen? Bei mir läuft das Script ja stündlich durch. Angenommen so eine M3u hat 250 Kanäle, dann wären dies bereits 6000 Checks täglich, oder missverstehe ich die Lösung? Zudem sagt das Bestehen der Prüfung nicht aus, dass der Kanal dann auch in TVHeadend rund laufen wird. Er kann dennoch regelmäßig stocken, nach 10 Sekunden einfrieren o.ä.

    Oder verstehe ich deine Lösung vielleicht nur nicht, richtig?

    Vielleicht kennt ihr das Problem? Ihr kennt eine tolle (und natürlich legale) m3u-Quelle aus dem Internet, mit der ihr Fernsehsender sehen könntet, die nicht bei kodinerds-iptv berücksichtigt sind. Ein Beispiel wären z.B. Fernsehsender in einer Sprache, die nicht bei kodinerds-iptv berücksichtigt wird. Gerne würdet ihr sie in TVHeadend nutzen, nur leider fehlen in der m3u die nötigen Pipe-Angaben für ffmpeg. Nun könntet ihr die m3u herunterladen, formatieren und einbinden. Nur müsstet ihr diese lokale Datei dann auch regelmäßig selbst aktuell halten. Ärgerlich, schließlich gibt es ja schon eine Community, welche die m3u aktuell hält. Die Community wiederum will aber keine Variante mit Pipe pflegen und versteht vielleicht auch das Problem nicht.

    Ich möchte hier einmal eine Lösung beschreiben, die ich zusammen mit Bing Copilot vor einigen Monaten entwickelt habe und die für mich wirklich in der Langzeitbeobachtung gut funktioniert. Bei dieser Lösung wird die m3u-Datei regelmäßig automatisch heruntergeladen, mit Pipe-Angabe neu formatiert und lokal gespeichert. Die lokale Datei wird dann in TVHeadend eingebunden.

    Natürlich müssen nicht alle so eingebundenen Streams gut funktionieren. Vielleicht kommt beim "Pipen" kein brauchbarer Stream raus oder es gibt geo-blocking. Anders als bei kodinerds-iptv fehlt ein echter Mensch, der einen Stream vorab testet. Aber für diejenigen Streams, für die es klappt, ist dies eine tolle Möglichkeit.

    Hier die genauen Details. Zum Konvertieren nutze ich folgendes Python-Script:

    In der Datei muss man in Zeile 5 die URL anpassen und fast unten bei "# Datei speichern" den Pfad für die lokale Datei anpassen.

    Je nach Linux-Distribution hat man ggf. noch das Problem, dass Abhängigkeiten zu lösen sind. Unter Ubuntu 24.04 ist dies auf jeden Fall python3.12. Dies zu installieren kann etwas komplexer sein und es gibt mehr als einen Weg. Daher ist dies nicht Teil dieser Anleitung. Im Zweifel fragt die KI eures Vertrauens.

    Natürlich kann man auch mehrere derartiger Scripte anlegen und so mehrere m3u-Quellen parallel anpassen.

    Damit das Script / die Scripte regelmäßig aktuell gehalten werden, legt man Cronjobs an (mit dem Befehl cronjob -e). Je nachdem, wie eure Lösung wegen der benötigten Python_Version aussieht, können die Zeilen etwas anders aussehen. So sieht es z.B. bei mir aus:

    Code
    0 * * * * /bin/bash -c 'source /opt/python3.12/bin/activate && python /opt/beispiel/beispiel.py'
    @reboot /bin/bash -c 'source /opt/python3.12/bin/activate && python /opt/beispiel/beispiel.py'

    Die erste Zeile startet das Script (hier soll es beispiel.py heißen) zu jeder vollen Stunde. Die zweite Zeile startet das Script zusätzlich nach jedem Neustart.

    In TVHeadend legt ihr die lokal erstellte Datei dann als IPTV Automatic Network mit der Pfadangabe

    Code
    file:///opt/beispiel/beispiel.m3u

    (entsprechend anpassen) an.

    Falls der Code für das geschulte Auge schrottig sein sollte, bedenkt bitte, dass in erster Linie Bing Copilot der Autor ist. Die Lösung habe ich im Dialog mit der KI entwickelt. Immerhin funktioniert er für mich nun aber doch schon mehrere Monate verlässlich, sodass ich die Lösung nun teilen wollte.

    In ähnlicher Situation nutze ich für streamlink noch zusätzlich die Optionen --mux-subtitles --retry-streams 3 --retry-max 60 --retry-open 3 --player-continuous-http

    - mux-subtitles um auch optional Zugriff auf die Untertitel zu kriegen (und hls-audio-select="*" hat steinchen schon genannt). Insbesondere interessant, wenn man "richtig komplette" Aufnahmen machen will.

    - die anderen Optionen halfen nach meinen Tests bei Streams, die nicht immer 100% zuverlässig sind, Abbrüche zu verhindern.

    Command-Line Interface - Streamlink 6.7.4 documentation

    Ich bitte vorab um Entschuldigung, dass ich auf einen Beitrag vom Mai antworte. Ich habe lange in diesem Forum nicht mehr mitgelesen und bin nun am mich wieder einlesen.

    Verstehe ich den Beitrag oben richtig, dass es möglich ist, Untertitel von Zattoo mit Telerising über streamlink nach TVHeadend einzubinden? Das wäre für mich ein Gamechanger. Wegen dieser fehlenden Möglichkeit habe ich vor langer Zeit TVHeadend den Rücken gekehrt und Zattoo Premium Ch nur noch direkt in Kodi genutzt. Ich würde aber wirklich gerne mit TVHeadend-Aufnahmen mit Untertiteln anfertigen. Das müsste dann ja gehen.

    Eigentlich bin ich eher der Typ, der nicht in Foren schreibt, sondern einfach selbst ausprobiert. Das hat in diesem Fall aber nicht geklappt. Bevor ich hier detaillierter zu Fehlermeldungen frage, möchte ich mich einmal rückversichern, ob streamlink tatsächlich die Untertitel von Telerising an TVheadend weitegeben kann.

    Hier eine Info für DNS4me-Nutzer: Ich haben bei dns4me angefragt, warum man keine custom domains für die Schweiz mehr erstellen kann. Als Grund erhielt ich die Auskunft, dass sie diese Option wegen Missbrauchsbeschwerden entfernen mussten. Mit der Anwahl von Zattoo -> Schweiz werden aber ab heute automatisch folgende Adressen der Schweiz mitzugeordnet:


    3-zurich.s3.netstream.cloud
    web.netstream.tv
    e01-ch-dub-1.xcdn.iptv.ch
    e02-ch-dub-1.xcdn.iptv.ch
    e03-ch-dub-1.xcdn.iptv.ch
    e04-ch-dub-1.xcdn.iptv.ch
    e05-ch-dub-1.xcdn.iptv.ch
    netstream-ott.customers.xcdn.iptv.ch
    netstream-hls.customers.xcdn.iptv.ch

    Hier der Inhalt meiner Exception.txt:

    ERROR:root:'pro7maxx'
    Traceback (most recent call last):
    File "/home/niwi/telerising-api/app/routes/api.py", line 358, in channel_list
    File "/home/niwi/telerising-api/app/providers/zattoo.py", line 430, in get_rec_list
    File "/home/niwi/telerising-api/app/providers/zattoo.py", line 430, in <listcomp>
    KeyError: 'pro7maxx'
    INFO:werkzeug:127.0.0.1 - - [04/Apr/2021 21:12:22] "[37mGET /api/zch/file/recordings.m3u HTTP/1.1[0m" 200 -