Wie gesagt, ich würde es wohl mit Tanix TX6 probieren. Hat aber auch nur 100M. Nicht zu verwechseln mit TX6S, der hat den H616, der ist noch nicht unterstützt.
Links habe ich keine, die darfst du dir selber suchen. Ich habe z.B. den OrangePi One Plus (H6), den finde ich online noch. Ansonsten musst du einfach mal suchen gehen und schauen was es wo überhaupt noch gibt und ob es das hat, was du haben willst. Wichtig ist nur H3, H5 oder H6.
Wenn dir 100er LAN reicht, ja.
Hardware unterstützt von softhddevice-drm
Bei mir läuft produktiv ein OrangePi Plus (H3). Ohne großen Aufwand sollten alle Boards mit H3, H5 oder H6 gehen.
Am wichtigsten ist die (mainline) Kernel Unterstützung.
Mit einem Board aus dieser Auswahl machst du auch nichts verkehrt. Wenn ich nicht schon genügend hätte, würde ich mich nach was mit Gehäuse umsehen, z.b. Beelink oder Tanix.
Gruß
Andreas
Mit
habe ich jetzt folgendes:
und
Wenn ich es richtig erkenne, wird der CMA reserviert und durch no-map nicht für das System zur Verfügung gestellt. Den Speicher direkt mit memory-region der VE zuzuweisen hat zu "[ 33.085565] cedrus 1c0e000.video-codec: failed to get scatterlist from DMA API" Fehlern geführt. Da habe ich noch keine Lösung.
Mal sehen, ob das schon ausgereicht hat, ich versuch das am Abend mal.
Gruß
Andreas
Solange es jemanden gibt, der ihn aufgreift, wäre das schon auch ok. Und dass meine "Wunschvorstellung" schwierig bis gar nicht umzusetzen ist oder Optimierungsbedarf besteht, wie man es am besten macht, ist mir auch klar. Am Ende wird es eh an der Manpower scheitern. So oder so. Und nicht, dass mich jemand falsch versteht - ich persönlich kann damit leben, wie es jetzt ist. Die "Wunschvorstellung" in die Praxis umzusetzen ist mit sehr hohem Aufwand verbunden, der es wahrscheinlich nicht wert ist - es geht ja auch anders. Irgendwie 
Klar, der Pull-Request macht auch nur Sinn, wenn es was zu diskutieren gibt und auch mindestens einen zweiten gibt, der das auch anschaut. Für ein diff, bei dem entweder alles klar ist oder eh niemand drüberschaut, ist ein pull request auch übertrieben. Ich mache bei meinen eigenen Commits auch keinen PR vorher, wenn niemand sonst beteiligt ist. Wichtig ist nur, dass das diff es halt irgendwie in den Code schafft und nicht im Forum auf die Rente hofft.
@ 2) Wenn jemand beisteuern will, MUSS er sich einen fork ziehen und einen PR stellen,
Das wäre wohl der Ende der Mitarbeit so mancher hier. git eine echte Hürde.
Möglich. Es kann aber auch eine Chance sein. Möchte sich jemand outen, für den git ein absolutes No-Go wäre? git funktioniert nur, solange jemand damit arbeiten möchte.... und git löst nicht das Problem, dass überhaupt jemand daran arbeiten möchte.
@ 6) der Code steht unter der AGPLWohl der absolut wenigste code hier.
GPL: If you publish the software, you have to do the same for the source code of it and any library that it borrows functions from.AGPL: If your software gives service online, you have to publish the source code of it and any library that it borrows functions from.
Richtig, Fehler von mir.
Erstmal zu git...
Wenn man mal das Wichtigste verinnerlicht hat, funktioniert git super.
Mit "git add ." "git add -p" "git commit" "git rebase -i" "git reset" "git push" "git pull" kommt man schon recht weit.
Und die ausgefalleren Sachen, und wenns bloß darum geht, einzelne Änderungen wieder in die Staging Area zu setzen, muss ich auch immer wieder googlen, da würde in der Tat ein kleines privates cheatsheet helfen ...
Ich möchte git nicht mehr missen und wenn man sich bei der Zusammenarbeit mit anderen an ein paar Regeln hält, funktioniert auch das. Was mal in einen Hauptbranch/master gepusht wurde, bleibt da. Ein Rebase erzeugt da nur Chaos und Ärger bei denen, die schon gepullt haben. Das wäre aber auch schon die wichtigste Regel...
Und jetzt meine Meinung zur Gesamtsituation ... 
Ich sehe das Grundproblem nicht bei Git oder nicht-Git. VDR bzw. eigentlich seine Plugins haben einfach das grundlegende Problem, dass die Hierarchie fehlt, die es bei größeren Projekten (libreelec, mesa, kernel etc.) gibt. Maintainer und Reviewer. Und es fehlen klare Regeln, an die sich jeder halten MUSS. Ohne die funktioniert es nicht und es bleibt beim Chaos, dass man den richtigen fork und die patches nicht mehr findet. Jetzt bin ich wirklich auch lange dabei. Überwiegend als Nutzer, aber auch hier und da mal mit etwas Code und wage zu behaupten, dass ich Linux, VDR und C einigermaßen gut verstanden habe. Aber auch ich tat mich vor einigen Monaten beim Wiedereinstieg schwer, mir erstmal einen Überblick zu verschaffen, was gerade so Sache ist. Da liest man einige Threads hier durch und kann sich auch nicht sicher sein, ob das, was im Wiki steht, noch aktuell ist.
Die angesprochenen Regeln würde ich folgendermaßen definieren:
/* Wunschvorstellung an */
1) Es MUSS eine zentrale Stelle geben, an der sämtlicher VDR Code zu finden ist, z.B. https://github.com/vdr-projects
2) Es gibt keine Mirrors dort, sondern ALLE Plugins, zu denen wer-auch-immer noch beisteuert, liegen dort im Original und die Leute, die sich drum kümmern haben commit Rechte. Das Plugin MUSS dort sein Hauptrepository haben. Wenn jemand beisteuern will, MUSS er sich einen fork ziehen und einen PR stellen, oder er findet jemanden, dem er seinen Patch schickt, der halt dann den PR stellt. Patches hier ins Forum zu stellen ist ja schön, bringt aber m.E. gar nichts, wenn man sich nicht gerade mit dem Thema beschäftigt. Ein Issue auf Github mit dem Patch wäre schon besser, als hier im Forum versteckt. Dann wäre er zumindest schon mal in der richtigen Gegend. Der Riesenvorteil von git, den ich sehr schätze, ist, dass man einen PR reviewen, testen und kommentieren kann. Man kann ihn verändern lassen und wenn man dann zufrieden ist und er auch wirklich läuft, wird er eingecheckt. Die Diskussion könnte zwar hier im Forum auch stattfinden, aber das ist nicht wirklich komfortabel. Klar, damit das alles klappt, brauchts erstmal Leute, die sich kümmern. Das Hauptproblem an sich.
3) Plugins, die nicht mehr gepflegt werden, offensichtlich nicht genutzt werden, oder evtl. gar nicht mehr laufen, MÜSSEN entfernt werden. Ich wäre da rigoros. Wenn jemand etwas vermisst, meldet er sich schon. Oder er legt selbst Hand an und reaktiviert das Plugin. Ich weiß auch, dass die Hemmschwelle dafür ziemlich hoch ist und vielen das Know-How fehlt oder sie nicht bereit sind oder die Zeit haben, sich das nötige Wissen anzueignen. Jammern lasse ich aber nicht gelten. Jeder hat mal angefangen. Ein Plugin, das nur einer nutzt, kann so wichtig nicht sein. Und wenn es mehrere am laufen haben wollen, steigt ja theoretisch die Chance, dass einer dabei ist, der gewillt ist. Ansonsten kann er ja auch betteln gehen. Dafür braucht er eine Anlaufstelle, wobei wir indirekt beim nächsten Punkt wären.
4) Das Wiki ist schön und gut aber man kann sich nicht sicher sein, ob da alles stimmt. Also ist es defacto unbrauchbar. Als Beispiel, ich war dabei, als linux-sunxi.org erstellt wurde. Da gab es zwar harte Regeln für alle, die sich einbringen wollten oder Hilfe benötigten, aber am Anfang hat das richtig gut geklappt und das wiki war in Top Zustand. Mittlerweile verwässert alles, viele Seiten sind outdated. Liegt daran, dass das Wiki gewachsen ist, die Disziplin nachlässt und schlichtweg die Motivation und Zeit der "Maintainer" fehlt, da mal wieder aufzuräumen. Die sunxis laufen mittlerweile einfach, ohne dass man notwendigerweise dem Wiki beisteuert. Aber ich behaupte mal, dass es die mainline kernel Unterstützung ohne dieses Wiki und dessen Disziplin nie gegeben hätte. Aber das nur so am Rande. Was bleibt als Anlaufstelle?
5) Das Forum. Ich persönlich schätze es sehr. Alleine schon wegen des Umgangstons miteinander. Das war zu Zeiten von linvdr teilweise noch anders Jeder bekommt hier Hilfe, sofern man auch etwas Eigeninitiative erkennen kann. Und sei es nur, dass ein Log gepostet wird.
Im Forum MUSS aber klar ersichtlich bzw. schnell zu finden sein, wo man aktuelle Plugins findet bzw. wo es eine aktuelle Liste (z.B. https://vdr-projects.github.io/) gibt und wie eigentlich die Regeln so sind...
6) Jeder hält sich an diese Regeln. Wäre schön, aber wird schwierig. Alle? verbliebenen Entwicklern kümmern sich um VDR in der Freizeit, der Code steht unter der AGPL, warum soll sich also jemand in ein "Korsett" zwingen lassen? Ich stelle aber mal die Behauptung auf, dass es für die Zukunft von VDR besser wäre, sich selbst ein Korsett zu verpassen. Und nein, ich sehe das Ende von VDR noch nicht am Horizont. Ich bin einer, der VDR nachwievor für lineares Fernsehen und als Videorekorder nutzt.
/* Wunschvorstellung aus */
Ein Beispiel zum Schluß: softhd*
Hier wurde damals leider eine klare Übergabe/Übernahme der Originalversion versäumt, so dass es mittlerweile 3,5? Forks gibt. Es gibt auch mindestens 4 Personen, die sich aktiv damit beschäftigen. Sicher ist jeder Fork für sich eine Bereicherung, aber schöner wäre es natürlich gewesen, alles in einem einzigen Plugin zu haben, was sicher möglich gewesen wäre, da sich einiges überschneidet und wofür git bzw. github o.ä. die richtige Wahl gewesen wäre. Aber leider ist es dafür zu spät, der Aufwand ist wohl zu groß. Wie alles andere, was ich geschrieben habe, soll das natürlich keine Kritik sein.
Fazit:
Für ein Fazit reicht es nicht mehr Ich hab auch keines. Auch keine Lösung. Ich möchte mich aber auch nicht beschweren. Bei mir funktioniert alles was ich nutze (softhddevice, streamdev, epgsearch, live, markad, tvguideng, skindesigner). Und diese 7 Plugins kann ich mir auch zusammensuchen oder patche selbst...
Gruß
Andreas
PS: Nachdem ich nochmal durchgelesen habe, was ich geschrieben habe, muss ich gestehen, dass ich mich bis jetzt selbst auch nicht immer an diese "Regeln" gehalten habe
Da ist mal was zum lesen:
Ok. D.h. wir haben die Situation Seite 6 mittlere Grafik. Der Speicherbereich für unser Multimedia liegt "dynamisch" im reservierten CMA-Bereich und kann auch von anderen Nutzern belegt werden, falls softhddevice das nicht tut. Wenn man davon keinen ausreichenden großen zusammenhängenden Bereich mehr frei hat, bekommt softhddevice ein Problem.
Wenn man über das dts für den Decoder entsprechend CMA reserviert, sollte der Speicher "theoretisch" von niemand anderem benutzt werden dürfen und wir wären auf Seite 6 untere Grafik.
Soweit so gut. Das erklärt, warum es krachen kann. Aber es erklärt nicht mein Problem mit dem ausgehenden Speicher aus Post #41, oder? Kann das noch jemand reproduzieren?
Ich glaube, ich werde dann jetzt doch mal CMA für die VPU über das dts reservieren und schauen, was das bewirkt.
Weiteres Problem:
Gestern hatte ich das erste Mal das Problem, dass im laufenden Betrieb ein altes Frame "mitgeflackert" ist. Beim Umschalten war das dann wieder weg. Ich weiß nicht, ob ich was besonderes gemacht habe und konnte das bisher nur beobachten, wenn ich eine Aufnahme bearbeitet habe und diese verlasse.
Kann das auch jemand bestätigen? JoeBar hast du da noch was rausgefunden?
Ich versuche in den nächsten Tagen mal hier weiterzukommen. Sonst läufts eigentlich ganz gut. Auch mit 2.5.4 jetzt.
Gruß
Andreas
Funktioniert, wenn man nach dem Einstellen mit der roten Taste die Hintergründe einmal durchschaltet.
So ich habe den Fehler nun gefixt. War ein Fehler im openglosd.
Ich hoffe es hat nun keine Seiteneffekte auf andere Skins.
mfg
jojo61
Wunderbar, danke. Habs in mein sofhddevice-drm übernommen und jetzt klappts. War wohl schon immer falsch in den GL Varianten...
Mit oder ohne GL Unterstützung?
das sich die Ausgabeplugins unterschiedlich verhalten, habe ich an den VDR-Maintainer gemeldet und warte auf die Rückmeldung, wie es eigentlich wirklich sein sollte.
Ich meine, das ist eigentlich klar.
charBm.DrawRectangle -> http://git.tvdr.de/?p=vdr.git;…defe9a2b43ca;hb=HEAD#l248
charBm.DrawText -> http://git.tvdr.de/?p=vdr.git;…defe9a2b43ca;hb=HEAD#l242
osd->DrawBitmap -> http://git.tvdr.de/?p=vdr.git;…defe9a2b43ca;hb=HEAD#l902
charBm ist ein neues Bitmap mit entsprechendem Hintergrund und das wird dann mit dem alpha Wert wird ins OSD geblendet. charBm ist an sich richtig.
Wenn der Bereich aber im OSD jetzt bereits belegt ist, wird über die alten Pixel geblendet. Bei schwarzem Hintergrund fällt das nicht auf.
Bei mir läuft: vdr-softhddevice-1.1.0 (https://github.com/ua0lnj/vdr-plugin-softhddevice)
und das kann übrigens auch "cuvid" (ich habe hier Intel VA-API im Einsatz).
Mit oder ohne GL Unterstützung?
https://github.com/ua0lnj/vdr-plugin-softhddevice/blob/vdpau%2Bvaapi%2Bcuvid/Makefile#L23
https://github.com/ua0lnj/vdr-…aapi%2Bcuvid/Makefile#L45
Ich würde meine Zeilen eher als Workaround sehen, da kann man schon noch optimieren.
Lese ich es richtig, dass die Zeichen alle mit DrawPixel gezeichnet werden?
^ Sry, nein. Mit DrawText.
sind die Message-Boxen (z.B. Kanalwechsel), die so auftauchen können, vom Hintergrund OK und was passiert, wenn die wieder verschwinden...sind da auch noch alte Textfragmente sichtbar oder ist der Bereich, in dem die Message-Box gezeichnet wurde, nach dem Verschwinden anders wie der Rest?
Wie kann ich die Message-Boxen denn einblenden? Ich habe es nicht geschafft, außer dem osdteletext was anzeigen zu lassen. Und es ist tatsächlich so, dass jedesmal eine neue Seite mit dem Alpha über alles alte geblendet wird, was dann natürlich im Wirrwarr endet...
Wenn sich an einer Seite was ändert, wird dann die Seite komplett mit allen Bereichen neu gezeichnet, oder nur die "dreckigen" Bereiche?
Ich stelle mir das so vor, dass jedesmal, wenn in einen Bereich etwas gezeichnet wird, für diesen Bereich erstmal alles gelöscht wird. Am besten wohl mit ->DrawRectangle in einer Funktion ählich ->CleanDisplay. Falls alles neu gezeichnet wird, würde wohl ein CleanDisplay reichen. Ich meine, so wäre es sauber, da ich nicht glaube, dass eine "Überblendfunktion" im Teletext Sinn macht?!
Allerdings frage ich mich, warum sich deine Ausgabeplugins da da anders verhalten. Nutzt du das softhddevice mit GL?
Ohne deinen Code ganz verstanden zu haben, tut es hier und hier möglicherweise auch schon ein
EDIT: Wenn das funktionieren sollte, ist es aber sicher nicht die performanteste Lösung
Gruß
Andreas
...dann wäre die Frage, welche OSD-Implementierung denn nach Vorgabe funktioniert bei Drübermalen von Bitmaps mit Alpha-Kanal.
Die original Software Implementierung von VDR?
Wenn du mehrere ->DrawBitmap in ein OSD, sprich auf pixmap[0] machst, ohne das OSD dazwischen zu löschen, sollten sich die Draws mit dem jeweiligen Alpha entsprechend überlagern. Das Foto sieht danach aus. Wird das OSD oder die pixmap irgendwann gelöscht, ausser, wenn osdteletext geschlossen wird?
Korrigiert mich, wenn ich mich irre, aber nur eine Vermutung ins Blaue:
Die OpenGL Implementierungen rendern auf Pixmaps und kombinieren diese dann in ein OSD. Dieser OSD-Buffer wird vor jedem "zusammenrendern" gelöscht.
odsteletext nutzt http://git.tvdr.de/?p=vdr.git;…06054bad2a2;hb=HEAD#l2109 und rendert über Umwege auf pixmap[0]. Meiner Meinung muss irgendwer diese pixmap löschen, bevor die Zeichen einer neuen Seite darauf gerendert werden.
Evtl. verhalten sich da OpenGL und Software Implementierungen anders. Funktioniert es denn bei jemandem mit OpenGL, von welchem softhd* auch immer?
Gruß
Andreas
Das könnte ein Problem von softhdcuvid sein. Das hatte ich aber mal behoben, welche Version nutzt du denn ?
Kannst du sagen, wie? Ich habe mit softhddevice-drm und OpenGL das gleiche Problem.
Danke Andreas
Kann es sein, dass markad immer nach /usr/bin installiert wird? Selbst übersetzte Programme habe ich lieber in /usr/local.
Ich habs dann verschoben, aber ich fände es gut, wenn man es mit dem Standard “--prefix“ mitgeben könnte... Oder hab ich was übersehen? Ansonsten klappt das richtig gut!
Gruß
Andreas
