Beiträge von Timmiotool

danke für die Rückmeldung, deine Hilfe. 6 Stunden oder Neustart kommt bei mir definitive nicht hin (wobei die Ursache natürlich auch anders gelagert sein kann (Notification wird evtl. einfach nur nicht angezeigt)).

Irgendwo muss man aber ja ansetzen.

Hab bei mir ein PI-Hole am laufen, da sehe ich abfragen auf:

releases.libreelec.tv sowie updates.libreelec.tv

von den Kodi Clients, welche auch durch gehen. Nur eine Update Benachrichtigung wird nicht angezeigt. Update Benachrichtigungen der Addons werden immer zuverlässig angezeigt.

Da hat jeder so seine Präferenzen. Ich sehe TV nur noch als Option mal durchs Programm zu zappen, Nachrichten zu schauen, da reicht mir SD. Der Rest (Filme, Serien) wird im Streaming oder als offline Medium konsumiert.

Bin nicht bereit auch nur 1 Cent für das werbefinanzierte Privatfernsehen zu bezahlen um mir Werbung in HD anzuschauen. Das hat einfach so überhand genommen, dass man nicht ansatzweise mehr von Filmvergnügen sprechen kann (Privatfernsehen). Das sieht aber jeder anders und schlussendlich muss man für sich selber entscheiden wie man es gerne hätte.

Grundsätzlich bin aber auch der Meinung, das bei IPTV die Vorteile überwiegen. Sat, lineares TV wird genau in diese Richtung laufen:

Zitat

Wenn ich dann noch überlege, dass die ARD und die Dritten am 07.01.25 SD über SAT abschalten und nur noch in HD übertragen, kann es nur noch eine Frage der Zeit sein, bis die privaten nachziehen und sich sagen "Wer uns noch gucken möchte, kann dann ja HD+ kaufen". Das ist so vorhersehbar...

Geht um das Intervall der Suche nach neues Build's. Zu finden unter Libreelec-> Einstellungen-> Aktualisierung.

Die Update Benachrichtigungen werden bei mir immer sehr zeitverzögert (manchmal 1. Woche) angezeigt. Es gibt dort keine Option das Intervall anzupassen.

Kann man das irgendwo händisch anpassen?

Ich nutze Zattoo, hatte vorher Sat. Bei mir war ein Umzug und "keine Lust auf Strippen ziehen" der Grund. Bin mit der Lösung 100% zufrieden, hatte vorher auch bedenken. Mit dem einbinden über das PVR Plugin ist es perfekt in Kodi integriert incl. Programmübersicht, Senderinfos.

Mit einem Free Account und dem PVR Plugin ist das ganze in 10 Minuten eingerichtet, ohne Kosten. Ich würde das einfach mal einrichten/testen, dann entscheiden.

Mir persönlich reicht die Free Variante, da ich auf die RTL Gruppe/Vergleichbare Sender gut verzichten kann. In der Schweiz ist sogar RTL/Pro 7 (SD) im Free Paket enthalten, in DE dann nur über Abo.

Zitat

Die Vorteile bei IPTV überwiegen für mich pers. eindeutig. Keine Strippenzieherei, keine zusätzlichen Verbraucher und wenn ich im Urlaub innerhalb Europa bin, kann ich mein TV-Programm mal eben mitnehmen.

Dem würde ich zustimmen. Sat ist meiner Meinung nach den Aufwand einer Neu - Installation von Schüssel, Kabel, etc. nicht mehr Wert, da es mittlerweile mit IPTV gute Alternativen gibt.

Perfekt, THX!

Verstehe.

Zitat

Beim Start von Kodi wird das Setting (noch) nicht gelesen, das passiert erst, wenn man in die Settings geht (da reicht das Aufrufen des Settings Screens). Das ist in der Tat ein Bug.

Erklärt das Verhalten. Wenn das mit einem der nächsten Updates gefixt werden könnte wäre das phantastisch PS: Danke für deinen Support!

PvD

Einstellung -> Medien -> Videos -> Informationen für ungesehene Inhalte anzeigen.

War aktiviert.

Zustand:

Aktiviert = Es wird das Cover statt Thumb angezeigt, Overlay der Einstellungen geöffnet, danach OK. Nach Neustart das Gleiche.

Deaktiviert = Es wird immer das Cover statt Thumb angezeigt.

Episoden waren ungesehen.

settings of 'hide for spoiler', 'hide episode thumb of unseen episodes' removed from skin settings

Wenn der Zustand sein soll, das die Hide Funktion (überblenden mit Cover) nicht mehr implementiert sein soll, scheint da leider noch ein Bug drin zu stecken...

PvD seit dem letzten Update werden nach dem Start von Kodi statt der aus dem Video extrahierten Thumbnails Bilder des hinterlegten Covers (oder Fanart) angezeigt (Hauptmenü + Serienmenüs). Geht man kurz in ein Overlay (z.B) das der Einstellungen (wo man die Versionsinfo, Sys Info, Hardware Info sieht) und wieder zurück werden die Thumbnails wieder korrekt angezeigt. Nach dem nächsten Neustart das Gleiche. Gehe ich zurück auf die vorherige Version des Skins ist alles wieder gut.

Ich hoffe, man versteht wie ich das meine. Kann sonst gerne Screenshots nachliefern.

LE 11.0.4 Official auf RPI5 + RPI4

Bei einer Neuinstallation würde ich das ins Auge fassen. Ohne zu sehr ins Detail zu gehen, meine Datenbank/Mediathek ist alt, groß, die älteren Medien aus heutiger Sicht auch schlecht benannt. Der Aufwand wäre hoch und käme eine Neuinstallation gleich. Um das nachhaltig und sinnvoll umzusetzen müsste die Medienablage, Benennung komplett überarbeitet werden.

Bis auf die "Verwaltung" der Thumbs bin ich zufrieden, läuft im großen und ganzen seit mehr als 10 Jahren problemlos, deswegen lasse ich es so.

Abschließend wollte ich (falls jemand sich die gleichen Fragen stellt) noch einmal kurz das Prinzip erklären (hab mir das noch einmal genauer angeschaut).

Dazu auch eine kurze Erläuterung und Fix meines Problems, welches mich zu dieser Frage bewogen hat.

Grundsätzlich werden die Thumbs bzw. die URL der Bilder Quelle in der Tabelle "Art" gespeichert, anhand der ID den Serien/Filmen zugeordnet.

Hier wird ausschließlich die Quell URL gespeichert aus der dann schlussendlich das Thumbnail und Hashwert generiert und im Thumbnail/Artworkcache (bei mir zentral) abgelegt wird. In der Regel sind die Quell URLs Pfade zu den Online Covern, Actors, etc. der Scraper Beispiel:

https://image.tmdb.org/t/p/original/6vwdsO3wG26DatBgkVyPY9OjnDL.jpg

Solange diese URLs erreichbar sind (was bei sehr alten Datenbanken wie meiner nicht immer der Fall ist) könnte man sogar gefahrlos die lokale Textures DB der Clients löschen, den zentralen Thumbnail/Artworkcache leeren, da die Thumbs danach einfach neu generiert werden würden aus den Quell URLs.

Ist nun der lokale Thumbnail/Artworkcache korrupt (das war bei mir der Fall durch einen Raid Defekt) und man muss diesen löschen/neu erstellen, bekommt man in der Realität das Problem, das Thumbs zu einigen Einträgen fehlen werden (Quell Bild nicht mehr per URL erreichbar).

Ich hab für mich einen recht einfachen Fix gefunden, wie man die bestehenden Thumbs wieder an alle Clients verteilt bekommt:

Voraussetzung ist eine komplette Sicherung der DB (aus Kodi) zum Zeitpunkt wo das System noch intakt war! Macht man hier: Bibliothek -> Bibliothek Exportieren -> in Einzelne Datei.

Hier wird ein Export Ordner erstellt der die komplette Video DB und (das ist das Entscheidende) alle Cover extrahiert aus dem Thumbnail/Artworkcache enthält.

Im nächsten Schritt habe ich die Video DB in Maria, den zentralen Thumbnail/Artworkcache , die lokale(n) Textures.db gelöscht.

Die Sicherungsdatei bzw. den Ordner habe ich nun im Netzwerk abgelegt (hier bietet sich der gleiche Ordner wie der zentrale Thumbnail/Artworkcache an).

Der Schritt die Sicherung im Netzwerk zu speichern ist notwendig, da wir ja wollen, das alle Clients Zugriff auf diese Daten haben (auf einem lokalen LW: C: gestaltet sich sowas schwierig).

