Beiträge von Timmiotool

Ich kann Dir nur den Tipp geben: Wenn du nicht 100% weißt, was du in der DB machst, lass die Finger davon.. Da macht man schneller was kaputt als man denkt.

Die Datenbank von Kodi ist alles andere als trivial, hat sehr viele Abhängigkeiten der Tabellen untereinander, die nicht immer ersichtlich sind da innerhalb der Tabellen ab und an die ID gewechselt oder wie bei den Thumbs sogar Quersummen aus den Links gebildet werden um diese dann dem Thumbcache zu zuordnen. Ich bin hier im Forum selten aktiv aber schon seit XBMC Zeiten dabei, ich hab den gleichen Mist vor Jahren genauso blauäugig versucht - ist nie gut gegangen

Zitat von locha

Weiß wer ne gute Quelle, vorzugsweise deutsch, wo ich mich über MariaDB/phpMyAdmin oder Grundlegend über Datenbanken informieren kann?

Schau am besten mal bei YT da findet man genügend Anfänger Tutorials, die auch die Grundlagen erklären. Fachliteratur dürfte an der Stelle den Rahmen sprengen.

Zitat von locha

Das kann alles ausgeschlossen werden, hier läuft schon alles und muss nicht anlaufen...

Wie gesagt das Cover von Film 1 ist ja ruck zu da, nur wenn neben Film 1 ein Film mit einer 4-stelligen ID ist, dann merkt bzw. sieht man die Wartezeit. Ändere ich die ID von 4-stellig auf 2-stellig geht es auch ruck zuck. Ich hab von der Thematik auch keine Ahnung, deswegen frage ich ja hier, aber trotzdem kann mir bis jetzt keiner so richtig erklären wieso das so wie ich es mache funktioniert…

Habe immer nach Änderungen sporadisch Filme aus der DB abgerufen, hat sowei alles funktioniert. Musste nur bei den geänderten Filmen die Arts neu einlesen per Information->Grafik auswählen usw.

locha du hast schon eine Erklärung bekommen:

Zitat von Lehmden1

Du hast das Prinzip, wie das Ganze funktioniert, einfach nicht verstanden. Beim ersten Mal -> lahm bis extrem lahm, ab dem zweiten Mal blitzschnell. Daran ändert das manuelle Herumpfuschen in der DB absolut gar nichts. Falls das doch einen Einfluss haben sollte, dann nur, weil du die DB geschrottet hast und nix mehr geht.

Stimm Dir 100% zu Lehmden1.

Zitat

Ja, wird ein Film gelöscht wird die ID frei, hab mir notiert welche IDs frei sind und diese neu belegt. Hab bis jetzt nichts negatives festgestellt, noch nicht.... wie gesagt, eher nur positives, sprich Arts von dem betroffenem Film werden schneller geladen.

Ist nicht richtig. Die kompletten Einträge bleiben in der DB. Lösch mal einen und füg den wieder hinzu... Da wirst du bemerken, das der noch nicht einmal als "neu hinzugefügt" angezeigt wird, da die kompletten "alten" DB Einträge weiter vorhanden bleiben. Der Eintrag wird lediglich aus einer Tabelle entfernt, die quasi den "View" steuert. Warum ist das jetzt "schneller"? Ganz einfach: Der Eintrag wird nicht zum ersten mal eigelesen, ist bereits in den lokalen Caches der Clients vorhanden.

Nimms mir nicht übel locha, ist ja deine DB aber dran rumzufummeln, obwohl man keine Ahnung hat, wie das eigentlich funktioniert, welcher Abhängigkeiten innerhalb der Tabellen vorhanden sind, das kann nur schief gehen. Du lieferst ja gerade selber das Beispiel:

Zitat

Habe immer nach Änderungen sporadisch Filme aus der DB abgerufen, hat sowei alles funktioniert. Musste nur bei den geänderten Filmen die Arts neu einlesen per Information->Grafik auswählen usw.

Was meinste warum du das machen musstest? ...dort fehlt jetzt die Zuordnung der Art Tabelle und das ist nur eine von diversen Tabellenzuordnungen, die nicht mehr passen. Dafür hat jetzt wahrscheinlich irgendein anderer Eintrag diese Daten und es werden die falschen Infos angezeigt. Du schrottest Dir damit schlicht die DB, da du das Grundprinzip (noch) nicht verstanden hast.

Das ganze findest du im Wiki: Klick

Vielleicht noch ein ein Hinweis: Spätestens wenn ein Change der Video DB ansteht von Kodi 21 (Video132) auf Video132 oder was auch immer es wird, wird dir die Migration um die Ohren fliegen, da die SQL's auf die Nase fallen. Wenn du eine DB Sicherung der SQL hast würde ich dir raten, diese wieder einzuspielen.

