-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Landscape fanart & contentid change #194
Comments
Das wird jetzt etwas schwierig...denn über Geschmack lässt sich bekanntlich (nicht) streiten. Punkt 1: Punkt 2: Vielleicht bekommen wir hier noch ein paar Meinungen dazu? |
Hm... Das ist das Problem mit content types, wenn ein Addon sie setzt. Kodi sieht vor, dass Video-Addons dies ausschließlich mit dem type videos tun sollte, nicht mit anderen. Skins sollten an content types angepasste Ansichten haben, nicht Addons content types setzen, damit bestimmte Ansichten erzwungen werden - das sage ich als Skinner, der darauf angewiesen ist, dass Addons berechenbar nach Vorgaben content types setzen. Ich wäre sehr dankbar, wenn dieses Addon dies wie andere tun könnte 👍🏻
Ja, dieser Punkt ist sicherlich Geschmackssache. Auch hier ist das Problem, dass es mit einem Skin wie Estuary in Ordnung aussieht, mit einem Fanart-zentrierteren Skin wie dem OSMC Skin allerdings weniger. Wäre hier ein Kompromiss möglich? Z.B. hochauflösendere, auf 16:9 ausgelegte Fanarts für jeden Sender und nicht nur die Icons doppelt? :) |
Vielleicht kannst du dazu mal die Doku linken? Kann ja nie schaden mal was neues zu lesen.
Das wird schwieriger. Die Repos aus dennen die Sender kommen, haben i.d.R. nur 256x256.
Kannst du das vielleicht noch etwas genauer fassen? Ich habe mir grade mal das OSMC skin installiert und finde es eigentlich gut...wahrscheinlich weil ich es nich anders kenne !? |
Item-Listen, die selbst keine Videos enthalten (wie übergeordnete Listen mit Sendern) haben entsprechend, wie zb im Youtube addon, das von Kodi devs bei git als Referenz erwähnt wird, keinen content type.
|
|
|
Schick mir doch mal was du siehst und was du erwartest. Dann kann ich das hier Lokal nachvollziehen... |
Z.B. die Ansicht "Wall info" des OSMC Skins ist für Serien, Staffeln oder Filme in der Kodi-Bibliothek mit einer hinterlegten Beschreibung oder eben Videos mit Beschreibung eines Video-Addons gemacht. Entsprechend setzen sie auf den korrekt gesetzten content type (movies, tv shows, seasons, videos). Wird der content type nun in einer Liste gesetzt, die für keinen Eintrag solche Informationen zur Verfügung stellt, sieht es so aus: Das ist nicht, wofür die Ansicht gemacht ist. Die Kontrolle hier drüber sollte entsprechend beim Skin liegen. Auch andere Skins machen das - Estuary ist da sogar meist sehr großzügig und bietet fast alle Ansichten überall an, egal welcher content type gesetzt ist. Umso angepasster die Ansichten allerdings sind, umso eher greift der (zugegeben eher schlecht dokumentierte) Ansatz von Kodi, dass der content type die grundlegende Steuerungsmöglichkeit der Skins ist, um spezifisch an Inhalte anpassen zu können. In einer Liste, die videos enthält (und entsprechend meiner Einstellung in den Addon-Einstellungen des Mediathekview-Addons den content type "videos" gesetzt hat), sieht es dann sinnvoll und korrekt aus: Und schlussendlich... So sieht dann eine Ansicht aus, die korrekt im OSMC Skin für eine Ansicht zur Auswahl steht, die keinen content type setzt, da es letztendlich "nur" eine Liste ist: So müsste z.B. auch die Liste aussehen, die die Sender auflistet. Der aktuell gesetzte content type ist im Debug Overlay des OSMC Skins übrigens immer oben rechts in der Ecke zu sehen (siehe Screenshots). |
Und wenn man einfach bei den Sendern noch Erklärtexte von wikipedia hinzufügt?
Ich finde den unschärfe Effekt auch nicht schlimm. |
Ich habe einen anderen Teil noch nicht einmal angeführt: Es fehlen alle zusätzlichen Informationen, die eine Ansicht mit dem content type movies zur Verfügung stellen würde. In einer korrekten Liste gäbe es zusätzlich sekundäre Informationen neben den Beschreibungstexten, die in einer zweiten Zeile unter den jeweiligen Listentiteln (oder bei Wall oder anderen Ansichten an anderer Stelle) angezeigt werden würden: All diese Felder, die für movies-spezifische Informationen vorgesehen sind (jeder Skin hat da eigentlich in irgendeiner Form speziellen Platz für vorgesehen), bleiben mit einer reinen Senderliste wie auch mit anderen Listen des Mediathekview-Addons leer. Ich sehe keine realistische Möglichkeit, dies zu ändern. Aber eventuell über sehe ich da auch was.
Der Unschärfe-Effekt aufgrund (zu) niedriger Auflösung im Hintergrund ist halt nicht das, was vom Skin und Kodi intendiert ist. Auch sollte Fanart im Hintergrund das Hintergrundbild des Skins überdecken, was normales Fanart auch tut... (Teil-)transparente Icons aber eben nicht.
Das klingt nicht schlecht. 👍🏻 Wenn ich es mir wünschen dürfte, wäre es schön, wenn das Addon überall in Listen, die Videos mit zusätzlich hinterlegten Informationen auflisten, fest den content type videos setzen würde, der für Video-Addons vorgesehen ist, in normalen Item-Listen keinen (wie dies auch andere Addons korrekt tun) und im Hintergrund wenn bildfüllende, hoch genug auflösende Fanart anbietet. Dann würde das Addon die Informationen korrekt zur Verfügung stellen und alles weitere den Skins überlassen. Wenn die Darstellung nicht ganz dem eigenen Geschmack entspricht, dann liegt dies am Ende ja eher am Skin, als daran, dass das Addon den Skin nicht so, wie gewünscht, dazu zwingt, es anders als vom Skin intendiert anzuzeigen. Das ist meine Perspektive als Skinner. |
Wie ist der Stand der Überlegungen hierzu? Würde mich sehr über Veränderungen freuen, wenn mein Input denn überzeugend war 👍🏻 |
Eigentlich wird alles was hier aufläuft irgendwann auch umbaut...in welcher Form oder wann kann ich dir noch nicht sagen... |
Ich habe jetzt die Bilder neu gebaut. Ich glaube es hätte schon gereicht auf 16x9 zu gehen...ich vermute Kodi skaliert da irgendwie rum und dadurch werden die Bilder unscharf... |
Ich bitte die verspätete Rückmeldung zu entschuldigen! Der korrigierte ContentType in den Listen ist perfekt, vielen Dank 👍🏻 Mit den Hintergrundbildern kann ich mich nicht wirklich anfreunden... Sie sind jetzt zwar hochauflösend, allerdings jetzt durch den fehlenden Rand um sie herum bildschirmfüllend bis an die Ränder dargestellt und je nach Farbe des Skins mal besser, mal schlechter zu erkennen. Monochrom und mit Rand wären sie mMn mit erheblich mehr Farben, Skalierungsarten (bildfüllend, etc.) und somit Skins kompatibel. Hier zwei Beispiele davon, was ich meine: Ließe sich da noch was anpassen? Ich denke, dass es nicht nur eine Anpassung an den OSMC Skin wäre, aber die Hintergrundbilder und Icons kompatibler machen würde (obwohl ich persönlich die Bilder im Hintergrund immer noch gänzlich weglassen würde, wie es zuvor war). |
Gibt es hierzu Neuigkeiten? :) |
Released als 1.0.9 |
Ich möchte zwei neu aufgetauchte Probleme der neuen 1.0.0-Version vermelden.
Der content type wird, unabhängig vom content type-Setting in den Einstellungen des Addons, in den ersten Listen Livestreams, Kürzlich hinzugefügt und Durchsuchen auf movies gesetzt und sorgt damit für eine merkwürdige Darstellung in Skins, die content types zur Zuweisung bestimmter Darstellungen z.B. von Listen nutzen. Kann in dieser Liste der Sender der content type wie bei älteren Versionen wieder leer bleiben? Er ist korrekt leer, wenn man eine Ebene weiter geht und die Liste der Sendungen eines Senders aufruft.
In der neusten Version werden die Icons für Sender und Sendungen (letztendlich alle Icons, die das Addon bietet) auch als ListItem.Art(fanart) gesetzt. Damit tauchen diese, je nach Skin, riesig und unscharf im Hintergrund auf. Ist es möglich, dies wieder rückgängig zu machen und das Infolabel ListItem.Art(fanart) leer zu lassen?
Fanart sollte eher ein hoch aufgelöstes, möglichst 16:9-kompatibles Bild sein, was (wie ich verstehe) leider bei den einzelnen Sendungen über das Mediathekview-Backend nicht bereitgestellt werden kann. Enstprechend wäre keines dann allerdings IMHO eleganter.
Ein Screenshot, der beide Probleme gut demonstriert:
Danke für die tolle Arbeit an diesem Addon!
The text was updated successfully, but these errors were encountered: