Posts by hoppel118

    Echt klasse, dass ihr euch hier gerade so zusammen rauft.


    Auch wenn ich VDR "nur" noch im Backend nutze, meine Frontends laufen alle mit Kodi, benötige ich natürlich auch noch ein paar Plugins: vnsi, live und epgsearch.


    vnsi wird von fernetmenta hervorragend weiterentwickelt. Das ist wohl auch schon mit vdr2.3.2 kompatibel.


    Neuerdings kommt auch noch robotv dazu. Das wird von pipelka gepflegt.


    Was live und epgsearch betrifft muss ich mir bei Gelegenheit wohl nochmal vdradmin-am ansehen.


    Wie dem auch sei. Vielen Dank für alles, was den VDR betrifft!


    Gruß Hoppel

    Moinsen,

    Ich habe ein Supermicro X10SLM+-LN4F Board, die Cine S2 v6.5 im ESXI 5.5 betrieben und nur Stress und Ärger gehabt mit Timeouts. auch mit msi=0 in ddbridge.


    Jetzt versuche ich erst mal die Karte auf einem anderen Supermicro Board einzubinden ohne ESXI....viel GLück :D

    ich habe die kvm nun mittlerweile fast 2 Wochen am Laufen. Bisher gab es keine Timeoutmeldungen oder sonstige Spinnereien bei meinem VDR. Der lüppt einfach (auch wenn der Server bisher noch nicht die Chance hatte ohne Reboot durchzulaufen, weil ich gerade noch ein ein anderes Thema mit dem Spindown meiner 8x4TB in Kombination mit zfs habe...) Ich habe die Cine S2 im Hostsystem nicht geblacklisted, sondern einfach nur wie folgt durchgereicht.


    Code
    1. root@proxmox:~# nano /etc/pve/qemu-server/vmid.conf
    2. ...
    3. machine: q35
    4. hostpci1: 02:00.0,pcie=1
    5. ...



    Gruß Hoppel

    Quote

    Ich habe ein Supermicro X10SLM+-LN4F Board, die Cine S2 v6.5 im ESXI 5.5 betrieben und nur Stress und Ärger gehabt mit Timeouts. auch mit msi=0 in ddbridge.


    Jetzt versuche ich erst mal die Karte auf einem anderen Supermicro Board einzubinden ohne ESXI....viel GLück :D


    So, nach ein paar Tagen Betrieb kann ich erstmal nichts negatives berichten. Meintest du mit Timeouts eigentlich folgende Meldungen im Syslog?





    Ich hatte vergessen, dass ich Anfang des Jahres, als ich openmediavault direkt auf dem Blech installiert hatte, auch schonmal Timeout-Probleme hatte. Diese Timeout-Probleme waren für mich aber
    damals nicht spürbar. Sie erschienen lediglich in meinen Logfiles bzw. sie haben mein Logfile zugemüllt. Ich hatte dazu damals auch einen Thread im OMV-Forum:


    http://forum.openmediavault.or…d-error-received-id-00e0/


    Damals habe ich dieses Problem wie im Link geschildet mit den Bootoptionen "pci=nomsi,noaer" in den Griff bekommen. Heute, wo seit ca. einer Woche Proxmox auf dem Blech läuft, sind mir diese Meldungen plötzlich wieder aufgefallen. Ich habe das Thema diesmal anscheind mit "pci=noaer" in der "/etc/default/grub" in den Griff bekommen. Wenn ich "pci=nomsi,noaer" setze, wird mein SAS-Controller nicht mehr in der kvm erkannt. ;)



    Nach der grub-Konfiguration und dem ersten Reboot hatte ich dann folgende Meldungen im Syslog:


    Code
    1. root@proxmox:~# dmesg | grep pcieport
    2. Oct 6 01:45:36 proxmox kernel: [ 0.947765] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
    3. Oct 6 01:45:36 proxmox kernel: [ 0.947795] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
    4. Oct 6 01:45:36 proxmox kernel: [ 0.947817] pcieport 0000:00:1c.2: Signaling PME through PCIe PME interrupt
    5. Oct 6 01:45:36 proxmox kernel: [ 0.947841] pcieport 0000:00:1c.4: Signaling PME through PCIe PME interrupt


    Das sieht schonmal wesentlich besser aus. Na schauen wir morgen mal, ob es weitere oder überhaupt neue Meldungen im Syslog gibt.


    Viele Grüße Hoppel

    die unterschiedlichen Module hätte ich spontan auch den verschiedenen Kernelversionen zugeordnet.


    Ich habe übrigens den kernel und die headers 4.4.19-1 des Hostsystems in der kvm installiert. Nun werden dieselben Module geladen, wie auf dem Host. Das gefällt mir optisch schonmla gut. Aber auch grundsätzlich stimmt mich das erstmal positiv ein. Nun kann ich bald mit der Konfiguration der einzelnen Dienste beginnen. ;)

    Ich meine erstmal gar nichts, so lange ich es nicht selbst getestet habe.


    Die Digital Devices Max S8 habe ich auf meinem Supermicro-Mainboard bisher noch nicht zum Laufen bekommen. Die Karte wird einfach gar nicht erkannt, kein Eintrag unter lspci. Beim Booten kann man direkt nach dem Einschalten an den LEDs der Max S8 erkennen, dass irgendwas nicht korrekt ausgehandelt werden kann. Es liegt aber am Supermicro-Mainboard, da diese Karte in Kombination mit einem Asus-Mainboard sofort erkannt wird.


    Die Digital Devices Cine S2 v6.5 hingegen läuft mit dem Supermicro-Mainboard ohne Virtualisierung absolut stabil und das sogar mit dem Treiber der im Kernel (4.4 habe ich mir aus den Backports gezogen) bereits enthalten ist, also plug-n-play. An den PCIE-Port-Settings im Mainboard-BIOS musste ich bei meiner Konstellation für die Cine S2 v6.5 nichts angepassen. Wie es mit dem Supermicro X11SSH-CTF, der Cine S2 v6.5 und Virtualisierung in Kombination aussieht, muss ich erst noch testen. ;)


    Bye

    Na dann bin ich ja mal gespannt, ob das irgendwann mit meinem Supermicro X11SSH-CTF stabil läuft...


    Habe auch noch ein anderes Problem mit der Digital Devices Max S8 in Kombination mit dem Supermicro-Mainboard. Hatte dazu auch schon Kontakt mit Digital Devices. Sehr guter und freundlicher Support. Man hat sich für mein Anliegen wirklich viel Zeit genommen. Ein paar Dinge möchte ich allerdings selbst noch testen, bevor ich das Thema gänzlich aufgebe. Das wird jedoch sehr zeitaufwendig und passt momentan einfach überhaupt nicht rein. Naja, Herbst und Winter stehen ja schon wieder vor der Tür. Wenn's draußen dunkel und ungemütlich wird, werde ich die Zeit finden. ;)


    Danke für die Info! Gruß Hoppel

    Hallo Mahlzeit,


    danke für die Info. Das man die Module blacklisten soll, steht auch gar nicht im proxmox-wiki unter "PCI EXPRESS PASSTHROUGH". Habe es allerdings auch öfters irgendwo im Internet gelesen, dass man die Module blacklisten soll. Von daher ist es umso besser, dass du deine Erfahrungen hier teilst. Ich werde die Module auf dem Host also nicht blacklisten.


    Ich habe mittlerweile eine Sata-SSD, einen LSI3008-SAS-Controller und die Cine-S2-TV-Karte an meine VM durchgereicht, zumindest sehe ich die devices nun in der VM (openmediavault). Vorher hatte ich openmediavault und alle Dienste direkt auf dem Blech bzw. dem zugrunde liegenden debian installiert. Erstmal möchte ich so wenig Abweichungen zur vorherigen Umgebung wie möglich, damit ich im Fehlerfall besser eingrenzen kann. Bevor ich mit dem ganzen LXC-Kram herumspiele, möchte ich also meine gesamte config in dieser einen VM zum Laufen bekommen. Später kann ich mir dann immer noch überlegen, was ich genau wie verteile und ggf. neu aufsetze und evtl. zusätzlich als Testsystem aufsetze.


    Eine Sache ist mir gerade bezüglich der Cine S2 aufgefallen:


    Auf dem Host sind folgende Module geladen:


    Code
    1. root@proxmox:~# lsmod | grep ddbridge
    2. ddbridge 24576 0
    3. cxd2099 20480 1 ddbridge
    4. dvb_core 122880 1 ddbridge


    In der VM folgende Module:


    Code
    1. root@mediatank:~# lsmod | grep ddbridge
    2. ddbridge 21641 0
    3. dvb_core 102010 1 ddbridge
    4. i2c_core 46012 4 drm,i2c_i801,ddbridge,drm_kms_helper


    Hast du dazu eine Idee? Warum werden in der VM andere Module geladen als auf dem Host? Hängt das evtl. mit den unterschiedlichen Kernel zusammen? Proxmox läuft mit "4.4.19-1-pve" und openmediavault mit "3.16.0-4-amd64". Ich werde mir unter openmediavault mal einen aktuelleren Kernel aus den Backports ziehen.


    Im nächsten Schritt werde ich dann erstmal openmediavault und meine Dienste einrichten. Habe aber momentan wenig Zeit. Mal sehen, wie es hier weiter geht.



    Gruß Hoppel


    Moinsen, ich beschäftige mich derzeitig auch mit der Virtualisierung von
    VDR und anderen Diensten. Als Host-System benutze ich die aktuelle Version proxmox. Bin aber derzeitig noch am probieren, da das ganze PCI-Passthrough-Zeugs für mich Neuland ist. Ich hatte es in der Vergangenheit irgendwann schonmal probiert, aber es gab einige Bugs, so dass ich mich dann damals (vor. ca 5Jahren) doch wieder gegen die Virtualisierung entschieden habe.


    Ich habe mal eine Frage bzw. Anmerkung zu deiner blacklist. Bei mir sieht das auf der Konsole wie folgt aus:



    ddbridge lädt bei mir 3 Module, in deiner blacklist sehe ich allerdings nur ddbridge. cxd2099 und dvb_core fehlen bei dir. Hat das einen Grund?


    Wofür sind die in anderen 3 in deiner Blacklist aufgeführten Module zuständig? Was haben die mit der Cine S2 zu tun? Bei mir werden diese Module auf dem Hostsystem auch standardmäßig geladen. Ich nehme an, dass es sich bei der V3 um eine andere TV-Karte handelt? Die Module werden bei mir nicht geladen?


    Hast du deine Probleme ggf. mittlerweile in den Griff bekommen?


    Viele Grüße Hoppel

    Hi Leute, habe übrigens mittlerweile vnsi auf den aktuellen Git-Master hochgezogen. Seither kann ich NDR zumindest grundsätzlich erstmal wieder schauen. Wenn allerdings auf eine lokale Sendung geschaltet wird, bleibt das Bild auch stehen und ich muss einmal kurz auf nen anderen Sender schalten. Danach funktioniert es dann.


    Eigenartige Geschichte...


    Habt ihr das mittlerweile in den Griff bekommen?


    Gruß Hoppel

    Code
    1. Aug 12 20:54:40 NAS kernel: [ 5257.521754] i2c write error
    2. Aug 12 20:54:40 NAS kernel: [ 5257.521893] i2c read error 1
    3. Aug 12 20:54:40 NAS kernel: [ 5257.521920] i2c read error 2


    hm..., ich weiß nicht ob das den Fehler löst, da es sich bei dir nicht um einen Timeout handelt, aber bei digital devices wird hier unter Punkt 6 auf folgendes hingewiesen:



    Quote

    Info: Falls I²C-Timeouts auftreten, bitte MSI für ddbridge deaktivieren:
    echo 'options ddbridge fmode=x msi=0' | sudo tee /etc/modprobe.d/ddbridge.conf


    Hast du das schon ausprobiert? Die Datei solltest du ja bereits haben...


    Manchmal kann man diese i2c-Thematik auch im Mainboard BIOS aktivieren/deaktivieren. Hast du dort schonmal nachgeschaut und ggf. was geändert?


    Gruß Hoppel

    Dann mach mal folgendes:


    • Datenplatte so unmounten, dass sie beim Start nicht mehr gemounted wird (über das omv web interface)
    • Logfile löschen
    • Server neustarten
    • wenn der Server hochgefahren ist, Kodi Client starten
    • wenn die Meldung "vnsi client channel no data" am Client erschienen ist, Server Logfile erneut hier posten


    Für das posten von Logfiles eignet sich übrigens pastebin.com hervorragend. Dateien jeglicher Art fremder Personen lädt man nur ungern auf den eigenen Rechner. ;) Hier gibt es beim Posten auch noch so eine Spoiler-Funktion (SP). Wieviel Zeilen Text da rein passen, weiß ich nicht.


    Gruß Hoppel

    Das Problem habe ich nur mit der Karte, also mit den Karten davor hatte ich die Probleme nicht, von daher kann es ja eigentlich nicht am VDR liegen.


    Aha, das hattest du glaube ich noch nicht erwähnt. Dann würde ich den VDR wohl auch erstmal ausschließen.


    An deiner Selle würde ich mir mal Gedanken, um die folgende Meldung in deinem Logfile machen:


    Code
    1. Aug 12 16:50:01 NAS monit[863]: 'fs_media_c218a41a-6a31-4cd0-91c0-fb2f5cb146f1' space usage 94.8% matches resource limit [space usage>80.0%]


    Dein Logfile ist voll damit. Deine Festplatte bzw. dein USB-Stick 'fs_media_c218a41a-6a31-4cd0-91c0-fb2f5cb146f1' ist voll. Sonst geht aus diesem Logfile leider gar nichts hervor, es ist nicht vollständig und nicht brauchbar für eine Analyse. Evtl. werden deine Probleme dadurch verursacht. Wofür benutzt du dieses Speichermedium genau?


    Ich habe übrigens gerade mal einen Blick in mein Logfile geworfen. Du hast folgenden Error:


    Code
    1. Aug 12 17:03:58 NAS vdr: [1314] VNSI-Error: cxSocket::read(fd=4): read() error at 0/4


    Bei mir sieht das etwas anders aus:


    Code
    1. Aug 12 18:19:50 mediatank vdr: [30612] VNSI: cxSocket::read(fd=44): eof, connection closed


    Ob man das nun vernachlässigen kann, weiß ich nicht. Ich würde erstmal das Speichermedium aufräumen. ;)



    Gruß Hoppel