[DISCONTINUED] Telerising API - Zattoo für tvHeadend und VLC [Perl]

    Ich hab tvHeadend lokal noch auf einem Raspberry Pi laufen. Ich check nicht so richtig warum er die channels.m3u nicht nimmt. Er liest die URLs nicht richtig, auf jeden Fall kommt beim Service-Scan folgendes.. Zieht sich halt durch die ganze Datei dann durch, das ist ein Ausschnitt:
    Betriebssystem ist debian, auf den ubuntu VPS läuft das ohne Probleme :-/

    Danke erstmal für das umfangreiche Update. Die automatische Bandwidth in Verbindung mit dem manuellen Überschreiben haut aber noch nicht ganz hin, imho. Ein Beispiel, u.a. TLC über Wilm44 ist per se nur SD =2999, auch im channelMappings.json ist es nicht als HD/FullHD-Sender gelistet. Dennoch konnte man bisher <v0.3.4 über bw=8000 den Sender (und andere Ausnahmen) in HD/FHD empfangen. Jetzt wird selbst beim setzen der Bandwidth in der Streaming-URL der Stream beim Klienten nur mit 1024x576 anstatt 1920x1080 abgespielt. Laut zattoo.pl-Log wird scheinbar noch eine 2999-Playlist zusammengebastelt, obwohl der der Aufruf mit bw=8000 erfolgt (Wobei: Es erfolgt ja ein resent mit 8000, jedenfalls wird dennoch nicht in voller erzwungener Auflösung gestreamt)

    Kannst Du dir das mal ansehen? Betrifft im Prinzip fast die ganze Discovery-Gruppe die man bisher so in FHD empfangen konnte.

    Code
    * 2020-04-09 10:15:57 LIVE-TV tlc_de | 8000 | hls5 - Loading channel configuration
* 2020-04-09 10:15:57 LIVE-TV tlc_de | 2999 | hls5 - Loading Live URL
* 2020-04-09 10:16:01 LIVE-TV tlc_de | 2999 | hls5 - Editing M3U8
* 2020-04-09 10:16:01 LIVE-TV tlc_de | 2999 | hls5 - Playlist sent to client
* 2020-04-09 10:16:02 LIVE-TV tlc_de | 8000 | hls5 - Playlist resent to client

    Edit: Generell kann man mit dieser Version nur noch das Downgrading erzwingen, wie mir scheint? Normale HD-Sender (RTS Un, SRF1, ...), welchen Sinn das auch haben mag, kann man ebenfalls nicht mehr zur FHD-Auflösung erzwingen.

    Zitat von easy4me

    Vermutlich ist der ffmpeg-Pfad falsch.

    Ich glaube daran liegt es nicht, weil ffmpeg -v folgendes ergibt- Irgendwie hab ich das Gefühl, als ob es ein Zeichen/Formatierungsfehler wäre, dass der Raspberry das "" falsch interpretiert, bei der URL. Bin noch nicht schlau geworden draus:

    @Sebas Du kannst mit

    "ignore_maxrate": "true"

    in der userfile.json die Qualitätsprüfung wieder deaktivieren. Hintergrund ist, dass kein Full HD geladen werden soll, wenn der Stream nur in SD vorliegt. Warum Wilmaa die Discovery-Sender als SD deklariert, kann ich nicht sagen.

    @derd Es gibt eine neuere Version von ffmpeg:

    Zitat von easy4me

    @Sebas Du kannst mit

    "ignore_maxrate": "true"

    in der userfile.json die Qualitätsprüfung wieder deaktivieren. Hintergrund ist, dass kein Full HD geladen werden soll, wenn der Stream nur in SD vorliegt. Warum Wilmaa die Discovery-Sender als SD deklariert, kann ich nicht sagen.

    Ah richtig, stimmt. Aber gäbe es nicht noch eine Option, dass bei nicht-Angabe von bw in der Streaming-URL die übermittelte Auflösung geladen wird und nur bei explizit in der Streaming-URL angegebenen Aufrufen die Auflösung erhöht wird?

    Sprich:
    "bw": "8000" im JSON & ip:port/index.m3u8?channel=sf_1_hd => Es wird die zu Verfügung stehende Auflösung 720p50 geladen
    "bw": "8000" im JSON & ip:port/index.m3u8?channel=sf_1_hd&bw=8000 => Es wird 1080p50 geladen
    "bw": "8000" im JSON & ip:port/index.m3u8?channel=tvm_3 => Es wird 576p50 geladen


    Andere Frage: Kann man "profile": "x" in der Streaming-URL nullen? Ansonsten macht der Aufruf &audio2=true bei setzen von "profile": "x" im JSON keinen Sinn mehr, denn die Angabe wird nicht mehr honoriert. Zumal es kein (überschreibendes) Profil gibt, bei dem zuerst die zweite Audiospur geladen wird.

    Zitat von easy4me

    Eher nicht, vielleicht sollte die Anzahl der M3U-Updates in tvHeadend reduziert und der Timeout erhöht werden.

    Ok, irgendwas stimmt da nicht.

    nach jedem 3. oder 4. Reload ändern sich die Streaming Urls:

    Sobald sich die Streaming Url ändert, löscht TVheadend die Services und macht neue MUXes

    Abfrage Url:
    http://0.0.0.0:8023/?file=channels…=true&profile=1

    Return: (jeder Absatz ist ein Reload dazwischen)


    Hier nochmal Reloads mit der Url:
    http://0.0.0.0:8023/?file=channels…ls5&ffmpeg=true

    Code
    pipe:///usr/bin/ffmpeg -i "http://X.X.X.X:8023/index.m3u8?channel=tele_zuri_hd&bw=5000&platform=hls5" -vcodec copy -acodec copy -f mpegts -metadata service_name="TeleZüri HD" pipe:1