Im nächsten Schritt lesen wir nun über einen beliebigen Client die Sicherungsdatei über den Netzwerkpfad ein. Macht man hier: Bibliothek -> Bibliothek Importieren -> Zeroconf Browser um auf die Netzwerkfreigabe der Sicherung zu gelangen, danach Import!

Anschließend sollte die komplette DB incl. aller Cover soweit wieder vorhanden sein und alle Clients können diese Thumbs auch (ohne funktionierende Online Quell URL) abrufen denn:

Beim einspielen der Sicherung wird in der "Art" Tabelle nun als Quell URL der lokale Netzwerkpfad zum Thumb der Sicherung gespeichert (Sicherung liegt für alle verfügbar ja nun im zentralen Thumbnail/Artworkcache ) jeder Client kann hier nun die Thumbs abrufen um Hash Werte zu generieren, das Thumb neu im zentralen Thumbnail/Artworkcache ablegen.

Das ganze Konstrukt "Gemeinsame Thumbs + geteilte DB" ist schon wie @DaVu sagte "solala" aber wenn wann die technischen Hintergründe kennt zu händeln.

Input zu Artworkcache findet man im Kodi Wiki: Artwork/Cache im Kodi Wiki

Zitat von buers

Zum Thema Teilen der Thumbnails, siehe auch RE: Wie erreiche ich 24p-Wiedergabe mit TV, AV-Receiver, FireTV 4K Max (Gen.2) und KODI 21? und ff. Persönlich sehe ich kein grundsätzliches Problem nach Analyse des Quelltext. Aber selbst Team-Kodi Mitglieder scheinen das nicht alle gleich zu sehen.

Ein Argument, was ich fand, ist dass die verwendeten Thumbnails auch vom Gerät abhängen können (sagen wir mit 4k Bildschirm anders als mit altem VGA-Bildschirm, wo kleinere Auflösung reiche). Aber dann wäre nach meinem Verständnis das ganze Konzept kaputt. Mein Notebook nutzt mal das eigene Display, mal einen externen Monitor, mal den Fernseher mit wieder anderer Auflösung. Und, nach meinem Quelltext-Verständnis würde es eh trotzdem noch klappen. Wahrscheinlichkeit von Hash-Kollisionen steigt. Aber das ist kein neues prinzipielles Problem. Das Problem ist eh schon da bei ungeteiltem Thumbnail-Ordner Ordner.

Ich hab einen ähnlichen Mix: Raspberry, Fire-TV, PC und konnte über Jahre hinweg keine Kollisionen beobachten (mag sein das es mal welche gab die mir nicht aufgefallen sind). Für mich funktioniert der gemeinsame Thumbnail Cache somit recht gut (auch wenn prinzipbedingt das ganze nicht sauber ist). Danke für den Input!

Zitat von DaVu

Und jeder Client hat seine eigene TexturesXX.db

Diese zu zentralisieren könnte zu Problemen führen. Man kann sie auslagern via PathSubstitution. Das müsste dann aber jeder Client machen und würde so entsprechend Platz von jedem Client auf dem NAS belegen. Über die PathSubstitution eine Art Zentralisierung zu bewerkstelligen ist eher "solala" und wäre nicht das, was ich empfehlen würde.

Je nach Netzwerkgeschwindigkeit könnte es mit ausgelagerten Thumbs auch zu längeren Ladezeiten bei den Covern kommen.

Wenn du das Cover auf Client "a" änderst verweist du auf ein anderes Bild. Der Pfad zum Bild ist in der MyVideos.db gespeichert. Das Feld sollte laut Wiki "c08" sein (Image URL). Ändert sich das Bild und du schreibst das in deine MySQL/MariaDB dann ändert es sich für alle Clients und alle Clients schreiben dann den neuen Hash in ihre lokalen TexturesXX.db Dateien

Verstehe. Mir ging es bei meiner Frage genau um diese Thematik, da ich mich gefragt habe ob es zu Wechselwirkungen/Problemen führt, wenn in der DB keine eindeutige URL hinterlegt ist. Habe einen gemeinsamen Thumb Speicher, den alle Clients nutzen, der liegt auf der Nas. Ich habe das Konstrukt in der Form um die 10 Jahre am laufen, konnte noch keine Probleme feststellen... Aber das es eher suboptimal ist, sehe ich mit dem Hintergrund wissen ein. Danke für den Input!

Zitat von buers

Ich kenne die interne Struktur der DBs in Kodi nicht sehr gut. Allerdings weiß ich, dass Kodi für die URLs der Thumbnail-Quelle einen Hash-Wert generiert. Ich nehme an, die Quell-URL steht in der DB. Daraus wird ein 32-bit Hash Wert generiert (Kodi nutzt CRC32). Den kann man jederzeit sehr schnell aus der URL berechnen. Dieser 32-Bit Wert wird Hexadezimal dargestellt (also mit Ziffern 0-9 und Buchstaben a-f. Dein Beispiel scheint paar Vertipper zu enthalten - daher erfinde ich ein neues Beispiel. Bei mir hasht die URL zum "Ganz oder Gar nicht" Cover zu 7e8ee14a. Der Name des Thumbnails heißt dann 7e8ee14a.jpg. Abgespeichert wird er in einem Ordner "7" (das erste Zeichen des Hashwertes) - also irgendwo in Kodi-Verzeichnis/userdata/Thumbnails/7e8ee14a.jpg.

Die Erklärung ist sehr verkürzt und erfordert bisschen Kenntnisse (von nicht total ganz alltäglichen) IT-Begrifflichkeiten und Konzepten.

Komm selber aus dem IT - Bereich. Sowas hab ich mir gedacht aber im Netz keinerlei Infos gefunden. Mein Beispiel war "ausgedacht", sollte das Prinzip der Ablage aufzeigen. Wäre natürlich noch interessant zu wissen, welche Quell-URL zur Generierung des Hash Wertes genutzt wird (finde ich sicher selber heraus). Meine Frage ist beantwortet! Besten Dank

Die liegt aber nicht im Netzwerk, sondern lokal auf den Clients. Wenn ich bei Client A ein Cover ändere, wird es schlussendlich auch auf Client B übernommen, der bekommt aber ja nicht die Textures13.db vom Client A sondern irgendwoher die Daten wo das Thumb liegt...

Hi. Ich habe kein technisch Problem aber ich würde gerne verstehen wie etwas funktioniert

Kurz zu meiner Konfiguration:

Verwende Kodi mit Maria DB, Thumbnails sind per <pathsubstitution> ausgelagert- liegen zentral im Netzwerk.

Ändere ich, sagen wir mal ein Cover, ziehen sich meine Clients das aktuelle Cover aus dem zentralen Thumbnail - Speicher, klappt wunderbar.

Suche ich mir nun exemplarisch ein Cover Thumbnail aus dem Thumbnail Speicher ist dieses auch eindeutig benannt z.B:

\\NETZWERKSERVER\kodi_thumbs\5\73a72dfa4.jpg.

In meiner Maria DB finde ich 3a72dfa4.jpg oder den Netzwerkpfad aber nicht. Ich würde hier erwarten, dass

in der DB hier eindeutige Einträge zu finden sind - denn woher soll der Kodi Client sonst wissen wo das Thumbnail liegt!?

Weiß hier jemand wie die Speicherung der Thumbnails technisch funktioniert und was dort für eine Logik hinter steckt?

Hi. Hab hier einen kleinen Bug. RPI4 mit Libreelec 11.03 und dem aktuellen Estuary Mod v2.

Geht man auf Filme -> Darsteller (Bild 1), klickt dann auf den jeweiligen Darsteller um die Auftritte zu sehen folgt einfrieren + Neustart Kodi/RPI.

Wechselt man den Skin auf Estuary Standard klappt es.

Hi. RPI4 mit Librelec 11.01/Kodi 20.1. Zattoo CH. Nach dem Update auf v20.3.10 stürzt(e) bei mir ebenfalls Kodi bzw. der Stream ab.

Rätsels Lösung ist Widevine erneut zu installieren/upzugraden (geht im Inputstream Helper Plugin). Scheint so, als wenn v20.3.10 bzw. der daraus übergebene Stream ein aktuelles Widevine benötigt. Wie rbuehlma bereits erwähnte, ist hier nicht direkt das Plugin sondern inpustream.adaptive/Widevine der Übeltäter.

Build v19.X Matrix mit Fix:

https://mirrors.kodi.tv/nightlies/wind…-Matrix-x64.exe

Test Build (v20) with fix/workaround:

https://mirrors.kodi.tv/test-builds/wi…ont-AMD-x64.exe

Hatte das Problem gerade auch (Graka getauscht RX6600, deswegen war die Ursache sofort klar). Selbst mit dem aktuellen Treiber ist das Problem noch vorhanden. Danke für den FIX, hat Abhilfe geschaffen.