So schnell ist ein angepasstes Openelec beim Raspberry Pi!

Zitat von Koloss

Ich weis immer noch nicht, wie man die Bilder neu laden kann, weis das wer?

Thumbnails-Ordner und Textures.db löschen, dann lädt er alles erneut herunter. Fanart bleibt wie gesagt bei 720/1080p, einzig <imageres> funktioniert und skaliert die Cover auf die dort angegebene Seitenlänge in Pixeln.

Alles soweit verstanden...aber bisher läuft mein OPenelec immer noch von der sd-Karte.
Ich benötige ne verständliche und ausführliche ANleitung auf deutsch.

Kann mir da jemand helfen?

LG

ok..sorry!!!

ok..sorry!!!

Koloss

Die Software im Video ist unter dem angegeben Link nicht mehr verfügbar.

Hat geklappt..vielen dank!!!

Vielen Dank Koloss

Zitat von tobi9876

PS: Gibt es bei OpenElec kein "Online Update"? Muss man immer den Umweg über die Hompage gehen und die Dateien manuell downloaden?

Doch, gibt es selbstverständlich. Seit OpenELEC 3.1 gibt es ein neues Settings Addon. Dort findest du einen Button zum Suchen und Installieren von Updates. Alternativ kannst du auch automatische Updates aktivieren, dann brauchst du dich um nichts mehr zu kümmern.

Noch mal ein Fazit nach 48 Stunden mit meinem neuen RPi: Wer nur Filme oder Serien guckt wird mit den neuen Geschwindigkeitsoptimierungen begeistert sein, nicht jedoch diejenigen, die einen Film auch mal pausieren oder einfach nur das OSD anzeigen möchten. Das Problem ist nicht, dass die Filmbibliothek 10 Sekunden schneller lädt, das kann man ja noch verkraften, aber die GUI-Performance selbst (z.B. während der Wiedergabe) ist einfach grauenhaft.

Ich verstehe auch ehrlich gesagt nicht, wieso man sich nicht mal die Mühe macht und die Rendering Engine optimiert und stattdessen die Ladegeschwindigkeit der Bibliothek bis zum Gehtnichtmehr optimiert. Das nützt einem doch nichts, wenn man nicht mal die Tonspur wechseln kann, ohne das man Angst haben muss XBMC macht die Biege.

Versteht mich nicht falsch: Das ist alles toll, was man aus so einer kleinen Kiste rausholen kann und ich bin ein großer Fan des kleinen PCs, aber für XBMC ist er nicht geeignet und wird es vermutlich niemals sein. Es macht einfach keinen Spaß auch nur zu versuchen LiveTV zu bedienen oder sich im OSD herum zu hangeln.

My 2 Cents…

Kann deine Meinung leider nicht teilen..
LiveTV läuft bei mir gestreamt von meiner Dreambox selbst in HD ruckelfrei..
Filme lassen sich ohne Probleme anhalten, wieder anspielen, anhalten, .. alles glatt..

Keine Probleme mit diesem Build.. von mir Daumen hoch

Zitat von Ruschi

Kann deine Meinung leider nicht teilen..
LiveTV läuft bei mir gestreamt von meiner Dreambox selbst in HD ruckelfrei..
Filme lassen sich ohne Probleme anhalten, wieder anspielen, anhalten, .. alles glatt..

Keine Probleme mit diesem Build.. von mir Daumen hoch

Machst Du mir ein Video? Dann mache ich auch eines und wir könnten mal vergleichen…

Zitat von Koloss

So ich habe nun meinen Pi mit einen sehr schnellen usb-stick bestückt:
http://www.amazon.de/Transcend-Extreme-Speed-JetFlash-USB-Stick-100MB/dp/B006VAOM6G/ref=sr_1_4?ie=UTF8&qid=1381222778&sr=8-4&keywords=usb+stick+transcend+780&tag=kodinerds04-21 [Anzeige]

Setup:
arm_freq=900
core_freq=333
sdram_freq=450
over_voltage=2
force_turbo=0

Also starten tut er 30sec(alter Stick 50sec, SD-Karte ca. 30sec). Filme durchbrowsen ist gleich schnell wie mit alten Stick. Kann man leicht testen in den man die filme durchscrollt (nach 30 sekunden stoppt der Pi automatisch), das Browsen geht mit einen USB-Stick als mit meiner SD-Karte.

