Raspberry Pi 2

  • hi !


    Nicht zu vergessen => mit Satip brauchts keine USB Tuner.. und durch das Gbit Ethernet hat der Banana die Nase vorn...


    Gruss gerd

    vdr => p8b75-m lx / pentium g2020t / 8 GB Ram / zotac gt 630 / cine S2 V5.5 / 60 gb ocz ssd / 640 gb wd scorpio blue / display noritake 256x64-3900 / chenbro PC71023 gehaeuse / yavdr stable / softhddevice


    spielsystem => p8b75-m le / intel core i3 3220T / ubuntu lts 14.04 / 16 GB ram / zotac gt 630 / cine S2 V6.2 / yavdr stable pakete / softhddevice / pulseaudio+alsa


    spielwiese => Zotac Zbox ID45 / 120 GB mSATA / via Satip => Octopus Net / yavdr stable / softhddevice

  • Hi !

    Klingt spannend. Ich spare mir mal die 8 Euro für das Farnell RTC Modul und warte ab ob dein Weg für mich umsetzbar ist. Welchen RTC Chip willst du denn dafür nehmen ?

    in China bestellt 4 wochen gewartet 2,2 USD :)


    Gruss Gerd

    vdr => p8b75-m lx / pentium g2020t / 8 GB Ram / zotac gt 630 / cine S2 V5.5 / 60 gb ocz ssd / 640 gb wd scorpio blue / display noritake 256x64-3900 / chenbro PC71023 gehaeuse / yavdr stable / softhddevice


    spielsystem => p8b75-m le / intel core i3 3220T / ubuntu lts 14.04 / 16 GB ram / zotac gt 630 / cine S2 V6.2 / yavdr stable pakete / softhddevice / pulseaudio+alsa


    spielwiese => Zotac Zbox ID45 / 120 GB mSATA / via Satip => Octopus Net / yavdr stable / softhddevice

  • Laut den ganzen Beiträgen im Kodi scheint der Kleine auf jedenfall wesentlich performanter zu sein wie der Alte. Meiner kam gestern. Hab nur leider vergessen eine MicoSD zu kaufen weshalb ich noch nicht probieren konnte. Irgendwer eine Ahnung ob das mit dem MPEG-Keys das selbe ist wie vorher?

  • Hi

    Das entscheidende ist doch: Eine RTC wird den Raspberry nicht aufwecken. Die ist nur ein I2C-Modul mit dem man eine Uhrzeit über einen Stromausfall retten kann.

    Schon klar.... mir gings nur um den Preisunterschied.... 8 € vs 2,20 $


    Gruss Gerd

    vdr => p8b75-m lx / pentium g2020t / 8 GB Ram / zotac gt 630 / cine S2 V5.5 / 60 gb ocz ssd / 640 gb wd scorpio blue / display noritake 256x64-3900 / chenbro PC71023 gehaeuse / yavdr stable / softhddevice


    spielsystem => p8b75-m le / intel core i3 3220T / ubuntu lts 14.04 / 16 GB ram / zotac gt 630 / cine S2 V6.2 / yavdr stable pakete / softhddevice / pulseaudio+alsa


    spielwiese => Zotac Zbox ID45 / 120 GB mSATA / via Satip => Octopus Net / yavdr stable / softhddevice

  • Hi,
    Aufwecken geht vielleicht doch.
    Den PI kann man aufwecken indem man GPIO-3 auf GND zieht (mache ich mit Taster).
    Wenn die RTC einen Interruptausgang hat der nach GND verbindet (low active) könnte das Aufwecken über den GPIO-3 funktionieren.

    Grüße, Dieter :)

  • ...Irgendwer eine Ahnung ob das mit dem MPEG-Keys das selbe ist wie vorher?


    Wie bisher auch.... Nach 4 Stunden hatte ich diese.

  • Laut Golem bietet der Pi 2 ca. 94Mbps gegenüber den 72Mbps des Vorgängers. Und ich gehe davon aus, dass er zu den 94Mbps noch eine Menge CPU-Resourcen über hat. Er sollte also als reiner Streaming-Client ausreichend sein. :)

    Server:  (K)VM on Proxmox 4.x-Host, VDR 2.2.0 (selbstgebaut vom yaVDR unstable Repo) auf Debian 8 (Jessie), 1x Digital Devices Cine S2 (V6) + DuoFlex S2
    Clients: Raspberry Pi 2/3 mit Raspbian, VDR 2.2.0 (selbstgebaut vom yaVDR unstable Repo) als Streamdev-Clients

  • Eins durchschaue ich bei Eurer ganzen Diskussion über die Netzwerk Bandbreite nicht so ganz. Ein durchschnittlicher HD TV Stream hat nicht mehr als 15MBit. Davon passen also diverse durch ne 100MBit Leitung. Selbst wenn der Stream über NFS aufgezeichnet wird ist noch genug übrig um gleichzeitig ne Aufnahme anzuschauen.
    Ich hatte vor einigen Monaten mal testweise einen Sender geschaut und gleichzeitig zwei Streams anderer Programme auf nen Notebook und Smartphone übertragen. Lief alles problemlos mit den zwei verwendeten Soundteck DVB-T Sticks. OK, das waren nur SD Sender, aber auch zwei von denen hatten ca. 8MBit. Die Bedienung wurde dann lediglich ein wenig träge, aber für den USB und Netzwerk Anschluss war das (selbst beim alten RPI) kein Problem.
    Aus meiner Sicht spricht also nichts dagegen den RPI als Server zu verwenden, sofern man nicht mehr als sechs (HD) Streams gleichzeitig über's Netzwerk befördern möchte, und das sollte in nem durchschnittlichen Haushalt doch nur sehr selten erforderlich sein. Und auch für ne direkt angeschlossene HDD hat der USB Port für diesen Anwendungszweck mehr als genug Performance. Wer will schon mehr als 10 Sendungen gleichzeitig (von zwei oder mehr DVB Sticks) aufnehmen und nebenbei auch noch diverse Streams übertragen.
    Das einzige was bisher dagegen gesprochen hatte, war der zu schwache Prozessor, und der sollte nun ja auch ausreichend Leistung haben.


    Claus

    MLD 5.5 mit vdr 2.6 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • clausmuus
    Ist ja beim Raspberry allgemein immer das Problem gewesen. Da wird immer und immer wieder rumzelebriert wie sch*** das Teil ist und was es alles nicht kann. Und dann liest man sich bissl durch was die Leute als alternative kaufen und 2 Monate später liest man dann das die Alternative im Schrank verstaubt weil keiner Bock hat für paar 100 Geräte was zu entwickeln.
    Außerdem liest man immer wieder das FullHD nicht geht und alles langsam ist etc. Da lob ich mir echt die Community die seit 2 Jahren da Vollgas dran ist und so extrem viel geschafft hat aus dem Platinchen das letzte Rauszuquetschen.


    Uwe thanks 4 Info. Gerade mal beide bestellt.. mal schauen ob ich sie nach Feierabend hab :)

  • Hallo,


    habe meinen gerade bekommen und schnell Debian Jessie gebootet. Die Werte von Golem kann ich bestätigen:


    iperf gibt 94.3 Mbits/sec aus, laut top bei 11% CPU-Last.


    Liebe Grüße
    Motz_e

    VDR-Clients:
    Raspbian Buster
    - vdr 2.4.1 - Raspberry PI 2B


    Home-Server:
    Debian Bookworm - vdr 2.6.0 (eTobi) - Kernel 6.1

    Asus Prime B360M-C - Pentium Gold G5400 - Mystique SaTiX-S2 Dual - Hauppauge WinTV-QuadHD

  • der Durchsatz ist wohl nur interessant wenn man den Pi auch als NAS nutzen will.
    Als Client sehe ich da auch keinen Grund warum es nicht reichen sollte. Hat bis jetzt auch immer gereicht.

  • Ich hab gerade Openelec mit VNSI ausprobiert und gerade beim Start und Kanal+EPG-Scan ist die Performance deutlich besser. Das geht fast so flott wie auf meinem normalen Rechner und das obwohl ichs jetzt nur übers Netz und nicht im Lokalen Lan ausprobiert hab. Schon mal vielversprechend.

  • Und auch für ne direkt angeschlossene HDD hat der USB Port für diesen Anwendungszweck mehr als genug Performance


    der alte RPI 1 hatte über USB Disk schon rund 20-23 MB/s , während auf Desktops in der Regel bei ca. 35MB/s über USB Schluss ist --> http://314256.blogspot.de/2014…disk-throughput-test.html


    Beim RPI 2 sollte sich der Wert auch noch etwas in Richtung 30MB/s bessern

  • Das Problem ist, meine ich, auch gar nicht so sehr der Netzwerk-Datendurchsatz. Ich habe mal eine über NFS eingebundene HD-Aufnahme wiedergegeben und nebenbei die CPU so richtig beschäftigt (VDR übersetzt, "ls -lR /usr" und dergleichen) und konnte nicht die geringsten Probleme bei der Wiedergabe beobachten. Schaue ich dagegen einen (HD)-Kanal live, so reicht oft der geringste anderweitige Netzwerk-Traffic aus um enorme Bild- und Tonstörungen zu verursachen. Das RTSP-Protokoll, das bei SAT>IP verwendet wird, ist halt ein ungesichertes Protokoll, das sich darauf verlässt, daß der Empfänger die Pakete schnell genug abholt und nichts verloren geht. Ich kenne zwar die genauen Details auch nicht, aber eventuell könnte hier mehr CPU-Leistung durchaus hilfreich sein...


    Klaus

  • Zitat

    Eine RTC wird den Raspberry nicht aufwecken


    mit dem ds1307 sicher nicht, der hat keine Alarm Register. Aber mit dem ds3231 --> http://www.dx.com/de/p/ds3231-…-5-5v-222910#.VNIl6CXMEWM


    könnte man sich was basteln. Unter RPI sollte das Modul laufen --> http://www.forum-raspberrypi.d…-i2c-frage-zum-ds3231-rtc


    über INT/SQW könnte man einen Pegel schalten --> http://forum.arduino.cc/index.php?topic=168421.0


    http://www.mikrocontroller.net/part/DS3231

  • Die Kritik zur "alten" GPU kann ich nicht nachvollziehen - die reicht völlig aus für alles was der VDR momentan verarbeiten kann. Ausserdem geht ein, meiner Meinung nach, wesentliches Detail oft vergessen:
    Zitat von »www.raspberrypi.org«
    Are you still using VideoCore?
    Yes. VideoCore IV 3d is the only publicly documented 3d graphics core for ARM-based SoCs, and we want to make Raspberry Pi more open over time, not less.
    Da mögen Mali & Co vielleicht besser sein, aber wer mag da schon ein natives Ausgabeplugin für den VDR entwickeln?


    Das denke ich eigentlich auch! Das 'Video-Frontend' ist so durchaus ausreichend (ah, hoert sich scheisse an, das Frontend ist fuer Video echt klasse!). Und jetzt gibts noch ne Menge mehr CPU Power. Also, was wollen wir denn mehr?


    Danke an die RaspPi Macher, dass sie den Kelch 'Kompatibilitaet' hochhalten. Das ist viel mehr Wert als 50% mehr CPU Leistung! Und das gilt nicht nur fuer die GPU, sondern auch fuer die GPIOs, Peripherieanschluesse, ...


  • Bitte nicht falsch verstehen - ich benutze softhddevice seit einiger Zeit auf meinem Wohnzimmer-VDR zur vollsten Zufriedenheit. Aber ich verstehe bis heute nicht, weshalb ich dazu den ganzen xorg-Karsumpel benötige. Mir sind die Abhängigkeiten von softhddevice irgendwie ein Dorn im Auge und für ein kleines ARM-System will ich auch was schlankes, so wie es beim Raspberry Pi möglich ist.


    Gut, ist auch ein Stück weit Geschmacksache. Aber ich mags halt schmal und schlank. ;)


    Gruss
    Thomas


    Der Usecase fuer Xorg ist halt wenn man auch andere Sachen als nur VDR oder XBMC machen will. Vor dem Projektor im Wohnzimmer, Funktastatur, Videobild auf Fenstergroesse, Browser auf, IMDB ueber den Film oder so (google maps, etc. pp), schell was shoppen...


    Das heisst natuerlich nicht, dass die Videoanwendung irgendwas von Fensterbetriebssystem/Xorg wissen sollte. Kenne mich aber nicht mit den verfuegbaren APIs gut genug aus, wie man das am einfachsten macht. Der omxplayer kann ja wohl die Moeglichkeit die Groesse des Bildes zu veraendern, da braeuchte man ja wohl "bloss" eine kleine Wrapper-app drumherum die ein Fenster macht und omxplayer reintut (oder fullscreen). So koennte ich mir das auch schoen fuer rpihddevice/VDR vorstellen.


    Habe bisher halt bloss Fernseher an den RPs dran, da ist das bisher nicht so aufgefallen, da hat man eher tablet/notebook mit dabei, weil man da auch den Bildschirm eher nur mit einer Person verwendet.

  • Das Problem ist, meine ich, auch gar nicht so sehr der Netzwerk-Datendurchsatz. Ich habe mal eine über NFS eingebundene HD-Aufnahme wiedergegeben und nebenbei die CPU so richtig beschäftigt (VDR übersetzt, "ls -lR /usr" und dergleichen) und konnte nicht die geringsten Probleme bei der Wiedergabe beobachten. Schaue ich dagegen einen (HD)-Kanal live, so reicht oft der geringste anderweitige Netzwerk-Traffic aus um enorme Bild- und Tonstörungen zu verursachen. Das RTSP-Protokoll, das bei SAT>IP verwendet wird, ist halt ein ungesichertes Protokoll, das sich darauf verlässt, daß der Empfänger die Pakete schnell genug abholt und nichts verloren geht. Ich kenne zwar die genauen Details auch nicht, aber eventuell könnte hier mehr CPU-Leistung durchaus hilfreich sein...


    Klaus

    Du hast Recht, die in SATIP 1.0 eingeflossenen Verbesserungen sollten eigentlich die CPU beim SATIP Empfang entlasten, das hat aber noch nicht richtig den Durchbruch gebracht. Ich habe noch eine Idee im Kopf, nämlich den SATIP eigenen Section Handler Thread zu eliminieren und damit einmal Ringbuffering der Daten einzusparen, muss aber sehen wann ich dazu komme.


    Ein anderes Phänomen das ich betrachte ist, dass ich (auf einer PC Hardware) immer wieder Paket-Fehler bekomme, ich vermute derzeit einen Zusammenhang mit dem Aufruf des record.sh Scripts (eine Aufnahme endet währen die andere läuft), weil da mit waitpid() der ganze Prozess angehalten wird und dann der SATIP Thread die UDP Pakete nicht mehr schnell genug vom Betriebssystem entgegen nehmen kann. Muss das aber nochmal verifizieren, wenn ich etwas Zeit habe.

  • Im Gegensatz zu dem ersten Modell damals, kann man das neue Modell nicht
    mehr bei RS als Privatkunde bestellen. Ich hab meinen bei Vesalia bestellt.
    Nur zur Info für diejenigen, die in Deutschland bestellen wollen.


    Der neue schlägt sich recht ordentlich. Die Kodi UI laggt nicht mehr so doll.
    Und das Beste: Ich kann nun ein echtes Debian armhf drauf installieren!
    Ich halt nicht soviel von den Fertigdistros für VDR oder Kodi. Da ist es immer
    so schwer, eigene Sachen nachzurüsten. Mache lieber mein eigenes Ding.

Jetzt mitmachen!

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