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

Ok, und wie werden die Spuren jeweils konkret ausgewählt von dem was vom jeweiligen Sender kommt?
Ist es immernoch empfehlenswert an dieser Stelle nur eine Audiospur in Telerising zu definieren?

easy4me, bei Telerising kann und will ich nicht mitreden. Mit ffmpeg habe ich einige Erfahrung. Nach meiner Erfahrung führt normalerweise das Hinzufügen von weitern Audiospuren ins Mapping nicht zu merklichen Verzögerungen. Hast du da wirklich andere Erfahrung gemacht? Ist für mich auf Anhieb nicht plausibel, aber mit den ganzen Anbietern, die telerising unterstützt habe ich keine Erfahrung. Auch wenn, könnte es dennoch für manche User sinnvoll sein.

Wenn man beispielsweise eine HLS Index-m3u8 hat, die nur eine Videoqualität anbietet, nehme ich typischerweise was wie (nur für die Diskussion wichtige Optionen) ffmpeg -i https://domain.org/path/to/index1080p.m3u8 -map 0 -c copy -copy_unknonw output.ts Dann hat man alle Audiospuren und alle Untertitel-Spuren dabei. Bei Audio könnte es z.B. eine AC3-Spur in Deutsch, eine mpeg2 in Original-Sprache, eine mit Audiodescription, ... sein und bei Untertiteln auch Deutsch und Originalsprache.

Viele HLS oder DASH haben nur eine Audio-Qualität - da passt es grundsätzlich. Leider hat man bei verschiedenen Video-Qualitäten in der index.m3u8 ein Problem mit map 0, da werden dann alle bearbeitet. Wenn man die Spuren kennt, kann man die richtige rauspicken, dann hat man aber kein allgemeingültiges Kommando mehr. Eine ffmpeg-Option, mappe die beste Videoqualität und alle Audio und alle Subtitle Streams kenne ich nicht und gibt es vielleicht nicht (ich habe gesucht und nix gefunden). Streamlink kann sowas leider auch nicht (konnte es jedenfalls nicht, als ich zuletzt geprüft hatte - Details habe ich jetzt vergessen, vielleicht lag es dort nur an den Subtitles). Für mich hatte ich mal einen eigenen HLS Parser geschrieben, der das richtige ffmpeg Kommando erzeugt - habe aber leider nicht mehr aktualisiert auf aktuellere HLS, mit separaten Audio und Subtitle-Streams, wie sie heutzutage sinnvollerweise oft verwendet werden. Früher war ja immer alles in einem Stream pro Videoqualität zusammen drin.

Ok. Dennoch, war nicht ganz klar wie du "nur feste Mappings" meintest. Schien im Kontext der Anfrage von Angus.MacGyver bisschen zu implizieren, dass man nicht alle Audiospuren auswählen kann (aber vielleicht interpretiere ich die Aussage falsch). Mit -map 0 wie in meinem Beispiel geht es schon.

Dein Argument verstehe ich. Allerdings benötigt halt ein zusätzlicher Audiostream vielleicht gerade mal einstelligen Prozentanteil an Paketen eines Video-Streams. Klar, bisschen Overhead kommt noch dazu, bei modularen Streams. Ich hatte (vor wenigen Jahren) das sorgfältig getestet und beispielsweise die meisten meiner Streams in tvheadend auf -map 0 umgestellt und konnte keinerlei Verzögerungen feststellen. Ich hatte in der Tat auch mit Stoppuhr Zapping-Zeiten und Weiteres gemessen. Andere ffmpeg-Optionen, z.B. -analyzeduration hingegen machten einen signifikanten Unterschied. Bei der klassischen Methode der HLS (ohne separate "modulare" Audio- und Video-Streams, sondern alles zusammen gemuxt in einem Transport Stream) kann man Netzwerk-mäßig Richtung WAN gar nix sparen, durch Nicht-Berücksichtigen aller Audio-Streams.

