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

Hey,

also, nachdem thheadend alles gemuxt hat und ich alles gemapped habe haben alle Channels unter Channels/EPG als Channel Nummer eine 0. Ich gehe dann mühsam hin und verteile 115 Kanalnummern damit die Sender im Kodi richtig Nummeriert sind. ARD bekommt die 1 ZDF die 2 usw. Suche hierzu eigentlich nur einen weg dies zu vereinfachen.

Wenn die Frau also den TV startet und im KODI TV auswählt und dann z.B. die 4 drückt muss da RTL kommen.

Wenn ich 115 nummern über das Webif vergeben habe und mal was zurücksetzten möchte oder was neu mache muss ich das halt immer wieder machen und kann die Sortierung nicht einfach wieder herstellen oder zurück kopieren.

In Sat Zeiten gab es z.B. für ENIGMA2 einen Bouque Editor da hat man einfach alles sortiert und gespeichert. Musste die Box mal neu aufgesetzt werden dauerte es 10 Sekunden und man hatte seine alten Settings sofort wieder am laufen.

Kannst du mir jetzt folgen ?

Gruß Tux

Ich hatte mit der 'alten', archivierten telerising API mehr und mehr Probleme mit dem Provider 1und1.tv. Immer mehr Streams stockten, hatten Tonprobleme und nun scheint es fast alle Streams erwischt zu haben.
Ich habe nun zwei Tage draufgegeben um zu checken woran es liegt...
tvheadend auf dev aktualsiert
tvheadends [definition='1','0']log[/definition] von syslog in eine separate Datei gelenkt
ffmpeg downgraded
verschiedene Patches and der Zattoo.pl um ffmpeg zu manipulieren
verschiedene Kombinationen in der usersettings.json
Nichts hat geholfen.

Da ich meinen ganz TV Kram auf einem Nanopi M4 unter armbian laufen lasse, kann ich den Build der neuen telerising API, aus diesem Thread, darauf nicht laufen lassen. Also hab ich einen x86 Testserver mit Ubuntu 20.04 erstellt, um die neue API zu testen. Lief alles wunderbar und nachdem ich auf HLS7 geschaltet habe lief auch bei den 1und1 Streams wieder alles.

Good work!

Ich würde die alte API gerne mit der neuen auf meinem Nanopi M4 ersetzen. Die bisher verfügbaren Binaries laufen darauf aber nicht. Der verfügbare Raspbian armhf Build ist für 32-bit Architektur und läuft nicht auf 64-bit arm Systemen. Der 64-bit Linux Build zielt auf die x86 Architektur ab und ist deshalb nicht auf arm lauffähig.
=>Wäre es möglich einen arm64v8 build der neuen API zu erstellen?
Ich kann gerne dabei unterstützen!

Wird der Quellcode, wie in der vorherigen Version, wieder offen gelegt oder bleibt das Projekt mehr oder weniger closed source?
Man könnte Github dazu nutzen um automatisch Binaries für mehrere Architekturen zu erstellen. Ich da auch praktische Erfahrungen und kann diese sicher auch auf Python übertragen.

UPDATE
Grundsätzlich ist armhf 32-bit Code auch auf arm64 Architektur lauffähig. Deshalb habe ich etwas weiter in diese Richtung geforscht und es geschafft einen Container auf Basis von https://hub.docker.com/r/takealug/new-telerising-api bzw. https://github.com/DeBaschdi/docker.new-telerising-api zur bauen in dem die API auch auf meinen NanoPi M4 mit 64-bit OS läuft.

Ich werde das Vorgehen hier noch beschreiben und takealug ebenfalls noch kontaktieren.

UPDATE
Um es ohne Docker auf einem 64-bit Hostsystem laufen zu lassen ist folgendes nötig:

dpkg --add-architecture armhf
apt -qy update
apt install libc6:armhf

Docker:
https://github.com/DeBaschdi/dock…sing-api/pull/2

Zitat von DeBaschdi

Danke, ich schaus mit morgen mal an, mein qemu muss aber drinne bleiben, sonst klappt mein hub.docker cross build hook nicht.

