Beiträge von infinity

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:

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

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

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

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.

Schade.

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.

Zitat von DaVu

[...]Wie @don schon sagte...wenn sich die Laufwerkserkennung (sdb, sdc etc....) ändert, stimmt der Pfad zum Film nicht mehr und die Bibliothek meckert, dass der Film unter dem hinterlegtem Pfad nicht mehr erreichbar ist.

Bin mir nicht ganz sicher, aber ich meine das stimmt so nicht ganz.

Soweit ich mich erinnere mountet OpenELEC/LibreELEC angeschlossene Datenträger mit einer Udelvil Regel. Und ich meine mich zu erinnern, dass diese Regel nach dem "LABEL" mountet und nicht nach dem genauen Pfad. Es sucht zwar diese sdb, sdc pfade ab, aber am Ende verknüpft es die "LABEL"s mit dem Library-Pfad. "LABEL" ist in diesem Fall der Datenträgername. Also meine externe HDD heißt unter Windows und auch unter LibreELEC "Volume" und mein USB-Stick heißt "USB-Flash". Es ist dennoch egal an welchen USB-Port und in welcher Reihenfolge ich all meine USB-Speicher an den Raspberry oder Odroid anschließe. LibreELEC ordnet die korrekt zu.

Aber das Problem des Threaderstellers habe ich leider auch hin und wieder mal gehabt. Es hat bislang immer geholfen diejenige Festplatte abzuziehen, und an einem Windows 8 oder 10 Rechner anzustöpseln. Zur Sicherheit auch die schnelle Überprüfung laufen lassen. Aber eigentlich reicht bereits das einmalige anschließen und öffnen der HDD am Windows PC, dass deren Header oder so wieder korrigiert wird. Danach müsste es auch unter Kodi wieder korrekt mit der Library laufen. Zumindest bei mir schon sehr viele Male so gewesen.

Am besten wäre es natürlich, wenn LibreELEC nach UUID mounten würde. Aber wer weiß, ob das bei diesem speziellen Stromausfall-Problem helfen würde. Denn der Datenträgername (LABEL) hat sich ja durch den Ausfall auch nicht geändert gehabt.

So... Nicht wundern, wenn demnächst das Netflix Addon mal nicht geht:
Golem: Netflix schließt bestimmte Linux-Distributionen aus

Ich bin irgendwie blind und finde gar keinen Thread zum Netflix inputstream Addon... daher poste ich das mal hier. Evtl sollte man eine User-Agent-Funktion mit einbauen.

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 Merlin.KIS

Sehr Cool!
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 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.

hahaha ... Irgendwie total lustig... auf den gleichen scheiß hätte auch ich reinfallen können ... Nun wieder was gelernt, und froh, dass auch sowas hier schön elaboriert wird

Nope, da tut sich zumindest bei meinem ollen 2012er Philips TV nichts.

• Hab erst die einzige img.gz vom 03.02. installiert (LibreELEC-Odroid_C2.arm-8.0.WRX-RB-Media_build.01.img.gz)
• Dann update vom 06.02. LibreELEC-Odroid_C2.arm-8.0.WRX-RB-Media_build.T220.tar installiert und erfolglos getestet
• Dann update vom 10.02. LibreELEC-Odroid_C2.arm-8.0.MB.02.FRA.Fix.tar installiert und erfolglos getestet.

Der Patch zielt ja auf den 3D Autoswitch ab. Leider geschieht da nichts, aber war auch nicht anders zu erwarten, sonst wäre es in den vergangenen 2 Monaten jemandem aufgefallen

Mal ein kleiner Diskussionsanstoß, weil mich die Zusammenhänge interessieren:
So rein hypothetisch... aus Sicht eines Programmier-Laien wie mir: Dieser FramePacked Patch von neulich... der fügt ja - wenn ich das richtig verstehe dem Kernel bzw. System neue Auflösungen/Refresh-rate-Modes hinzu, welche eben auf FramePacked basieren, oder?

Also LibreELEC unterstützt ja den automatischen Refresh-rate-switch: Sobald ein 24Hz/23.976Hz Film gestartet wird, wird ja von der GUI refresh-rate 1080p60Hz in die native Film-refresh-rate 1080p24Hz gewechselt.

Dank dieser neuartigen FramePacked "Wiederholfrequenz-Modi" wäre doch im Grunde (wie gesagt aus meiner laienhaften Vorstellung heraus) der Hebel in Krypton doch eigentlich an der automatischen Refresh-rate Funktion anzusetzen? Denn Kodi erkennt ja durchaus, dass ein 3D Film gestartet wird. Es schaltet die GUI ja tatsächlich in den Oben/Unten oder SideBySide Modus um, sowie auch den Film selbst. Das Bild ist dann halt 2D gesplittet mit einem feed oben fürs linke auge und einem unten fürs rechte Auge (oder analog dazu side by side). Währenddessen schaltet Kodi auch automatisch in den 1080p24Hz Modus (jedoch halt 2D). Wenn man Kodi nun also im Refresh-rate-Code beibringen würde, dass es neue Modi gibt - in Form von diesen neuen FramePacked Modes wie "1080fp24hz" - und diesen Modus dann statt dem normalen 1080p24hz an den Fernseher meldet, dann müsste der TV ja dank des "FramePacked" flags automatisch in den 3D Modus wechseln. Dem bliebe gar nichts anderes übrig. Bloß, ob der dann auch den richtigen 3D Modus wählt, wäre auch eine frage.

In Krypton müsste diese Verbindung zwischen dem automatischen GUI-Wechsel-in-3D-Modus und dem Frame-rate-switch-in-FramePacked ja bereits existieren, da der Raspberry Pi ja genau das macht. Also entweder es ist in dem Code aller Plattformen bereits drin (dank des Pis), oder es wäre möglich den Code dann direkt vom Raspberry LE Code zu übernehmen. Damit meine ich den funktionalen Zusammenhang zwischen:
1. Dem bereits funktionierenden "Kodi-erkennt-den-3D-Flag-im-Namen-des-Filmdateinamens-und-wechselt-die-GUI-und-den-Film-in-einen-entsprechenden-Splitscreen"
und
2. Kodi signalisiert bei diesem Wechsel in den Splitscreen auch einen Refreshrate-Switch in den entsprechenden FramePacked 1080fp24hz Modus.

Was denkst du über sowas Raybuntu? Vielleicht ist ja schon ein riesen Schritt getan, wenn man diesen einen Commit in den Kernel knallt, und dann schaut, was im Raspberry Pi code für FramePacket Modi drin stecken, und wodurch die von Kodi aus getriggert werden?
Vor allem die richtigen FramePacked-Bezeichnungen müssen dann natürlich an diese neuen Amlogic FP-Bezeichnungen angepasst werden (falls die nicht ohnehin standardisiert sind).

Das ist jetzt nur so meine distanzierte und laienhafte Überlegung... quasi Abstrahiert.

Danke!
ich probiere dann mal kurz die "LibreELEC-Odroid_C2.arm-8.0.MB.02.FRA.Fix.tar 10-Feb-2017 21:14 146851840" aus. Der Patch ist auf den 04. Febr. datiert, also müsste es ja in der Build vom 06.02. oder 10.02. drin sein.

Berichte gleich mal

Zitat von Flapman

Du bist damit nicht allein. Ich habe das selbe Problem, nachdem ich eben das [Stable] OpenELEC 8.0.0 (x86_64) Update file genau nach der offiziellen Anleitung installiert habe.

Bin als RasberryPi-Neuling leider auch absolut ratlos.

Externer Inhalt picload.org

Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

Klicken Sie hier, um das externe Bild anzuzeigen

Du kannst das von dir verlinkte Update nicht auf einen Raspberry Pi aufspielen. Das was du da hast ist ein Update für eine x86 CPU, also Intel oder AMD Prozessoren mit 64 bit. Du musst nun deine SD-Karte komplett platt machen und LibreELEC so installieren, wie es hier beschrieben ist:
https://libreelec.tv/downloads/ (oben mit "Download for Windows" das LibreELEC Downloader Tool herunterladen, dort wie bebildert die Raspberry PI2 version auswählen, sie herunterladen lassen, auf die SD-Karte schreiben lassen)

