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.
Beiträge von niwi
-
-
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:
- Die Sendung hat keine feste Startzeit. Ein einfacher Timer würde also nicht reichen.
- 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:
- 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.
- 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: trueDies 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.
Codeimport requests response = requests.get(stream_url) if not response: print("Stream offline") else: print("Stream online")
Oder vielleicht besser mit Status Code.
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:
Code
Alles anzeigenimport requests import re # URL der m3u-Datei url = "https://bei.spiel/beispiel.m3u" # Datei herunterladen response = requests.get(url) content = response.text # Funktion zum Extrahieren des Kanalnamens def extract_channel_name(extinf_line): match = re.search(r',(.+?)(?: \(|$)', extinf_line) return match.group(1) if match else "Unknown" # Zeilen anpassen def adjust_lines(content): lines = content.splitlines() adjusted_lines = [] channel_name = "" for line in lines: if line.startswith("#EXTINF"): channel_name = extract_channel_name(line) adjusted_lines.append(line) elif line.startswith("http"): # Leerzeichen in der URL mit \ maskieren url = line.strip().replace(" ", "\\ ") # Kanalname f r ffmpeg-Befehl maskieren metadata_name = channel_name.replace(" ", "\\ ") adjusted_lines.append(f"pipe://ffmpeg -loglevel fatal -i {url} -metadata > else: adjusted_lines.append(line) return "\n".join(adjusted_lines) # Neue Datei erstellen new_content = adjust_lines(content) # Datei speichern with open("/opt/beispiel/beispiel.m3u", "w") as file: file.write(new_content) print("Datei erfolgreich angepasst und gespeichert.")
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:
Code0 * * * * /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
(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.
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 - -
-
Um es kurz zu fassen,
geht nicht, du brauchst 2x tvheadend.
Je Tvheadend instanz gibt es nur ein listen port der je device zugeordnet werden kann.**edit
Schau dir mal Docker anDanke schön für die klaren Worte und den Tipp mit Docker (-:
Docker ist tatsächlich noch recht neu für mich. Gibt es da eine leicht verständliche Anleitung konkret zur Einrichtung mit TVHeadend und Telerising? Wenn nicht, muss ich das aus Zeitgründen erst einmal auf einen späteren Zeitpunkt verschieben.
-
Für den reibungslosen Betrieb ist erforderlich, dass der Client (dein TVHeadend-Server) per Schweizer IP den Stream abruft.Das führt aber wiederrum zu komplikationen mit dem deutschen Account.
Vermutlich brauchst du zwei TVHeadend-Server
1x für den deutschen free-account und schweizer Premium-Account (läuft dann im PVR-Modus)
1x für den Schweizer Free-Account. (mit entsprechendem Host-Eintrag für den Prozess, dass der DNS4Me-Dienst nur hier greift).Das ist nicht die Lösung, sondern der von mir im ursprünglichen Posting beschriebene Status Quo, den ich verbessern will.
-
@niwi
[...] Ich weiß jetzt nicht mehr genau, was du nutzt, aber nehmen wir mal an nen Raspi. Dort nutzt du ja z.B. eth0 als Netzwerkadapter. Dieser hat jetzt Beispielsweise die deutsche IP.Nun legst du einfach einen neuen virtuellen Netzwerkadapter an, eth1. Und dem musst du dann das DNS4Me zuordnen.Ich habe einen intel-basierten Mini-PC mit zwei Netzwerkkarten und Ubuntu 20.04. Dein Vorgehen oben hatte ich auch schon getestet. Die Netzwerkkarten erhielten die je passende DNS.Adresse für Google (8.8.8.8 = mein tatsächlicher deutscher Aufenthaltsort) oder von dns4me (= Schweiz). In der jeweiligen userfile.json von Telerising gab ich außerdem an, welche Netzwerkkarte zu nutzen sei.
Dies funktionierte dann aber nicht stabil. Unabhängig von meinen Einstellungen wurde mal der Google-DNS-Server und mal der Dns4me-DNS-Server von den Telerising-Instanzen genutzt.
-
@niwi
Frag mich jetzt nicht genau wie, da müßten die Linuxprofils ins Detail gehen, aber man kann ein zusätzliches virtuelles Netzwerk installieren.
Dann könntest du beide APIs getrennt nutzen. Eine API auf dem Netzwerk mit schweizer DNS und das andere ganz normal mit deutscher IP.
Ich hab das vor Monaten mit langer Google-Arbeit mal auf einer VM realisiert. Allerdings mit schweizer VPN und deutscher normalen IP.
Müßte aber ähnlich funktionieren.
Nur wie gesagt, so ne Anleitung würde ich jetzt nicht mal eben so auf die Kette bekommen.Was du mit der VM beschreibst, ist gar nicht so schwierig, Das ist ja meine bisherige Lösung für eine zweite schweizer Zattoo-Instanz. Man richtet mit VirtualBox eine zweite Linuxinstallation mit TVHeadend ein. In dieser baut man dann die Internetverbindung mit einem schweizer VPN-Anbieter auf oder nutzt (wie ich) einen Smart-DNS-Anbieter (bei mir dns4me.net). Wenn man will, kann man dann noch die Streams der einen TVHeadend-Instanz in die andere integrieren oder man nutzt sie halt separat. Solange der Rechner leistungsstark genug ist, funktioniert dies sehr gut. Diese Lösung gefällt mir aber nicht. Sie braucht viel Speicher und Rechenleistung, die ich gerne anders nutzen würde. Außerdem ist der Konfigurationsaufwand sehr hoch.
Ich hoffe daher darauf, dass irgendjemand es schon eleganter hinbekommen hat und mit uns vielleicht seine Config-Dateien teilen möchte...
Hier mal ein paar Ideen, die aber bei mir leider nicht funktioniert haben:
- Ich habe drei Telerising-Instanzen auf dem selben Server mit deutscher IP eingerichtet. Jede Instanz war mit einem anderen Zattoo-Server und unterschiedlichen Ports konfiguriert. Eine Instanz war für mein deutsches Konto eingerichtet, eine mit meinem schweizer Premiumkonto und eine mit dem kostenlosen schweizer Konto meiner Frau. Dann habe ich für das kostenlose schweizer Konto meiner Frau unter /etc/hosts den passenden Eintrag für dns4me hinterlegt. Nach meinem Verständnis hätte die schweizer Telerising-Instanz nun Zattoo mit schweizer IP "kontaktieren" müssen. Telerising meldete nach einem Neustart aber weiter, dass ich nicht in der Schweiz sei.
- Ähnlich wie 1, nur dass mein Server dank DNS4Me Zattoo mit schweizer IP kontaktierte. Innerhalb der DNS4Me-Webseite habe ich dann konfiguriert, dass der Zattoo-Server den meine deutsche Telerising-Instanz nutzte, mit deutscher IP versorgt wurde. Auch dies hat aber nicht funktioniert.