[Docker] NEW Telerising-API Support Thread

    libreelec mit Docker und televising macht keinen Sinn. Lieber Xbian mit api Start über api Datei nehmen

    Hi, ich bin dank google über dieses Thema gestolpert und habe es ohne große Hoffnung einfach mal probiert.
    Was soll ich sagen: Es lief auf Anhieb perfekt mit netcologne nettv (das ich bis gestern für den größten SCH... auf Erden gehalten habe).

    Vielen Dank an easy4me und DeBaschdi! Das ist großartig!

    Zwei Fragen habe ich noch:
    1. Wie ist bei euch der visuelle Eindruck der iptv-streams? Obwohl sie als 1080p kommen, sehen sie etwas schlechter als die DVB-Streams aus, die nur mit 720p kommen (TV ist ein 65" 4k oled). Wenn ich auf die Bitrate schaue, ist die auch deutlich geringer als die des DVB-Streams.
    2. Im Docker-log erscheint periodisch: Missing EPG ID for ...
    Wenn ich es richtig verstanden habe, wird eh kein EPG abgerufen - wie bekomme ich diese Ausgabe weg?

    kannst du bitte n update auf 0.9.5 machen ? kann nichts mehr sehen :-S

    bitte gleich dazu schreiben wie man das ganze updatet.
    bin froh gewesen, dass ich alles zum laufen bekommen habe, und jetzt sowas :D meine frau will gleich DSDS gucken :D

    edit:verschrieben

    Das läuft glaube ich auch nicht mehr.
    Du kannst aber einfach den alles aus der telerising-v0.9.5_x86-64_linux.zip in den Ordner kopieren, den du auf /telerising gelegt hast und schon läuft es wieder:

    Zitat von H4ck3d

    kannst du bitte n update auf 0.9.5 machen ? kann nichts mehr sehen :-S

    bitte gleich dazu schreiben wie man das ganze updatet.
    bin froh gewesen, dass ich alles zum laufen bekommen habe, und jetzt sowas :D meine frau will gleich DSDS gucken :D

    edit:verschrieben

    hast du das update hinbekommen?

    ich habe noch version API v0.6.8 auf meinem omv6 im docker installiert, allerdings ist das bei mir auch gefühlt jahre her, und ich kann ich keine streams mehr schauen obwohl kein fehler vorliegt oder ich keinen finden kann.
    wie kann ich das jetzt updaten auf die neueste version?

    könnte mir da vielleicht jemand netterweise helfen?

    EDIT
    hat sich erledigt, drüber kopieren der neuen version geht einwandfrei

    Hallo zusammen,

    alter Leser, neuer Nutzer hier ;D.

    Folgende Konstelation. Grundsystem ist ein Supermicro Server H1 als XPenology mit DSM 7.1.1-42962 Update 1. Darauf ist, neben einigen anderen Programmen, installiert:
    Plex (Version 4.104.2), jedoch nicht aus dem Paketcenter, da dort die Versionen veraltet sind
    TVHeadend aus dem Paketcenter, HTS Tvheadend 4.3~d885496
    Docker aus dem Paketcenter

    Im Docker laufen aktuell (nur für dieses Projekt interessanten Docker):
    takealug/new-telerising-api
    thejf/antennas

    Telerising ist soweit eingerichtet mit 1und1.tv Daten. Einzelne Streams laufen auch im VLC etc., alles super.
    TVHeadend kann ich diese Streams auch Problemlos hinzufügen. Auch hier ist alles klasse.

    Plex findet auch den DVR mit allen Kanälen etc.. Nimmt Plex auch anstandslos an.

    Nun zum Problem. Weder lokal (http://meineip:32400) noch direkt über https://app.plex.tv/ kann ich die Streams Live TV und DVR starten. Es kommt ausnahmslos Fehler s1001 (Netzwerkfehler). Gleiche spielchen bei Apps für Konsolen. Im TVHeadend wird allerdings angezeigt (unter Status), dass der Stream bereits läuft.

    Nun zum kuriosen, absolut überall kommt der Fehler, mit einer einzigen Ausnahme. Am Smartphone (sowohl iOS sowie Android) mit der jeweiligen PlexApp aus dem Play- bzw. Appstore, läuft es Einwandfrei. Beinahe instant startet der Stream.

    Ich habe nur absolut keine Ahnung, woran es scheitert. Ich habe schon an den Transcodereinstellungen rumgespielt. Keine Besserung.
    Habe Antennas über SSH, ohne Docker, installiert und es getestet. Keine Besserung.

    Den DVR zig mal entfernt und wieder hinzugefügt. Alles neu aufgesetzt etc. pp.. FFMPEG ist alles korrekt hinterlegt. Ich verstehe es einfach nicht. Vor allem verstehe ich nicht den Unterschied, warum es über die schnöde MobileAPP läuft aber sonst nirgends. Habe jetzt schon 2 Nächte damit verbracht, den Fehler zu finden. Hier weitestgehend alles durchforstet, Dr. Google befragt, ja sogar ChatGPT (oh wunder, keine Lösung ;D).

    Selbst die TVHeadend-Log macht er anscheinend keinen Unterschied, ob der Stream nun vom Smartphone oder PC/Konsole/AndroidStick etc. abgerufen wird. Ich kann doch wirklich nicht der einzige Mensch sein, der dieses Problem hat.

    In Kodi läuft es mit dem TVHeadend-Plugin natürlich einwandfrei. Ich habe auch keinen Plan, wie ich Antennas noch extern testen kann.

    Vielleicht hatte hier jemand mal ein Ähnliches Problem. Ich vermute ja, ich sehe einfach nur den Wald vor lauter Bäumen nicht und es ist einfach nur irgendwo einen Haken setzen.

    LG
    Motverge

    Zitat von cyb3rgh05t

    Hallo,

    hat das hier jemand hinbekommen den Container mit einem VPN zu verbinden auf einem Desicated Server?

    Vielen Dank

    Nutze die Docker Variante nicht mehr. Hatte ich damals zu den Anfangszeiten von Telerising mal kurz. Und ja, zu der Zeit habe ich auch die Kombination mit VPN ausprobiert.
    Ich kann zwar nicht mehr so genau ins Detail gehen, da ich die ganzen Schritte nicht mehr so im Hinterkopf habe, aber du brauchst für die Lösung, die ich damals hatte, auf jeden Fall OpenVPN.
    Keine Ahnung, ob dein VPN Anbieter .ovpn Dateien bereit stellt.
    Falls ja, guck mal hier: https://github.com/Publish3r/dock…un-over-openvpn

    Zitat von Publish3r

    Nutze die Docker Variante nicht mehr. Hatte ich damals zu den Anfangszeiten von Telerising mal kurz. Und ja, zu der Zeit habe ich auch die Kombination mit VPN ausprobiert.Ich kann zwar nicht mehr so genau ins Detail gehen, da ich die ganzen Schritte nicht mehr so im Hinterkopf habe, aber du brauchst für die Lösung, die ich damals hatte, auf jeden Fall OpenVPN.
    Keine Ahnung, ob dein VPN Anbieter .ovpn Dateien bereit stellt.
    Falls ja, guck mal hier: https://github.com/Publish3r/dock…un-over-openvpn

    Vielen Dank

    Hallo und Juten Tach!

    Seit dem Update von API v0.10.1 auf API v0.10.3 (API v0.10.2 ist mir entgangen) befindet sich mein Container in einer Update-Schleife. Das Log sieht so aus:

    Das Problem läßt sich auf einem Odroid N2 mit CoreELEC, einem RockPi mit Ubuntu und einem RasPi mit Raspbian reproduzieren.
    Wie läßt sich das Problem mit den Bibliotheken (libm.so und libpthread.so) beheben?

    DeBaschdi nimmt direkt das von easy4me bereitgestellte Binary für die jeweilige Architektur aus dessen öffentlichem Repo. Für arm64 wird dabei ebenfalls die arm32/armhf binary genommen. Ergo müsste in diesem Fall das Problem irgendwo bei easy liegen. Vermutung, da ich das auch gerade bei meinem minimal Docker durch hab:

    Easy baut jetzt auf einem Bullseye basierenden Debian/Raspbian, und das läuft dann nicht auf einem Buster basierenden Debian/Raspbian weil Bullseye eine neuere GLIBC Version mitbringt

    Zitat von dlueth

    DeBaschdi nimmt direkt das von easy4me bereitgestellte Binary für die jeweilige Architektur aus dessen öffentlichem Repo. Für arm64 wird dabei ebenfalls die arm32/armhf binary genommen. Ergo müsste in diesem Fall das Problem irgendwo bei easy liegen. Vermutung, da ich das auch gerade bei meinem minimal Docker durch hab:

    Easy baut jetzt auf einem Bullseye basierenden Debian/Raspbian, und das läuft dann nicht auf einem Buster basierenden Debian/Raspbian weil Bullseye eine neuere GLIBC Version mitbringt

    Daß die Ursache am bzw im Container liegt, hab ich auch angenommen. Die Pfade im Log sind ja Container-intern.

    Jetzt hab ich nach etwas Bastelei Deinen Container auf meinem N2 (CoreELEC) ans Laufen bekommen.

    Zitat von dlueth

    DeBaschdi nimmt direkt das von easy4me bereitgestellte Binary für die jeweilige Architektur aus dessen öffentlichem Repo. Für arm64 wird dabei ebenfalls die arm32/armhf binary genommen. Ergo müsste in diesem Fall das Problem irgendwo bei easy liegen. Vermutung, da ich das auch gerade bei meinem minimal Docker durch hab:

    Easy baut jetzt auf einem Bullseye basierenden Debian/Raspbian, und das läuft dann nicht auf einem Buster basierenden Debian/Raspbian weil Bullseye eine neuere GLIBC Version mitbringt

    Danke für die Info, da ich zuhause aktuell Baustellentechnisch alles auf den Kopf stelle bekomm ich hier kaum noch was neues mit :D , am besten mich markieren wie dlueth es tat.

    Meine Image Version 0.0.3 basiert nun auch auf Bullseye, sollte also wieder funktionieren, ab 0.10.3 wird jetzt eben zwingend auch ein Containerupdate auf 0.0.3 benötigt.

    Containerversion 0.0.2 funktioniert nur bis API 0.10.2.

    Witerhin danke an easy4me für das fleißige erstellen der Binarys, ich hätte dafür mal so überhaupt keine Zeit.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden