Beiträge von icebaer

    Ja, weil du damit anscheinend einen GET-Aufruf machst. Der funktioniert für einen "Input.Right" Befehl nicht mehr.


    Mit was rufst du die URL auf?
    Im einem Browser kannst du das schwer testen, weil der beim manuellen Aufruf einer URL eigentlich immer einen GET ausführt.

    Oder rufst du das über die RTI-Steuerung auf. Die kenne ich leider nicht. Sie müsste dir aber die Auswahl zwischen GET und POST an der Stelle bieten, sonst wird es leider nichts.


    Bei einem POST Aufruf sind die Daten dann nicht Teil der URL, sondern müssen separat mitgegeben werden.

    Die URL wäre dann einfach http://192.168.178.2:8080/jsonrpc

    Der Teil dahinter kommt ins Body-Feld, was dir RTI oder sonstiges anbieten müsste.

    Wo liegt der Fehler?

    So wie es aussieht, muss der Befehl als POST versendet werden.

    Auf der Seite gibt es eine Tabelle im Abschnitt "API versions". Da ist bei HTTP GET ab Version 10 bzw Kodi 18 eine Bemerkung. Die besagt, dass Actions einen POST brauchen. Anscheinend ist "Input.Right" eine Action.


    Wenn man einen POST auf http://<kodi-ip>:<port>/jsonrpc macht und diesen Body nimmt, geht es:
    {"jsonrpc":"2.0","id":1,"method":"Input.Right"}


    Dann muss man sich auch nicht mit irgendwelchen Escape-Zeichen rummachen :zwinker2:

    Ja, ist leider so.

    War auch ein "Feature" über das ich mich gefreut hatte, als mein ehemaliger X35 in Rente ging und sein Nachfolger (X7000) kam. Der fährt auch ohne diese Einblendung an eine andere Position - wenn das per Netzwerk passiert.

    Mit nur einer Messung ist man leider auch maximal Fehlerintolerant, was lokale Störungen betrifft. Bspw Reflektionen der Kopfstütze oder Armlehnen.

    Das wird durch mehrere Messungen und einem Durchschnitt darüber wieder ausgeglichen.

    Deswegen würde ich schon mehr als eine machen.


    Die anderen müssen ja nicht allzuweit von der ersten entfernt sein.

    Je weiter, desto mehr Kompromisse gibt es dann wieder. Das stimmt.

    Gefällt mir auch sehr gut. Vor allem die Front!!


    Ist mal was anderes, mit der Beleuchtung und der Struktur neben der LW.

    Das Ambilight scheint ja auch im Filmbetrieb nicht weiter zu stören.


    :respect:

    Ja, ist bei mir sogar der Standardfall.


    Wenn eine neue Filmdatei dazu kommt, hat die noch keine Metadaten und keine NFO. Also wird die Datenquelle aktualisiert, um die neue Datei zu finden und damit auch alle Hintergrundprozesse inkl ARD auf neu gefundene Einträge angewendet.

    Ist das durchgelaufen, wurde zwar ein Seitenverhältnis erkannt, aber noch nicht in eine NFO geschrieben, sondern nur in die TMM DB.

    Erst bei einer weiteren Aktion wie bspw. Scrapen, wird eine NFO mit allen Daten erzeugt.


    So läuft es zumindest bei mir ab.

    Bei dir wird vorher schon eine NFO erzeugt. Macht das evtl Kodi, Emby oder sonst ein Dienst, der mit NFOs arbeitet?

    Meine Änderung wurde leider so nicht direkt angenommen, d.h. das eine NFO immer nach einer Aktualisierung einer Datenquelle geschrieben wird.

    Der "Kopf" hinter TMM hat recht strikte Vorgaben, was das Handling von Daten betrifft.


    Der Kompromiss besteht jetzt darin, die Daten immer dann in eine NFO zu schreiben, wenn schon eine existiert. Ist keine vorhanden, wird auch keine angelegt. Das kann man dann entweder explizit auslösen oder bspw durch ein Scrapen eines Films.

    Hoffe das hilft bei dem aktuellen Problem.

    Wenn bei dir eine NFO geschrieben wird, sobald der Scan ausgeführt wird, passiert das anscheinend bevor das Seitenverhältnis erkannt wurde.


    Richtig wäre auf alle Fälle, wenn am Ende des Scans eine NFO geschrieben wird. Dann sollte dort der richtige Wert drin stehen.

    Hab dafür gerade mal einen MergeRequest aufgemacht. Wenn die Änderung in die offizielle Version übernommen wurde, ist das Problem dann hoffentlich erledigt :)

    Dann haben doch sowohl aktive Absorption als auch ein DBA die Gemeinsamkeit, am besten an bestimmten Positionen zu arbeiten. Je weiter man davon abweicht, desto geringer wird die Effizienz.

    Das DBA gibt dabei i.d.R. halt mehr Positionen vor, als eine aktive Absorption mit max. 4 Ecken (in einem rechteckigen Raum).


    Eine aktive Absorption wirkt vermutlich auch nur auf einem Platz bestmöglich.
    Das DBA ist dagegen theoretisch im gesamten Raum modenfrei.

    Also bei mir funktioniert das nach wie vor alles perfekt bei Filmen. 3500 wurden quasi fehlerfrei korrekt erkannt. Nur bei Serien hakts ab und an mal.

    Danke Moe :sbier:

    Bei mir läuft die Erkennung auch ohne Probleme.

    Dennoch scheint es Fälle zu geben, in denen was schief läuft. Da müssen wir schauen, was anders ist.


    Ansonsten:
    Quelle neu einlesen
    Scrape starten
    Seitenverhältniss erkennen lassen (eigentlich "Automatische Bildverhältnisserkennung" aktiviert)
    Bereinigen umbenennen.

    Genau so mache ich es auch.
    Sobald die Quellen neu eingelesen werden, wird automatisch das Seitenverhältnis erkannt. Danach wird der Film gescraped und automatisch umbenannt.
    Der Unterschied könnte aber in der zeitlichen Abfolge liegen.

    Bei mir lasse ich den Hintergrunddienst erst fertig laufen. Wann das der Fall ist, sieht man unten rechts am Fortschrittsbalken. Erst dann scrape ich die einzelnen Filme.

    Wenn man schon scraped/editiert, bevor die Hintergrundanalyse fertig ist, kann es passieren, dass nicht das erkannte Seitenverhältnis in die NFO geschrieben wird, weil es zu dem Zeitpunkt noch nicht vorlag.

    Das würde auch erklären, warum nach einem explizitem schreiben, die NFO dann den richtigen Wert enthält.

    roninf Falls das bei dir der Fall sein sollte, probiere doch mal zu warten, bis der Hintergrunddienst fertig ist. Danach sollten die erkannten Werte immer richtig in die NFO geschrieben werden.


    Es gibt eine grosse Anzahl filme, wo die erste Grössenbestimmung zum Wert 0 geführt hat.


    Wenn ich die neu berechnen lasse, führt das immer zum wert 1,78

    Das scheint ein anderes Problem zu sein, da das Seitenverhältnis anscheinend gar nicht richtig erkannt wird. Wenn es sogar eine große Anzahl an Filmen betrifft, scheint an einer Stelle prinzipiell was noch nicht zu stimmen.

    Kannst du mir sagen, welches Betriebssystem und welche FFMPEG-Version du nutzt?

    Frage: Kann man die Information nicht über einen Scraper direkt ziehen? Bluray- disc.de zb hat die infos ja alle

    Dafür sind die Infos leider nicht zuverlässig genug. Zum einen stimmen sie teilweise mit den anhand des Films ermittelten Werten nicht überein. Zum anderen gibt es bei der Suche nach dem Titel viele Treffer mit teilweise verschiedenen Editionen/Steelbooks/... Da ist es recht schwer, einen passenden Scraper zu erstellen.


    Bei mir hab ich festgestellt, dass oft die NFO initial falsch geschrieben wird, also Film hat 2.4 in der NFO steht 1.78....

    Erst ein erneutes Schreiben der NFO korrigiert das dann.

    Kannst du mal genau beschreiben, wie dein Ablauf ist, um die Filminfos zu erzeugen?
    Gerne auf per PN.

    Und wie geht man dann vor? nfo manuell löschen, filmformat neu erkennen lassen?

    Die NFO wird bei sehr vielen Aktionen neu geschrieben.

    Das kann entweder explizit über einen Rechtsklick auf einen Film und "Erweitwerte Bearbeitung" / "NFO für ausgewähjlte Film neu schreiben" ausgelöst werden.

    Es wird aber auch bspw. nach dem bearbeiten, scrapen oder dem neu erkennen lassen des Seitenverhältnisses ausgelöst.
    Die einzige Aktion, die ich in dem Zusammenhang gesehen habe, die kein direktes schreiben einer NFO auslöst, ist das automatische Erkennen des Seitenverhältnisses, sobald man eine Datenquelle neu einliesst.

    Gestern kamen dann Steckdosen von Nous (Tasmota-WiFi-MQTT) (4Stück um 50€). Auf den ersten Blick: geniale Teile. Sehr wertig. Schalten angeblich 16A. Einfachste Einbindung in HA per MQTT. Keine Cloud. Einfache Konfiguration über das WebInterface der Steckdose. Umfangreiche Doku auf GitHub zu Tasmota. Mal sehen wie sie sich im Betrieb verhalten.

    Die laufen bei mir auch und bin auch sehr zufrieden damit :)

    Ja, läuft bei mir. Sogar passend zum Thread hier in Unraid.

    Sinn macht es dann, wenn man mit mehreren Clients auf seine Sammlung zugreifen will. Darüber lässt sich dann alles synchron halten.


    Als Player gibt es bspw den Desktop Client.

    Ist nur die Frage, wo/wie willst du den nutzen?
    Auf dem Handy kann man direkt über den WebClient abspielen. Da weiss ich zwar nicht, ob der Atmos kann. Sollte dafür aber eigentlich nebensächlich sein.

    Auf einem PC kann man einfach den Weg über Kodi gehen. Da geht dann auch Atmos.

    Kann man Emby oder Jellyfin als Datenbank nutzen oder ist das dann lediglich so, dass dies die grundlegenden "server" sind und Kodi am HTPC bloß dessen Oberfläche zur Verfügung stellt?

    In Emby/Jellyfin werden alle Filmmetadaten (Titel, Laufzeit, Cover, ....) gepflegt. Kodi verbindet sich dann mit Emby/Jellyfin und holt sich von dort die Daten. Kodi kann andersrum auch Daten an Emby/Jellyfin schicken, um bspw Filme als gesehen zu markieren.

    Es ist also quasi eine Datenbank plus Pflegeoberläche.

    Danke, probier ich aus. :)


    Muss dann wohl nur 2 Kodi Versions Datenbanken anlegen, da im HK 17.6 läuft mit dem DS Player und am TV die aktuelle Version.

    Wieso nutzt du dann nicht Emby oder Jellyfin?

    Die können die erzeugten NFO Dateien direkt lesen. Es gibt Kodi Addons um sich damit zu synchronisieren. Und wenn veschiedene Kodi Versionen darauf zugreifen, ist es auch kein Problem.

    So könntest du auch bspw im Kino einen Film anfangen und dann am TV fortsetzen.

    aber auch hier habe ich es doppelt gemacht

    Ja, du hast die Subs in der Simulation durch die Gegend geschoben.

    Es gibt aber noch die Freiheitsgrade Delay, Gain und Invertierung - was Alpi gemacht hat.


    Zudem scheinst du auf dem Boden zu liegen, beim Filme schauen :zwinker2: Das wird in Realität vermutlich etwas höher sein.