locha Interessant zu wissen wäre, ob du mittels pathsubstitution die Thumbnails in der advancedsettings.xml
ausgelagert hast (auf die Nas)? Wenn du das getan hast, kann es durchaus zu längeren Wartezeiten, wie beschrieben kommen.

Wenn nicht, sollten die Cover nach dem ersten Laden (lokal) gecached, sofort verfügbar sein.

Zitat von locha

Also der Punkt mit den Ladezeiten der Cover/Fanart von teilweise 15s bei neu hinzugefügten Filme nervt mich total

Hab jetzt mal zum Test händisch bei ein paar Filme die idMovie so angepasst, dass diese näher an der alphabetischen Sortierung liegt und siehe da, viel viel besser und "gleichmässiger" Aufbau der Arts.

Es macht doch viel mehr Sinn, dass die Datenbank von Kodi, welche alphabetisch sortiert ist auch in dieser Reihenfolge aufgebaut/abgerufen wird und nicht nach der Abhängigkeit der idMovie.

Bin ich den der Einzige den das stört oder habt ihr das Problem bei ausgelagerter Kodi DB und neu hinzugefügten Inhalten (Filmen) nicht?

Du hast ja oben schon erwähnt, das du nicht sonderlich viel Ahnung von Datenbanken hast, das merk man an dieser Äußerung auch ganz gut

Also der Punkt mit den Ladezeiten der Cover/Fanart von teilweise 15s bei neu hinzugefügten Filme nervt mich total

-> Wenn keine ausgelagerten gemeinsamen Thumbs, werden diese beim ersten Laden über den vom Scraper gelieferten Link (das kann eine URL im www oder auch ein lokaler Link (z.B auf der Nas) sein)) bezogen, lokal (auf dem jeweiligen Client) gecached. Das kann nun sein, das die Quelle einfach nicht so schnell liefert... Evtl. muss dein Nas auch erst aus dem Standby anlaufen, bis die SQL DB oder SMB Daten liefern kann. Die Synology DS 220j ist extrem schwach, klar läuft da Maria, MySQL drauf aber das ist einfach keine Rakete. Denk vielleicht einfach drüber nach die Nas nur als Medienquelle zu nutzen, überlasse den Rest Geräten, die das besser können. Ich hab die SQL DB, Thumbs z.B auf nem RPI5 ausgelagert (braucht einfach nicht viel Strom im 24/7 Betrieb). Obwohl die Daten nur auf einer SD Karte liegen, die Cover on the fly von den Clients (teilwiese über WLAN) abgerufen werden, sind die direkt da. Das gleiche Konstrukt hatte ich vorher auf einer relative performanten QNAP NAS laufen, das lief ähnlich langsam wie bei Dir.

Hab jetzt mal zum Test händisch bei ein paar Filme die idMovie so angepasst, dass diese näher an der alphabetischen Sortierung liegt und siehe da, viel viel besser und "gleichmässiger" Aufbau der Arts.

-> kein guter Einfall. Die ID's werden nicht grundlos einmalig, aufsteigend in die DB geschrieben - die werden in diversen anderen Tabellen genutzt. Wenn du die nun händisch in einer anpasst, wird es an anderen Stellen zu Konflikten, Zuordnungsfehlern kommen. Schneller ist das jetzt (vermutlich) nur, da er die Hälfte seiner Tabellen nicht mehr findet und die hälfte der SQL-Abfrage sofort mit "Error" auf die Nase fällt.

Es macht doch viel mehr Sinn, dass die Datenbank von Kodi, welche alphabetisch sortiert ist auch in dieser Reihenfolge aufgebaut/abgerufen wird und nicht nach der Abhängigkeit der idMovie.

-> So funktionieren Datenbanken einfach nicht. Siehe dazu auch Lehmden1 "Bei einer Datenbank wird mit Abfragen (Englisch "Query", das Q in MySQL) gearbeitet". Was du mal schauen könntest, in PHPmyadmin:

für 500 Datensätze benötigt meine DB das (damit du ein feeling für die Abfragezeiten bekommst)... Wenn hier bei Dir nun 10 Sekunden steht, passt definitive was nicht

Android ist nicht gleich Android. Die Hersteller passen das Android auf Ihre Bedürfnisse an... Gerade auf Geräten wie TV's, Media Player, sind das dann die Typischen Probleme. Die Shield, das ist immer eine gute Wahl gewesen als Android Player, viele anderen Geräte sind leider reines Glücksspiel.

Es geht um die spezifischen Testfiles von KodiUserMKV , da die Vermutung dort im Raum steht, das diese das Problem sind. Rest stimmt natürlich, er könnte das selber gegen testen mit einem anderen Player, anderen Testfiles.

Bei mir funktioniert 7.1 ohne Probleme.

Wenn ich n Link zu den Testfiles bekomme, kann ich die testen, wäre kein Problem.

Ich hab den 1500H, alles gut mit 7.1. Sicher das nicht einfach die 7.1 Testfiles Müll sind, dort die Kanäle schon vertauscht sind? Im Passthrougt Modus wird ja einfach nur das Signal aus der Medienquelle an den Receiver durchgereicht...

Ich hatte bei nem Android Player mal das Problem, das der nicht alle Formate per Passthrougt übergeben konnte (API Level Android zu niedrig). Du könntest mal folgendes testen: Passthrougt in KODi aus und Kanal auf 7.1 stehen lassen. Am Receiver sollte nur PCM Mehrkanal bzw Multi in ankommen...(KODi decodiert/codiert das Audio Signal nun neu) Passt es evtl nun? Falls nicht ist mit ziemlicher Sicherheit die Mediendatei der Übeltäter....

Zitat von Innocent

Ich finde es nicht.

Ich denke ich bin zu blöd dafür...

Ist das ein anderer Skin? Dann schalt den doch bitte mal auf den Estuary Standard um... Falls nicht, das sieht mir (vom Screenshot her) nicht wie Libreelec aus bzw. wenn, dann ist die Version wirklich sehr sehr alt, das Design passt zumindest gar nicht auf ein aktuelles.

Meine Frage: Ist das wirklich LE? Version? Ich frage deswegen, weil ja auch das Standard SSH PW + User nicht passt, Addon nicht vorhanden, Oberfläche völlig anders...

Zitat von Innocent

Ja, Zugriff auf den Pi habe ich.

Werde ich testen.

Ich finde Dienste nicht...

Kann man das nicht irgendwie auslesen?

Den Reiter Dienste findest du im Libreelec Addon (Kodi Einstellungen), unter Dienste....

je nachdem ob Sprache engl. oder ger. dann unter Dienste oder Services...

Jupp, 22 per Putty. usr: root pw: libreelec

die Anleitung basiert auf Raspi OS (Debian). Es ist schon so, das nicht jeder "normale" User einen reboot initiieren darf/soll. Kommt dann immer etwas auf die Distribution und den User (Rechte) an, mit dem man arbeitet, bei LE könnte es tatsächlich ohne klappen (nie getestet). Wenns ohne klappt gut, ansonsten halt mit SUDO

Zitat

Des weiteren halte ich generell auch ein sudo, welche stets (ausser in einer root shell) ein Passwort abfragt, keine geeignet Konstruktion in einem script oder cron job ist, der, wie im vorliegenden Fall, ja eine automatische Aktionen ausführen soll und zwar ohne User-Intervention, wie bei einer -m.M.n.- kontraproduktiven sudo-Passwortabfrage .

da wird (zumindest bei debian/Raspi OS) kein PW abgefragt. Hab diverse Scripte mit sudo über crontab -e laufen. Gibt natürlich Prozesse die ein PW verlangen...ein reboot oder shutdown gehört nicht dazu. Es geht ja nur darum, das der Prozess vom "root" User systemseitig ausgeführt wird.

@joeAverage62

Zitat

ich schätze auch (bin unsicher), dass du nach Erstellung des cron jobs den Service reloaden/restarten muss, via:

systemctl reload cron.service

...wenn der globale Cron (Wichtig: crontab -e) gespeichert wird, wird die Konfiguration geschrieben und ist dann live - kein restart erforderlich.

Innocent (Fast identisches) Thema hatten wir letztens schon einmal...:

Zitat

Man muss im Crontab (wie buers erwähnte) den User mitgeben sollte er abweichen von pi.

Geht mit:

* * * * * USERNAME /pfad/zum/script.sh

EDIT:

nachgestellt:

Crontab -e mit User pi:

down.sh:

abgelegt unter:



RPI fährt wie geplant um 19:05 herunter... (Dauert ca. 1 Minute bis der Shutdown greift).

Unbedingt dran denken, die .sh auch ausführbar zu machen (sonst passiert nix). Dazu in den Ordner der .sh's wechseln und: chmod +x down.sh Wenn du über eine GUI verfügst, danach zum testen mal n Doppeklick drauf. Sollte dann so aussehen:



Klick auf Ausführen und der RPI fährt nach ca. 1 Minute herunter (Test für das Script).

Wenn es so nicht funktioniert, sorry, dann ist das System korrupt oder verkonfiguriert.

Getestet auf einem aktuellen RaspiOS (bookworm).

Alles anzeigen

Siehe: https://www.kodinerds.net/thread/78876-autoexec-py-zum-starten-eines-scriptes/?postID=756806#post756806">autoexec.py zum Starten eines Scriptes

Innocent in deinem Fall natürlich sudo shutdown durch sudo reboot ersetzen...

Als Workaround könntest du die beiden einfach Nachts als Cron Job ausführen.

Das ganze könnte tatsächlich eine Folge von Speichermangel oder defekten Ram sein. Hatte sowas ähnliches selber einmal.

Hast du evtl. einfach zu viele VM's am laufen, den Ram zu sehr überprovisioniert?

Kannst du unbesorgt abschalten. In deinem "Heimnetz" werden die Clients mit IPv4 arbeiten, sofern du das nicht bewusst abgeschaltet hast. IPv6 ist sone Sache, läuft quasi simultan mit in der Fritz Box und den Clients (mit allen guten und schlechten Seiten). Gerade mit PI-Hole, AdGuard macht es dann gerne (bei nicht 100% Korrekter Konfiguration) Probleme. Da du zu Hause niemals den IPv4 Adressbereich ausschöpfen wirst, abschalten und gut is..PS: Einen Performance Vorteil gibt es nicht. IPv6 dient zur Adressierung der Clients und wurde eingeführt, da die IPv4 Adressen im www schlicht zuneige gehen.

...die 21 läuft auf meinen RPI5 absolut Problemlos. Auf Win und Linux habe ich ebenfalls keine Probleme. Das Problem ist an der Stelle nicht Kodi sondern der "Unterbau" den du nutzt. Stickwort: Flatpak

Flatpak ist nicht die Beste Wahl, solche Probleme sind dort vorprogrammiert. Ich würde drüber nachdenken ein "Out of the Box" problemloser laufendes System zu nutzen. Libreelec, Kodi unter Win wären hier Beispiele die ohne Probleme deine externe HDD erkennen werden.

Was die Ordnerpfade betrifft:

Am einfachsten schaust du mal in die passende .xml (Kodi speichert die Pfade in der sources.xml) und passt diese ggf. händisch an. Hierzu sei aber gesagt, dass wenn du Kodi im DB Modus nutzt, das nichts bringen wird, da die Datei Pfade in der DB selber auch hinterlegt werden somit falsch bleiben.

In Deinem Fall (wie du ja schon in Auge gefasst hast) wäre ein kompletter Reset und Neu-Installation von Kodi vermutlich am einfachsten.

Wenn du einen "Reset" machen willst löscht du einfach den kompletten Ordner Userdata! Nach dem Neustart von Kodi wird der dann neu angelegt.

Pfade zum Userdata Ordner sind Systemabhängig siehe:

Userdata - Official Kodi Wiki

Ich nutze den Skin nicht, habe die Ansicht gar nicht... Mag sein, das die Detail Infos dann nicht (mehr) geliefert werden vom Addon.

Zitat von DerRuhige

Hmm, interessant...
Bei mir zeigt seit einiger Zeit, jeder Rechner/Box: NULL Grad an.

Dann möchte ich anders fragen:
Gab es irgendwelche Änderungen (API?) in letzter Zeit, die ein erneutes Einrichten oder Änderung der APIs etc. erforderlich machen?

Liebe Grüsse
Tommy

Alles anzeigen

Wenn alle deine Boxen keine Werte liefern, ist vermutlich was anderes im argen. Ich benutze Multi Weather ohne API Schlüssel, OUT of the Box - funktioniert. Vielleicht aus versehen die URL geblockt sofern du sowas wie PIHole / Firewall im Einsatz hast? Kodi ist eine aktuelle Version? Welche Hardware, System? Genrell würde ich das Addon ansonsten mal löschen, neu installieren mit default Werten.

Bei mir ist alles OK (Multi Weather).

Es gibt noch die Möglichkeit KODi mit einer MariaDB SQL DB zu betreiben, die Clients darüber anzubinden. Neben der Video, Music DB kann man auch die TV und EPG DB dorthin auslagern. Wäre vielleicht eine Alternative die relative Out of the Box läuft, auch mit Libreelec. Die EPG Daten werden dann direkt vom KODi PVR Plugin in die gemeinsame SQL DB geschrieben und allen Clients verfügbar gemacht. Ist experimentell aber funktioniert. Siehe; https://kodi.wiki/view/Advancedsettings.xml#videolibrary unter Punkt 2.4.14. Hatte das mal ausprobiert. Meine Erfahrung beim EPG ist, das eine gemeinsame Datenquelle keine wirklichen Vorteile bringt. Ich lasse jedem Client deswegen seine eigene lokale EPG Datenbank und diese wird beim KODi start aktualisiert... Video,Music und TV DB dann in einer gemeinsamen SQL.