Frage:
Sind die Erweiterungen eingeflossen um die Plugins vdrboblight oder seduatmo zu füttern?
ist ja jetzt fast schon ein Jahr alt dein Post: hast du das zwischenzeitlich zum Laufen bekommen (Ubuntu bzw. Coreelec), die Schnittstelle sollte ja für beide Plugins identisch sein?
Ich hab Jörg gebeten das seduatmo um den Frontendnamen zu erweitern damit es weiß wo es sich attachen soll, werde danach mal hier auf VDRSternELEC testen.
ist ja jetzt fast schon ein Jahr alt dein Post: hast du das zwischenzeitlich zum Laufen bekommen (Ubuntu bzw. Coreelec), die Schnittstelle sollte ja für beide Plugins identisch sein?
Ich hab Jörg gebeten das seduatmo um den Frontendnamen zu erweitern damit es weiß wo es sich attachen soll, werde danach mal hier auf VDRSternELEC testen.
Hallo,
ich meine das JoJo das eingebaut hat, jedoch nutze ich auf dem Odroid Hyperion.ng. Damit kann man das Bild direkt grabben und an die Sedu-Lights ausgeben. Den "Umweg" mit dem boblight-plugin nutze ich auf dem NUC8 mit softhddrm und externen hyperion.ng.
So ganz rund läuft das auf meinem n2+ noch nicht mit dem seduatmo, ich muss das aber noch mal in Ruhe testen. - Das Plugin selber läuft, connected sich über die udev Rule mit dem Controller und kann auch die Farben separat ausgeben, soweit so gut. Wenn ich den atmo mode starte erhält sich der vdr aber merkwürdig, die CPU Load geht hoch und er zeigt auch keine sauberen Farben an - auch wenn es so scheint als würde er dem Bildinhalt irgendwie folgen.
Ich muss da noch mal hinterhergehen - Vielmehr stoße ich mich im Moment aber eher an den enorm hohen Umschaltzeiten, da sind je nach Sender 6-8 Sekunden drin. - ich hab wirklich den ganzen Zoo an sofhd* Plugins hier am laufen (-cuvid, -drm, -vaapi) alle mit streamdev und überall sehe ich Zeiten von 1-3s. Verhalten ist auch unter ubuntu oder dem CE Image von Zabrimus identisch.
Ist da irgendwo Abhilfe in Sicht, oder mach ich noch irgendwas falsch?
st da irgendwo Abhilfe in Sicht, oder mach ich noch irgendwas falsch?
Da muss noch ein Fehler bei dir sein. Hier mit meinem N2+ liegen die umschaltzeiten bei 1-3. Ist das mit oder ohne seduatmo?
Kannst du mal mit satip testen ?
ohne seduatmo und auch nur mit softhdodroid und satip/streamdev, auf ubuntu ie auch auf CE Basis, Zabrimus bestätigt das auch. Vllt ne spezielle Einstellung in den Plugin settings die vom default abweichen?
Ansonsten läuft die Kiste flüssig und macht ein Bild wie ne eins
ja gern, komm ich aber erst morgen zu
also mit dem reinen hardkernel image selber tu ich mich schwer, ich hab das aber jetzt als chroot unter coreelec laufen und da hab ich ganz ansprechende Umschaltzeiten. ich beobachte das mal weiter
jojo61: Vielleicht ist das Problem von durchflieger ähnlich meinem Problem mit SES Demo UDH. Das Bild ist unter CE UBUNTU chroot zwar da, aber kaum sichar, so als hätte jemand die Helligkeit komplett runtergedreht. Nur wenn extrem helle Schriftzüge o.ä. da sind, sieht man es. Vielleicht hat KODI hier noch ein paar Dinge anders voreingestellt (Kontrast, Helligkeit, Farbe o.ä.). Unter Ubuntu funktioniert es ja einwandfrei, daher schließe ich meinen LG-TV z.B. aus.
Komischerweise habe ich das Problem aber nicht beim Verkaufs-TV QVC ind UHD...
ich war hier auch drüber gestolpert an meinem 10 Jahre alten Samsung FHD im Arbeitszimmer, hatte den odroid aber heute im Esszimmer am Sony UHD TV angeschlossen und die Inhalte wurden fehlerfrei , genauso wie von vom NUC8 mit softhddrm, wiedergegeben. Wenn man auf einen HLG Kanal schaltet atmet der Fernseher leicht durch und schaltet dann in einen anderen Modus, das HDR Bild wirkt auch leicht dunkler. (bei softhddrm auch)
Hab Im kodi die Auflösung dann auf 2160p gesetzt und das Ganze läuft wirklich beeindruckend rund! 
Ich hab dann im Esszimmer auch das seduatmo noch mal probiert und hier ist definitiv noch was nicht korrekt:
Er scheint sich an die API vom sofhdodroid zu connecten und versucht auch die LEDs entsprechend des Bildinhalts zuzuweisen. Es ist auch so das ich die angezeigten Farben "irgendwo" im Display wiederfinde aber es ist komplett flau und tut halt nicht das Erwartete bei recht viel CPU Last (bei 92 Kanälen die angefragt werden, also nur eine recht grobe Grafik).
Die Frage wäre wie ich hier am besten vorgehe um das Ganze zu debuggen. Durch die chroot Umgebung kann ich ja mittlerweile schnell Änderungen an den beteiligten Plugins einsetzen. jojo61 : würde es hier Sinn ergeben, wenn ich horchi nach seinem Urlaub bitte das seduatmo so zu modifizieren, dass es alle 2-3s ein Bild wegschreibt um dessen Sicht zu sehen. man könnte ja hier eine Aufnahme pausieren und die dagegenhalten? Denke das mit der Last macht erst Sinn anzusehen wenn die Ausgabe funktioniert.
Danke bis hier her, ganz neue Dimensionen am VDR - jetzt fehlt nur noch ordentlich UHS Content von den Sendeanstalten.
würde es hier Sinn ergeben, wenn ich horchi nach seinem Urlaub bitte das seduatmo so zu modifizieren, dass es alle 2-3s ein Bild wegschreibt um dessen Sicht zu sehen. man könnte ja hier eine Aufnahme pausieren und die dagegenhalten?
Also erstmal wegen dem dunklen UHD Bild: Die UHD Sender bis auf die Ausnahme vom Shopping Sender senden alle in HDR. Wenn der Fernseher dann nicht auf HDR umschaltet dann ist das Bild zu dunkel. Ob der Fernseher überhaupt HDR kann sieht man am EDID und genau danach richtet sich auch softhdodroid oder genauer gesagt der Kernel Treiber. Also vergleicht mal das edid wo es geht mit dem wo es nicht geht. Bei Fernshern die kein HDR können wird es auf SDR umgerechnet. Wenn das Bild also zu dunkel ist kann es ein das der TV (EDID) sagt er kann HDR aber dann doch nicht umschaltet.
Ich kann nicht sagen wie seduatmo die Farben errechnet, aber es könnte evtl. sein das das Bild das ich liefere auf dem Kopf steht. Deswegen macht es sicher Sinn das seduatmo das Bild mal ausgibt damit man sieht auf welcher Basis es die Farben berechnet,
mfg
jojo61
Jörg ist noch eine Woche im Südafrika und schaut sich das dann an.
AFAIR berechnen das seduatmo/vdrboblight gar nichts an den Farben. Vielmehr fragt es über die ATMO1_GRAB_SERVICE ein Bild in der Geometrie der verbauten LEDs - hier bei mir 38x21 also 118 LEDs am Frontend, an und schickt die Information (vermutlich einen Mittelwert der äußeren Pixel, bei cinebars geht er auch weiter rein ins Bild), direkt auf den LEDs aus. Das hat er damals mit johns entwickelt kann ich mich erinnern, aber das ist schon lang her. So richtig tief drin steckt da nur er.
Aber wie du schon sagst wir müssen erst mal schauen was da für ein Bild ankommt im sedu.
Ich habe hier auf einem odroid n2+ Mikroruckler beim TV sehen. Mir ist unklar, an welchen Parametern/Einstellungen ich spielen kann, damit die nicht mehr auftauchen. Das System ist CoreELEC mit der letzten Version von softhdodroid.
Mit Android / Kodi habe ich keine Probleme feststellen können. Da wird alles ohne Probleme abgespielt.
Hat jemand eine Ahnung was hier die Ursache sein könnte oder an Besten sogar eine Lösung?
Kann es sein das dein TV auf 60 Hz läuft ?
Auf die Idee kam ich auch irgendwann, aber das Problem habe ich sowohl am TV, als auch am Monitor sowohl mit 50/60 Hz.
Ein baugleiches Modell (mit derselben emmc) liefert an beiden Endgeräten gar kein Problem.
Ich habe es auch noch nicht geschafft, die Boot-Reihenfolge auf SD, eMMC zu ändern. Dieses eMMC ein-/ausbauen geht mir auf den Senkel.
Du kannst den Bootsektor auf der eMMC kaputt schreiben und von SD wieder herstellen. Dann musst Du nicht immer ein- und ausbauen.
Aber nicht vergessen den Bootsektor vorher zu speichern!
Ich habe das hier beschrieben: https://forum.odroid.com/viewt…hp?f=177&t=43593&start=50
Ich habe das hier beschrieben: https://forum.odroid.com/viewt…hp?f=177&t=43593&start=50
Sensationell! Passt zwar nicht hierhin, aber danke. Wird unbedingt probiert.
Display MoreIch habe hier auf einem odroid n2+ Mikroruckler beim TV sehen. Mir ist unklar, an welchen Parametern/Einstellungen ich spielen kann, damit die nicht mehr auftauchen. Das System ist CoreELEC mit der letzten Version von softhdodroid.
Mit Android / Kodi habe ich keine Probleme feststellen können. Da wird alles ohne Probleme abgespielt.
Hat jemand eine Ahnung was hier die Ursache sein könnte oder an Besten sogar eine Lösung?
ich hab genau das gleich beobachtet mit chroot auf CE, und zwar fällt mir das nur bei Fußball auf wenn ich das aktuell im Arbeitszimmer parallel mitlaufen lasse. Habe gestern zum Gegentest mal meinen Celeron NUC7 mit softhdvaapi dran gehabt und da ist das nicht, auch wenn dort das Bild in sich nicht so toll ist wie bei odroid. Beide Geräte sind sind exakt gleich konfiguriert. Beim normalen Fernsehen ist das nicht zu bemerken, es fühlt sich an wie so ein leichtes Nachziehen hinter dem Ball.
Habe gerade mal in die aktuelle Fußballübertragung von der ARD gezappt - das sieht alles sehr flüssig aus.
Den Effekt, dass es ruckelig aussah, hatte ich aber auch schon ein paar mal. Das erste Problem war kodi - die Oberfläche war auf 60 Hz konfiguriert. Diese Rate blieb beim Wechsel zu vdr. Seitdem habe ich in kodi 50 Hz eingestellt. Alternativ könnte man
echo 1080p50hz > /sys/class/display/modein das Umschaltscript bei der Rückkehr zu vdr eintragen. Ich habe es bisher nur in meiner runvdr vor dem Start von vdr stehen.
Ein anderes mal zeigte der TV 50 Hz, und dennoch lief es erst nach einem reboot wieder flüssig.
Probier doch mal den o.g. Befehl. Wenn er was bringt, sollte man ihn im vdr-Startscript und beim Wechsel von kodi zu vdr ergänzen, dann kann kodi auch auf 60 Hz laufen.
Was ist in der boot.ini und config.ini definiert? Ich bin mir nicht sicher, ob die boot.ini schon komplett obsolet ist oder zumindest Teile davon noch greifen.
In meiner boot.ini steht setenv vout "1080p60hz" und in der config.ini sind HDMI custom mode und HDMI mode auskommentiert.
Das ist alles seltsam. Alles neu installiert und keine Probleme. Dann habe ich in Kodi die Refresh Rate auf 50Hz gesetzt und schon kamen die Probleme wieder.
Die schlaue Idee, die Refresh Rate in Kodi wieder auf 60Hz zu setzen funktioniert nicht, weil ich nicht mehr an die Settings komme. Die sind jetzt disabled 
echo 1080p50hz > /sys/class/display/mode
hat an dem Problem auch nichts geändert. Dann habe ich die /flash/config.ini geändert und folgende Einträge gemacht:
Nach einem reboot lief wieder alles problemlos. Aber an die Kodi Einstellungen komme ich immer noch nicht. Aber wenn es jetzt läuft, werde ich erstmal nix weiter daran basteln.
Du kannst den Bootsektor auf der eMMC kaputt schreiben und von SD wieder herstellen. Dann musst Du nicht immer ein- und ausbauen.
Aber nicht vergessen den Bootsektor vorher zu speichern!
Ich habe das hier beschrieben: https://forum.odroid.com/viewt…hp?f=177&t=43593&start=50
Moin beta,
Deine Beschreibung im CoreElec-Forum ging ja von einer Ubuntu-Installation auf der eMMC aus. Inzwischen verwenden wir ja eine CoreElec-Installation und haben Ubuntu nur noch in einer chroot-Umgebung.
Passen die Befehle zum Sichern des Ubuntu-Bootloaders:
dd if=/dev/mmcblk0 of=bootloader.bin bs=512 count=2047zum Zerstören des Bootloaders:
dd if=/dev/zero of=/dev/mmcblk0 bs=512 count=3und zum Zurückschreiben des Bootloaders:
dd if=./bootloader.bin of=/dev/mmcblk0 bs=512auch für den Bootloader von CoreElec, oder sind Größe bzw. Blöcke evtl. unterschiedlich zu Ubuntu? Auf meiner eMMC habe ich am Anfang (vor der 512 MB großen FAT16-Partition namens COREELEC, die von Block 8192 bis 1056767 reicht) einen freien Bereich von 4 MB (bis Block 8191). Genauso ist es auch auf einer SD-Karte mit CoreElec. Ich weiss nicht so recht warum das so ist - im CoreElec-Image ist dieser freie Bereich am Anfang nicht drin. Ich bin nicht mehr sicher, wie ich das Image auf die eMMC geschrieben habe. Ich glaube, ich hatte den balenaEtcher verwendet.
Don’t have an account yet? Register yourself now and be a part of our community!