pipe:///usr/bin/ffmpeg -loglevel fatal -i "http://X.X.X.X:8023/index.m3u8?channel=tele_zuri_hd&bw=5000" -map 0:0 -map 0:1 -map 0:2 -c:a:0 copy -c:a:1 copy -c:v copy -f mpegts -metadata service_name="TeleZüri HD" pipe:1
    Zitat von easy4me

    Dein beschriebenes Verhalten bei tvHeadend kann eigentlich nur auftreten, wenn mehrere API-Schnittstellen gleichzeitig laufen. Ich würde mal mit killall perl alles beenden und die API einmal neu starten.

    Habe mit pkill perl alles beendet und anschließend die API neu gestartet.

    Aber die Streaming Urls ändern ständig nach dem Reload:

    Mal sind Umlaute falsch, dann stimmen sie wieder. Und dann sind wiederrum die Reihenfolge der Mappings unterschiedlich.

    Auszug aus Top sobald ich den Telerising 1x Prozess starte.

    pkill perl beendet auch alles. Aber hab es auch mit deinem Befehl nochmals gemacht und die VM Rebootet.

    Die Streaming Urls werden trotzdem gefühlt 5x richtig dann wieder 1x falsch ausgegeben.

    Hab nochmals ein Bild im vorherigen Post dazu gegeben

    Nach jedem Reload der Url ein Glücksspiel wie die Urls aussehen.

    Habe die VM Rebootet und die Telerising API gestarter.

    Trotzdem sehe ich sofort unzählige Perl Prozesse nach Start der API:

    Code
    2096 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl
   2097 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl
   2098 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl
   2099 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl
   2100 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl
   2101 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl
   2102 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl
   2103 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl
   2104 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl
   2105 root      20   0   49584  33660   1620 S   0.0   0.8   0:00.00 perl

    Also ich habe testweise in meiner userfile.json bis auf den Provider Wilmaa nichts drin stehen und kann die URL beliebig oft aufrufen, ohne dass irgendwelche Abweichungen auftreten. Wie lautet die restliche Konfiguration?

    Eine weitere Idee wäre es, die ":cached"-Dateien aus dem Verzeichnis zu löschen.

    Zitat von easy4me

    Also ich habe testweise in meiner userfile.json bis auf den Provider Wilmaa nichts drin stehen und kann die URL beliebig oft aufrufen, ohne dass irgendwelche Abweichungen auftreten. Wie lautet die restliche Konfiguration?

    Eine weitere Idee wäre es, die ":cached"-Dateien aus dem Verzeichnis zu löschen.

    Abfrage:
    ?file=channels.m3u&bw=5000&platform=hls5&ffmpeg=true&profile=1

    {
    "provider": "wilmaa.com",
    "login": "xxxxxxxxxxxxxx",
    "password": "xxxxxxxxxxxxx",
    "interface": "eth0",
    "address": "xxxxxxxxxxxxxxxxxxxxx",
    "ffmpeg_lib": "/usr/bin/ffmpeg",
    "port": "8023",
    "ssl_mode": "1",
    "youth_protection_pin": "1234",

    "platform": "hls5",
    "bw": "1500",
    "server": "zh2-0",
    "profile": "1",
    "audio2": "true",
    "dolby": "true",
    "ignore_maxrate": "false",
    "loglevel": "fatal"
    }


    Wo finde ich die cached files?

    Ich merk halt dass bei Kanälen mit Umlauten diese immer wieder mal UTF-8 und mal wieder komplett falsch ausgegeben werden.

    TeleZüri HD TeleZüri HD


    Refetching lässt sich im TvHeadend nicht deaktivieren:
    https://tvheadend.org/boards/5/topics/21847

    Es muss somit wirklich daran liegen, dass Telerising bei mir immer eine andere m3u ausgibt.
    Vor dem Update vor 2 Tagen hat alles noch funktioniert.


    Ich such hier mal nach fehlern, vielleicht passt hier irgendwas noch nicht ganz

    Zitat von easy4me

    Ich habe ein Problem bei den evaluation-Expressions bemerkt, das dazu geführt hat, dass die Rytec IDs nicht in der Wilmaa-Liste auftauchten. Magst du du bitte neu clonen und testen?


    Hallo,
    sieht erst mal gut aus, aber die Umlaute stimmen manchmal nicht, die werden spontan mal ausgegeben, dann wieder mal nicht.

    Zattoo:
    pipe:///usr/bin/ffmpeg -loglevel fatal -i "XXXXX:8022/index.m3u8?channel=sf-1&bw=5000" -map 0:0 -map 0:1 -map 0:2 -c:a:0 copy -c:a:1 copy -c:v copy -f mpegts -metadata service_name="SRF 1 HD" pipe:1

    Wilmaa:
    pipe:///usr/bin/ffmpeg -loglevel fatal -i "XXXXX:8023/index.m3u8?channel=sf_1_hd&bw=5000" -map 0:0 -map 0:1 -map 0:2 -c:a:0 copy -c:a:1 copy -c:v copy -f mpegts -metadata service_name="SRF 1 HD" pipe:1

    Zitat von matthias1232

    die Umlaute stimmen manchmal nicht, die werden spontan mal ausgegeben, dann wieder mal nicht

    Was genau ist hiermit gemeint? Im letzten Bild sind beide Kanalnamen identisch - die "falschen" Umlaute kommen vom Browser und sind dann in tvHeadend richtig.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden