LibreElec 8 - Kodi 17 - 3D auf Odroid C2

    Zitat von grappi

    Allerdings habe ich durch den Patch gelernt, wie genau die Umschaltung des TV erfolgt.
    Wenn ich per Konsole ein echo "3dlr" > /sys/class/amhdmitx/amhdmitx0/config mache, dann schaltet mein TV in den 3D links/rechts Modus.

    Ich habe bei mir jetzt das Addon "Kodi Callbacks" installiert. Das kann bei bestimmten Events Aktionen ausführen. Wenn bei mir ein Film startet, wird ein Script aufgerufen, das den übergebenen Typ des Steremodus auswertet und dann den entsprechenden oben genannten Befehl absetzt.

    Sehr Cool! :thumbup:

    Ich erlaube mir das mal zusammen zufassen:

    echo "3dlr" > /sys/class/amhdmitx/amhdmitx0/config

    3dlr = SBS
    3dtb = HOU
    3doff = AUS
    +
    Addon: Kodi Callbacks

    Damit lässt sich echt etwas zur Überbrückung bauen

    The more you give a king, the more he wants.

    Zitat von Raybuntu

    Hat von euch mal einer wrxtasy's LE8 mediabuild 32 bit probiert. Er hat einen 3D patch da drin den würde ich dann bei mir auch einbauen. Hab keine 3D TV zum testen.

    Kann ich den einfach so von Deinem Image Updaten, dann probieren/testen, und dann zurück zu Deinem Image?
    Wenn ja, dann teste ich es gern für Dich....

    Zitat von Raybuntu

    [...]Ich dachte das umschalten in den 3D Modus würde nicht gehen? [...]

    Worauf genau beziehst du dich? Ich vermute du liest in meinem Text einen Widerspruch... hab mal wieder auch echt zu viel in die Tasten gehauen und wohl verwirrendes gepostet :/.

    Also damit du dir vorstellen kannst, was ich meine:

    1. Funktionierender Autoswitch eines SideBySide Videos:
    Der Fernseher hat automatisch in den 3D Modus gewechselt. 3D-TV-Autoswitch erfolgreich.

    2. Hier nochmal der erfolgreiche 3D-TV-Autoswitch: Der Fernseher zeigt als Auflösung "1080p24 3D" an:
    Das ist das was ich in meinem vorigen Post meinte: Der TV bekommt eine spezielle 3D Auflösung von
    Kodi mitgeteilt und weiß auch wirklich, dass er 3D anzeigt.

    3. Krypton ohne den 3D TV-Autoswitch - KODI GUI geht in 3D Modus, der TV zeigt aber alles in 2D an:
    Kodi weiß zwar, dass es 3D anzeigt, und schaltet die 3D GUI/OSD ein, aber teilt es dem TV nicht mit.

    4. Nochmal der nicht funktionierende Krypton 3D Modus - Mit der TV-Fernbedienung zeige ich zum Vergleich die TV-eigenen Auflösungsinfo an:
    Der TV denkt es sei einfaches 2D Bild und schaltet daher zwar in 1080p24, aber nicht "1080p24 3D". Daher sieht man auch im Hintergrund, wie das Bild einfach gesplittet auf dem Fernseher ankommt. In diesem Zustand, muss man die Fernseher Fernbedienung in die Hand nehmen, in dessen 3D-Menü gehen (also nicht Kodi 3D OSD, sondern in meinem Fall in das Philips Fernseher OSD) und manuell dort den 3D Modus auswählen, den meine Augen sehen: In diesem Fall SideBySide. Damit kann man den Fernseher umständlich halt doch noch zur 3D Anzeige zwingen. Danach halt wieder die Fernseher Fernbedienung weglegen... wieder die Kodi-Fernbedienung nehmen und film gucken. Hoffen, dass der TV nicht aus dem 3D Modus springt, sobald man mal zwishendurch in Kodi ins OSD geht usw.

    5. Der Vollständigkeit halber - Was Krypton macht, wenn man MVC startet:
    Kodi erkennt, dass es 3D ist, wechselt seine GUI(OSD in den HOU 3D Modus, aber das eigentliche Videobild bleibt 2D und wird nicht mal gesplittet... also es wird eigentlich nur ein Auge angezeigt, somit kann man in diesem Fall auch mit der TV-Fernbedienung keine 3D Anzeige erzwingen. Es wird dann das Menü drei-dimensional, aber das Bild bleibt flach.

    6. Wie der MVC-Fehler in Krypton für den Fernseher aussieht:
    Der Fernseher denkt es sei einfach ein 2D Signal und wechselt somit nur in die 24Hz refreshrate.

    Hoffe diese Ausführung ist für dich etwas verständlicher. In krypton wird von Kodi irgendwie nie eine Art trigger-signal an den TV gesendet, das ihm signalisiert nicht in "1080p24" zu wechseln, sondern in "1080p24 3D".

    _____________________

    Ich schrieb vorhin so viel über FramePacked und den Raspberry, weil der dieses Trigger-Signal in Form einer FramePacked-Refresh-rate an den TV Sendet. Wie man an den Screenshots sieht, erkennt Kodi für sich ja, dass grade eine 3D Film gestartet wurde, daher wechselt es sein eigenes OSD ja in den korrekten 3D Modus, aber es sagt dem TV trotzdem, dass der in 1080p24 wechseln soll, anstatt ihm zu senden, dass der in 1080fp24 gehen soll, was bei meinem Fernseher mit einem Raspberry auch den "1080p24 3D" auslöst. Deswegen meinte ich, dass es evtl möglich sei mit diesem komischen Linux Patch diese neuen Modi einzuführen und dann zu gucken, wie das Kodi auf dem Raspberry zwischen 1080p24 und 1080fp24 unterscheidet bei dessen Refresh-rate-switch-automatik. Aber klar, spätestens ab dem Kodi-internen Signal für den Refreshrate-switch (zu 1080fp24) ist dann alles anders zwischen Raspberry und Odroid.

    Zitat von tosa1965

    Hmmm, is ja n Ding.... Das funtioniert ja wirklich....Und dann is es soooooo schwer, dass die Kodi-Devs da Probleme mit haben, das einzubauen?

    Ich warte auf deinen Patch dann ;)
    Du siehst ja @grappi hat da was probiert mit dem Koying Patch. Das geht aber dann nicht automatisch weil da wohl ein Fehler drin steckt.
    Das Problem ist ja nicht ob es einfach oder schwer ist. Keiner hat daran Interesse vorallem weil das während der Entwicklung getestet werden muss.

    EDIT: Wie gesagt es ist vermutlich nicht schwer das einzubauen. FramePacked würde ja genau so funktionieren mit aktuellen Nougat Kernel.

    Zitat von Merlin.KIS

    Sehr Cool! :thumbup:
    Ich erlaube mir das mal zusammen zufassen:

    echo "3dlr" > /sys/class/amhdmitx/amhdmitx0/config

    3dlr = SBS
    3dtb = HOU
    3doff = AUS
    +
    Addon: Kodi Callbacks

    Damit lässt sich echt etwas zur Überbrückung bauen

    Tatsächlich, genial! Switched in die entsprechenden Modi ganz unabhängig von der refresh-rate. (Also auch in 1080p50 3D in meinem TV-eigenen OSD).

    Das ist zum Beispiel die nicht-FramePacked version des 3D Triggers. Die in wrxtasys Jarvis vollautomatisch funktionierte. Diese non-FramePacked version ist im Raspberry meines Wissens nach glaube ich gar nicht mehr implementiert, weil die vor ein paar Jahren komplett auf das FramePacked Signal gewechselt sind, weil dieses in jedem standalone BluRayPlayer standardmäßig genutzt wird.

    Das bedeutet, dass mit dieser Möglichkeit hier alles in 2 Stufen abläuft:
    1. KODI sendet beim Filmstart erstmal einen Refresh-rate switch, also "Wechsel auf 24Hz". --> TV wechselt in den 24Hz modus für den Film
    2. KODI sendet dann echo "3dlr" > /sys/class/amhdmitx/amhdmitx0/config , um dem Fernseher zu signalisieren, dass er nun auch noch den SideBySide 3D modus anwerfen soll.

    Genau diese zwei Schritte erklären nun auch endlich, warum man bei wrxtasys Jarvis in den Einstellungen immer auf den Stereo Modus "Ask me" bzw. "Nachfragen" stellen musste.
    Denn Sobald in "Einstellungen-->Videos/Player-->Wiedergabe-->Wiedergabemodus stereoskopischer Video = "Bevorzugter Modus" einstellte, haben die meisten Fernseher trotzdem nicht in den 3D Modus geschaltet. Wie sich bei meinen Tests im Februar herausstellte lag das aber daran, dass der Fernseher die zwei Kommandos "Wechsle in 24Hz" und "Wechsle in 3D mit echo "3dlr" > /sys/class/amhdmitx/amhdmitx0/config" zu schnell bekam und somit nur in den 24Hz Modus schaltete und das 3Dlr commando wohl irgnorierte, weil es ankam, während der Fernseher noch mit dem Wechsel in 24Hz beschäftigt war.

    Durch das Setzen von "Nachfragen" in den Einstellungen, konnte man diese Kommandos zeitlich trennen: Beim Filmstart wechselte der TV in Ruhe in 24Hz, und zeigte dann nach 2s (auf meinem TV) dann den 3D-Auswahldialog an. Sobald ich dort "bevorzugter Modus (Wie Film) ausgewählt habe, wurde wohl an den Fernseher das "echo "3dlr" > /sys/class/amhdmitx/amhdmitx0/config" gesendet, was dann auch erfolgreich den 3D Modus triggerte.

    Jetzt werden mir auch einige Sachen etwas klarer ... Danke vielmals @grappi !

    Zitat von Raybuntu

    Ich warte auf deinen Patch dann ;) Du siehst ja @grappi hat da was probiert mit dem Koying Patch. Das geht aber dann nicht automatisch weil da wohl ein Fehler drin steckt.
    Das Problem ist ja nicht ob es einfach oder schwer ist. Keiner hat daran Interesse vorallem weil das während der Entwicklung getestet werden muss.

    EDIT: Wie gesagt es ist vermutlich nicht schwer das einzubauen. FramePacked würde ja genau so funktionieren mit aktuellen Nougat Kernel.

    Ja das ist echt mies, wenn man nicht direkt mal eben schnell per SSH die Funktionsfähigkeit der meisten Kommandos testen kann :/.
    Was passiert eigentlich bei deinem Fernseher @Raybuntu, wenn du echo "3dlr" > /sys/class/amhdmitx/amhdmitx0/config an den Odroid SSH'st?

    @grappi
    Du meintest, dass der Patch bei dir nicht funktioniert. Hast Du evtl mal probiert während des Films in Kodi OSD auf 2D und dann wieder auf 3D zu schalten? Evtl. hast du dieselbe "Ask me/Nachfragen" vs. "Preferred Mode/Bevorzugter Modus" Problematik wie seit jeher bei Jarvis. Sprich: Es könnte sein, dass dein Patch funktioniert, bloß dein Fernseher mit dem Switch auf die 24Hz refreshrate beschäftigt ist, und den (gleichzeitig kommenden) 3dlr Befehl verpasst. Durch das manuelle switchen im Kodi OSD während des Films kann man das kurz testen, denn da ist man schon im 24Hz Modus und dann wird mit dem Patch nur noch 3dlr/3dtb/3doff gesendet.

    Zitat von infinity

    @grappi
    Du meintest, dass der Patch bei dir nicht funktioniert. Hast Du evtl mal probiert während des Films in Kodi OSD auf 2D und dann wieder auf 3D zu schalten?

    Ja, habe ich ausprobiert, aber leider keine Umschaltung.
    Ich habe es jetzt auf "Preferred Mode" Mode stehen und musste in meinem Script zum Umschalten eine Verzögerung von 2 Sekunden einbauen, damit der Fernseher das Signal nicht während des Frequenzwechsels bekommt.

    In dem Patch wird in der Datei AMLUtils.cpp eine neue Funktion eingeführt "static void aml_hdmi_3D_mode(const std::string mode3d)"-
    Innerhalb dieser Funktion wird eigentlich dass gleiche gemacht, dass ich jetzt per Script erledige. Es wird mit dieser Zeile : "aml_set_sysfs_str("/sys/class/amhdmitx/amhdmitx0/config", mode3d.c_str());" der 3D-Modus gesetzt.
    Ich habe nur das Gefühle, dass dieser Code nie ausgeführt wird. Wahrscheinlich ist schon vorher irgendwo ein Fehler.

    Zitat von Raybuntu

    @infinity Also verstehe ich das richtig das NUR Framepacked interessant ist? Ich bin erstmal am Experimentieren mit Nougat Kernel. Dann kann ich mal schauen was man mit dem Koying Patch machen kann.
    Die Funktion ist ja ganz toll aber es much ja auch benutzt werden ;)

    Hmm.... bin mir selbst nicht sicher. Ich denke, dass das was grappi gemacht hat eher am schnellsten realisierbar ist, weil da ja schon fast alles wohl erledigt ist. Zumindest liefs in jarvis ja auch mal.

    Ich bin selbst kein richtiger experte dafür, da ich mich auch nur durch die Foren forste, was mich so interessiert. Aber ich glaube seine Methode (ursprünglich von Koying) ist eine Art ältere 3D-Trigger methode, welche evtl. vor HDMI 1.4 zum Einsatz kam.

    1. Es gibt also diese "leichte" Methode von Koying, die @grappi nutzt und an sich für die meisten ans Ziel führt: 3D-TV-Autoswitch
    2. Es gäbe die neuere Frame Packing Methode aus diesem Linux Commit: https://github.com/khadas/linux/c…e783873c221c543
      DIese hätte wohl mehr Potential für die Zukunft, weil damit auch irgendwann mal sogar FullHD 3D möglich wäre.

    Ab HDMI 1.4 wurde halt Frame Packing eingeführt. Frame Packing ist meines Wissens nach quasi die Übertragungsart, wie 3D Datenströme über das HDMI Kabel an den Fernseher geschickt werden. Also es ist kein 3D Modus oder sowas, sondern ein extra für 3D (in diesem Fall für den MVC-"codec") eingeführter Übertragungsstandard... also sowas wie ein TCP-IP-Protocoll, bloß in diesem Fall nicht für Ethernet, sondern für HDMI in Verbindung mit 3D.
    Denn ab HDMI 1.4 wurde mal das MVC kodierverfahren eingeführt, welches beide 3D-Augen-Bildstreams in FullHD als Differenz ermöglicht. Also das linke Auge hat einen vollen Datenstrom mit komplettem 2D Bild (das auch für 2D Wiedergabe genutzt wird, wenn man 3D abschaltet) und das rechte Auge kriegt die Änderungen als Restdaten (diff), wodurch somit FullHD 3D nicht doppelt so groß wird, sondern nur so 30%. Beide ströme zusammen (weiterhin eigentlich normales H.264) werden irgendwie zusammen in einer Art Container (MVC) zusammengelegt, wobei ich die Abgrenzung zwischen Container und Codec hier nicht so genau nehme... es ist glaube ich weiterhin ein normaler Codec, quasi eine Erweiterung von H.264 mit denselben Verfahren, bloß beide Augen irgendwie verwurschtelt.
    Wie auch immer... also dieser MVC Daten-Strom muss ja irgendwie an den Fernseher. Dafür hat man dann den Frame Packing Standard ab HDMI 1.4 eingeführt.
    Der Grund war wohl: Der BluRay Player kriegt den um den Faktor 1,3 größeren MVC 3D Strom (~30% größer als 2D) in seinen Dekoder. Der Dekoder dekodiert diesen "Diff" beider Augen in 2 volle 1080p Videostreams, jedes Auge einen, und nun ist das ja eine doppelt so große Datenmenge (statt vorher 30%), die durchs HDMI Kabel an den Fernseher muss. Also hat man wohl dieses Frame Packing Übertragungsverfahren dafür entwickelt. Der Standard sieht zudem vor, dass man wohl Frame Packing immer nur im Zusammenhang mit 3D hat, wodurch ein Fernseher beim Empfang von "Frame Packed" Material immer den 3D Modus anschmeißt. Ich denke daher, dass Frame Packing an sich die bessere Investition ist, auf längere Sicht gesehen.


    Leider ist vieles von dem was ich schrieb eher auf Vermutungen und Schlüssen basierend... müsste mich da selber mal mehr mit der Thematik befassen. So einiges könnte nicht korrekt sein. Man müsste mal rauskriegen, was die Kodi Entwickler genau als Pro Contra zu Frame Packing zu sagen haben. Dann weiß man genau, ob sich der Frame Packing weg lohnt, oder der Weg von @grappi im Endeffekt genau dasselbe macht.

    Ich meine nämlich, dass @grappi / @koyings Lösung unvereinbar mit FullHD MVC ist, daher sagen @wrxtasy usw. beim Odroid und AMLogic generell ja auch immer, dass MVC bei Odroid "eh nur half-rez" sei, und daher den Aufwand nicht Wert ist. Aber es ist eh die Frage, ob MVC jemals jemand für die AMlogics nochmal implementieren wird. Für die ganzen Half Side-By-Side und Half-Top-and-Bottom Filme ist @grappis Lösung völlig ausreichend, sobald sie denn Funktioniert. Sie schickt den TV ja in den 3D Modus.

    Andererseits ist ja wiederum Interessant, dass in Jarvis MVC durch einen Koying Patch tatsächlich dekodierbar war. Nur die Ausgabe an den TV war auf halbe Auflösung beschränkt (daher im Endeffekt nicht besser als H-SBS/H-TAB), weil eben kein Frame Packing beherrscht wird und somit nicht genug Bandbreite für FullHD 3D da ist. Wenn man jetzt theoretisch diesen Frame Packing Patch da zum laufen bekäme, dann hätte man schonmal die erste Voraussetzung für FullHD-3D auf dem Odroid geschaffen.
    Wenn dann noch Koyings MVC Patch/decoder irgendwie in Krypton lauffähig wäre, DANN hätte der Odroid den Raspberry Pi in allen Belangen in den Sack gesteckt. Aber so oder so... Framepacked müsste den TV auch bei H-SBS und H-TAB in den 3D Modus schicken, auch ohne MVC... denn der Raspberry macht es auch einfach dank Frame Packing Fähigkeit, selbst bei H-SBS Material. Die Leute von Kodi (glaube Milhouse und Popcornmix) sind diejenigen, die das damals in die Raspberry Builds reingebaut haben.


    Man... sorry für die langen Texte...!


    EDIT:
    Neben dem MVC Full-HD 3D Potential, das Frame Packing in mkv containern ermöglichen könnte, wäre der nächste Vorteil, dass dann auch die ganzen User mit ihren BluRay ISOs auf ihren NAS dann auch direkt Full HD 3D aus den ganzen BluRay Isos abspielen könnte, wie halt ein richtiger BluRay Player.

    Junge Junge schreibst du viel. Muss ich mal als Einschlafhilfe nehmen.

    Also wenn ich mir Koyings Patch ansehe und das Nougat ding was bei mir läuft dann spricht nichts dagegen das alles automatisch umgeschaltet werden kann.
    Ich versuche erstmal den Nougat Kernel zum laufen zu bringen. Kszaq hat den Kernel schon am laufen jedoch nur eine halbe Lösung (Frankenstein Kernel).

    Wenn ich was hab könnt ihr ja erstmal testen ob ihr manuell umschalten könnt alle Modi.
    Was dann nur noch fehlt ist ist die automatische Umschaltung in Kodi.

    Zitat von Raybuntu

    Junge Junge schreibst du viel. Muss ich mal als Einschlafhilfe nehmen.

    Vergiss nicht ein Kissen vor die Tastatur zu legen... will nicht für eine Beule an deiner Stirn verantwortlich sein :thumbup:

    Zitat von Raybuntu


    Also wenn ich mir Koyings Patch ansehe und das Nougat ding was bei mir läuft dann spricht nichts dagegen das alles automatisch umgeschaltet werden kann.
    Ich versuche erstmal den Nougat Kernel zum laufen zu bringen. Kszaq hat den Kernel schon am laufen jedoch nur eine halbe Lösung (Frankenstein Kernel).

    Wenn ich was hab könnt ihr ja erstmal testen ob ihr manuell umschalten könnt alle Modi.
    Was dann nur noch fehlt ist ist die automatische Umschaltung in Kodi.

    Warum eigentlich immer der Nougat Kernel? Weil auf den sowieso bald gewechselt wird, oder weil nur der irgendwelche speziellen Funktionen beherrscht? Hoffe deine Builds damit werden wieder 32Bit Dinger sein :)

    weil das da drin ist. Der Kernel ist ja der selbe den wir schon nutzen nur mit Updates von Amlogic. Der Commit den du zu framepacked verlinkt hast ist im aktuellen Amlogic Kernel. Ich selbst hab keine Lust einen Frankenstein Kernel zu pflegen. Wenn dann alles richtig übernehmen. Irgendwann im laufe des Jahres haben wir sowieso mainline 4.13 oder so am laufen. Dann geht wahrscheinlich wieder die Hälfte nicht mehr.

    Zitat von infinity

    Würde es dir was ausmachen mal den genauen Weg und das Skript zu posten, das du für den Kodi Callbacks Workaround nutzt? Wäre ja eine durchaus schicke Übergangslösung, sofern es klappt.

    Das mache ich gerne.

    1. Script (ohne .txt) auf den C2 kopieren. Bei mir liegt es im Verzeichnis /storage/.kodi/addons/virtual.network-tools/bin
    Bei anderen Verzeichnissen hatte ich das Problem, dass das Script nicht gefunden wurde. Wenn nicht vorhanden, dann einfach erstellen.

    2. Addon installieren ( Kodi Callback / Kodi Repo)

    3. Addon konfigurieren
    Unter Tasks (ich nehme jetzt mal Task1 und nenne nur die Einstellungen die ich verändert habe):
    Task: script
    Max num of this task running sim....: 1
    Script executable file: /storage/.kodi/addons/virtual.network-tools/bin/Startplay
    Requires shell?: Yes
    Wait for script to complete: No

    Unter Events:
    Choose event type: onPlayback started
    Task: Task1
    Var subbed arg string: sm=%sm

    Das wars. Mit OK das ganze speichern und schon sollte es funktionieren.

    Viel Spaß beim ausprobieren.

    Zitat von Raybuntu

    weil das da drin ist. Der Kernel ist ja der selbe den wir schon nutzen nur mit Updates von Amlogic. Der Commit den du zu framepacked verlinkt hast ist im aktuellen Amlogic Kernel. Ich selbst hab keine Lust einen Frankenstein Kernel zu pflegen. Wenn dann alles richtig übernehmen.

    Ach interessant. dann haue ich mal testweise wrxtasys nougat testversion rauf und schaue mal ob sich da irgendwas anders verhält.

    Gibt es beim Odroid etwas vergleichbares wie beim Raspberry dieses "tvservice -s"? Das Zeigt beim Raspberry den gerade genutzten Video-Modus an:

    Code
    OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive

    das "3D FP" steht für Frame Packing beim Raspberry Pi. In diesem Fall hatte ich eine 3D H-SBS Datei abgespielt. Also einfach sidebyside in halber Auflösung.
    Wenn ich beim Odroid ein ähnliches Kommando hätte, oder etwas, das alle HDMI Modi auflistet (EDID?), die der TV Unterstützt, dann könnte man ja schonmal den aktuellen Kernel mit dem Nougat Kernel vergleichen.

    Zitat von Raybuntu

    Irgendwann im laufe des Jahres haben wir sowieso mainline 4.13 oder so am laufen. Dann geht wahrscheinlich wieder die Hälfte nicht mehr.

    Ach, ich glaube man kann sich sicher sein, dass dann praktisch nichts anständig laufen wird. Wenn ich mir beim jetzigen Kernel die Probleme mit Lirc, GPIO-IR, fehlendes i2c-1 Interface anschaue, dann kann man beim Mainline erst recht von massiven Schwierigkeiten und Supportanfragen ausgehen. Ich glaube aber eh nicht so wirklich, dass es so "bald" sein wird mit dem Kernel.


    @grappi
    Danke vielmals! Werde das mal demächst ausprobieren! Ein wenig zögerlich erstmal, da ich diese "echo "3dlr" > /sys/class/amhdmitx/amhdmitx0/config" mal auf @Raybuntus Krypton8 während einer LiveTV Sendung (war zwar 2D, aber nur um die Reaktion meines TVs darauf zu beobachten) ausprobiert habe und sah, dass der tatsächlich in SideBySide ging. Leider ist die GUI nach 30s dann auf einmal unerträglich langsam geworden und das ganze system hat sich aufgehägt. Ausschalten ging nicht, ssh "reboot" auch nicht, "systemctl restart kodi" auch nicht, und shutdown now -h ebensowenig. Musste den Stecker ziehen, was meine SD-Karte mir auf Dauer bestimmt nicht danken wird. Da ist wohl irgendwie entweder der Speicher, oder die CPU durch die Decke gegangen.

    Zitat von Raybuntu

    Ich tippe mal auf Kernel Panic was mich bei Amlogic nicht wundern würde.

    Haha...

    Also mit wrxtasys Nougat version verhält es sich genauso wie mit deiner normalen.

    Frame Packing scheint überall deaktiviert zu sein. Auch bei deiner Krypton8 ist FramePacking überall = 0. DeepColor in der 43. Zeile ist jedoch neu dabei.

    Im Vergleich zu deiner Krypton8 fehlen hier 480i60hz und 576i50hz

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden