MediaLibrary: Infos zu tatsächlich enthaltenen Audio- und Untertitel-Sprachen

  • :D Moment da kann ich sogar ganz konkret werden.
    Diese Einstellung da gilt für:

    • Container formats: AVI, MPEG, WMV, ASF, FLV, MKV/MKA (Matroska), QuickTime, MP4, M4A, AAC, NUT, Ogg, OGM, RealMedia RAM/RM/RV/RA/RMVB, 3gp, VIVO, PVA, NUV, NSV, NSA, FLI, FLC, DVR-MS and WTV
    • Video formats: MPEG-1, MPEG-2, H.263, MPEG-4 SP and ASP, MPEG-4 AVC (H.264), H.265 (as from Kodi 14) HuffYUV, Indeo, MJPEG, RealVideo, RMVB, Sorenson, WMV, Cinepak.

    Quellenangabe: http://kodi.wiki/view/Features_and_supported_formats

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

  • Das wiederum finde ich sehr schade. Deine Arbeit hätte mehr Wert, wenn du Sie in die Community zurückfliesen lassen würdest. Am besten in den passenden Skin - ohne diesen zu forken.
    Das würde dir auch ersparen, deine Modifikationen auf jede neue Version anpassen zu müssen.


    Einen Skin in den es zurückfließen kann gibts nicht weil der komplett selbst entwickelt wurde und seit 5 Versionen verwendet wird.
    Zwangsläufig Pflege ich ihn also, aber eben nur das was wir verwenden.

    Dazu müsstest du den Skinengine besser kennen um die Gründe zu wissen, warum ich mich dafür entschieden habe.

    In aller Kürze:
    Vieles im Enginge wird mehrfach verwendet und muss dadurch zwangsläufig über Bedinungen "verschieden Aussehen".
    Diese Bedingungen werden jedesmal geprüft, geladen, verglichen..
    Warum also sollte ich Ansichten künstlich verlangsamen/mich einschränken lassen im Aussehen,
    wenn ich in den letzten 10 Jahren nicht einmal PVR genutzt habe, Bilder eingepflegt, Musik gehört oder Addons verwendet habe?

    Nur in der wagen Hoffnung das danach 10 andere den Skin nutzen, und nicht nachdem ich mit dem komplizierterem Code
    "leben" muss nach zwei Wochen den nächsten skin Verwenden?

    Und nur dafür Baue ich auch keinen PVR Support und Fenster wie Untertitelsuche ein die ich nie im Leben jemals außer fürs Skinnen
    öffnen werde, und Kleister den Skin, den wir Definitiv nutzen wollen, mit für uns Unnützem "zu" das auch noch langsamer wird bis ich alles
    "deaktivierbar" Eingebaut habe.

    Und ich Behaupte mal ich trage hier genug bei, auch ohne Skin .
    Dazu gibts ja auch weißgott genügen Alternativen.

    Grüße

  • Danke für die detailierten Einsichten. Sehr interessant.

    Hast du Code entfernt, oder deaktiviert? Im letzteren Fall wäre das ja eine Funktionalität, die für andere Leute auch interessant wäre. Wenn man sozusagen per Einstellungsmenü verlangsamende und unbenötigte Komponenten deaktivieren könnte. Das hätte durchaus Wert für die Community.

  • Hast du Code entfernt, oder deaktiviert? Im letzteren Fall wäre das ja eine Funktionalität, die für andere Leute auch interessant wäre. Wenn man sozusagen per Einstellungsmenü verlangsamende und unbenötigte Komponenten deaktivieren könnte. Das hätte durchaus Wert für die Community.

    Um das gehts ja.. Deaktivieren in dem Sinne gibts nicht im Skinegine.

    Es gibt 2 Arten Code zu implementieren

    Ein Resolutionflag für Ansichten der so aussehen kann.

    Code
    <control type="image">
    				<left>1050</left>
    				<top>15</top>
    				<width>63</width>
    				<height>36</height>
    				<texture>$INFO[ListItem.VideoResolution,flagging/resolution/,.png]</texture>
    			</control>


    Wenn ich den jetzt aktiv/inaktiv schalten will brauche ich ein Setting dafür. Das ist im wesentlichen ein Knopf in den Skinsettings der true/false
    in deine userdata/addondate/skin/settings.xml schreibt

    Das heißt dann Meinetwegen "ResolutionFlags"
    Jetzt kann ich den Code direkt in einer Liste verwendet und mit <visible>!Skin.HasSetting(ResolutionFlags) + !String.IsEmpty(ListItem.VideoResolution)</visible>  könnte ich ihn ausblenden wenn ein user es auf nicht anzeigen stellt.
    Das wird aber jedesmal wenn ich die view öffne geprüft und einfach nur nicht angezeigt.

    Die zweite Variante wäre diesen codeblock in ein include zu packen was "ausgelagerter Code" wäre.

    Code
    <include name="Resolutionflag">
    	<control type="image">
    		<left>1050</left>
    		<top>15</top>
    		<width>63</width>
    		<height>36</height>
    		<texture>$INFO[ListItem.VideoResolution,flagging/resolution/,.png]</texture>
    	</control>
    </include>

    und das aufrufen in einer liste mit <include condition="!Skin.HasSetting(ResolutionFlags)">Resolutionflag</include>
    Das würde nur geladen werden wenn die Einstellung vorhanden ist.
    Das hat aber wie man schnell sieht einen Pferdefuß: Ich kann jetzt Z.B. nicht so einfach die Positionierung rauslassen, es geht zwar
    machts aber komlizierter, also was tun wenn ich ihn an 3 Plätzen brauche?
    Auch wegen der Menge an includes die dabei entstehen würde ist es auch nicht für jeden "kleinmist" brauchbar.

    Beim laden wird aber Trotzdem jedes mal alles egal ob include oder visible aufs neue geprüft und verlangsamt dadurch auch einen
    Skin.

    Ein wirkliches Beschleunigen für langsame Systeme käme dann erst wenn man nicht benötige Dinge aus Dateien streicht.
    Und da jeder Skin ein Unikat ist gibts da nicht viel außer sich gut im Skincode auszukennen - un natürlich nicht soweiso alles zu brauchen
    was vorhanden ist;)..

    Ein Ansatz wäre die skinsettings durchzugehen, alles was man dort an/abschalten kann kann man sich als doppelten code Vorstellen.
    Es gibts zwar auch Möglichkeiten das laden durch includierung zu verhindern, das macht aber an vielen Stellen keinen Sinn.

    In der Praxis sind solche Beispiel natürlich immer komplizierter.

    Aus der Praxis mal die Hintergründe in "Videos" im Skin Transparency:

    Spoiler anzeigen

    Kann man auch ohne Kenntniss schnell erkennen das das sicher langsamer sein dürfte als Hintergrundbild als nur ein Fanart und sonst nix das nur noch dieses wäre.

    Brauche ich also kein multiimage und was weiß ich nicht alles, läuft trotzdem jedesmal der ganze Codeblock durch - grob gesagt bei jedem öffnen des Fensters aufs neue.

    Eine Stelle fällt jetzt nicht ins Gewicht, Dutzende oder gar Hundert schon.
    Aber da muss jeder selber durch, es für sich entscheiden und sich auch darüber klar sein das man danach ebenfalls ein
    Unikat hat das man eigenständig Pflegen und verwalten muss bei Updates.
    Dazu muss man aber auch genug Ahnung von Skincode haben um das wirklich hinzubekommen.
    Eine Anleitung gibts dafür nicht - mein code paßt auch nur zu meinem Skin und ist nicht als "Funktionalität" zu sehen.

    Grüße

  • Sehr interessant. Danke für die detailierte Erklärung.
    Wie du schon sagtest, verstehe ich von den Internas nichts. Spontan würde mir einfallen, den Code dynamisch imt einem Python-Script generieren zu lassen. Bei jedem Ändern der Settings, müsste wahrscheinlich noch zum Neustart aufgefordert werden (kleiner Nachteil). Beim nächsten Start vergleicht das Skin-Python-Script ( ;) ) den hash der Settings-Datei, bemerkt so ggf. Änderungen und generiert (vor dem Laden des Skins) dessen Code neu. Wie gesagt - ausm Bauch raus. ;)

  • Wie du schon sagtest, verstehe ich von den Internas nichts. Spontan würde mir einfallen, den Code dynamisch imt einem Python-Script generieren zu lassen. Bei jedem Ändern der Settings, müsste wahrscheinlich noch zum Neustart aufgefordert werden (kleiner Nachteil). Beim nächsten Start vergleicht das Skin-Python-Script ( ) den hash der Settings-Datei, bemerkt so ggf. Änderungen und generiert (vor dem Laden des Skins) dessen Code neu. Wie gesagt - ausm Bauch raus.

    Das wäre sogar sicher einfacher möglich - davon hab ich aber wiederrum keinen Plan.
    Das menüscript skin.shortcuts macht sowas aber fürs Menü und Templatebasiert für Widgets. Dort wird einfach per Runscript wenn man die Settings verläßt quasi immer Zwangsweise das Include bzw. die erzeugte xml neu erstellt.

    Das wäre sicher nicht das Problem.

    Was eher der stolperstein wäre ist das verzahnen.
    Es wäre ja nicht nur ein Code Block der sich ändert sondern viele. Da steht man schnell vorm Problem wie man das Handeln soll im Code und Schlimmer, wie Visualisiert man eine Einstellung dazu.

    Stell dir die Listeview vor mit dem Resolution Flag.. Dort will ich dann noch ein Watchedoverlay haben, rechts davon das dann wenn man es aktiviert das Resolutionflag Symbol nach links "schiebt". Weil wir schon dabei sind dann aber bei Sets ein Setsymbol.
    Und was wenns auch noch 3D ist? also nochmal eins dazu.. Dann hätten wir schon 3 bis 4.

    Nicht nur das man jetzt jedes Kombination des Codes irgendwie in Verbindung hinterlegen müsste wenn man einfach sagt per script "schreibe Datei a als xml soweiso bei Setting xxx", man braucht auch ein Verständliches Settings dazu im Skin. Da man dort ja fast nur auf Buttons beschränkt ist, kapiert das ja schnell keiner, und eine Visualisierung in der Art eine Ansicht zu hinterlegen mit Buttons drauf die zeigen was man an/aus schaltet sprengt ja definitiv den Rahmen weil es ja tausende Zeilen Code wären, die wir ja vermeiden wollen.

    Ich denke das wird alles zu kompliziert als das man irgendwas spart.

    Du müsstest dir mal deinen Skin den du nutzt schnappen und in einer Kopie etwas herumexperimentieren inwieweit das was nützt.
    Einige Views die man nie verwendet in ein guter Ansatz den man auch am ehesten Bemerken wird in der Bedienung und auch den Vorteil mit sich bringt das man beim Viewwechsel nciht ständig dieselben "überspringen muss".

    Dazu einfach mal die MyxxxNAV Dateien öffnen, die Viewincludes identifizieren und alle die man nicht nutzen will inklusive der ID Nummern die die header dieser Dateien und <views> eingetragen sind entfernen.

    Sofern man einen "Viewschalter" im Skin hat der wirklich nur alle durchschaltet die verfügbar sind und nicht einzelne views öffnet,
    hat man zumindest mal einiges los an code, der dann zwar noch "tot" irgendwo herumliegt und womöglich an einigen stellen noch
    sinnlos Abgefragt wird, aber man merkt spätestens jetzt ob es überhaupt was bringt.

    Je nach System Reden wir hier ja von Milisekunden, kommt natürlich auch extrem auf den Skin an (wie kompliziert), wie komplex andere Fenster sind wie die Home.xml, die DB Größe sicher auch usw..

    Für mich als Betreuer eines Skins sicher Marginaler - 1000 Zeilen weniger Code liest sich leichter und läßt sich global vieles eher vereinheitlichen was durch die Nutzung von gleichen includes dann auch einen Geschwindigkeitsvorteil bringt.

    Grüße

Jetzt mitmachen!

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