Fazit: Hardware Ausstattungstechnisch geht es nicht mehr schneller, der einzige Performanceschub wäre noch volles overclocken, werde ich auch demnächst einwenig spielen damit, als Dauerlösung würde ich es aber nicht empfehlen.

Alles anzeigen

Ich habe meinen auf:
cpu_freq=1000
core_freq=500
sdram_freq=600
over_voltage=6

Er läuft selbst ohne Kühlkörper nie heiß. 65°C mit Gehäuse ist das höchste der Gefühle. Ich hätte da keinerlei Bedenken. Mit den RPej-Builds ist wie gesagt das Laden der Bibliothek viel schneller, die Geschwindigkeit des USB-Sticks ist zweitrangig, denn selbst wenn Du einen USB-Stick mit über 20 MB/s hast nützt das dem RPi nichts, denn der Flaschenhals am System ist SoC mit CPU, RAM und Grafik und nicht der USB-Stick selbst.

Da gibt es andere Baustellen bei XBMC, die man eher mal angehen könnte als dauernd die Ladegeschwindigkeit der Bibliothek zu optimieren… z.B. das Auslagern der GUI auf die Grafikkarte. Das würde viel mehr bringen.

Zitat von Cassiel

Da gibt es andere Baustellen bei XBMC, die man eher mal angehen könnte als dauernd die Ladegeschwindigkeit der Bibliothek zu optimieren… z.B. das Auslagern der GUI auf die Grafikkarte. Das würde viel mehr bringen.

Das GUI ist doch schon sehr stark auf die Grafikkarte ausgelagert. Was könnte man da verbessern?

Zitat von Cassiel

Da gibt es andere Baustellen bei XBMC, die man eher mal angehen könnte als dauernd die Ladegeschwindigkeit der Bibliothek zu optimieren… z.B. das Auslagern der GUI auf die Grafikkarte. Das würde viel mehr bringen.

Das hat man bereits in XBMC 11 gemacht. Es ist so gut wie alles in der GUI. Früher musste man das noch per extra [definition='2','0']as.xml[/definition] Eintrag bestimmen. Ab XBMC 12 geht das alles automatisch direkt über die GUI.

Zitat von Koloss

@Cassiel: force_turbo=0 oder force_turbo=1 ?

force_turbo=0 - noch möchte ich meine Garantie erhalten. Bis ich mir ein paar Passivkühler besorgt habe und sicherstellen kann, dass ich auch dauerhaft unter 85°C bleibe. Das ist das Hardware-Limit ab dem der ARM runtertaktet. Teoretisch kann also nichts passieren, ich habe zusätzlich noch den Wert für max_temp auf 75 gesetzt, dann taktet er schon bei 75°C runter und es kann wirklich gar nichts mehr kaputt gehen. Ob man jetzt bei einem 36,- EUR Gerät die Garantie erhalten muss… lässt sich drüber streiten, zumal es ja ein Bastlergerät ist.

Zitat von keibertz

Das hat man bereits in XBMC 11 gemacht. Es ist so gut wie alles in der GUI. Früher musste man das noch per extra [definition='2','0']as.xml[/definition] Eintrag bestimmen. Ab XBMC 12 geht das alles automatisch direkt über die GUI.

Ach tatsächlich? Es heißt doch immer, dass die GUI sehr CPU-intensiv sei. Und wenn ich mir die CPU-Auslastung/FPS anzeigen lasse, merkt man auch, dass diese miteinander korrelieren. Da scheint noch lange nicht das Ende der Fahnenstange erreicht zur sein bei der Optimierung.

Nachtrag:
Das was ihr meint, mit den Parametern der [definition='2','0']as.xml[/definition] ist doch nur die Aktualisierung des Framebuffer bei Dirty Regions, also Regionen, die nach dem Senden eines Frames an die Grafikkarte quasi "direkt" neuberechnet werden müssen. Das alleine reicht nicht um die CPU vollständig zu entlasten, das optimiert quasi nur den Weg von CPU -> GPU -> Framebuffer -> Ausgabe. Mit einem kleinen Prozessor (ähnliche Atom oder ARM) könntest Du eine noch so starke Grafikkarte haben, der Flaschenhals würde die CPU bleiben. Nun muss man auch sagen, dass die CPU schon sehr damit gefordert ist die teilweise sehr komplexen XML-Dateien des Skins einzulesen, zu parsen und zu analysieren bzw. auf den Bildschirm zu zeichnen. Ich bin sicher mit einer guten Rendering-Engine und auf HTML5/CSS3/JavaScript-Basis könnte man Skins wesentlich performanter machen.