Posts by Toxic-Tonic

    Moin,


    denke wenn der Puffer größer wird, verzögere ich nur das Problem. Die Ursache ist aber offensichtlich der SMB-Mount. Ich habe jetzt mal auf NFS umgestellt (gleicher Ziel-Pfad) und siehe da, 5 Aufnahmen gleichzeitig ohne Meldungen. Verstehen tue ich es trotzdem nicht, ich schreibe auf das NAS mit 80-100MB/s von dem VDR aus und auch von meinen Windows-Systemen aus. NFS ist im gleichen Bereich!


    Was macht der VDR anders als alle anderen?


    Gruß


    Toxic

    Nö, keine Backups tagsüber und keine markad, habe nur epgsearch, live, vnsi und streamdev aktiviert. CPU bohr sich in der Nase, der Container hat 512MB RAM. Habe mal alle unnötigen VMs und Container runtergefahren, kommt immer noch. Wenn keine Aufnahme läuft sieht das so aus:


    Code
    1. root@toxic-vdr01:~# dd if=/dev/zero of=/srv/data/upload/test.file bs=1M count=4096
    2. 4096+0 Datensätze ein
    3. 4096+0 Datensätze aus
    4. 4294967296 Bytes (4,3 GB, 4,0 GiB) kopiert, 41,8359 s, 103 MB/s


    Hast du einen Vorschlag für einen Test? Größere Datei oder öfters hintereinander? Andere Tools?

    Hallo zusammen,


    ich habe z.Zt. ein Debian Stretch als LXC-Container unter Proxmox 5.4 laufen und darin einen VDR von etobi installiert. Das ding ist "headless" und schreibt die aufnahmen per SMB auf mein NAS. Leider sind mit zuletzt einige Aufnahmen "negativ aufgefallen", weil sie total viele Aussetzer haben. Im Log habe ich dieses hier gefunden:



    Das Log ist bei zwei Aufnahmen (ARD und ZDF) parallel entstanden. Bei einer einzelnen Aufnahme ist es weniger, kommt aber auch vor...


    Bei der Suche nach einer Lösung habe ich den Hinweis auf mangelnde SMB-Performance gefunden. Habe da ordentlich dran geschraubt (vers=smb3 usw.) und habe jetzt parallel zu den Aufnahmen per dd eine Datei erstellt:

    Code
    1. root@toxic-vdr01:~# dd if=/dev/zero of=/srv/data/upload/test.file bs=1M count=2048
    2. 2048+0 Datensätze ein
    3. 2048+0 Datensätze aus
    4. 2147483648 Bytes (2,1 GB, 2,0 GiB) kopiert, 25,1203 s, 85,5 MB/s


    Denke also die Platten-Performance kann ich abhaken! ;)


    Leider endet da schon mein Latein! Ich bin mal zum Test auf einen alten Kernel zurück gegangen, weil ich dachte, dass das früher alles besser war, aber das war auch nix!


    Ich frage mich, ob der Ring-Buffer immer was mit wegschreiben zu tun hat, oder ob das auch mit dem Lesen von der DVB-Karte (übrigens eine Digital Device Cine S2 Dual) zu tun haben kann. Das ist ja durch das Mappen in den Container wahrscheinlich auch etwas langsamer? Habe aber keine Idee wie ich das testen kann. Wollte schon einen TVHeadend-Server ausprobieren =O, aber da ich seit Ewigkeiten den VDR nutze will ich eigentlich nicht weg... :*


    Jemand irgendeine Idee dazu??


    Besten Dank und beste Grüße


    Toxic

    Moin,


    habe grade einen Proxmox-Container mit Debian Stretch und dem "e-Tobi-VDR" gebaut. Läuft soweit echt fein, allerdings hat das vnsiserver-Plugin gezickt:



    Habe es mir jetzt selber übersetzt, aber vielleicht ist es ja nur eine Kleinigkeit ...


    Danke für das ansonsten coole (und aktuelle) Repository! :thumbup:


    LG


    Tobias


    PS.: Ein Hinweis auf die Installation des GPG-Keys auf der Homepage wäre hilfreich und würde den Google-Server deutlich entlasten... ;)

    Moin,


    Danke für deine Hilfe, habe mich jetzt aber entschieden doch auf Debian zu gehen und die Pakete von e-Tobi zu benutzen. Das läuft jetzt schon und ist ja auch grade aktualisiert worden. Die Container-Vorlage ist aber auch echt schlecht bei Proxmox, bin nicht sicher, ob das nicht auch dazu geführt hat...


    Besten Dank und beste Grüße


    Tobias

    Installiert habe ich diese:


    apt-get install vdr vdr-plugin-live vdr-plugin-streamdev-server vdr-plugin-epgsearch vdr-plugin-markad vdr-plugin-vnsiserver vdr-markad


    sind natürlich ein paar mehr mitgekommen!


    Aus eurem Repo müssten diese sein:


    dpkg -l | grep yavdr

    Hallo zusammen,


    habe mich grade mal nach langer Zeit wieder mit meinem VDR beschäftigt und da ich neuerdings Proxmox einsetze hatte ich die verrückte Idee, Yavdr in einen Container zu verpflanzen.


    Bisher hat auch alles gut geklappt, habe aus einem Template ein Ubuntu 14.04 installiert, die PCIE-Karte durchgereicht, die Repositorys hinzugefügt und die Pakete installiert.


    Jetzt mein Problem: Der VDR startet nicht! Wenn ich "/etc/init.d/vdr start" oder "start vdr" den VDR starten will passiert einfach gar nichts (Ausgabe: "vdr start/running, process 3098") aber kein VDR wird gestartet und auch nichts im Log. Wenn ich direkt "/usr/lib/vdr/runvdr start" aufrufe startet der VDR, allerdings natürlich ohne alle plugins etc.. Ich habe keine Idee wo ich ansetzen soll. Was mir aufgefallen ist ist, dass die Ausgabe von "/etc/init.d/vdr start" nicht zum Script passt. Als ob er das gar nicht (richtig) ausführt...


    Kleine Besonderheit, der VDR muss als root laufen, da es sonst in einem Container Berechtigungsprobleme gibt. Das ist aber gegeben, beim manuellen start über runvdr nimmt er ja die Settings aus /etc/defaults/vdr...


    Ich weiß, das ist ziemlich schwammig, aber genauer habe ich es grad nicht.


    Irgendein Ansatz?


    Danke und Gruß


    Toxic

    Hallo zusammen,


    gibt es einen Grund, warum im yaVDR immernoch das Fritzbox-Plug 1.5.2 enthalten ist? Ich habe bei der Nummernauflösung über das lokale Adressbuch ein Problem (geht halt nicht) und das ist in der 1.5.3 gefixt. Ich kann das jetzt selber aktualisieren, aber vielleicht gibt es in der 1.5.3 andere probleme oder es würde sich jemand finden, des das im Repository zur Verfügung stellt?!


    Danke und Gruß


    Toxic

    dann stimmt deine sig nicht?
    EDIT: (schnell noch die Sig angepasst he?)


    Spass beiseite - welche Einschränkungen funktional habe ich links und rechts?


    Hm, erwischt!


    Habe aber festgestellt, dass vnsi auch noch mal aktualisiert worden ist. Erster Test mit RASPBMC war erfolgreich. Aufnahmen, die ich vorher nicht spulen konnten gehen jetzt!


    Gruß


    Toxic

    Hi,


    xvdr ist sweit ich das überblicke aktueller, vnsi ist dafür bereits im "std.-XBMC" enthalten. Habe beides mal gehabt, nutze aber momentan vnsi wegen der Unterstützung unter allen XBMC-Plattformen (Win. und Raspbmcz.B.).


    Gruß


    Toxic