Beiträge von te36

Auf meinen RPIs mit rpihddevice funktioniert das screengrabbing prima. Wird dann verwendet fuer xxv und live, also die beiden Apps mit denen ich remote kontrolle vom VDR mache - um dort Vorschaubild zu sehen.

Allerdings: Ich setze ein angepasstes mplayer plugin ein, um im VDR nicht-VDR dateien abzuspielen. DIese plugin verwendet omxplayer auf dem RPI. Und solange das laeuft, sehe ich im Vorschaubild nur ein schwarzes bild. Was dann leider die remote-kontrolle/support erschwert.

Wie funktioniert da jetzt eigentlich das screen-grabbing. Ich nehme mal an, dass so eine App sich das irgendwie vom VDR holt (SVDRP ?) und der VDR sich das dann vom outdevicetreiber (rpihddevice). Richtig ? Und das pugin tapst dann ins dunkle, weil es nicht wirklich an den bildspeicher herankommt, der von der anderen App (omxplayer) geschrieben wurde ??

Bei der FF karte geht das alles ganz prima d.h. mplayer schreibt dabei ja wohl direkt die MPEG2 codierte Video + overlay auf die FF und VDR etc.. kann das resultierende Video von dort grabben.

Waere schick, wenn man das mit RPI auch hinbekommen wurde.

So aus neugier (habe nix im Einsatz). Wie sieht das mit softhddevice aus, so wie es ja wohl bei den meisten Leuten eingesetzt wird, Mali-400 oder NVidia - funktioniert da das screengrabbing wenn da nicht der VDR selbst das video decodiert ?

Danke!

was ist das problem, den streamdev-server auf 0.6.1. bringen wo das streamen von aufzeichnungen supported ist ?

2013

http://www.vdr-portal.de/board…v-streamen-von-aufnahmen/

Zitat

Auch ich habe die neuen Aufnahme-Streaming-Fähigkeiten des streamdev plugin jetzt entdeckt.
Ist ja nur im repository drin, in der letzten versionierten 0.6.0 noch nicht.

einfach auf 0.6.1. bringen ?

Mir hat hat vor allem das Manual von dem Motherboard den Rest gegeben. Auf den Bildern kann man sehen, dass die Entwickler Monate in die graphische Aufbereitung der GUI gesteckt haben, und aus dem Text wird dann klar, dass da dann kein Geld mehr war um vernuenftige Funtionialitaet reinzubringen oder die existierende Funktionalitaet sinnvoll zu erklaeren. Stattdessen die klassische zero-use self referential explanations:

"foobar: Enable foobar to enable the foobar function"

Erinnert mich an KODI. Da wird auch immer 90% auf GUI Arbeit verschwendet. Die dann am besten nochmal mit jeder Release neu gemacht werden muss. Und die Komplexitaet der GUI dient nur dazu die Entwicklung von echter Funktionalitaet zu erschweren. *motz* *mecker* *beschwer*

Eigentlich finde ich ASrock ja prima, hatte auch lange deren Motherboards gekauft, aber die sind ja wohl Sklaven ihrer Kunden. Naja, meine beiden letzten Motherboards waren ASrockRack. Leider teurer, aber gutes SnR.

Kommt immer auf den Anwendungsfall an. Fuer einen vollen Desktop hast Du sicher recht. So fuer embedded anwendungen, VDR client oder so ist es aber wohl keine schlechte Idee ?

klar, wenn ich denn mal zeit finde, mich mit der 2.3.1 zu beschaeftigen..

jgrete:

1. Was haengt denn da fuer ein monitor an der GT 730 dran ? Ich habe mit Projektoren und TVs schon haeufiger das Problem, dass die nicht alle Aufloesungen anzeigen koennen, und dann beim booten bild schwarz blieb, bis dann mal X open war und eine supported Aufloesung anzeigte. Ich glaube auch mich erinnern zu koennen, dass details der aufloesung auf die graphikkarte ankommen, also bloss weil man bootbild bei der onboard intel sieht heisst das nicht dass die GT 730 genau dieselben bildeinstellungen machen wuerde. Also am besten das ganze erst mal mit einem PC monitor ausprobieren statt mit TV oder projector.

