Beiträge von jNk20

    Ich finde es okay, dass @darkside40 die Streams vorerst aus der Liste entfernt hat - das erstmal vorweg.

    Hier ist ja auf jeden Fall noch anzumerken, dass wir keinerlei Einfluss darauf haben, ob der Stream empfangen werden kann oder nicht. Es geht bei der Entscheidung einzig darum, ob wir den Stream in der Kodinerds IPTV Liste sozsuagen "weiterverbreiten" oder nicht.
    Die entsprechenden Links sind somit weiterhin gültig und können bei Bedarf in eigenen Forks/Listen eingetragen und verwendet werden.

    ---

    Wichtig ist aber an dieser Stelle, dass wir für die Zukunft klar definieren müssen, was denn nun überhaupt in die Liste aufgenommen wird und was nicht.
    Das haben die Fragen bzgl. dem Sender "RT DE" vor ein paar Wochen und die aktuelle Frage bzgl. RT allgemein gezeigt.
    Mir geht es dabei um grundsätzliche Definitionen, was denn die Richtlinien und Anforderungen der Kodinerds IPTV Liste sind.

    Vieles basiert ja noch auf Entscheidungen, die ich vor einigen Jahren einfach so nach eigenem Ermessen getroffen habe - aber leider nie klar ersichtlich dokumentiert habe (abgesehen von offensichtlich illegalen Sendern).

    Mein Anspruch an die Liste war bisher immer, möglichst alle linearen Empfangsarten (DVB-S, DVB-C, ...) abzudecken, bzw. - wo verfügbar - auch Nebensender der entsprechenden Sender.

    Ich verstehe die Kritik an diesem Sender, würde aber persönlich die meiner Meinung nach "möglichst objektive und vollständige Abdeckung des linearen Fernsehangebots" durch politische Entscheidungen ungerne einschränken.

    Daher meine Meinung: Sender rein.

    Das mit den Direktlinks hatten wir/ich die letzten Jahre eigtl auch immer so gemacht.

    Die master-URLs haben natürlich den Vorteil, dass die deutlich(?) ausfallsicherer sind, führen aber meines Wissens nach in allen Clients (Kodi, Tvheadend, VLC) zu deutlich längeren initialen Ladezeiten.
    Welche Clients da genau betroffen sind, und ob sich da mittlerweile was geändert hat, weiß ich nicht.
    Bei den Direk-URLs ist das eben genau umgekehrt.

    Das wurde auch schon desöfteren im Kodinerds IPTV Thread angesprochen, eine einheitliche Meinung existiert dazu leider auch nicht.

    Je nachdem wie aktiv die Listen gepflegt werden, macht da halt immer das eine oder andere mehr Sinn.

    Das ganze ließe sich auch sicher irgendwie automatisiert umsetzen. An Ideen mangelt es da nicht, leider an der Zeit.

    Was mir da noch spontan einfällt ist die Zuordnung zu den tatsächlichen Kanalnamen. Da gibt es ja auch immer verschiedene Schreibweisen.

    Falls eine Zuordnung nötig ist, stellt sich da natürlich noch die Frage, unter welchem Name das verknüpft wird, da auch hier wieder ungleiche Benamungen folgen können.
    Oder reicht hier tatsächlich eine einfache Liste?

    Als Beispiel (unabhängig davon, in welcher Datenbank-Struktur das dann gespeichert wird):

    Code
    [
    "DasErste.de",
    "ZDF.de",
    "BILD.de",
    ...
    ]


    oder:

    Code
    [
    "DasErste.de" -> ["Das Erste HD", "Das Erste", "ARD"],
    "ZDF.de" -> ["ZDF HD", "ZDF"],
    "BILD.de" -> ["BILD", "Bild", "Bild TV"],
    ...
    ]


    Brauchen wir da überhaupt eine Zuordnung wie im 2. Beispiel?
    Falls ja, wird es an der Stelle vermutlich wieder recht komplex. Denn: Welcher Name ist der "richtige"?

    Rytec hat in der eigenen Liste an der Stelle eine Zuordnung zu einem Klarname + (glaube ich) die Service-Provider ID vom jeweiligen Netz.

    Wenn wir davon ausgehen, dass die Namen der TVG-IDs immer direkt erkennbar bleiben und die Zuordnung klar ist, kann man sich die Zuordnung zum Klarname natürlich sparen.
    Je nachdem wie zukünftig Namensänderungen behandelt werden sollen, kann das aber auch wieder notwendig werden.

    Der Rytec-Maintainer hat sich bereits gemeldet und hat Interesse bekundet, eine gemeinsame Lösung zu finden (siehe hier).

    Die TVG-ID für den neuen Kanal "Bild" wird er an die TVG-ID vom easyEPG Grabber angleichen, das Problem wäre dann also auch schon gelöst :)

    Das heißt, jetzt können wir gemeinsam Vorschläge sammeln, eine gemeinsame Liste/Datenbank für "Standard-TVG-IDs" zu pflegen.


    Von @darkside40 kam da schon die Idee, das mit einer einfach JSON-Datei zu speichern und auf GitHub zu maintainen.
    Das kann man dann sicher als Organisation einrichten, dann ist es auch unabhängiger von Einzelpersonen oder -projekten.

    Ich mache mir die Tage auch mal ein paar Gedanken, was wir da alles mit einbringen sollten.

    Beim neuen Sender "Bild" gibt es übrigens auch bereits Abweichungen:
    https://github.com/jnk22/kodinerd…mment-918011936

    Bin da gerade mal die Commit-History durchgegangen:

    - https://github.com/sunsettrack4/c…408d15f68d44eb1

    Im easyEPG Grabber gibt es Bild mit der TVG-ID "BILD.de" bereits seit dem 11.05.2019


    - https://github.com/doglover3920/E…1679ed35d2d44c2

    Bei Rytec mit "BildTV.de" tatsächlich erst seit dem 11.09.2021 (also vor 2 Tagen)


    Da der Sender laut Wikipedia bereits seit dem 22.08.2021 sendet und es bereits vorher eine TVG-ID im easyEPG Grabber gab, macht das nachträgliche Umstellen da natürlich wieder weniger Sinn..


    Edit: Zu langsam :D

    Falls es mehr Sinn macht, die Änderungen in der Kodinerds IPTV Liste rückgängig zu machen, ist das natürlich auch weiterhin eine Option.

    Da der easyEPG Grabber und die Kodinerds IPTV Liste beide aus diesem Forum stammen, könnten wir das natürlich auch so sehen und unseren eigenen Standard definieren.
    Aus meiner Sicht verschiebt sich das Problem dann halt einfach zu den Usern, die aktuell Rytec bzw. Rytec-basierte EPG-IDs nutzen. Vorher bei denen vom easyEPG Grabber.

    Meines Wissens nach hat Rytec nur 2 Sender in den letzten Jahren angepasst: immer dann, wenn sich auch der Sendername geändert hat und somit ein Eingreifen des Users in die eigenen Kanäle sowieso mindestens wahrscheinlich war.

    Hi, ich bin auf jeden Fall gerne bereit, hier eine ordentliche und zukunftssichere Lösung zu besprechen, wie wir das zukünftig handhaben möchten :)

    Wie von @buers im Kodinerds IPTV Thread angemerkt, habe ich vor einigen Jahren tatsächlich die Rytec EPG-IDs als Grundlage genommen, weil die damals halt einfach schon da waren und alle(?) Sender abgedeckt hatten, ohne dass ich mir da selber Gedanken drüber machen musste.

    Welche EPG-IDs hattet ihr als Basis für den easyEPG Grabber benutzt?

    Durch Google habe ich soeben dieses Repo gefunden: https://github.com/doglover3920/EPGimport-Sources
    Der User Doglover3920 scheint im Forum OpenPLi direkt in das Rytec-Projekt involviert zu sein.
    Bis auf meine Google-Suche habe ich aber auch noch nichts von dem Forum gehört.

    Vielleicht macht es Sinn, da mal nachzufragen auf welcher Basis Änderungen passiert sind und zukünftig passieren werden, dass wir ungefähr abschätzen können, ob das willkürlich passiert oder nach einem definierten Schema?

    Die IDs in der Kodinerds IPTV Liste wurden damals an die von Rytec angepasst, um mit deren EPG kompatibel zu sein.

    Da sich dort die IDs geändert haben, macht es wohl Sinn, die jetzt wieder anzupassen.


    @easy4me Benutzt du beim easyEPG Grabber auch bereits die neuesten TVG-IDs von Rytec - bzw. unterstützt diese?

    ---

    Wenn es hier keinen Einwand gibt, merge ich den Request demnächst:
    https://github.com/jnk22/kodinerds-iptv/pull/425

    @Willi55 kann ich so bestätigen. Ich habe den Stream für münchen.tv gerade in Tvheadend und VLC media player getestet:

    https://muenchentv.iptv-playoutcenter.de/muenchentv/muenchentv.stream_1/playlist.m3u8

    In Tvheadend alles problemlos (pipe-Liste: https://bit.ly/kn-pipe), im VLC media player nur Video, ohne Ton. IPTV Simple Client nicht getestet.
    Vielleicht wirklich nur temporäres Problem bei denen?


    Auf der Seite von münchen.tv scheint ein anderer Stream zu laufen, der funktioniert aber bei mir nicht mal im Browser auf deren Seite. Wurde hier aber glaube ich auch bereits erwähnt.

    Ich habe das ganze ein bisschen mitverfolgt, dabei geht es um die Ankündigung der 6.9.0-beta35, wie von @hi2hello richtig zitiert.

    Hintergrund ist, dass Unraid jetzt von Haus aus diverse Treiber mithilfe von Plugins statt - wie vorher inoffiziell - mit Custom Kernel-Builds unterstützen soll.
    Dabei kam von limetech die Äußerung, dass die neue Methode Builds von u.a. linuxserver.io obsolet macht und machen "soll".

    Da es da wohl vorher keine Kommunikation zwischen den Parteien limetech und linuxserver.io gegeben habe, wurde das von Seiten linuxserver.io (so wohl unter anderem CHBMB) nicht so positiv aufgenommen.

    Hier noch ein Statement von limetech zu der Situation: https://forums.unraid.net/topic/99023-mea-culpa-and-apology/

    (Das dazu, bin aber selber erst seit Unraid 6.8.3 "dabei" - daher hier von meiner Seite keine Wertung zu einzelnen Positionen)

    ---

    Jetzt zur Entwarnung bzgl. 6.9.0:

    Ich habe bereits 6.9.0-rc2 am Laufen und benutze die Plugins [Plugin] Nvidia-Driver und [Plugin] DVB-Driver.
    Damit ist dann auch nicht mehr das Plugin Unraid Kernel Helper/Builder nötig, sofern man keine weiteren Treiber integrieren möchte.

    Beide ließen sich problemlos installieren, Tvheadend funktioniert mit dem Plugin ohne Änderungen wie vorher.
    Das Nvidia Plugin habe ich bisher nur installiert, nicht aber in Dockern getestet - daher hier nur die Vermutung, dass es ebenfalls problemlos funktionieren wird/sollte.

    Werde die Änderungen jetzt mergen:

    (Pfad zu ffmpeg: 'pipe:///usr/bin/ffmpeg' -> 'pipe://ffmpeg')

    https://github.com/jnk22/kodinerds-iptv/pull/257
    https://github.com/jnk22/entertain-iptv/pull/20

    Ich befürchte, dass alle Kanäle in Tvheadend neu gemappt werden müssen - das war zumindest in der Vergangenheit so bei Änderungen an den URLs.
    Sollte aber dafür in Zukunft "besser" bzw. auf mehr Systemen OOTB funktionieren, so auch mit LibreELEC (siehe hier).

    Bei wem es nach dem Update nicht mehr funktionieren sollte, hier mögliche Lösungsansätze:

    • Link zu ffmpeg hinzufügen: ln -s /usr/bin/ffmpeg /usr/local/bin/ffmpeg
    • ffmpeg aus dem Package-Manager installieren, sodass ffmpeg system-weit installiert ist (möglicherweise veraltete Version von ffmpeg?)
    • ffmpeg aus einem anderen Repo installieren, sodass ffmpeg system-weit installiert ist

    https://github.com/jnk22/kodinerds-iptv/issues/230

    Hier gab es auf Github den sinnvollen Vorschlag, den Pfad der pipe-Listen von pipe:///usr/bin/ffmpeg auf pipe://ffmpeg zu ändern.
    Das würde laut jugi80 auch die Probleme bzgl. LibreELEC lösen, sofern ffmpeg-tools installiert ist.

    @CvH kannst du das so bestätigen?

    Wenn das passt, würde ich das so übernehmen und die Pfade aktualisieren.
    Kann dann bei dem ein oder anderem dazu führen, dass möglicherweise ffmpeg system-weit installiert werden muss (bzw. verlinkt werden), sollte aber eine deutlich sauberere Lösung sein.