Telerising API - Zattoo, blue TV & Sky CH für tvHeadend und VLC [Web App]

dlueth gute Nachrichten. Ich habe nun DietPi Bookworm (12) geladen und installiert, um meine Schande der letzten Nacht zu "vertuschen". Jetzt läuft alles einwandfrei, keine Libraries mehr zu tasuchen. Ich werde nun Bookworm (noch nicht) auf meinem Telerising Pi installieren, sondern weiterhin Bullseye nutzen, da dass austauschen der Libraries dort gut geklappt hat und jetzt auch sehr gut funktioniert. Nochmals vielen lieben dank für dieses Brett was du geliefert hast. Ich habe mich bereits einen neuen Pi Zero 2W kaufen sehen, ich bleibe also (noch) stur auf meinen Pi 1B sitzen, bis dieser auseinanderfällt Softwaremäßig natürlich.

LooseMyMindOnLinux das ist echt komisch, da bookworm ja neuer ist als bullseye. Aber bullseye war ja auch problematisch, was das Bauen angeht, weswegen ich letztlich auf Buster geblieben bin...

dlueth genau das habe ich auch nicht verstanden, als du erwähnt hast dass du Buster zum Kompilieren nutzt. Tatsächlich war es auch so, dass dein Docker GitHub-Build (ARM) auf Bullseye mit "Illegal Instructions" quittiert wurde, aber auf Bookworm mit den "ELF Align Fehlern" gegen den Libraries im Archiv, also vermutlich PageSize, oder andere Eigenarten, beendet wurde. Da habe ich dann auch schon versucht die Libraries gegen die von easy4meauszutauschen, endete dann aber letztendlich als "Speicherzugriffsfehler" wegen des inkompatibeln ARM32v7-Build. Zusammenfassend kann also gesagt werden, dass Bullseye gar nicht funktioniert, es sei denn man tauscht die Libraries gegen easy4me's Libraries aus. Oder man nutzt halt Bookworm ohne den ganzen Stress - noch. Ich bin gespannt was Debian Trixie (13) dazu sagt, das werde ich als nächstes testen. Zudem werde ich den ARM32v6-Build nochmal auf einem ARM32v7 Raspberry Pi 3B gegentesten, ob dieser wie vermutet auch funktioniert, hat noch nicht jemand getan soweit ich es sehen kann.

Natürlich ist das austauschen der Libraries keine Dauerlösung, die veralten ja auch zunehmend.

Debian ist sowieso manchmal anstrengend, dort sind die Libraries teilweise echt veraltet, selbst bei neueren OS-Versionen wie Bookworm. Wie oft musste ich auch Pakete nachbauen, weil die von Debian hoffnungslos veraltet sind. Ist aber jetzt schon Off-Topic, ich mache jetzt mal Schluss.

Danke dir und easy4me für die Bereitstellung dieses Projekts, Ihr seid spitze!

Zitat von Publish3r

Du könntest vielleicht mal in Telerising nen anderen Zattoo Server versuchen.

Das war es tatsächlich - ich habe von Auto auf einen anderen Server gewechselt und schwups, HLS7 ging. Alle anderen Einstellungen waren nicht nötig.

Danke!

Gruß

PS: Ich hatte diese Probleme auch unter VLC, nicht nur in Emby. Der Ton des Streams hat sich nach einiger Zeit wie eine hängende Schallplatte wiederholt.

Ich versuche gerade, die Kombination aus tvheadend und telerising API zum Laufen zu bekommen. Leider ist es problematisch. Das Abspielen mit VLC funktioniert sehr gut, aber die Ausgabe von ffmpeg hat Aussetzer, d.h. die Konvertierung von mpeg dash zu mpeg ts läuft nicht "glatt". (Ich habe das ausprobiert, indem ich den ffmpeg-Befehl aus der pipe in channels.m3u kopiert und die Ausgabe an ffplay weitergeleitet habe.) Damit werden leider in tvheadend auch die "muxes" nicht erkannt ("scan no data, failed").

Ein klein wenig besser funktioniert es (einige wenige "muxes" werden erkannt), wenn ich telerising auf HLS umstelle. Allerdings muss dann in der ffmpeg-pipe in channels.m3u das Eingabeformat mit "-f hls" explizit angegeben werden. Ich habe channels.m3u entsprechend editiert. ( easy4me:) Es wäre natürlich deutlich komfortabler wenn der Parameter bei der Kombination "Manifest type HLS" und "Retrieve streams via ffmpeg pipe" automatisch ergänz würde.

Zitat von getitdone

Ich versuche gerade, die Kombination aus tvheadend und telerising API zum Laufen zu bekommen. Leider ist es problematisch. Das Abspielen mit VLC funktioniert sehr gut, aber die Ausgabe von ffmpeg hat Aussetzer, d.h. die Konvertierung von mpeg dash zu mpeg ts läuft nicht "glatt". (Ich habe das ausprobiert, indem ich den ffmpeg-Befehl aus der pipe in channels.m3u kopiert und die Ausgabe an ffplay weitergeleitet habe.) Damit werden leider in tvheadend auch die "muxes" nicht erkannt ("scan no data, failed").

Ein klein wenig besser funktioniert es (einige wenige "muxes" werden erkannt), wenn ich telerising auf HLS umstelle. Allerdings muss dann in der ffmpeg-pipe in channels.m3u das Eingabeformat mit "-f hls" explizit angegeben werden. Ich habe channels.m3u entsprechend editiert. ( easy4me Es wäre natürlich deutlich komfortabler wenn der Parameter bei der Kombination "Manifest type HLS" und "Retrieve streams via ffmpeg pipe" automatisch ergänz würde.

Schau dir mal bitte die angehängten Screenshots an.

Settings aus Bild 1 machen, falls noch nicht gemacht.

Dann Playlist in TVH NEU EINLESEN! Natürlich die für FFMPEG PIPE, siehe Bild 2.

Edit:

Wenn du jetzt zwischen DASH und HLS7 umstellst, muss natürlich jedes mal die Playlist neu eingelesen werden, da jetzt die Dateiendung mpd oder m3u8 mit dranhängt. Allerdings brauchen manche FFMPEG Versionen die Dateiendungen.

Publish3r Danke! Wobei ich mich frage, ob das Aktivieren von "Enable m3u8/mpd Link extension" nicht sinnvoller Weise Standard sein sollte. (Denn ohne funktioniert es ja einfach nicht.)

(Aktivieren oder Deaktivieren von "-re" macht bei mir übrigens keinen Unterschied, das hatte ich schon vorher ausprobiert.)

Zitat von getitdone

das Aktivieren von "Enable m3u8/mpd Link extension" nicht sinnvoller Weise Standard sein sollte. (Denn ohne funktioniert es ja einfach nicht.

Bei mir schon, allerdings habe ich auch sehr sehr alte FFMPEG Version, scheint wohl eher bei den neueren Versionen nötig zu sein.

Zitat von getitdone

Aktivieren oder Deaktivieren von "-re" macht bei mir übrigens keinen Unterschied, das hatte ich schon vorher ausprobiert.

Scheint auch überall anders zu sein. Bei mir macht die -re Option bei DASH Probleme.

Ich bin ja gerade am Neuaufsetzen meines System!

Das System lief ja ursprünglich aufg einem Schweizer Server!Habe aber gelesen,das du nur für das "einlesen" der Schweizer Senderr in meinem Fall Sky eine Schweizer IP brauchst?

Wenn ja hole ich mir eine Schweizer IP füge die dann in Telerising ein und wenn dann die Sender im TVH eingelesen sind,füge ich die IP meines Pi´s in Telerising ein?

Ebenfalls habe ich gelesen das man die Größe des Speicherplatzes wo TVH die Aufnahmen speichert selber ändern kann!Wo mache ich das?

Es gibt ja für TVH verschiedene Grabbermodule wie WebGrab++ etc.Ichg habe bis jetzt dafür immer den Link vom easyepg genommen.

Was benutzt ihr in der Regel?Könnt ihr mir da etwas besseres empfehlen?Reicht das der Link vom easyepg aus?

Zitat von Jackie

Habe aber gelesen,das du nur für das "einlesen" der Schweizer Senderr in meinem Fall Sky eine Schweizer IP brauchst?

Sky CH braucht nur bei der Registrierung eine CH IP. Betreibst du Telerising lokal, ist keine CH IP mehr nötig. Zumindest für Sky nicht. Betreibst du Telerising auf nen VPS, kann es durchaus sein, dass die IP seitens Sky geblockt ist / wird. Dann macht es natürlich sinn einen Proxy o.ä. zu nutzen.

Zitat von Jackie

Ebenfalls habe ich gelesen das man die Größe des Speicherplatzes wo TVH die Aufnahmen speichert selber ändern kann!Wo mache ich das?

Bin mir jetzt nicht sicher, ob es das für Aufnahmen gibt, finde es gerade selber nicht, finde es nur für Timeshift und da geht es unter den Timeshift Settings.

Zitat von Jackie

Es gibt ja für TVH verschiedene Grabbermodule wie WebGrab++ etc.Ichg habe bis jetzt dafür immer den Link vom easyepg genommen.

Was benutzt ihr in der Regel?Könnt ihr mir da etwas besseres empfehlen?Reicht das der Link vom easyepg aus?

Könnte so funktionieren, gibt es hier im Forum auch irgendwo schon Anleitungen zu. Ich nutze allerdings den Grabber "Extern XMLTV" und den Einlesebefehl cat /path/to/easyepg/epg.xml | socat - UNIX-CONNECT:/path/to/tvheadend/xmltv.sock (muss natürlich angepasst werden). Ob diese Option besser ist? k.A. - muss jeder individuell entscheiden.

Edit:

Für Aufnahmen gibt es aber die Option anzugeben, wieviel Speicher noch frei bleiben soll. Siehe Screenshot.

Zitat von Publish3r

Sky CH braucht nur bei der Registrierung eine CH IP. Betreibst du Telerising lokal, ist keine CH IP mehr nötig. Zumindest für Sky nicht. Betreibst du Telerising auf nen VPS, kann es durchaus sein, dass die IP seitens Sky geblockt ist / wird.

Bin mir jetzt nicht sicher, ob es das für Aufnahmen gibt, finde es gerade selber nicht, finde es nur für Timeshift und da geht es unter den Timeshift Settings.

Könnte so funktionieren, gibt es hier im Forum auch irgendwo schon Anleitungen zu. Ich nutze allerdings den Grabber "Extern XMLTV" und den Einlesebefehl cat /path/to/easyepg/epg.xml | socat - UNIX-CONNECT:/path/to/tvheadend/xmltv.sock (muss natürlich angepasst werden). Ob diese Option besser ist? k.A. - muss jeder individuell entscheiden.

Edit:

Für Aufnahmen gibt es aber die Option anzugeben, wieviel Speicher noch frei bleiben soll. Siehe Screenshot.

Danke für die Infos!

Ich weiss nicht ob es bei mir ein Einzelfall war oder ob ich was falsch gemacht habe, aber vorletzte Woche als ich von TVheadend meine Telerising SKY CH streams einlesen lassen habe, wurde mein SKY Konto geblockt. Ein Anruf bei Sky brachte die Aussage es wurden ca. 400 Streams in kurzer Zeit abgefragt und von missbrauch ausgegangen. Konto wurde nach dem Anruf und Versicherung von mir, dass mein Account nur von mir genutzt wird wieder aktiviert.. hoffe die kommt bei Euch nicht vor. Gruss

Zitat von Walti

Ich weiss nicht ob es bei mir ein Einzelfall war oder ob ich was falsch gemacht habe, aber vorletzte Woche als ich von TVheadend meine Telerising SKY CH streams einlesen lassen habe, wurde mein SKY Konto geblockt. Ein Anruf bei Sky brachte die Aussage es wurden ca. 400 Streams in kurzer Zeit abgefragt und von missbrauch ausgegangen. Konto wurde nach dem Anruf und Versicherung von mir, dass mein Account nur von mir genutzt wird wieder aktiviert.. hoffe die kommt bei Euch nicht vor. Gruss

Man sollte beim Einlesen der Streams auch den Wert für die maximale Anzahl der Inputstreams von 0 (unlimitiert) auf 1 oder max. 2 setzen. Wo man das einstellt, siehe Screenshot. Wurde hier aber auch schon mehrfach geschrieben!

Das ist übrigens für alle Provider zu empfehlen, nicht nur für Sky.

Hat man alles eingerichtet kann man es wieder auf 0 setzen. Wobei ich, je nach Provider, auch evtl. 4 empfehlen würde.

Mein Wert stand auf 2, deshalb ja meine Verwunderung

Zitat von Walti

Mein Wert stand auf 2, deshalb ja meine Verwunderung

Ok, das wundert mich auch. Auch, dass der Account gesperrt wurde, höre ich zum ersten mal.

Man kann aber auch in TVH einstellen, dass die Streams direkt übernommen und nicht getestet werden, das nutze ich mittlerweile schon länger, da es auch wesentlich schneller geht.

Oh dies klingt spannend, kannst Du bitte kurz erklären wie dies geht?

Zitat von Walti

Oh dies klingt spannend, kannst Du bitte kurz erklären wie dies geht?

Unter Netzwerke, im jeweiligem Netzwerk, Service-ID von 0 auf 1 ändern.

Zitat von dlueth

So, hier nun die Binaries gesammelt mit der Bitte um Feedback: https://limewire.com/d/172c526f-e89…hQi_30RrmPLmk4A

arm32v6 war etwas anstrengender als erwartet, da Debian das gar nicht mehr offiziell bereitstellt, aber könnte/müsste laufen

Kurzes Feedback: ARM32v6 läuft auch auf Debian 13 (Trixie) - gute Nachrichten für die Zukunft. Zusammen mit Debian 12 (Bookworm) läuft also die Binary Out-of-the-Box mit den statischen Libraries aus dem Archiv. Nur Debian 11 (Bullseye) macht weiterhin ärger, ich werde es auch nicht mehr ergünden - da (oldstable) und somit irrelevant. ARM32v7 konnte ich noch nicht testen, finde meinen Raspberry Pi 3B einfach nicht mehr.

Ruhe in Frieden nello. Zumindest geht's von Oracle Cloud nicht mehr...

ERROR:root:Failed to retrieve channel playlist.
Traceback (most recent call last):
 File "/home/ubuntu/tr1/requests/models.py", line 974, in json
 File "/home/ubuntu/tr1/json/__init__.py", line 346, in loads
 File "/home/ubuntu/tr1/json/decoder.py", line 337, in decode
 File "/home/ubuntu/tr1/json/decoder.py", line 355, in raw_decode
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
 File "/home/ubuntu/tr1/app/providers/netstream.py", line 292, in load_channel_file
 File "/home/ubuntu/tr1/requests/models.py", line 978, in json
requests.exceptions.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
 File "/home/ubuntu/tr1/app/providers/netstream.py", line 296, in load_channel_file
 File "/home/ubuntu/tr1/app/providers/netstream.py", line 31, in do_request
Exception: Failed to fetch requested data.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
 File "/home/ubuntu/tr1/app/routes/api.py", line 494, in channel_file
 File "/home/ubuntu/tr1/app/providers/netstream.py", line 300, in load_channel_file

Zitat von ee8eiQuiedelei1U

Ruhe in Frieden nello. Zumindest geht's von Oracle Cloud nicht mehr...

Code

ERROR:root:Failed to retrieve channel playlist.
Traceback (most recent call last):
 File "/home/ubuntu/tr1/requests/models.py", line 974, in json
 File "/home/ubuntu/tr1/json/__init__.py", line 346, in loads
 File "/home/ubuntu/tr1/json/decoder.py", line 337, in decode
 File "/home/ubuntu/tr1/json/decoder.py", line 355, in raw_decode
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
 File "/home/ubuntu/tr1/app/providers/netstream.py", line 292, in load_channel_file
 File "/home/ubuntu/tr1/requests/models.py", line 978, in json
requests.exceptions.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
 File "/home/ubuntu/tr1/app/providers/netstream.py", line 296, in load_channel_file
 File "/home/ubuntu/tr1/app/providers/netstream.py", line 31, in do_request
Exception: Failed to fetch requested data.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
 File "/home/ubuntu/tr1/app/routes/api.py", line 494, in channel_file
 File "/home/ubuntu/tr1/app/providers/netstream.py", line 300, in load_channel_file

Alles anzeigen

Leider wahr, Schade drum