2. Schliess mal keine SATA oder GT 730 an und versuch das system mit einem linux USB stick zu booten im default BIOS setup. Evtl. gucken dass der USB stick entweder GPT drauf hat (was UEFI ist), oder einfach ein ISO per dd drauf (CD-ROM kompatibel) Auch probieren, beim booten den boot-hotkey druecken um zur auswahl zu gelangen, da gibts bei BIOS'es haeufig verschiedene modi, wie ein USB angesprochen werden kann, ich hab nie versucht die zu verstehen, sondern bloss solange probiert bis ich eine option gefunden have die funktioniert.

3. Sobald Du da ein linux am laufen hast, die GT 730 reinstecken, aber nicht BIOS aendern, sondern bloss im linux per lspci gucken, dass die karte erkannt wird, evtl. auch mal xorg auf der karte starten (passende config setzen etc). Was dann erstmal sagt, dass die karte funktioniert.

4. Versuch mal rauszufinden ob deine GT 730 UEFI unterstuezt. Scheint vom verwendeten Chip oder wie alt die karte ist, abzuhaengen:
http://forums.evga.com/Do-they…0-and-GT740-m2200753.aspx. Wenn Die Karte UEFI kann, dann solltest Du da auch im BIOS output kriegen, indem du im BIOS bloss die booprio auf diese PCIe Karte setzt. Wenn die karte kein UEFI kann, dann musst Du dich mit CFM rumquaelen wenn Du beim booten BIOS output auf der GT730 willst.

5. Fuer die Beschreibung der "OpROM Policy" im Handbuch hat sich ASrock Waterboarding verdient. Ich habe keine Ahnung was das heissen soll. Da wird ja noch nicht mal die "do not launch" option erwaehnt die du beschreibst. Frage mich was der Unterschied zwischen "do not launch" und "UEFI Only" sein soll. Die hoffnung ware ja, dass "do not launch meint, dass sowohl UEFI also auch legacy BIOS devices "gebootet" werden sollen. Das macht verbal aber auch wenig sinn.

6. Du hast nicht beschrieben, ob Du im Szenario 1 BIOS ausgabe bekommst.

Zitat von Argus

für ARM Hardware hätte ich auch nicht den Port Multiplier empfohlen. Die Port Multiplier Funktionalität ist vom Chipstatz auf Hardwareebene und Treiberunterstützung auf Softwareebene abhängig. Und gerade bei ARM hängt dort noch einiges hinter den PC Architekturen hinterher. Einige Kernelversionen unterstützen es gar nicht und andere nur so lala.

Jo, gibt ja auch nicht so viele SBCs mit SATA. Aber fuer den banana-pi gabs dann halt fertige distributionen, womit das ging. Allerdings hatte ich erst mal probiert, aehnlich wie Du, das Raid case bloss mit PMP am VDR Server PC anzuschliessen (x86), und da gab es dann halt noch mehr treiberprobleme. Habe immer noch von jemandem einen patch fuer den Kerneltreiber rumliegen, der immer noch nicht im aktuellen Linux Kernel ist. Und ich auch mich zu erinnern, dass bei meinem gelese durch foren herauskam, das SATA via PMP prinzipbedingt weniger zuverlaessig in Fehlersituationen ist als ohne PMP, frag mich aber nicht mehr nach Details.

Zitat von Argus

Ich habe per Port-Multplier mir so ein externes Case gebaut --> http://www.fdm-ware.de/SATA/index.html

Genial. Link das doch mal auf Kls' page mit der liste von gebastelter Hardware. Kann man bei Dir hardwareumbauten bestellen ? ;-)). HW maessig habe ich es bloss geschafft, ein schickes externes RAID gehaeuse umzuruesten. Hatte ich mir mal vor 12 Jahren gekauft mit 5 * 80 GByte platten, optisch passend zu einem Mac Cube. Und dann halt mal ATA cage gegen SATA ausgetauscht und platten auf 8TB aufgeruestet. Leider keine Bilder parat. Gehaeuse gibts immer noch, aber halt nicht mehr im schoenen silver/beige/transarent-acryllic, sondern nur noch in schwarz: http://www.servercase.com/Merchant2/merchant.mvc?Screen=PROD&Product_Code=ULTRA-P5-U320&Category_Code=SCA%2FSAS

[quote='Argus','index.php?page=Thread&postID=1282886#post1282886']
Mit dem bin ich soweit zufrieden. Sogar "hotplugging" also Platten im laufenden Betrieb zuschalten funktioniert problemlos. Dort ist es aber ein anderer Chipsatz und bei Intel Chipsätzen fehlt meist die Portmultiplier Funktionalität, sodass nur ein Gerät erkannt wird. Da muss man für seine HW vorher genau recherchieren.

Jo. Oder (siehe oben) selbst rumpatchen am kernel. Schade das es keine SBCs mit N*SATA gibt damit man sich noch einfacher kleine NAS bauen kann.

Mit port multipliers waere ich extrem vorsichtig, aka: waere fuer mich bloss eine Option wenn alle anderen nicht gehen.
Habe mit einen Banana-PI und einem 5-port port-multiplier und einem SATA gehaeuse ein NAS gebaut - und da haette halt nix
groesseres reingepasst also SBC und PMP, also keine Option. Tut im prinzip auch, aber immer wenn es schwierigkeiten beim
zugriff auf eine platte gibt, eg: I/O reset einer platte oder so (wenn man eine platte rausnimmt und eine andere reintut),
dann ist meistens ein reboot notewendig, weil der SATA treiber durch den PMP hindurch nicht mehr korrekt mit den anderen Platten reden kann.
Denke mal, bei einem DVD laufwerk kann das bei medienwechsel auch passieren (keine erfahrung, nur vermutung). Ach ja, und es
sind natuerlich nicht immer die SATA treiber mit support fuer PMP compiliert/im-kernel, und einige SATA treiber unterstuetzen
PNP ueberhaupt nicht.

Schade dass es keine echten Busoptionen mehr gibt wie seinerzeit SCSI.

Hehe, die werbeaussage fuer die Intel CPU motherboards mit 48 * SD video streams (surveillance) in parallel sind schon verlockend: http://asrock.com/mb/Intel/J3455M/

Ich will ja nicht 48 Ueberwachungskameras, aber mit den 4 Tunern in meinem VDR koennte ich eigentlich 16 sinnvolle SD Kanaele (das SD-GEMA buoquet auf einem 4K Display gleichzeitig darstellen. Dass waere schon witzig, und vielleicht sogar nuetzlich. Mal ein anderer Grund auf 4K aufzuruesten, gerade bei einem Projektor (wo man genug sichtbare Flaeche fuer die volle 4K Aufloesung hat). Gibt aber ja wohl bloss keine GUI fuer Darstellung mehrerer Bider im Raster, oder ? Denke nicht das bei VDR oder KODI gesehen zu haben. Wahrscheinlich am einfachsten mit einer Surveillance App der man die "Kameras" mit streamdev URLs konfiguriert.

Aber Spass beiseite, auf dem VA-API thread ([Announce] VA-API/VPP Patch for vdr-plugin-softhddevice - updated "v9") ist ja nicht viel los, befuerchte mal, das man mit Intel GPU nicht so leicht ein problemloses VDR hinbekommt als wie mit NVidia. Fuer Mobos in "normalen" PCs stoert das ja nicht, kann man ja immer NVidia nachruesten. Aber so fuer NUC waers toll. Gerade die Beebox sieht guenstig/interessant aus.

Tscha, eigentlich war ich ja fan davon, dass der client moeglichst standalone ist, also dachte ich daran, die SD readonly zu machen, so dass ich dann so einen client auch schoen per ssh troubleshooten kann, selbst wenn mal irgendwas mit dem server/netz/svdrp/etc schief geht.

Jetzt lese ich aber gerade den thread zum VDR 2.3.1 wo ja wohl vieles fuer multi-VDR installationen vereinfacht wird, aber wie praktiziert man den umstieg von 2.2.x auf 2.3.x in einem multi-VDR produktivsystem mit hohen WAF requirements ?

Bei mir ist es halt ein zentraler VDR server, der auf verschiedenen Boot-partitionen verschiedene VDR versionen hat. Damit kann man immer sehr schoen per chroot an der naechsten Linux/VDR/etc. version arbeiten, oder dann schnell wieder die "alte" Version booten, wenn dann doch unerwarteterweise nach einem Monat mit einer neuen Installation dort ein Problem auftaucht, etc. pp . Ja klar, mehrere Server-PCs (neu/alt) waere prima, aber dafuer muss ich erstmal meine DVB-S2 tuner und LNBs amortisiert haben und auf SAT-IP umsteigen, ansonsten geht das nicht wirklich.

Aber zurueck zum client: Gemischter 2.2.x und 2.3.x Betrieb wird da nicht viel Spass machen, und auch nicht erlauben, die Vorteile von 2.3.x richtig auszufahren. Also will man eigentlich eine einfache Moeglichkeit ahben, das komplette System zwischen 2.2.x und 2.3.x hin und her zu schalten. Auf dem Server ist das ein reboot mit anderer Rootpartition (aufzeichnungen usw sind auf einer separaten partition). Aber wie sieht's mit den ganzen RPI's im Haus aus ?

Antwort: wenn die RPIs ihre VDR installation aktiv ueber netboot vom server laden, dann geht das ganz einfach. Einfach die RPIs rebooten wenn man den Server rebootet hat. AM besten automatisiert. Und jede VDR server installation hat ihre eigene passende, NFS exportierte rootdirectory fuer die clients.

Und mit cross-compile umgebung auf dem server hat man auch die einfachere moeglichkeit die RPI installationen zentral schnell u patchen.

Vielen Dank fuer die intensive Arbeit.

Was evtl. sinnvoll waere, waere es eine wiki Seite zu haben fuer 2.3.1, wo man kollaborativ mal reinschreiben koennte, was mit 2.3.1 dann wirklich fuer den Benutzer besser wird, weil die Release notes ja bloss die technischen Details drinstehen, die man aber als Benutzer evtl garnicht verstehen will.

Eg: Wenn ich das so lese, dann scheint es leichter & besser zu werden, mehrere VDRs miteinander zu verbinden, eg: client-server VDR. Ich habe z.b. RPI als VDR/streamdev clients mit all den patches und plugins (wie wir das im wiki fuer 2.2 beschrieben haben), damit solche clients alle einen gemeinsamen VDR server verwenden (tuner, programmierungen, aufzeichnungen).

Fuer den Benutzer mit mehrern Clients wird die Erfahrung besser, weil man ja wohl keine Aussetzer mehr bei Menus kriegt die derzeit bei gleichzeitiger Nutzun wegen SVDRP single-instance auftauchen. Das ist super. Ist ja echt ein rattenschwanz von code der dafuer geschrievben werden musste (per-client SVDRP, locking, etc. pp). Respekt.

Fuer den Entwickler ist mir nicht so ganz klar, welche wenn nicht alle der plugins/patches fuer solche Clients jetzt im 2.3.1 standard oder unnoetig sind.

Ansonsten: 24 FPS autodetection. Super, aber so als Benutzer wuerde ich gerne mal ein Beispiel wissen, wo es denn schon 24p zu sehen gibt.

Ok, komme jetzt erst dazu mir die release notes vom 2.3.1 anzuschauen. Da komme ich jetzt nicht drum herum erstmal diese polemische Email zu verfassen wegen

- The dvbsddevice and rcu plugins are no longer part of the VDR source archive. You can get the latest versions of these plugins from ftp://ftp.tvdr.de/vdr/Plugins.

Tscha. Ich kann es ja verstehen, aber es macht schon echt melancholisch. Die FF Karte war DIE originale Hardware fuer den VDR. Ohne sie haette es VDR nie oder nur viel spaeter gegeben. Also wahrscheinlich erst ca. nach dem grossen Finanzdebakel von 2008 statt in all den gluecklichen Vorkriegsjahren *sob*.

Ja, ok, die FF wurde schon im 2.x ein wenig stiefmuetterlich behandelt, aber sie jetzt so sang und klanglos ins Repository Altersheim abzuschieben ist schon ein wenig unwuerdig. Vor allem weil man sich bei all den API changes leicht ausrechnen kann, wann Oma's herzschrittmacher nicht mehr mit den neuen VDR Versionen mitkommt. Ein kleiner Sektempfang haette da schon sein koennen.

Ich habe immer noch eine FF produktiv im EInsatz (und eine im Schrank als HW Ersatz ;-). Ok. mehr als Backuploesung fuer die neueren Optionen, RPI und KODI, gibt aber immer noch details, die in der FF GUI vom VDR besser gehen als in den neueren Alternativen (image plugin z.b. ;-).

Vielleicht mal so als Anregung: http://www.tvdr.de/hardware.htm anpassen und vielleicht mal eine history.htm Seite basteln, wo die zeitliche Entwicklung von VDR inklusive der wichtigsten historischen Hardwarekomponenten gewuerdigt werden.

Die ASrock NUCs sind nochmal billiger:

https://www.reichelt.de/?ARTICLE=157023&PROVID=2773&psuma=Geizhals

und kommen direkt mit IR receiver eingebaut und Fernbedienung.

Am besten mal von der CLI mit tools wie mediainfo, ffprobe oder ffplay/mplayer anschauen/abspielen, die sagen dir, was fuer ein aspect ratio am anfang des files ist. Und mplayer sagts dir auch im Verlauf der Aufnahme, wenn dort AR changes sind.

Wenn das dann wirklich 16:9 ist aber eigentlich 4:3 sein sollte, dann Dateien fixen oder mit was abpielen womit man AR aendern kann.
- Kenne keinen file fix der ohne re-encoding geht, d.h. diese option ist am besten, wenn man die dateien eh platzsparender archivieren will.
- AR anpassung via VDR plugin fand ich immer pfriemelig und instabil. Hatte ich allerdings auch bloss mit FF ausgabe ausprobiert, und die wird in 2.x sowieso hmmm "altersdiskriminierend" ? behandelt , habe lso nicht soviel Erfahrungswerte. Kodi und andere Medienplayer machen es einfach, aber wenn diese Dateien selten geschaut werden, einfachm im Fernseher-Menu. Eigentlich sollte sowas wie Softhddevice sowas auch koennen, ich verwende das aber nicht, deswegen k.A.

Wenn die dateien im Tool zeigen, dass sie 4:3 sind, dann ist das ein abspielproblem im VDR. Weiss nicht, ob das noch jemand loesen will, ist wahrscheinlich auch dann sinnvoller, das nach VDR2.x kompatiblen TS dateien umzuwandeln.

Die Skripten um das zu machen scheinen archivieren zu wollen == weniger qualitaet. Auf jeden Fall lange die Ergebnisse anschauen, bevor man sich dafuer entscheidet, das bei allem alten VDR material zu machen. Und interlaced und non-interlaced resultate anschauen. Ich hadere noch mit meiner H.264 archivierung. Ich mache bloss seit 8 Jahren DIVX/"MPEG4" archivierung, da hatte ich auch lange nach Parametern geschaut mit denen ich dann zufrieden war.

Ansonsten mal einfach die Dateien verlustfrei von MPEG2 PS (VDR) nach MPEG2 TS (VDR 2.x) umwandeln. Das kostet halt nochmal 10% mehr platz, aber man muss nicht ueber qualitaet oder sonstige Verluste nachdenken. Eg: "ffmpeg -i 001.vdr -map 0 -c copy 001.ts". Dabei sollte alles vom originalen encoding erhalten bleiben, inklusive aller aspect ratio details. Musst natuerlich auch per script die namen der metadateien und directory anpassen, so wie das archivierungsscript das auch macht, also evtl. die ffmpeg konvertierung bloss als verlustfreie option reinhacken, falls das nicht eh schon drin ist.

Hast Du kontrolliert das da wirklich die Tasten nicht gehen ? Eg: vor (Smartphone) Kamera gehalten und gesehen dass beim druecken anderer Tasten die IR LED aufleuchtet, aber beim druecken der Farbtasten nicht ?

Wenn neue, einfache Remote gebraucht wird empfehle ich die URC6440, siehe http://www.vdr-wiki.de/wiki/in…enung_-_OneForAll_URC6440. Leicht erhaeltlich, guenstic, programmierbar, laeuft bei mir mit dem RPI IR bastelempfaenger vom wiki, MCE empfaenger, Streamzap empfaenger und fernseher+CEC+Kodi etc. Einziges Problem ist das eine der URC6440 die ich habe ca. einmal im Jahr die Programmierung vergessen hat. Kann man aber leicht fixen, weil man die Programmierung einfach per USB sichern und restaurieren kann.

Danke fuer die SD details.

Besteht dann Deiner Meinung nach ein Problem wenn man den RPI mit SD ReadOnly betreibt, aber da den Strom unerwartet im Betrieb abschaltet ohne runterzufahren, eg: wenn da gerade was von SD gelesen wird ? Eg: wenn mann den RPI nur vom Strom des Fernsehers betreibt und den halt einfach abaschaltet ? Habe leider noch nix gefunden wie ich da dem RPI eine dying gasp warnung geben kann so dass er dann evtl. rechtzeit ein reset oder so macht.

Transcoding koennte man evtl. auch CPU-sparend mit der GPU machen, das war bei mir noch nicht auf dem Radar als ich meine MBs aufgeruestet habe. Mit so einer 1050 sollte das ja wohl gehen. Leider keine Erfahrung. Wuerde aber die billigen Q1900M o.aeh. MBs interessanter machen wenns gut geht.

Das DVD scheint ja zu existieren, also USB 2.0 auf SATA adapter. Gibt halt nie welche die gleich den internen USB header dran haben, also muss man da kabelmaessig rumbasteln.

Kann man bei dem Gehaeuse nicht noch ein 2tes 3.5" Laufwerk mit Wechselramen einbauen ? So fuer Sicherung oder Aufzeichnungsarchiv. Dann wuerde sich auf jeden fall eine 2* SATA PCIe Karte anbieten. 1*SATA PCIe habe ich auch noch nie gesehen.

Kann keine bestimmte PCIe karte empfehlen, hatte in der Vergangenheit immer Zuverlaessigkeits/Treiberprobleme mit PCI/PCIe add-on SATA, aber das war auch wohl ein Linux-Kernelproblem und immer nur mit Festplatten, nie mit dem DVD-Laufwerk. Einfach ausprobieren und im schlimmsten Fall zurueckschicken/durchprobieren. Oder halt USB adapter kabel gebastel.2xSATA scheint ja Standard auf den MBs mit fester CPU zu sein.

Da geht man dann zum ersten posting im Thread und aendert das Subject to [Geloest] ...
Oder wenn man es ehrlicher mag [Gelöst] .... [Anfängerfehler ]

Hilft aber, da kann man viel einfacher nach Lösungen suchen im Forum Archiv.