p.s.: Auch wenn OpenELEC heute eine version 8.0 aus dem Hut gezaubert hat... ich würde es auf keinen Fall insallieren.
1. Hab ich vorhin schon beiläufig einen Haufen Beschwerden gelesen, weil die Version wohl überhaupt nicht getestet wurde
2. Ist OpenELEC nicht mehr wirklich das was es mal war, sondern alle wichtigen Entwickler (bis auf ein paar wenige Ausnahmen) haben LibreELEC gegründet und entwickeln OpenELEC unter neuem Namen weiter. Das was nun als OpenELEC released wird, ist höchstwahrscheinlich eine mit heißer Nadel gestrickte LibreELEC Kopie, die ungetestet ist und auch mit größter Sicherheit höchstens mangelhaft gepflegt wird. Support kannst du jedenfalls nicht viel erwarten. Aber warten wir mal ab. Vielleicht wird es noch eine Überraschung geben und OpenELEC fängt sich auf wundersame Weise wieder. Bloß jetzt kann es (noch) nicht ratsam sein auf eine aktuelle OpenELEC version zu setzten.

Eigentlich sollte ein kleines buntes quadrat bei OpenELEC eine zu niedrige Versorgungsspannung anzeigen. So ein großes habe ich noch nie gesehen... komisch.... aber ich gehe jetzt einfach mal davon aus, dass es trotzdem eine zu niedrige Spannung andeutet in eurem Fall.

Gründe dafür wären:
1. Pi Übertaktet (könnte auch eine komische default Übertaktung in der von eingesetzten build sein. Dafür mal die SD-Karte in den PC tun, und die config.txt datei auslesen... da ist was mit Übertaktung beim Pi
2. Ihr nutzt ein schlechtes Netzteil (Pi2 ist da meines Wissens nach recht empfindlich, was beim Pi3 dann entschärft wurde).
3. Schlechtes MicroUSB-Kabel am Netzteil, bzw. eine Verlängerung oder eigenes separat gekauftes Kabel dran: Das ist meist zu dünn und hat zu hohe Verluste. Vor allem, wenn es länger als 1,5m ist.

Einfach noch mal ein paar weitere Netzteile mit deren original Kabel durchprobieren.

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.

Cool zu hören!
Weißt du welche build das ist? Er hat ja mehrere auf dem Mirror: http://wrxtasy.libreelec.tv/Krypton-32bit/
Allerdings alle vom Februar und er hat meines Wissens nach nie was auf 3D bezogenes, im Zusammenhang mit seinen Krypton builds, erwähnt.

Und was genau war das Ziel des Patches? (Damit man beim Testen nicht wahllos alles auf den Fernseher wirft, was 3D im Titel hat)

SPMC müsste bei weitem das bessere Kodi auf Android sein. Ich würde bei SPMC bleiben und zwischendurch immer mal die Kodi version checken. Bin mir nichtmal sicher, ob kodi mittlerweile wieder einen echten android maintainer hat, seit man koying rausgeekelt hat, wobei die meisten Kodi Android updates wahrscheinlich trotzdem noch durch koying kommen und von SPMC zu Kodi übertragen werden.

Zitat von hpoperator

Danke, hatte scheinbar wirklich riesige Tomaten auf den Augen
Aber nun, als ich dies und den aktivierungscode eingestellt habe.... und erneut auf "manuell downloaden" ging.
Kam eine Fehlermeldung die auf das >Log.File verwies.

Anbei das Logfile auf Pastepin:

http://sprunge.us/CaGO

12:01:19.902 T:1693963168 NOTICE: [Rytec EPG Downloader]: get epg
12:01:19.902 T:1693963168 NOTICE: [Rytec EPG Downloader]: get source
12:01:21.828 T:1693963168 NOTICE: [Rytec EPG Downloader]: get epg url
12:01:21.856 T:1693963168 NOTICE: [Rytec EPG Downloader]: download epg
12:01:21.957 T:1693963168 NOTICE: [Rytec EPG Downloader]: epg download started
12:01:27.156 T:1693963168 NOTICE: [Rytec EPG Downloader]: epg download complete
12:01:27.157 T:1693963168 NOTICE: [Rytec EPG Downloader]: save epg url to config
12:01:28.488 T:1693963168 NOTICE: [Rytec EPG Downloader]: rytec downloader started
12:01:28.488 T:1693963168 NOTICE: [Rytec EPG Downloader]: Rytec Germany/Austria/Swiss XMLTV
12:01:28.489 T:1693963168 NOTICE: [Rytec EPG Downloader]: no epg update needed
12:04:06.093 T:1439691680 NOTICE: AddOnLog: PVR IPTV Simple Client: EPG file path is not configured. EPG not loaded.
12:11:34.859 T:1962144880 NOTICE: Previous line repeats 1 times.

Wenn ich mir diese Passage anschaue, dann scheint der Downloader bereits die EPG Datei gezogen zu haben. Diese müsstest du auch in dem Verzeichnis sehen, das du im Rytec downloader als Ziel angegeben hast. Notfalls kannst du die Datei "rytecxmltvGermany.gz" löschen und danach noch mal den Download anstoßen.

Dann sieht man an dem Log auch, dass du im IPTV-Simple client die EPG-Einstellungen nicht durchgeführt hast. Du musst da nämlich auf lokale EPG-Datei einstellen und auf eben diese "rytecxmltvGermany.gz" verweisen. System neustarten und wundern, dass es geht

Die langen Umschaltzeiten liegen wohl eher an Kodi Krypton, da es mit HLS streams so seine Probleme zu haben scheint:
LibreELEC Krypton/Leia/Agile Odroid C2, Wetek.Hub, Wetek Play 2 64bit kernel mit 32bit userspace
Du könntest testweise Kodi Jarvis installieren und wohl sehen, dass es da wesentlich schneller geht.

Ferner werden deine Streams wohl auch von sich aus evtl. nicht die schnellsten sein und durch einen VPN oder SmartDNS evtl. zusätzlich beim Tunen ausgebremst.
Dein Rechner müsste performancetechnisch eigentlich gar keine Probleme haben. Ich vermute ganz stark, dass es einfach an Krypton und den Streams liegt.

Zitat von hpoperator

Ich kann nirgendwo in den Einstellungen des Rytec EPG Downloader die "zu ziehenden Länder" Einstellen....!?
Konnte nur den Pfad einspeichern, dort wo der Download hin kopiert werden soll und den "Aktivierungscode" einstellen. Wenn ich auf den "Manuellen Download" klicke passiert NICHTS!
nach ca einer sekunde kommt die Meldung das der download erfolgreich gewesen ist, doch es wurde definitiv NICHTS gedownloaded.

Kann mir jemand weiterhelfen?

LG Andy

Entweder du hast nen seltsamen Skin druff, oder Tomaten auf den Augen

Wo wir neulich ja über das leidige Thema 3D und so beim Odroid C2 und Kodi gesprochen hatten, hat im forum.kodi.tv Odroid C2 Thread der user
danjames92 einen Commit gepostet, der irgendwie 3D Framepacking bei Amlogic ermöglichen soll, oder darauf abzielt...:
http://forum.kodi.tv/showthread.php…4249#pid2564249

Mein ungeschultes Auge sieht nicht mal warum das ein Commit für Amlogic devices sein soll, aber wenn das irgendwie wirklich Framepacked ermöglichen könnte, müsste es automatisch bedeuten, dass es den TV in den 3D Modus schickt, sobald ein entsprechender Film angeht. Keine Ahnung, ob das irgendwie kompatibel mit den Kernel oder Kodi wäre.

Für mein Verständnis: Ist dieser Commit nun für das Linux Basissystem, oder für Kodi, oder für den Kernel?
(Ich habe echte Schwierigkeiten zu unterscheiden ob das Commits für Kernel, oder Kodi oder das Linux Basissystem sind)