Youtube2k Disskussionen

  • Moin,

    hier einmal der Disskussionsthread für das ReWrite von Bromix Youtube-Addon.

    Folgende Gits sind nun initialisiert und mit Struktur gefüllt:
    https://github.com/h0d3nt3uf3l/plugin.video.youtube2k
    https://github.com/h0d3nt3uf3l/script.module.youtube-api

    Ob nun das script modul genutzt wird oder nicht muss noch ausdiskutiert werden.
    Dieser Thread wurde nach meinem letzten Post im alten Thread erstellt.

  • Du hast Recht:
    Interface:
    - Ich hätte gerne zu Anfang schon ein schönes Interface. Dafür bräuchten wir jemanden der sich damit auskennt und Kreativ wäre, @membrane wäre das etwas für dich?

    Funktion:
    - Der Login muss stehen (JSON / Youtube-API / Settings speichern)
    - Die Suche muss stehen. (JSON / Youtube-API / ggf. Youtube-TV = Request per HTML)
    - Auswahl der Videos und natürlich dass diese abgespielt werden können. Das ganze sollte schon auf inputstream.mpd angepasst sein (>= Kodi 17).
    Als alternative muss natürlich auf den normalen Player runtergegangen werden. (inputstream.mpd / DVDPLayer)
    - Die Implementierung von strm-files wäre ebenfalls nciht schlecht, sodass sich das Addon von Anfang an remote füttern lässt (Kore / Yatse / Browser-Addons) (Keine Ahnung)

    Ich denke wenn das steht wäre es schon solide genug für den Anfang.

    Auch die Doppelte Arbeit von mir war ein Kurzschlussgedanke, du hast recht :) ob die Funktion nun intern oder extern ausgeführt wird ist einerlei.


  • - Ich hätte gerne zu Anfang schon ein schönes Interface. Dafür bräuchten wir jemanden der sich damit auskennt und Kreativ wäre, @membrane wäre das etwas für dich?


    Ja der Blingbling Kommentar war reichlich sinnlos. Macht natuerlich voellig Sinn wenn das UI von Anfang an schoen gemacht wird.


    - Auswahl der Videos und natürlich dass diese abgespielt werden können. Das ganze sollte schon auf inputstream.mpd angepasst sein (>= Kodi 17).
    Als alternative muss natürlich auf den normalen Player runtergegangen werden. (inputstream.mpd / DVDPLayer)


    Gibts da irgendwo ein Forum Thread zu diesem neuen InputStream Interface? Ich habe das Repo gesehehen, das dash mit diesem Interface implementiert: https://github.com/mapfau/inputstream.mpd. Was ich aber noch nicht gefunden habe, ist was diese Interface eigentlich ist. Oder kennst du es schon und kannst es in zwei, drei Saetzen erklaeren (fuer Details wird eh Code lesen angesagt sein).


    - Die Implementierung von strm-files wäre ebenfalls nciht schlecht, sodass sich das Addon von Anfang an remote füttern lässt (Kore / Yatse / Browser-Addons)


    Ich kenne strm-files bisher nur als Moeglichkeit um Addons in die Video Library zu integrieren. Wo kommen da Kore und Co ins Spiel?

  • Bist du anderer Meinung bzgl des BlingBling kommentares?
    Ein schönes Gesicht lenkt immer vom Hintergrund ab. Das Addon wird nicht viel können zu dem Zeitpunkt und die User dieses Addons sind seelenlos was das angeht. Ich kann mir mitlerweile denken warum bromix nicht mehr weiter gemacht hat.
    Ausserdem habe ich in meinem letzten Projekt (von der Arbeit) gelernt dass man jeden Mist klar Kommunizieren muss, auch wenn es eibem selbstverständlich erscheint.

    Was das strm file angeht schau ich nochmal nach. Die Kernaussage davon soll sein "Remote abspielen können sollte gewährleistet sein"

  • Moin ich hab gestern ne Mail bekommen. Die ist vieleicht relevant:

    --------------
    Guides nicht mehr verfügbar wegen Youtube unvermögen guten von schlechten Kodi Videos zu unterscheiden.

  • Viel gestalten kann man da nicht, das hängt größtenteils am viewmode und ist auch Skin abhängig.
    Wie oben schon gesagt, würde ja was simples für den Anfang ausreichen und könnte dann je nachdem wie es weitergeht und was wir brauchen bzw möglich ist, noch verfeinert werden.
    Viel anders machen als das momentane YT addon ist, würde ich das nicht machen (können).
    Man kann sicher mittels 'skinning' noch viel mehr bzgl gui machen, da habe ich aber keine ahnung von.

    Wg PS, wenn es sonst hier niemand mit PS hat und das gerne machen würde, könnte ich auch das Logo bzw Ordnerthumbs erstellen (Menüführung)

  • Für meine Mediatheken hab ich ein kleines Framework geschrieben. Im Kern ist das ca. 100 Zeilen Code - es ist einfach und effektiv. Die Add-ons bestehen dann fast nur noch aus dem Scraper. Der Scraper liefert alle Suchergebnisse als list, wobei jeder Eintrag ein dict mit allen möglichen Angaben darstellt:


    Das hat mehrere Vorteile. Die Struktur vom Add-on vereinfacht sich merklich, es sieht für mich viel sauberer aus. Der Code zum Auflisten kann von mehreren Add-ons verwendet werden - dieser ist bei mir eh immer der selbe. Außerdem kann man den Scraper auch außerhalb von Kodi laufen lassen - gut fürs automatische Testen oder für die IDE. Weiterhin können auch andere Add-ons die Infos bekommen ohne das Youtube Add-on direkt aufrufen zu müssen.

    Was mir beim alten Youtube Add-on gefallen hat ist die Suchhistorie. Das sollten wir unbedingt als unabhängiges Modul auslagern, damit auch andere Add-ons dies nutzen können.

    Ich würde von Anfang an konsequent auf Dash setzen. In meinen Augen bringt die bisherige Methode kaum Vorteile.

    Zwecks der Funktion, per Remote/Browser Links zu senden: strm Dateien werden dazu nicht benötigt. Man kann den Abspielvorgang per Json RPC request einleiten.

  • Klingt doch gut :)

    Ich werde mich nun erstmal ne Woche abseilen da ich bald aufs Summerbreeze (Festival) fahr und dafür noch ein paar Sachen organisieren muss.
    Wer möchte kann ja schonmal bisschen was Coden, denke die Ziele sind klar.

    Soweit es geht alles übers Git dokumentieren und commiten :)

  • Ich hätte da noch 'ne Frage: wer managed denn interne Pull-Requests in Form von Code-Review? Bzw. wo/wie koordinieren wir das?

    Ansonsten: nutzen wir nur den Master + einzelne Feature/Hotfix-Branches? Oder gibt's noch einen Integrationsbranch in Form des develop-Zweiges dazu?

    btw: ich hab mich mal an beiden Repos versucht... :D

  • Denke das mit den PRs macht @h0d3nt3uf3l

    Wobei die nicht unbedingt notwendig sind, da wir ja direkten write access für die zwei repos haben (können also direkt commits erstellen)

    Habe grade mal das icon des modules angepasst. Das ist so ein standard template von kodi für modules (denke das ist erstmal ok)

  • Ich wuerde auch sagen PR's sind intern nicht wirklich noetig. Wir muessen uns sowieso absprechen bezueglich den Interaktionen zwischen den einzelnen Modulen und wenn zwei (oder mehr) am selben arbeiten umso mehr. Einfach wie teufel geschrieben hat nur funktionale commits in den master machen. Kleinere Entwicklungsschritte als commits in lokalen oder separaten branches festhalten und dann squash-mergen in den master. So wuerde ich es angehen.

    Ich denke was wir jetzt machen/diskutieren muessen ist: Klassen mit ihrer Funktionalitaet definieren. Ausser jemand hat viel mehr Zeit als alle anderen und haut gleich Mal einen Grossteil des Codes hin kann sonst nicht einfach angefangen werden mit Coden. Vielleicht ist das auch mehr ein Problem von mir, weil ich Kodi Addons nicht gut kenne, und es gibt da einen "Standard". In jedem Fall lohnt es sich meiner Meinung nach so eine Struktur irgendwie festzuhalten. Die wuerde dann natuerlich fortlaufend angepasst/erweitert.

  • Denke der Kern der Kodi Lib besteht aus dem Auflisten der Daten. Dh Ordner bzw Links (Videos).

    Jetzt ist die Frage, wie wir das genau handhaben. Ich denke wir sollten uns von der Struktur her an @membranes Beispiel orientieren.
    So sollte auch jm, der keine Ahnung von Kodi hat, einiges bauen können

    Das könnte ich mich gerne mal die nächsten Tage anschauen, evtl krieg ich da schon was Vernünftiges bei rum

  • Gibts da ein repo @SLiX mit einem repraesentativen Beispiel von membrane?

    @voodoo44
    Dein merge ist etwas komisch: Der erste commit hat keinerlei Aenderungen. Da waere squashen (zusammenfuegen zu einem "sauberen" commit) for dem mergen angesagt, damit die master commit history moeglich sauber und klar bleibt.

  • Jetzt ist die Frage, wie wir das genau handhaben. Ich denke wir sollten uns von der Struktur her an @membranes Beispiel orientieren.


    Ich werde mal eine saubere Variante auf die Beine stellen. Die 'libMediathek' ist ein Prototyp, der immer nur erweitert wurde - ohne Rücksicht auf Lesbarkeit. Noch sind da einige experimentelle/tote Codezweige drinnen.

  • moin,
    @imsodin Denke das hier ist die verarbeitende Methode https://github.com/prof-membrane/…ediathek.py#L18
    @membrane ich war mal so frei und habe deinen Code verlinkt.

    Wie gesagt, ich würde das gerne so ähnlich handhaben, solange niemand einen besseren Vorschlag hat.

    Evtl wäre es noch etwas einfacher, wenn wir nicht ein dict übergeben, sondern eine Liste mit dicts (wie oben im Post von membrane dargestellt)
    Dann in unserer 'AddEntry' Methode die Liste durchlaufen.

    So könnte man theoretisch mit einem Aufruf eine 'ganze Seite' auflisten (quasi Ordner + Videos in einem Call)

    Damit würde ich gerne die nächsten Tage mal anfangen

    Nochmal fürs Verständnis:
    Der ganze Kram der dazu gehört, in Kodi unsere Inhalte darzustellen wandert in eine eigene Klasse (aber nicht in die 'additional Video-Item' Class?)

    Dann würde ich mal hingehen und im plugin.video.yt2k einen neuen Unterordner 'lib' in 'resources' erstellen und dort eben mal eine neue 'kodi_utils.py' erstellen.

    Code verschieben/in eine Klasse packen kann man ja immernoch. Ist etwas schwer abzuschätzen, wie ihr die generelle Struktur gerne hättet.

    Denke da werden wir uns aber im Laufe der Zeit schon einander annähern

  • @membrane ich war mal so frei und habe deinen Code verlinkt.


    Die Version ist viel zu alt. Im Repo ist eine aktuelle Version, die ich aber nicht vorzeigen möchte.

    Evtl wäre es noch etwas einfacher, wenn wir nicht ein dict übergeben, sondern eine Liste mit dicts (wie oben im Post von membrane dargestellt)
    Dann in unserer 'AddEntry' Methode die Liste durchlaufen.


    Genau das macht die neuere Ausgabe. Noch besser: die ganze Liste wird an Kodi übergeben. Das ist vorallem auf langsamen Systemen besser. Gib mir ein paar Tage um eine reine Version + Doku hinzuzufügen.

  • die ganze Liste wird an Kodi übergeben. Das ist vorallem auf langsamen Systemen besser

    Die Liste direkt an Kodi übergeben machst du mittels addDirectoryItems oder?
    Ist mir nie aufgefallen, dass die schneller als addDirectoryItem ist. Habe aber auch einen relativ potenten dev PC

    Aber wo du es sagst: Müsste an für sich schneller sein.
    Zumindest wäre es nachvollziehbar, wenn Kodi eine Liste etwas schneller verarbeitet als jd Element einzeln via addDirectoryItem zu übergeben

  • Ich verfolge die disskussion hier jetzt schon ein paar tage und habe mir auch mal die infos auf github durchgelesen.

    Ein großes Problem scheint ja das youtube api quota zu sein, in der wiki steht das ein alternative gesucht wird für youtube suche.

    Was spricht dagegen einfach nen simplen webscraper dafür zu basteln?

    Youtube such urls sind ja sehr simple und auch fix selbst generiert, danach einfach die seite nach den wichtige daten durchforsten.

    Ich habe mir das ganze nur mal kurz angeschaut und eigentlich sollte das alleine mit urllib2 und re modul funktionieren (im schlimmsten fall noch beautifulsoup).

    Ich weiß dass das keine sehr saubere Lösung ist im vergleich zur ner nativen api und sicherlich auch langsamer, aber wenn man quota spart warum nicht?

    Habe zwar momentan wenig zeit da ich an einem anderen Projekt arbeite für die Arbeit aber nen simplen scraper der am ende die wichtigen infos zusammenstellt sollte ich zwischendurch noch hinbekommen.

Jetzt mitmachen!

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