Bitte ignorieren das ein Abschnitt im Text gestrichen ist. Das ist ein Bug im Wiki-Generator den ich noch fixen muss.
Dann ist da aber auch kein VDR auf diesem "Moi Pro". Diese Software gibt es nur für Linux.
Es geht in dem Fall nicht um ein Slotblech sondern um eine Cine S2 mit 6 Tunern. Mit einem Slotblech ist dann nicht mehr getan. Wir werden wohl im PC Bereich nach Gehäusen suchen. Hauptsache die Karten sitzen fest. Den Raspberry kann man dann mit Abstandshaltern irgendwo hinschrauben.
Weil nach Sat-IP gefragt wurde: Theoretisch hast du beide Optionen. Es gibt fertige Server in verschiedenen Preisklassen und es gibt mit minisatip auch eine freie Implementierung des Standards. Sowie er einfacher verfügbar ist, werde ich selbst mal einen Raspberry 5 als Server testen. An den kann man, dank PCI Express, bestehende Tuner-Karten anschließen.
Wird jetzt zwar Off Topic, aber du wirst nie alle Kopien eines Plugins vom Netz bekommen. Deshalb war ja die Idee eine Liste der "aktuellen Quellen" auf https://vdr-projects.github.io/ zu halten.
Die Frage ist eher ob mini73 noch weiter am Plugin arbeiten will. Mein letzter Stand war, dass er gar keinen VDR mehr nutzt. Ich habe jetzt erstmal das vdr-projects Repo auf https://vdr-projects.github.io/ verlinkt.
So wie ich das sehe gibt es aktuell niemanden mehr der wirklich aktiv daran arbeitet. Entsprechend "Community Maintained". Hab einen Patch nachgezogen der bei yaVDR drin ist (sscanf fixes) und den Stand mal als neues Release getaggt.
Letztlich alles eine Frage der Anforderungen. Ein Bekannter wollte sowieso schon ewig auf die Aufnahmen auch an verschiedenen Stellen zugreifen können.
Und so ist ein VDR-Server auf Basis eines Raspberry Pi 4 entstanden. Tuner kommen da tatsächlich über IP aber jetzt wo der Raspberry 5 in den Startlöchern steht haben wir schon drüber nachgedacht eventuell die Tuner auch wieder direkt an den Server zu bekommen. Festplatte ist in einem externen USB 3.0 Gehäuse und hängt so direkt am Raspberry.
Egal welchen aktuellen Tuner du heute kaufst: Die haben alle keine Treiber mehr direkt im Kernel. Und das Angebot ist auch am Schrumpfen. Ich sehe das Konzept "TV via Antenne" tendentiell aussterben. Gerade in Mietwohnungen wird man in Zukunft sicher irgendwann gesagt bekommen "Es liegt Glasfaser bis in die Wohnung. Eine zentrale Antennen-Anlage wurde nicht mehr installiert".
Eigentlich ist das hier angesprochene Problem meiner Meinung nach nur Bestandteil einer größeren Baustelle.
Ich hatte das vor, ich glaube mittlerweile schon Jahren, schonmal irgendwo angemerkt, dass ich eigentlich liebend gerne für Kodi ein PVR-Addon schreiben würde, das direkt auf VDR-Schnittstellen verbindet. Die ganze VNSI-Schnittstelle wurde vor Jahren vom ursprünglichen Entwickler aufgegeben. Plugins für den VDR haben leider so eine Tendenz irgendwann keinen Maintainer mehr zu haben (vnsiserver, streamdev). Auch wenn ich tvheadend nicht für besonders gut halte (meiner Meinung nach tendentiell ein totes Projekt) haben die doch einen Vorteil: Ein Protokoll direkt zum "Server" in dem alles kommuniziert werden kann.
Klaus hat da mal einen ersten Schritt gemacht und eine Lösung erarbeitet wie sich VDR-Systeme untereinander finden können. Leider wurde das nie "zu Ende geführt". Mehr wie Timer sharen geht damit nicht.
Eigentlich sollte das Ziel sein das der VDR irgendwann mal komplett netzwerktransparent wird. Also nicht nur Timer über die bereits vorbereiteten Schnittstellen übertragen, sondern im Idealfall verbinde ich von meinem Client einfach mit dem Server. Mehr nicht. Nur der Server muss wissen wie die Aufnahmen heißen und wo sie liegen. Und wenn ich vom Client eine Aufnahme wiedergeben will, dann sagt mein Client das dem Server und der Server streamt mir das Video rüber. Ich will da gar nicht noch mit NFS oder wasweißich rumfummeln müssen. Gleiches mit Live-TV. Für das Streaming sollte der VDR sorgen. Zusätzliche Plugins sollten da gar nicht nötig sein.
GIT nicht gleich GitHub. Ich denke mal du meinst letzteres.
Mal den Spam Ordner gecheckt? Bei mir kommt zuverlässig alles an.
Wenn man Aufnahmen priorisiert haben will, dann kommt man um einen VDR Server nicht herum.
Ich hab sowas ähnliches bei einen Bekannten laufen. VDR Server auf einen Raspberry 4. Der bekommt seine Tuner via LAN und alles was an Clients im Haus ist (entweder LibreElec oder Kodi auf Android) greift ausschließlich auf den VDR Server zu.
Vorteil ist dann im Wesentlichen das man auf dem VDR Server keine Tuner direkt braucht. Wäre am Raspberry 4 auch schwer gewesen da mehrere Tuner dran zu hängen.
Was ich gemacht habe sind nur Patches, die sowieso schon "jeder nutzt", direkt ins Repo übernommen. "Community Maintained" meint aus meiner Sicht erstmal nur "Bestehendes am Leben erhalten". Alles was mehr ist kann zwar gerne als Pull Request eingereicht werden. Dann ist es erstmal sauber abgelegt. Aber gemergt werden solche PRs in aller Regel nicht solange keiner sich bereiterklärt das Plugin ganz offiziell weiter entwickeln zu wollen. Mit allen Rechten und Pflichten.
Im Prinzip müsstest du die Firewall auch so konfigurieren können, dass die zwei gegenseitig kommunizieren können. Das wäre wahrscheinlich die einfachste Lösung.
Ist ja nicht nur der Kernel Support der nachlässt. Es scheint generell das Angebot an Tunerkarten zurückzugehen. Das letzte Mal, das ich geschaut habe, hatte auch DD keine "kleinen" Karten (max 2 Tuner) mehr. Mittlerweile ist wohl wieder eine gelistet.
Ich bin da der falsche Ansprechpartner. Ich nutze das Plugin nicht Mal. Aktuell ist das Plugin "Community Maintained" was bedeutet, dass es keinen aktiven Projektleiter mehr gibt.
https://www.amazon.de/dp/B0BZ91Q2Z3/
Hab in einem Mietshaus den, bzw. eine ältere Variante davon, seit 10 Jahren ohne Probleme als Mehrteilnehmeranlage laufen.
Ich frage mich an der Stelle halt warum man über /bin/sh geht? Script direkt aufrufen und Parameter dann dafür übergeben. Dann wäre auch kein Escaping nötig.
VDR sollte gar keine Shell starten. Man kann "argv" direkt als Array übergeben. Müsste man mal die Stelle suchen und checken. Parameter mit Leerzeichen trennen ist auf jeden Fall suboptimal.
No, I mean "Documentation" on https://vdr-projects.github.io/, it's linked to https://github.com/ua0lnj/vdr-…Bvaapi%2Bcuvid/README.txt
Done.
If any future changes are needed, it would also be possible to submit the needed changes on your own by creating a pull request against this repo: https://github.com/vdr-projects/vdr-projects.github.io
I released version 2.0.0 of the plugin from the test branch.
Attention, the default branch is now "latest". The latest version from the vaapi+vdpau+cuvid branch is 1.12.5.
This version can va-api+vdpau+cuvid+nvdec+cpu, that's too much for a branch title
M-Reimer, please update vdr-projects.github.io.
Please update this in the settings of your repo on GitHub. You can set the default branch there.
Bei einem Farbigen TFT müsste man eigentlich doch über graf-TFT oder dessen Nachfolger osd2html (oder so ähnlich) gehen?
Nicht unbedingt. Wenn man das will müsste aber in der Tat erstmal jemand einen Framebuffer Treiber für das kleine TFT schreiben.
Graphlcd kann schon länger auch mit farbigen Displays. Es fehlte bisher nur an einfach nutzbarer Hardware dafür.