Ah OK ich hab das erst später gecheckt als ich in den Code für das pre build event gesehen habe. Fette Sache die du da gebaut hast! Mit Docker builds habe ich mich noch nicht so sehr befasst.

@easy4me
Wird der Code noch auf Github zu finden sein? Ich würde wirklich gerne dabei unterstützen!

Nachdem nun alle Sender (1und1) wieder funktionieren die mit der alten Api nicht funktionierten habe ich das Problem dass einige der Sender die mit der alten Api funktionierten nun mit der neuen nicht laufen.
DMAX ist ein Beispiel dafür. Ich bekomme keine Tonspur und der Videostream ist nach knapp 30 Sekunden nur noch Brei.
Ich würde gerne herausfinden woran das liegt und mich ggfs. auch mehr in die Materie einarbeiten. Das Programmieren ist für mich kein Problem, ich verdiene mein Geld damit.

BTW: Ich habe überlegt ein ähnliches Projekt aus dem Boden zu stampfen und würde dafür Golang einsetzen. Man kann mit Golang sehr effizienten Code schreiben, es kommt eine einzige Binary heraus die keine weiteren Abhängigkeiten hat und es ist leicht Binaries für verschiedene Plattformen zu bauen. Das geht auch alles ohne viel Aufwand mit dem Github CI. Bei einem Release werden die Builds auch gleich als Assets eingefügt. Man schreibt nur noch Code checkt ein, tagged und released und Rest passiert automatisch auf Github.
Ich mache aber gerne bei Deinem/Euren Projekt mit und nutze eine andere Sprache, das ist für mich kein Glaubenskrieg sondern immer eine pragmatische Entscheidung mit möglichst wenig Aufwand zum Ziel zu kommen.

Tolles Skript! Funktioniert mit den meisten ÖR Programmen einwandfrei. Leider habe ich bei allen privaten Sendern (RTL, Pro7) jeweils alle 4 Sekunden im Wechsel mit dem normalen Fernsehbild eine Hinweistafel "We seem to have a problem here - The source signal is interrupted, we are working on a fix". Der Ton läuft dabei ohne Unterbrechung weiter - getestet mit Version 4.0.6 unter Ubuntu 20.04 sowohl unter VLC als auch tvheadend (mit ffmpeg). Plattform ist auch egal (hls, hls5, hls7), ebenso der Account (Zattoo Free oder 1&1, also auch unterschiedliche Server). Im Logfile von telerising gibt es keine Einträge, allerdings weiss ich hier nicht, wie ich den Loglevel erhöhen kann (umstellen von "fatal" auf "[definition=12,0]debug[/definition]" scheint keine Auswirkung zu zeigen. Tvheadend loggt "continuity errors".

Hat jemand eine Idee wo das Problem liegt? Die Hinweistafel scheint ja von Zattoo zu kommen, das finde ich sehr merkwürdig...

Leider verarbeitet auch weder VLC noch tvheadend die von telerising erstellte Channel-List, d.h. ich muss die Angaben aus der M3U-Datei manuell in VLC als Netzwerkstream öffnen.
also
http://192.168.1.111:8080/?file=channels.m3u&bw=8000&platform=hls
kann VLC nicht verarbeiten, die Angabe eines bestimmten Senders (hier: CNN)
http://192.168.1.79:8080/index.m3u8?channel=cnn-international&platform=hls
hingegen schon.

Dito tvheadend. Ich muss für jeden Sender einen Mux hinzufügen weil die Angabe zum m3u-File (erzeugt mit

http://192.168.1.111:8080/?file=channels.m3u&bw=5000&platform=hls5&ffmpeg=true

nur zu einem "FAIL" beim Scannen des MUX in tvheadend führt). Öffne ich das m3u file mit einem Editor und richte einen einzelnen Stream von Hand (pipe-Kommando) als neuen MUX ein, so funktioniert es (für diesen einzelnen Stream).

Hättest du den ersten Post gelesen, würde dir auffallen, dass du ne ganz andere api benutzt. Das ist gleichzeitig die Lösung für dein Problem.

Tach zusammen,
ich weiß nicht, ob es schon mal jemand probiert hat, das Script parallel zu einem pihole auf raspbian buster zum Laufen zu bringen. Bei mir scheitert es - vermutlich, weil auch pihole einen http-Daemon installiert. Beim Start meldet telerising:

* IPv4 address: 127.0.1.1
 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

Ich denke mal, da kollidieren die Interfaces. Wenn ich die API auf Port 5000 anspreche, gibts ein "internal server error" und im [definition='1','0']log[/definition]:

192.168.77.8 - - [14/Mar/2021 15:47:34] "GET / HTTP/1.1" 302 -
192.168.77.8 - - [14/Mar/2021 15:47:34] "GET /login HTTP/1.1" 302 -
[2021-03-14 15:47:34,535] ERROR in app: Exception on /signup [GET]
Traceback (most recent call last):
  File "/home/pi/telerising/flask/app.py", line 2447, in wsgi_app
  File "/home/pi/telerising/flask/app.py", line 1952, in full_dispatch_request
  File "/home/pi/telerising/flask/app.py", line 1821, in handle_user_exception
  File "/home/pi/telerising/flask/_compat.py", line 39, in reraise
  File "/home/pi/telerising/flask/app.py", line 1950, in full_dispatch_request
  File "/home/pi/telerising/flask/app.py", line 1936, in dispatch_request
  File "/home/pi/telerising/app/routes/views.py", line 48, in signup
  File "/home/pi/telerising/flask/templating.py", line 138, in render_template
  File "/home/pi/telerising/jinja2/environment.py", line 930, in get_or_select_template
  File "/home/pi/telerising/jinja2/environment.py", line 883, in get_template
  File "/home/pi/telerising/jinja2/environment.py", line 857, in _load_template
  File "/home/pi/telerising/jinja2/loaders.py", line 115, in load
  File "/home/pi/telerising/flask/templating.py", line 60, in get_source
  File "/home/pi/telerising/flask/templating.py", line 89, in _get_source_fast
jinja2.exceptions.TemplateNotFound: signup.html
192.168.77.8 - - [14/Mar/2021 15:47:34] "GET /signup HTTP/1.1" 500 -
192.168.77.8 - - [14/Mar/2021 15:47:34] "GET /favicon.ico HTTP/1.1" 404 -

Insofern ist die Config per Web-API sicher ganz komfortabel, aber nicht immer optimal. Eine optionale config per command oder Datei wäre vielleicht eine Idee wert?
Gruß

mal die Ports vergleichen. Sollte normal gehen.

Zitat von rolapp

mal die Ports vergleichen. Sollte normal gehen.

Hab meinen Beitrag nochmal editiert. pihole läuft auf 80, telerising auf 5000. Erzeugt obiges [definition='1','0']log[/definition].

Zitat von easy4me

Was wohl eher daran liegt, dass das Skript nicht im korrekten Ordner ausgeführt wird:
jinja2.exceptions.TemplateNotFound: signup.html

Wenn der Port blockiert ist, sollte eine Möglichkeit im Terminal erscheinen, einen anderen Port einzugeben. Ansonsten kann man den Port in die Konfigurationsdatei eintragen ("settings.json").

Guter Tipp, danke!

Zuerst einmal vielen Dank für das die neue API und das Update.

In Version 0.5.3 und auch 0.5.4 ist noch ein kleiner Fehler bei der Eingabe der Jugendschutzpin über das Webinterface.
Wenn die 4-stellige PIN mit einer 0 beginnt, wird die Eingabe nicht akzeptiert -> "PIN must consit of 4 numbers"

1234 -> i.O.
0123 -> n.i.O.

(1&1 TV auf PI3 mit OSMC)

Workaround ist die Eingabe in die Konfigurationsdatei ("settings.json").

Ich bekomme die Streams mit VLC nicht mehr geöffnet - noch jemand Probleme damit? Auf dem selben Rechner mit Kodi keine Probleme, aber unter VLC wollen die Sender nicht mehr (sowohl channels.m3u als auch direkt URL). Habe ich sowohl mit v.0.5.5 als auch v.0.5.3, weiter drunter habe ich nicht getestet, aber mit der allerersten Version ging es damals. Ich sehe in der Konsole gar keine get-Anfrage, wenn ich einen Sender öffne bzw. wechsle.