Alles anzeigenAlso mir ist alles recht. Wie du sagst merkt man ja beim Programmieren
nichts davon wie Kodi spaeter die Module organisiert. Doppelte Arbeit
verstehe ich aber nicht ganz: Der Code ist ja derselbe ob das nun ein
alleinstehendes Modul oder ein internes ist. Was dazukommt beim
alleinstehenden ist das packaging, also addon.xml, setup.py, usw.
erstellen. Aber die Arbeit faellt einfach einmal an, ob das nun direkt
zu Beginn oder erst spaeter bei Bedarf gemacht, aendert nichts am
Aufwand. Oder vergesse ich da was?
Aber irgendwie haengen wir uns an Details auf. Was ja momentan
eigentlich wichtig ist, dass wir ein uns ein Framework basteln. Und da
muessten wir wohl als erstes Mal Ziele definieren, also was unser Addon
in der ersten Version koennen soll. Ich waere dafuer, diese moeglichst
tief zu stecken, dafuer klaren und gut erweiterbaren Code zu schreiben.
Sobald das dann laeuft, koennen wir immernoch viel Funktionalitaet und
Blinbling einbauen. Ansonsten verzetteln wir uns wohl schnell.
Und ja, die Zahl ist ziemlich beeindruckend...
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?
Moin ich hab gestern ne Mail bekommen. Die ist vieleicht relevant:
You are receiving this notice because you have enabled YouTube API Services on your project(s) in the Google Developer Console.
Dear Developer:
As the YouTube API Services continue to grow and evolve, we periodically review the YouTube API Services Terms of Service. Today we are posting an update to these terms (“Updated TOS”), and introducing new YouTube API Services Policies (“Policies”), to provide additional guidance and clarification on how you can properly access and use the YouTube API Services. The Updated TOS and Policies will become effective in 6 months on February 10, 2017, so that you have time to understand and comply with them.
Changes to the Updated TOS and Policies:
- Policies set out the operational requirements and provide additional guidance on how you can properly access and use the YouTube API Services, including policies relating to data usage, storage and security, protecting user privacy, commercial use, and prohibited access and use of the YouTube API Services.
- Policies also require compliance with the Required Minimum Functionality that explains the rules you must follow when using certain YouTube features and functionalities to support a good user experience.
- We also updated terms on what happens when we make modifications to the YouTube API Services in the Updated TOS.
In addition to these changes, there are other modifications and clarifications. We, therefore, recommend that you read the complete Updated TOS and Policies.
Please take a look at the updated terms to check if you are happy with the changes. If you are, then you don’t need to do anything, and you can continue accessing and using the YouTube API Services to create great experiences for users. We recommend that you read and understand the Updated TOS and Policies, and make any adjustments to your API Client(s) to comply with the Updated TOS and Policies that become effective in 6 months on February, 10, 2017.
If you do not wish to accept the Updated TOS and Policies, please submit this YouTube API Services termination form by no later than 11:59 pm (Pacific Time) February 9, 2017, and we will reach out to you to process your termination.
We know that developers are busy, so we appreciate you taking the time to review our Updated TOS and Policies! You can subscribe to the RSS feed for revision history to be notified of changes to the terms.
Please note, this e-mail was sent from a notification-only address that cannot accept incoming e-mail. Please do not reply to this message.
—The YouTube API Services Team
© 2016 YouTube LLC. 901 Cherry Avenue, San Bruno, CA 94066 USA
You've received this mandatory service announcement email to update you about important changes to the YouTube API Services.
Wenn ihr mit Interface das kodi gui meint, dann könnte ich da auch beisteuern. Also Menüführung, etc
Jawoll @SLiX mach dich mal an Photoshop und tu nen Vorschlag
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:
[
{
'name':'Erstes Verzeichnis',
'url':'www.abc.de',
'thumb' :'www.abc.de/thumb.jpg',
'type':'dir',
'mode':'listMore'
},
{
'name':'Ein Video',
'url':'www.abc.de/video',
'thumb' :'www.abc.de/video.jpg',
'type':'video',
'mode':'play',
'plot':'Hier steht eine Beschreibung'
}
]
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... 
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