Will hier auch nicht zu viel off topic diskutieren - vielleicht ist manche meiner Info neu für dich. Ansonsten gerne ignorieren. Eine Intention von mir ist auch Barriere-Freiheit. Sehe, dass hier im Kodi-Umfeld, das manchmal etwas kurz kommt. Hatten vor nicht allzu langer Zeit Diskussion zu fehlenden Untertiteln. Einfache Sprache oder Audiodeskription kann leicht verschütt gehen. Natürlich kann man und will ich da keine Forderungen stellen - nur Anregungen geben ...

Wenn es in Deutschland frei zugängliche HLS oder DASH-URL gibt, die durch zusätzlichen Audiostream in der ffmpeg-Verarbeitung merkliche Verzögerungen bewirkt, wäre ich interessiert, mir das mal anzusehen.

Zitat von skifahrer

Es reicht eigentlich, in xteve die m3u von telerising per Playlist einzulesen (ohne ffmpeg) und dann die Kanäle zuzuordnen. Dann bei plex einbinden. So funktioniert es bei mir...

Das hatte ich zuerst versucht. Mit Apps wie "IPTV-Player" lässt sich dann die Playlist auch von xTeVe abspielen, jedoch erhalte ich bei Plex eine Fehlermeldung und in den Logs taucht eine Fehlermeldung (Unknown Content Type war es glaube ich) auf. Nach meiner Recherche unterstützt Plex keine HLS streams, diese müssen mit einer ffmpeg pipeline zu MPEG-TS umgewandelt werden. Habe jetzt statt xTeVe auch Threadfin ausprobiert, jedoch mit dem gleichen Ergbenis.

Ist es bei dir auch ein 1und1 Account den du so eingebunden hast? Mich würden dann die Einstellungen interessieren, damit ich die ffmpeg Pipeline nicht benötige.

Hallo

Besteht die/eine Möglichkeit, bei telerising (api) v0.14.x insbesondere mit Bezug auf " YalloTV (ohne account!)" die "Umschaltzeiten" zu optimieren, beim telerisng Program-Coding oder anderweitig?

Im Vergleich zappt es sich bei Zattoo.ch - hier eben mit free account - zügiger...

Danke

Zitat von herbert08

Hallo

Besteht die/eine Möglichkeit, bei telerising (api) v0.14.x insbesondere mit Bezug auf " YalloTV (ohne account!)" die "Umschaltzeiten" zu optimieren, beim telerisng Program-Coding oder anderweitig?

Im Vergleich zappt es sich bei Zattoo.ch - hier eben mit free account - zügiger...

Danke

Ich glaube da wird es nicht viel zum Optimieren geben. Dass Yallo im Free Modus etwas länger braucht, könnte am Workaround für die geschaltete Werbung liegen, die normalerweise vor dem Stream läuft.

Hi, I have a question about the proxy feature.

Should it work when using the m3u8 list, or is it only for the built in web player??

My current setup is:

docker openvpn
- docker telerising with --net over the vpn
- docker liveproxy with --net over the vpn
- xteve
- plex

this is because i need the stream to be over the vpn.

Today I saw telerising has a proxy feature, so i enabled it, turned off liveproxy, reconfigured xteve and plex from scratch.

But streams fail to start.

Is there anyone with a similar setup that could help me figure it out?

Thanks

Probleme mit waipu, wenn mehrere Streams gleichzeitig verwendet werden:

Ich habe jetzt mal Telerising mit der providers.json für 5 Devices/Streams von fds97AVVS S getestet.
Für waipu.tv habe ich jetzt 4 Provider in Telerising angelegt.
Anschließend wurden in TVH 4 DVB-Inputs -> Networks nach diesem Muster angelegt:

Beim Mappen der Services aus den Muxes muss man bei "Merge same name" einen Haken setzen, damit werden die Muxes zusammen gefügt, so dass nur jeweils 1 Channel bekommt. Das hat alles soweit gut funktioniert und ich kann alle Sender/Streams im PVR-Addon Tvheadend-HTSP-Client anschauen.

Die ersten gravierenden Probleme kamen, als ich probierte im PVR-Addon die Funktion Streaming -> voraussagendes Tuning mit. z.B 2 oder 3 Sendern zu aktivieren. Damit konnte ich früher bei Zattoo wirklich sehr schnell (<1 Sek.) durch die Sender/Streams zappen.

Wenn ich das jetzt hier bei waipu mache, dann wird der Stream immer wieder unterbrochen, stockt und geht dann, wenn man Glück hat nach 5 ... 10 Sekunden weiter. Und genau das gleiche passiert dann, wenn man z.B. eine Aufnahme macht und weiterzappen will.
Entweder wird die Aufnahme unterbrochen, stockt oder der Live-Stream wird unterbrochen und geht dann irgendwann weiter.
Das kann man sehr gut im TVheadend -> Status -> Stream beobachten, denn dann haben plötzlich Streams eine "Bandwith = 0" , also es werden Null daten übertragen.

Da konnte ich auch beobachten, dass es auch dazu kam, das der empfangene Stream das verwendete Network gewechselt hat.

Da diese Problem vorher mit Zattoo, wo man ja für die 4 Streams nur 1 TVH-Network gebraucht hat, nicht vorhanden war, vermute ich, dass es an TVheadend liegen muss.
Bei zattoo konnte ich problemlos 2 oder 3 Aufnahmen gleichzeitig machen und dann noch mit dem 4. Stream durchs LiveTV zappen.

Meine Einstellungen für das IPTV-network, wie ich es für die 4 waipu-Streams erstellt habe, sind oben zu sehen.
Bis auf den "Network name" und die "URL" ist alles gleich eingestellt.

Die Frage wäre, ob das überhaupt so funktioniert, wie von mir gedacht?
Hat das jemand überhaupt so am Laufen und kann damit flüssig Aufnahmen + LiveTV machen?

Gibt es ein paar Tipps, wo ich da evtl. noch etwas einstellen kann/muss, damit es flüssig läuft und ich vor allem 1 oder 2 Aufnahmen plus LiveTV gleichzeitig zum laufen bekommen kann.

Paust55 hast du auch wirklich bei jedem der 4 devices die richtige url drin, und nicht immer die gleiche?

ich hab hier 2x waipu und in hochzeiten bis zu 10 streams ohne problem.

• wpu/file/favorites.m3u
• wpu2/file/favorites.m3u
• wpu3/file/favorites.m3u
• wpu4/file/favorites.m3u

Oh Mann, ist das peinlich.
Ich war mir absolut sicher für jedes IPTV-Network die separate URL von Telerising übernommen zu haben.

Jetzt habe ich nochmals genau nachgeschaut und 3x die gleiche URL eingetragen!

Ich habe es nochmals neu gemacht und nun folgende URLs in den IPTV-Networks direkt von Telerising übernommen:

• http://192.168.1.3:5000/api/wp2/file/f…m3u?ffmpeg=true
• http://192.168.1.3:5000/api/wp22/file/…m3u?ffmpeg=true
• http://192.168.1.3:5000/api/wp23/file/…m3u?ffmpeg=true
• http://192.168.1.3:5000/api/wp4/file/f…m3u?ffmpeg=true

Ich benutze die "waipu.tv (Wb/Mobile)" bei Telerising, deshalb sieht das wohl etwas anders aus, dürfte aber trotzdem passen.
Okay, jetzt werde ich nochmals testen und hoffen das nun alles wie gewünscht klappt!

Zitat von Paust55

http://192.168.1.3:5000/api/wp4/file/f…m3u?ffmpeg=true

wp4 = wp24

Nö, das kommt bei Telerising mit "wp4" raus.
Vielleicht in der "providers.json" so definiert?

Oder gibt es inzwischen eine neuere Version der "providers.json", als die die ich aus meinem verlinkten Beitrag habe?

Testen kann ich leider erst am späten Abend, da ich jetzt am VDR/KODI-PC nicht rumspielen darf/kann!

easy4me

then something else is wrong, telerising is on 192.168.0.200:5000, and if I browse to it and login I can open the web player and stream just fine.

But plex doesn't work, the logs from xteve say this:

2025/06/23 21:56:48 [Threadfin] Buffer:                 false [-]                                                                                                                                                       
2025/06/23 21:56:48 [Threadfin] Channel Name:            ITAL1HD                                                                                                                                                        
2025/06/23 21:56:48 [Threadfin] Client User-Agent:      Lavf/LIBAVFORMAT_VERSION
2025/06/23 21:56:48 [Threadfin] Streaming URL:          http://192.168.0.200:5000/api/tby/live/344.m3u8
2025/06/23 21:56:48 [Threadfin] Streaming Info:         URL was passed to the client.
2025/06/23 21:56:48 [Threadfin] Streaming Info:         Threadfin is no longer involved, the client connects directly to the streaming server.

so I know the plex server is receiving the correct url, but it still fails with the message Could not tune channel. Please check your tuner or antenna.
One thing I had to do to make it work with liveproxy, was to pass extra parameters to ffmpeg.

Can I do that in telerising and pass -copyts -f mpegts to ffmpeg, or is some other application doing the proxy?

Zitat von Paust55

Ich benutze die "waipu.tv (Wb/Mobile)" bei Telerising, deshalb sieht das wohl etwas anders aus, dürfte aber trotzdem passen.

So, ich habe jetzt getestet, mit jedem IPTV-Network eine eigene URL von Telerising.
Den Test habe ich auf die Schnelle mit dem PVR-Addon Tvheadend-HTSP-Client gemacht und da die Funktion Streaming -> voraussagendes Tuning mit 3 Streams eingestellt.

Das Ergebnis war etwas ernüchternd, denn es war noch nicht so richtig rund, denn es kam immer noch zu Aussetzern im Stream.

Dann habe ich mir gedacht, wenn fds97AVVS bei Telerising die Provider "waipu.tv (Smart TV)" nimmt und nicht wie ich bisher immer die "waipu.tv (Web/Mobile)", dann teste ich nochmals damit.
Also in Telerising die neuen Provider "waipu.tv (Smart TV) 1 ... 4" eingerichtet und in TVH die IPTV-Networks mit den neuen URLs versorgt. Nach dem Muxen und Mappen der erste Test mit dem PVR-Addon:
**** Alles läuft wie geschmiert, rund und flüssig. Keine Aussetzter mehr bei den Streams! ****

Endlich läuft es so wie es sein soll. Perfekt!
Danke an easy4me für das Addon und fds97AVVS für die Hilfe!

Tests mit Aufnahmen usw. mache ich dann Morgen, aber ich denke das wird nun auch perfekt klappen!
Da muss also zwischen dem "waipu.tv (Smart TV)" und dem "waipu.tv (Web/Mobile)" doch noch etwas anderes in der Bearbeitung bei waipu.TV sein, als nur der unterschiedliche Anmelde-Login.

Update zu 1&1 TV -> Telerising -> Threadfin -> Plex:

Ich konnte das Problem lösen, dass die Streams in Plex nicht liefen: Die Performance vom RPi 5 war tatsächlich zu gering!

Nachdem ich Telerising & Threadfin auf der Synology aufgesetzt habe, funktioniert die Einbindung in Plex prima! Vielen Dank für das tolle Projekt easy4me!

Abschließend möchte ich hier noch meine FFMPEG Pipeline Settings festhalten, falls jemand anderes Probleme bei der Einbindung von 1&1 TV in Plex hat:

-hide_banner -loglevel error -analyzeduration 500000 -probesize 500000 -i [URL] -map 0:v -map 0:a:0 -c:v copy -c:a libmp3lame -b:a 192k -ac 2 -c:s copy -f mpegts -fflags +genpts -movflags +faststart -copyts pipe:1

Die einzige Änderung zur Default FFMPEG Pipeline von Threadfin ist der Parameter -c:a libmp3lame, ohne den schmeißt Plex einen Fehler bzgl. des Content Types.

Zitat von heyJu

Die Performance vom RPi 5 war tatsächlich zu gering!

So ein läppischer Stream noch dazu ohne Transkodieren ringt dem RasPi 5 normalerweise nicht mal ein müdes Lächeln ab. Außerdem sollte das NAS eigentlich deutlich weniger Leistung haben als ein RasPi 5. Irgendwas stimmt ja offensichtlich nicht. Doch das ist mit Sicherheit kein prinzipieller Leistungsmangel beim Pi5. Aber wenn es so für dich läuft, ist es ja gut. Sonst müsste man wirklich mal nachschauen, was da klemmt.