Kodi auf dem Raspberry 3 unter verschiedenen Betriebsystemen

[hugly]

Moin,

versuche gerade das arm7 oder arm64 binary Release von https://wiki.netbsd.org/ports/evbarm/raspberry_pi/ via rawrite32.exe zu installieren.

Leider bootet das nicht, ist das momentan kaputt oder weiss jemand mehr??

vg h

 

[mr44er]

Ins Blaue geraten:
"Most ARM boards (unless they have UEFI or Raspberry Pi firmware) require a board-specific U-Boot image alongside the generic NetBSD image to be written to their storage. In most cases board-specific U-Boot images can be built using pkgsrc."
sowie
"

• The Raspberry Pi 1 requires the ARMv6 rpi.img.gz.
• The Raspberry Pi 2-3 can use the standard ARMv7 armv7.img.gz image.
• The Raspberry Pi 3 can also use arm64.img.gz.

Decompress it and write it to the SD card:

$ gunzip armv7.img.gz
$ dd if=armv7.img of=/dev/rld0d conv=sync bs=1m progress=1
"

Wie ich das sehe (und hoffentlich richtig interpretiere), geht auf dem nur ARMv6. Achte darauf, dass du für Flashmedien immer die .img nimmst, nicht die .iso.
Wenn rawwrite versagt (kenne ich nicht), dann kannst du es mal mit rufus probieren.
-> https://rufus.ie/en/

Ansonsten direkt mit dd, das sollte in jedem Fall gehen.

 

[cabriofahrer]

Ich habe die arm64 Version von dem Link hier gerade heruntergeladen, mit dd auf eine MicroSD geflasht und im Raspberry 3 ausprobiert.
Ein shutdown -p now führt zu einem Reboot und ein shutdown -h now fährt nicht ganz runter, sondern man wird aufgefordert, eine Taste zum Rebooten zu drücken. Habe dann die Gelegenheit genutzt, um am Schalter physisch auszuschalten.
Ich nehme mal an, es handelt sich um einen Bug? Da war auch die Meldung, dass es sich um einen Snapshot der neuesten Experimentierversion handele und nicht um eine Release Version. Könnte jemand vielleicht sagen, ob das von mir beschriebene Problem bei einer Release Version nicht besteht?

 

[cabriofahrer]

Also mittlerweile habe ich es selbst nochmal probiert mit einer arm64 9.2 Version und genau das Gleiche. NetBSD scheint auf einem Raspberry nicht normal herunterfahren zu können...

 

[berni51]

Ich hab auf meinen Raspis das evbarm Image laufen und das kann sowohl Halten als auch Rebooten. Natürlich kann es den Pi nicht abschalten, aber das kann ja wohl kein OS.

 

[morromett]

Natürlich kann es den Pi nicht abschalten, aber das kann ja wohl kein OS.

Beim PI4 geht das abschalten schon, wenn man den bootloader entsprechend konfiguriert hat. Z. B.:

:~ $ rpi-eeprom-config | grep -i halt
POWER_OFF_ON_HALT=1

 

[cabriofahrer]

Natürlich kann es den Pi nicht abschalten, aber das kann ja wohl kein OS.

Nun, ich bin ja ganz neu bei Pi und was ich meine, bzw. mir aufgefallen ist, ist folgendes: Wenn ich in Kodi/Xbian die Option "Power off system" wähle, fährt das System runter und der Fernseher bekommt kein Signal mehr. Aus der Sicht des Fernsehers ist das Gerät also ausgeschaltet. Gleiches passiert, wenn ich bei FreeBSD ein "shutdown -p now" ausführe. Am Pi leuchtet dann nur noch ein rotes Lämpchen. Um das Gerät wieder einzuschalten, muss ich dann den Schalter am Kabel 2x betätigen: Nach dem ersten Mal geht das rote Lämpchen aus, nach dem zweiten Mal fährt der Pi dann hoch. Das machte mich schon stutzig und macht den Eindruck, dass das Gerät nicht wirklich aus ist, sondern in einer Art Stand-By Modus? Es ist also nicht genau wie bei einem PC?
Denn weiterhin: Wenn der PC heruntergefahren ist, ist das HDMI-Symbol im Fernsehermenü aussgegraaut, beim Pi hingegen nicht.
NetBSD verhält sich hingegen nicht so wie Linux oder FreeBSD, was mich eben vermuten lässt, dass es nicht korrekt runterfährt / hält.

 

[berni51]

Mit dem evbarm-Image verhält es sich NetBSD genauso wie Linux oder FreeBSD: Der Prozessor wird wohl abgeschaltet, aber die entsprechenden GPIO-Pins haben nach wie vor 5 V anliegen und die rote LED leuchtet.
Werd nachher mal den Tipp von @morromett nachgehen und den POWER_OFF_ON_HALT-Parameter ändern.

 

[morromett]

Das machte mich schon stutzig und macht den Eindruck, dass das Gerät nicht wirklich aus ist, sondern in einer Art Stand-By Modus? Es ist also nicht genau wie bei einem PC?

Ja, das kann ich bestätigen.
Wenn ich meinen PI3B+ mit FreeBSD13.0R mit "shutdown -h now" oder mit "shutdown -p now" (beim PI3 ist zwischen -h und -p kein Unterschied, weil der PI3 das poweroff nicht unterstützt) runterfahre und das Stromkabel nicht ziehe, kann ich die lauschenden TCP- und UDP-Ports des PI3 nicht mehr erreichen, aber ich kann die IPv4-Adresse des PI, im LAN der FritzBox per arping (arp) und per Ping (icmp) noch erreichen. In der FritzBox wird der PI3 auch noch als aktive Verbindung angezeigt.
Erst wenn ich das Stromkabel ziehe, ist der PI3 nicht mehr per arping/Ping erreichbar.

EDIT:

BTW: In diversen Foren gibt es auch Hinweise, dass der PI(3) auch noch via angeschlossenem HDMI-Kabel "etwas" Strom bekommen kann/könnte, und das auch dann wenn er schon heruntergefahren worden ist. Ich kann das nicht testen.

 

[cabriofahrer]

Mit dem evbarm-Image verhält es sich NetBSD genauso wie Linux oder FreeBSD: Der Prozessor wird wohl abgeschaltet, aber die entsprechenden GPIO-Pins haben nach wie vor 5 V anliegen und die rote LED leuchtet.

Das kann ich nicht bestätigen. Ich habe es vorhin ausprobiert und es ist genauso wie bei arm64.
Andere Dinge die mir bei NetBSD negativ auffallen:

• Beim Wechseln in eine andere Konsole (Ctrl+Alt+F2) kriege ich nur einen Promt, aber keine Schrift, wie z.B. "login:"
• Nach Installieren von pkgin mit sysinst lässt sich weder firefox noch opera noch xfce noch kodi installieren, weil es die Pakete offenbar nicht gibt. Ein pkgin search listet zwar sämtliche Pakete zu xfce, der metaport scheint aber zu fehlen.

Nett finde ich allerdings, dass sich der alte xmms noch installieren lässt, der unter FreeBSD schon längst abgeschafft wurde.
Ebenfalls nett ist, dass auch hier "service ftpd onestart" geht. So konnte ich schnell mal ein mp3-Album auf den Pi schieben und mit xmms auf dem Fernseher abspielen.

 

[berni51]

Sonderbar,hab gestern etliche male heruntergefahren oder rebootet, ging immer.
Den namenlosen Prompt auf den Consolen habe ich nur, wenn ich slim als DM einsetze.
Um firefox und xfce4 zu installieren, habe ich in den Eintrag in der repository.conf auf https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/9.3/All gesetzt.
Dann müssen zwar nachträgliche einige softlinks in /usr/lib gesetzt werden, aber das, was ich brauche läuft.

 

[cabriofahrer]

Ich habe mal ein Strommessgerät davorgesteckt und habe nicht schlecht gestaunt: Der Pi verbraucht im Betrieb (Kodi lief) nur 2W! Nach dem Runterfahren blinkte das Gerät zwischen 0 und 1W. Da braucht man eigentlich gar nicht runterfahren zu wollen...
Da frage ich mich nur noch, wie lange so ein Pi denn im Dauerbetrieb halten würde? Gibt es da irgendwelche Erfahrungen?

 

[mr44er]

wie lange so ein Pi denn im Dauerbetrieb halten würde?

Der Dauerbetrieb an sich ist ohne nennenswerten Verschleiß. Hitze ist jedoch immer noch der größte Feind von Bauteilen, daher würde ich zu keinem passiven Gehäuse raten und generell einen Lüfter verwenden.
->

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

 

[berni51]

Mein erster Pi 4 läuft jetzt schon 3 Jahre als Kamera-Server mit Xeoma - nonstop. OK, vielleicht 3 mal wegen Update rebootet. Nach meinen Messungen verbraucht er aber ca. 10 W (mit Lüfter).

 

[medV2]

Da frage ich mich nur noch, wie lange so ein Pi denn im Dauerbetrieb halten würde? Gibt es da irgendwelche Erfahrungen?

Meiner Erfahrung nach sind die relativ Robust.

Ich betreibe derzeit 2 RPI 4, beide nur mit passiven Kühlern (1mal Alu, 1mal Kupfer) und auch ohne Gehäuse. Die Platinen liegen einfach hinterm Schrank, bzw. in einem Regal. Einer ist seit ca. 3 Jahren im Betrieb einer seit 2. Natürlich 24/7. Temperatur jetzt im Sommer bei beiden so bei gut 60 Grad. Bisher keine Probleme.

Einen RPI 1B hatte ich ca. 5 Jahre im Betrieb, ebenfalls einfach die Platine unterm Tisch damals liegen, ganz ohne Kühlkörper, funktionierte auch bis zum Schluss, wurde halt getauscht weil ein PI 1 keinen Spass mehr macht.

 

[cabriofahrer]

Jetzt mal zum Thema Micro SD Karte. Diese ist offensichtlich der Flaschenhals im Pi. Das Navigieren in Kodi dauert wesentlich länger als selbst bei einem alten PC mit Einkernprozessor. Wenn man in einer App auf eine Kategorie klickt (z.B. "Movies") dreht sich das Kreissymbol ziemlich lang, bis endlich eine Liste erscheint. Ich habe eine 64 GB Karte von Gigastone, die Klasse 3 und V30 ist, also theoretisch eine Schreibgeschwindigkeit von 30 MB/s haben sollte. Ich habe mal einen Test laut diesem Artikel hier durchgeführt:

2020’s Fastest Raspberry Pi 4 Storage SD / SSD Benchmarks

The fastest storage devices for the Raspberry Pi 4 including both Solid State Drives (SSD) and Secure Digital (SD / MicroSD). Compiled from benchmarks.

jamesachambers.com

Die Ausgabe ist hier:

Result submitted successfully and will appear live on https://pibenchmarks.com within a couple of minutes.

     Category                  Test                      Result     
HDParm                    Disk Read                  MB/s                    
HDParm                    Cached Disk Read           MB/s                    
DD                        Disk Write                13.1 MB/s                
FIO                       4k random read            1990 IOPS (7960 KB/s)    
FIO                       4k random write           475 IOPS (1903 KB/s)     
IOZone                    4k read                   5493 KB/s                
IOZone                    4k write                  1559 KB/s                
IOZone                    4k random read            4502 KB/s                
IOZone                    4k random write           1524 KB/s                

                          Score: 664                                         

Compare with previous benchmark results at:
https://pibenchmarks.com/
xbian@xbian ~ $

Beim dd write test sieht man schon: 13.1 MB/s, das ist sehr ernüchternd...
Kann mir hier bestätigt werden, dass das Verhalten von Kodi auf die relativ geringe Schreibgeschwindigkeit der Karte zurückzuführen ist? Würde es sich also lohnen, eine bessere Karte mit höherer Schreibgeschwindigkeit zu kaufen um das Problem zu lösen? Welche kann man da empfehlen, insbesondere, so dass es auch stimmt, was auf der Karte draufsteht?

Kann man dem Test noch etwas anderes entnehmen, was von Interesse sein könnte?

 

[medV2]

Ich habe SanDisk Karten, eine V30, eine V10 und erhalte mit dd immer den spezifizierten Wert. Wichtig ist, dass dieser Wert auf eine Leere, also getrimmte SD Karte gilt. Also zuerst fstrim / machen.

Wenn du das nicht hast, hast du nen Mangel und kannst die Karte auch reklamieren.

Für Kodi, insb. Ladezeiten sollte aber eher der read relevant sein. Wenn der auch an den 13 MB/s ist, dürfte das eigentlich keine Rolle spielen, es sei denn du hast wirklich große Verzeichnisse mit Tausend Datein. Es könnte also schon auch die CPU oder auch der RAM sein. Du kannst einen PI3 nicht mit einem alten 1Kern Prozessor vergleichen, das sind völlig andere Architekturen.

Das solltest du aber auch schnell rausfinden können, in top müsste der wait wert durch die Decke gehen wärend sich die CPU langweilt. Auch mit iotop könntest du schauen wie schnell Kodi überhaupt Daten braucht.

Ich würde für solche Benchmarks btw bonnie++ empfehlen (fs sollte aktives Trim haben), bei doch komplexeren Bashscripten die noch dazu Rootrechte verlangen hätte ich meine Zweifel.

 

[CommanderZed]

Was für ein OS und welche Kodi-Version etc nutzt du denn jetzt genau?

Das PI3 war bei mir bei bestimmten Kodi-Geschichten auch etwas träge, das PI4 da ne ecke schneller - da gings aber eher um CPU-Lastiges.

Was navigierst du denn genau? Sind die daten lokal auf der SD-Karte oder irgendwie im NetzwerK?

 

[cabriofahrer]

Was für ein OS und welche Kodi-Version etc nutzt du denn jetzt genau?

Xbian/Kodi19.4

Was navigierst du denn genau? Sind die daten lokal auf der SD-Karte oder irgendwie im NetzwerK?

Es handelt sich höchstwahrscheinlich um die Scraper-Funktion der App. In irgendeinem Artikel über Kodi habe ich mal gelesen, dass aus diesem Grund auch eine Kabelverbindung empfohlen wird, weil diese Scraper Unmengen von Servern durchwühlen. Also Netzwerk. Wenn ich hingegen mit Kodi auf der SD-Karte nach lokal gespeicherten mp3's suche, geht das ruckzuck.
Da liegt also die Vermutung nahe, dass der Pi im Gegensatz zum PC einen Flaschenhals im Zusammenhang mit dem Netzwerk hat?

 

[Columbo0815]

Können wir bitte zurück zum Thema kommen? Hier geht es um NetBSD auf einem RaspberryPi.

 

[CommanderZed]

Xbian/Kodi19.4

Ich hab den Thread mal ins Geplauder verschoben und den Titel angepasst - das hat nun ja so garnichts mehr mit NetBSD zu tun.

Außerdem, eine ganz dringender genereller Vorschlag: Wenn du im Thread von XYZ schreibst - hier NetBSD, und dann später bin Xbian - schreib das doch mal irgendwo zwischendrin dazu, sonst denken über ganz andere Szenarien nach.

Ich glaube ich hab dir das schon öfter geschrieben, das ist sehr unhöflich und bindet die dir kostenfrei von dritten geschenkte Zeit.

Es handelt sich höchstwahrscheinlich um die Scraper-Funktion der App. In irgendeinem Artikel über Kodi habe ich mal gelesen, dass aus diesem Grund auch eine Kabelverbindung empfohlen wird, weil diese Scraper Unmengen von Servern durchwühlen. Also Netzwerk. Wenn ich hingegen mit Kodi auf der SD-Karte nach lokal gespeicherten mp3's suche, geht das ruckzuck.
Da liegt also die Vermutung nahe, dass der Pi im Gegensatz zum PC einen Flaschenhals im Zusammenhang mit dem Netzwerk hat?

Hmmm, njein, also ganz sicher kann man die CPU <-> Nic oder wifi anbindung und die Chips selbst nicht mit denen in aktuellen Desktops oder gar Servern vergleichen. Dtl. schneller als gängige DSL-Leitungen (100Mbit oder so) sollten sie aber im normalfall schon sein - ich glaube also nicht das dies der flaschenhals ist.

Vermutlich sind die aktuellen Bibiliotheken / Scraper einfach umfangreicher als früher, sowas kann dann uu dauern.

Generell lohnt es sich mit sehr großer wahrscheinlichkeit mal libre-elec zu versuchen - die haben auch spezialisierte builds für den RP3 und kein Kombi-Image für 2/3 - da könnt es durchaus performanceschmälerungen geben.

 

[mr44er]

1.) Ich weiß es nicht genau bei/bis welchem Modell, aber die pis waren oft zu den Anhängseln (bspw. card reader) via USB2 intern verdrahtet. Wenn sich der card reader und die NIC jetzt auch noch die USB2-Bandbreite teilen, ist das noch mehr penalty. Kann sein, muss aber nicht.
2.) Wenn der card reader nur bis gen$ ist, kann der auch nur Karten bis gen$ ausschöpfen. Auch hier habe ich kein Detailwissen zum pi3.
3.) Karten erreichen die beworbenen Geschwindigkeiten also nur im passenden reader und da auch nur sequentiell. Scraping, in kodi navigieren oder eine Liste öffnen ist das genaue Gegenteil von sequentiell.

 

[CommanderZed]

Ich hab auch noch mal geschaut, der PI3 hat auch ungefähr den gleichen Prozessor wie der Pi2, das war damals auch bei mir der Flaschenhals beim Software-Decodieren von verschlüsselten Videostreams.

Wir reden hier also von ca. 7 Jahre alten Prozessoren - in der sehr schnell-lebigen ARM-Welt eine ewigkeit.

Der PI4 ist da ne Ecke potenter - aber innerhalb des ARM-Universums auch nicht der schnellste Hobel auf dem Markt, und auch nicht der mit dem besten Preis/Leistungsverhältniss, auch nicht als er vor 2 Jahren auf dem Markt kam und ganz sicher heute nicht.

Wenn ich jetzt akut einen kaufen würde speziell für Kodi, würde ich schauen welcher erstens gut von openelec ODER nem gut supporteten "normalen" Linux OS unterstützt wird und dann bei Budget X die meiste Leistung bietet.

 

[cabriofahrer]

Sorry, dass sich das hier etwas vermischt hat, aber ich hatte zwischendurch auch NetBSD ausprobiert, dann ging es widerrum um allgemeine Dinge wie Stromverbrauch, Kühlung, etc.

1.) Ich weiß es nicht genau bei/bis welchem Modell, aber die pis waren oft zu den Anhängseln (bspw. card reader) via USB2 intern verdrahtet. Wenn sich der card reader und die NIC jetzt auch noch die USB2-Bandbreite teilen, ist das noch mehr penalty. Kann sein, muss aber nicht.

So etwas habe ich auch schon irgendwo gelesen und vermutet, dass es damit zu tun haben könnte. Mein Modell ist dieses hier:

Raspberry Pi 3 Mini-Linux-PC, 1 GB, inkl. WLAN und Bluetooth 4.1, komplett montiert und betriebsbere

Anschließen, einschalten, loslegen Der Raspberry Pi 3 wird als Fertiggerät mit der vorinstallierten Programmsammlung Noobs inklusive…

de.elv.com

Bin ich also davon betroffen?

Xbian ist wie openelec und libreelec ebenfalls ein speziell für den Pi angepasstes System, es ist sicherlich nicht die falsche Wahl. Libreelec kam für mich nicht in Frage, da es angeblich nur ein read-only Filesystem erstellt.

Vermutlich sind die aktuellen Bibiliotheken / Scraper einfach umfangreicher als früher, sowas kann dann uu dauern.

Es geht hier nicht um einen Vergleich mit früher: Wenn ich genau das gleiche auf dem alten PC mache, dauert es eben lange nicht solange, in diesem Sinne geht es auch nicht hierum

Ich hab auch noch mal geschaut, der PI3 hat auch ungefähr den gleichen Prozessor wie der Pi2, das war damals auch bei mir der Flaschenhals beim Software-Decodieren von verschlüsselten Videostreams.

, sondern wirklich nur um das Anklicken einer Kategorie, z.B zuerst "Movies", dann z.B. "Action Movies", es dauert dann sehr lange, bis eine Liste erscheint. Das Abspielen des Steams selbst, wenn man dann einen anklickt, funktioniert wunderbar mit geringer Prozessorbelastung und mit Hardwarebeschleunigung (sieht man durch Drücken der Taste "O").

Zum Thema NetBSD wollte ich noch sagen, dass es zunächst interessant erschien, da es Audio auf dem Pi unterstützt und angeblich auch Hardwarebeschleunigung auf dem Grafikchip. Allerdings gibt es kein Kodi für NetBSD.

Hinzu kommt jetzt noch, dass es unter dem neuen Bullseye (Debian 11) angebleich keine Hardwarebeschleunigung für die QuadCore GPU mehr geben soll? Dann muss man wohl gezwungenermaßen ein älteres Release nehmen?
Und vielleicht gibt es irgendwannmal einen Treiber für FreeBSD mit Hardwarebeschleunigung für den QuadCore...

 

[CommanderZed]

Ich muss ehrlich sein das ich Kodi bislang (fast) nur auf dem Raspberry getestet hab - mit dem Pi4 lief dann alles dtl. schneller, auf dem Pi3 war es tatsächlich auch bei mir bei bestimmten dingen etwas träge neben dem Hauptproblem (Das Hauptproblem war das ich netflix, prime etc damit auf dem Fernseher schauen wollte wofür es auch ein Plugin gab, das auch funktioniert hat aber halt nur in Software berechnet hat - für den 3 einfach zu viel.

Dann gab es irgendwie ein Update, dann ging Prime nicht mehr, dann dort eins, dann ging xyz nicht mehr, ich hab das Projekt Kodi / Raspberry dann wieder verworfen, zu viel rumgebastel um spontan nen Film zu schauen und verwende mein älteres (Thinkpad t450s) Windows-Notebook dafür - villeicht ja auch garnicht blöd, ein system weniger um das man sich kümmern muss.

Für den Pi3 hab ich nen guten alternativnutzen gefunden, für den Pi4 muss ich noch etwas sinnvolles finden.