Posts by hoppel118

  • [ERFOLGREICH GELÖST] Digital Devices Max S8 und Supermicro X11SSH-CTF - ein paar generelle Fragen

    und hier die BIOS-Konfiguration für SLOT6 (PCI-E 3.0 X8 :(






    "SLOT6 Max Link Speed" steht per default auf "Auto", muss an diesem Port aber unbedingt auf "GEN1" konfiguriert werden. Andernfalls muss der Server nach einem Kaltstart immer nochmal rebootet werden, damit die Karte sauber erkannt wird.


    Ich betreibe meine MaxS8 v1.2 nun SLOT4 (PCI-E 3.0 X2).


    Ich hoffe, mit diesen Informationen dem einen oder anderen hier helfen zu können. Ansonsten ist das Thema nach nun knappen 10 Monaten erfolgreich abgeschlossen! ;)



    Viel Spaß noch!


    Gruß Hoppel


    EDIT: Die ganzen Postings waren übrigens erforderlich, weil man hier im Forum immer nur max. 5 Bilder pro Post hochladen kann und ich keine Lust hatte die Bilder extern irgendwo hochzuladen und hier dann wieder zu verlinken.

  • [ERFOLGREICH GELÖST] Digital Devices Max S8 und Supermicro X11SSH-CTF - ein paar generelle Fragen

    Laut Digital Devices funktionierte bei einem anderen Supermicro Mainboard User die Erhöhung des "Latency Timers" im BIOS auf "192" und die Konfiguration des "PEG-Ports" auf "GEN1":


    http://support.digital-devices…ledgebase.php?article=172


    Bei mir funktioniert das mit der MaxS8 v1.1 nicht, hier nochmal der Screenshot:



    Für die MaxS8 v1.2 ist die Erhöhung des "Latency Timers" zumindest bei meinem Mainboard nicht erforderlich. Ich habe die Standard-Einstellungen des Latency Timers wieder hergestellt:


  • [ERFOLGREICH GELÖST] Digital Devices Max S8 und Supermicro X11SSH-CTF - ein paar generelle Fragen

    Hallo Leute,


    was lange währt, wird endlich gut. Eigentlich hatte ich dieses Thema schon fast aufgegeben, aber der Support aller Beteiligten hat mich bei Laune gehalten. Mittlerweile werkelt seit 4 Tagen eine MaxS8 in meinem Server.


    Die Story:


    Zunächst hatte ich mit Digital Devices Kontakt. Wir sind dann per Teamviewer und IPMI meines Supermicro X11SSH-CTF Mainboards gemeinsam sämtliche BIOS-Einstellungen durchgegangen. Aber alle vorgenommenen Veränderungen führten nicht zum Erfolg. Die Karte wurde nicht erkannt.

    Dann nahm ich mit Supermicro Kontakt auf und habe ein Support-Ticket erstellt. Die zuständigen BIOS-Entwickler haben dann nochmal mit mir gemeinsam ein PCIe-dump erstellt, um herauszufinden, ob die Karte überhaupt vom Mainboard erkannt wird. Aber wie schon zu vermuten war, die Karte wurde nicht erkannt. Mir wurde dann ein Beta-BIOS für mein Mainboard bereitgestellt. Aber auch das half nichts. Zu guter Letzt war ich dann soweit die MaxS8 nach Amerika zu Supermicro in’s Labor zu schicken. Dies wurde aber dann doch noch kurzfristig von Supermicro geblockt.


    Mittlerweile gibt es übrigens auch ein offizielles BIOS-Update für mein Mainboard, welches ich Anfang des Jahres installiert habe:


    Code
    Firmware Revision : 01.15 
Firmware Build Time : 02/19/2016 
BIOS Version : 2.0 
BIOS Build Time : 12/28/2016 
CPLD Version : 02.b1.01 
Redfish Version : 1.0.1


    Die erste MaxS8 wurde damit aber auch nicht erkannt.


    Während des gesamten Zeitraums hatte ich immer wieder Kontakt mit Bernhard von LINUX4MEDIA. Nach den gesammelten Erfahrungen wollte ich die MaxS8 nun durch eine DuoFlex ersetzen. Bernhard bot mir dann an, mir zusätzlich noch eine weitere MaxS8 zuzuschicken, um einfach alle Fehler ausschließen zu können.


    Vor kurzem kamen dann beide Karten an. Wenn ich ehrlich bin, habe ich zu dem Zeitpunkt nicht daran geglaubt, dass die MaxS8 laufen würde, so dass ich erstmal die DuoFlex in Betrieb genommen habe. Da dieses Mainboard so viele Einstellungsmöglichkeiten bereitstellt und ggf. nur eine einzige bestimmte Konstellation an BIOS-Einstellungen funktioniert, wollte ich mir für die Tests mit der neuen MaxS8 mehr Zeit nehmen.


    Der Einbau:


    Nun gut, soviel zur Geschichte, der große Tag war gekommen. Ich habe die CineS2 v6.5 und die DuoFlex v4 entfernt und die neue Max S8 in den x8-PCIe-Port meines Mainboards gesteckt und den Server gestartet. In dem Moment habe ich natürlich ziemlich genau die LEDs der MaxS8 beobachtet. In dem x8-Port gibt es ein längeres Training (ca. 30sek). Alle 5 LEDs der MaxS8 blinkten im Sekundentakt. Das war mit der ersten MaxS8 auch schon so. Kurz danach veränderte sich dann das Blinken der LEDs. Die beiden äußeren und die LED in der Mitte blinkten immer abgewechselt, wenn ich mich recht entsinne. Das habe ich so zumindest bei der ersten MaxS8 noch nicht gesehen. Nach ein paar Sekunden hat mein Server dann selbständig einen Reboot durchgeführt und tadaa die beiden unteren LEDS leuchten. Als der Server dann hochgefahren war, habe ich direkt erstmal mit „lspci“ geprüft, ob die Karte nun sichtbar ist. YES, die Karte ist da!


    Code
    root@omv:~# lspci | grep "Digital Devices" 
02:00.0 Multimedia controller: Digital Devices GmbH Device 0007



    Hier noch Angaben zur genauen Hardware-Revision:


    Code
    root@omv:~# dmesg | grep "DDBridge: HW" 
[ 11.795427] DDBridge: HW 0201000c REGMAP 00010002


    Ich habe dann noch ein Bisschen weiter getestet, weil mir aufgefallen ist, dass die neue MaxS8 nach einem Kaltstart grundsätzlich nicht erkannt wird und somit immer ein Reboot erforderlich ist. Nachdem ich dann im BIOS „Link Speed“ auf „Gen1“ gesetzt habe, war das Problem aber gelöst, die Karte wurde nun in diesem Port auch direkt nach dem Kaltstart erkannt. Das Training (ca. 30sek.) findet in dem x8-Port übrigens bei jedem Kaltstart statt, so dass ich mich dazu entschieden habe, die Karte nochmal in den x1-Port zu setzen. Tadaa, die Karte wird ohne Training sofort direkt erkannt. Perfekt, nun konnte es mit der Installation des Treibers losgehen.

    Die Installation des Treibers:


    Nun habe ich mich also an die Installation des Treibers gemacht, denn unter „/dev/dvb“ war noch kein Adapter zu sehen.


    Zunächst habe ich mich an die Anleitung von Digital Devices gehalten und den Treiber 0.9.28-v7a selbst kompiliert. Die Adapter0-7 waren zu sehen, alles andere sah auch gut aus. Was fehlte war allerdings das Bild und die EPG-Informationen im Live-Plugin. Habe alle möglichen Einstellungen (fmode=0, fmode=1 jeweils mit und ohne msi=0) getestet. Aber nix.


    Dann habe ich den Treiber von @wolfi.m installiert, und das Bild und die EPG-Informationen waren sofort da. Warum das so war/ist, weiß ich nicht. Es handelte sich auf jeden Fall um dieselbe Treiber-Revision 0.9.28-v7a.


    Das Ergebnis:


    Hier die Ausgabe des geladenen ddbridge-Moduls:



    Code
    root@omv:~# lsmod | grep ddbridge ddbridge 102400 56 cxd2099 20480 1 ddbridge dvb_core 122880 1 ddbridge


    Code
    root@omv:~# modinfo ddbridge filename: /lib/modules/4.4.59-1-pve/updates/dkms/ddbridge.ko version: 0.9.28 license: GPL author: Ralph and Marcus Metzler, Metzler Brothers Systementwicklung GbR description: Digital Devices PCIe Bridge srcversion: B7D0071B39C2757EF6A1654 alias: pci:v0000DD01d00000320sv*sd*bc*sc*i* alias: pci:v0000DD01d00000201sv*sd*bc*sc*i* alias: pci:v0000DD01d00000013sv*sd*bc*sc*i* alias: pci:v0000DD01d00000011sv*sd*bc*sc*i* alias: pci:v0000DD01d00000008sv*sd*bc*sc*i* alias: pci:v0000DD01d00000007sv*sd*bc*sc*i* alias: pci:v0000DD01d00000006sv*sd*bc*sc*i* alias: pci:v0000DD01d00000005sv*sd*bc*sc*i* alias: pci:v0000DD01d00000003sv*sd*bc*sc*i* alias: pci:v0000DD01d00000329sv*sd*bc*sc*i* alias: pci:v0000DD01d00000328sv*sd*bc*sc*i* alias: pci:v0000DD01d00000323sv*sd*bc*sc*i* alias: pci:v0000DD01d00000322sv*sd*bc*sc*i* alias: pci:v0000DD01d00000321sv*sd*bc*sc*i* alias: pci:v0000DD01d00000320sv*sd*bc*sc*i* alias: pci:v0000DD01d00000210sv0000DD01sd00000003bc*sc*i* alias: pci:v0000DD01d00000210sv0000DD01sd00000002bc*sc*i* alias: pci:v0000DD01d00000210sv0000DD01sd00000001bc*sc*i* alias: pci:v0000DD01d00000203sv0000DD01sd00000001bc*sc*i* alias: pci:v0000DD01d00000201sv0000DD01sd00000002bc*sc*i* alias: pci:v0000DD01d00000201sv0000DD01sd00000001bc*sc*i* alias: pci:v0000DD01d00000013sv0000DD01sd00000044bc*sc*i* alias: pci:v0000DD01d00000013sv0000DD01sd00000043bc*sc*i* alias: pci:v0000DD01d00000012sv0000DD01sd00000042bc*sc*i* alias: pci:v0000DD01d00000011sv0000DD01sd00000041bc*sc*i* alias: pci:v0000DD01d00000011sv0000DD01sd00000040bc*sc*i* alias: pci:v0000DD01d00000006sv0000DD01sd00000039bc*sc*i* alias: pci:v0000DD01d00000008sv0000DD01sd00000038bc*sc*i* alias: pci:v0000DD01d00000008sv0000DD01sd00000037bc*sc*i* alias: pci:v0000DD01d00000008sv0000DD01sd00000036bc*sc*i* alias: pci:v0000DD01d00000008sv0000DD01sd00000035bc*sc*i* alias: pci:v0000DD01d00000008sv0000DD01sd00000034bc*sc*i* alias: pci:v0000DD01d00000007sv0000DD01sd00000023bc*sc*i* alias: pci:v0000DD01d00000006sv0000DD01sd00000033bc*sc*i* alias: pci:v0000DD01d00000006sv0000DD01sd00000032bc*sc*i* alias: pci:v0000DD01d00000006sv0000DD01sd00000031bc*sc*i* alias: pci:v0000DD01d00000003sv0000DD01sd0000DB03bc*sc*i* alias: pci:v0000DD01d00000003sv0000DD01sd00000030bc*sc*i* alias: pci:v0000DD01d00000006sv0000DD01sd00000024bc*sc*i* alias: pci:v0000DD01d00000006sv0000DD01sd00000022bc*sc*i* alias: pci:v0000DD01d00000003sv0000DD01sd00000021bc*sc*i* alias: pci:v0000DD01d00000003sv0000DD01sd00000020bc*sc*i* alias: pci:v0000DD01d00000005sv0000DD01sd00000011bc*sc*i* alias: pci:v0000DD01d00000003sv0000DD01sd00000010bc*sc*i* alias: pci:v0000DD01d00000003sv0000DD01sd00000003bc*sc*i* alias: pci:v0000DD01d00000003sv0000DD01sd00000002bc*sc*i* alias: pci:v0000DD01d00000005sv0000DD01sd00000004bc*sc*i* alias: pci:v0000DD01d00000003sv0000DD01sd00000001bc*sc*i* alias: pci:v0000DD01d00000002sv0000DD01sd00000001bc*sc*i* depends: cxd2099,dvb-core vermagic: 4.4.59-1-pve SMP mod_unload modversions parm: adapter_alloc:0-one adapter per io, 1-one per tab with io, 2-one per tab, 3-one for all (int) parm: msi: Control MSI interrupts: 0-disable, 1-enable (default) (int) parm: ci_bitrate: Bitrate in KHz for output to CI. (int) parm: ts_loop:TS in/out test loop on port ts_loop (int) parm: vlan:VLAN and QoS IDs enabled (int) parm: tt: (int) parm: fmode:frontend emulation mode (int) parm: old_quattro:old quattro LNB input order (int) parm: xo2_speed:default transfer speed for xo2 based duoflex, 0=55,1=75,2=90,3=104 MBit/s, default=2, use attribute to change for individual cards (int) parm: alt_dma:use alternative DMA buffer handling (int) parm: stv0910_single:int parm: no_init:do not initialize most devices (int) parm: adapter_nr:DVB adapter numbers (array of short)


    Ohne die Option "msi=0" in der "ddbridge.conf" gibt's bei mir kein Bild:

    Code
    root@omv:~# cat /etc/modprobe.d/ddbridge.conf options ddbridge fmode=1 msi=0


    Hier die Ausgabe zu den 8 Adaptern:



    Code
    root@omv:~# ls /dev/dvb/adapter?/ /dev/dvb/adapter0/: demux0 dvr0 frontend0 net0 /dev/dvb/adapter1/: demux0 dvr0 frontend0 net0 /dev/dvb/adapter2/: demux0 dvr0 frontend0 net0 /dev/dvb/adapter3/: demux0 dvr0 frontend0 net0 /dev/dvb/adapter4/: demux0 dvr0 frontend0 net0 /dev/dvb/adapter5/: demux0 dvr0 frontend0 net0 /dev/dvb/adapter6/: demux0 dvr0 frontend0 net0 /dev/dvb/adapter7/: demux0 dvr0 frontend0 net0



    Meine System-Basis sieht mittlerweile übrigens wie folgt aus. Sämtliche Pakete kommen aus etobis Repo, bis auf vnsiserver. vnsiserver habe ich direkt von github kompiliert.


    Code
    root@omv:~# vdr -V vdr (2.2.0/2.2.0) - The Video Disk Recorder epgsearch (1.0.1.beta5) - search the EPG for repeats and more vnsiserver (1.5.2) - VDR-Network-Streaming-Interface (VNSI) Server epgsearchonly (0.0.1) - Direct access to epgsearch's search menu conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu live (0.3.0) - Live Interactive VDR Environment quickepgsearch (0.0.1) - Quick search for broadcasts


    Ich setze den 4.4LTS-Kernel von Proxmox ein. Die Umgebung ist aber momentan noch nicht virtualisiert, da ich sehen möchte, dass bare metal alles läuft.


    Code
    root@omv:~# uname -a Linux omv 4.4.59-1-pve #1 SMP PVE 4.4.59-87 (Tue, 25 Apr 2017 09:01:58 +0200) x86_64 GNU/Linux


    Als OS setze ich openmediavault 3 in der aktuellsten Version ein, die Basis ist debian:


    Code
    root@omv:~# cat /etc/debian_version 8.8


    Die Erkenntnisse:


    Was nun klar ist, es gibt verschiedene Revisionen der MaxS8. Neben leichten Unterschieden an Hardwarebauteilen, steht das auch unten auf dem Flügel neben den PCIe-Slot-Kontakten. Hier links, die v1.1 und rechts die v1.2:



    Hier die MaxS8 (v1.1) nach der fehlgeschlagenen Initialisierung am PCIe-Port:



    Hier die MaxS8 (v1.2) nach der erfolreichen Initialisierung am PCIe-Port:



    Ich habe beide MaxS8 nochmal in meinen alten Asus-HTPC eingebaut, um die Firmware-Versionen zu prüfen. Die MaxS8 v1.1 habe ich in telefonischer Anwesenheit von Digital Devices auf die derzeitig aktuelle v1.12b geupdated. Laut "DD Control Center" unter Windows7 waren dann beide MaxS8 auf der aktuellen Firmware-Version 1.12b.



    Außerdem gibt es wohl noch eine v1.0, die irgendwo noch einen Jumper hat. Dieser Jumper ist aber sowohl auf der v1.1, als auch auf der v1.2 nicht mehr vorhanden.



    Das Fazit:

    Ich will hier definitiv kein Fingerpointing auf die Hersteller machen. Denn grundsätzlich haben mich Digital Devices und Supermicro entsprechend deren Möglichkeiten gut in der Fehlereingrenzung unterstützt. :) Außerdem kann man nun immer noch nicht klar sagen, woran es eigentlich gelegen hat:



    • Auf der einen Seite funktioniert die MaxS8 v1.1 an einem PCIe-Port eines herkömmlichen Asus-Mainboard. Die Karte ist also nicht defekt, funktioniert aber trotzdem nicht am PCIe-Port des Supermicro-Mainboards.
    • Auf der anderen Seite funktioniert die MaxS8 v1.2 am PCIe-Port des Supermicro-Mainboards.

    Ich will dazu hier auch keine Diskussion entfachen. Es ist, wie es ist!

    Alles in allem war das eine ganze Menge Arbeit. Aber es hat sich gelohnt. Hatte gestern testweise mal 12 Aufnahmen gleichzeitig für 5min laufen. Die Aufnahmen waren alle fehlerfrei, ohne Verpixelungen. Hammer!



    Vielen Dank an alle hier im Forum die mich unterstützt haben. Mein besonderer Dank geht an Bernhard von LINUX4MEDIA für die Bereitstellung des Testequipments und Andreas von Digital Devices für den Support.


    Gruß Hoppel

  • Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT, MAX S8 sowie TT S2-6400 (Teil 3)



    wolfi.m Vielen Dank für die Bereitstellung dieses Treibers und der Anleitung zur Installation. Damit habe ich gerade eine MaxS8 in meinem Supermicro Server Mainboard zum Laufen bekommen. Was unterscheidet den von dir bereitgestellten Treiber mit dem von Digital Devices?


    Mit dem von mir manuell kompilierten Treiber habe ich die Karte nicht zum Laufen bekommen, obwohl es sich um dieselbe Versionsnummer (0.9.28-v7a) handelt: http://support.digital-devices…ledgebase.php?article=151



    Zu meiner MaxS8 in Kombination mit meinem Supermicro Mainboard gibt es eine längere Story. Darauf werde ich bei Gelegenheit in meinem Thread von vor mittlerweile fast einem Jahr auch nochmal eingehen.



    Danke und viele Grüße


    Hoppel

  • [Howto] Proxmox 4.4 und LXC - TV-Karte (hier Digital Devices Cine S2 v6.5) im Container verfügbar machen

    LXD scheint eine interessante "Spielerei" zu sein. Dafür benötigt man allerdings ein aktuelles ubuntu oder ein aktuelleres debian, als das was proxmox von Hause aus mitbringt. proxmox ist debian jessie. Mit jessie ist LXD nicht ohne größeren Aufwand (evtl. geht das über die backports) möglich. LXD soll wohl ab debian stretch möglich sein. Momentan bleibt uns proxmox Usern somit erstmal nur lxc und kvm. Docker (emby media server) läuft bereits in meiner openmediavault-kvm. Auch das läuft super stabil, trotz Virtualisiserung" und "Containerisierung". ;)

  • [Howto] Proxmox 4.4 und LXC - TV-Karte (hier Digital Devices Cine S2 v6.5) im Container verfügbar machen

    Vielleicht noch ein anderer guter Tip, auch wenn das hier eigentlich offtopic ist. Anfangs habe ich an meinen LXCs immer SSH aktiviert, obwohl das vielleicht nicht unbedingt erforderlich war.


    Du kannst am Host folgende Befehle verwenden, um deine LXCs zu managen:


    * pct enter <vmid> - Command Line des Containers
    * pct start <vmid> - Starten des Containers
    * pct stop <vmid> - Beenden des Containers


    Gruß Hoppel

  • [solved] Proxmox 4.4 mit LXC und etobi's Repo - apt-get "Failed to fetch"

    Jupp, hast du gut gemacht! ;)


    Für mich ist das auch alles noch relativ neu. Aber mittlerweile habe ich schon eine FHEM Installation in einen LXC überführt. Wenn man irgendwelche Geräte im Container benötigt, ist das einfach viel geiler als PCI- oder USB-Passthrough bei KVM. Die Hardware ist direkt sichtbar/verfügbar. Man muss nur die richtigen Berechtigungen setzen. Dafür habe ich übrigens vorhin ein kleines Howto geschrieben:


    http://www.vdr-portal.de/board60-linux/board104-server/130353-howto-proxmox-4-4-und-lxc-tv-karte-hier-digital-devices-cine-s2-v6-5-im-container-verfügbar-machen/


    Vielleicht kannst du das ja gebrauchen und auch nochmal ein Feedback geben, ob ich was vergessen habe. ;)


    Viel Spaß mit LXC!


    Gruß Hoppel

  • [Howto] Proxmox 4.4 und LXC - TV-Karte (hier Digital Devices Cine S2 v6.5) im Container verfügbar machen

    Hallo Leute,


    da hier immer wieder einige Leute mit Proxmox unterwegs sind und die nachfolgend beschriebene Thematik noch nicht wirklich vollständig transparent im Internet dargestellt wurde, schreibe ich hier mal ein kleines Howto. In diesem Howto geht es darum eine TV-Karte, in meinem Fall eine Digital Devices Cine S2 v6.5, in einem LXC (LinuxContainer) verfügbar zu machen. Für KVM ist dieses Howto nicht geeignet, da die TV-Karte dort per PCI Passthrough durchzureichen ist, während bei LXC lediglich die Berechtigungen für /dev/dvb zu erteilen sind. PCI Passthrough ist mit LXC also nicht erforderlich. Mit LXC sollte es also definitiv keine Timing-Probleme geben.


    Ich gehe in diesem Howto nicht darauf ein, wie ein LXC zu erstellen ist oder der VDR zu konfigurieren ist. Dafür gibt es andere gute Howtos. ;)


    Proxmox 4.4 setzt den derzeitig aktuellen Kernel 4.4LTS ein, so dass meine Cine S2 direkt erkannt wird und ein weiteres Laden von Treibern oder Modulen nicht erforderlich ist. Des Weiteren ist auch das blacklisten dieser TV-Karte am Host nicht erforderlich bzw. sogar im Falle von LXC sogar dringend zu unterlassen. Wenn ihr eine andere TV-Karte einsetzt, müsst ihr ggf. zusätzliche Schritte ausführen, um eure TV-Karte am Host verfügbar zu machen.


    Zunächst prüfen wir, ob die TV-Karte in Proxmox sichtbar ist:


    Code
    root@proxmox:~# lspci
02:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter


    Dann prüfen wir, ob die dvb Devices verfügbar sind und ermitteln die Berechtigungs-ID (ich nenne sie mal so):



    Die Berechtigungs-ID ist direkt hinter "root video" bei den beiden Adaptern zu finden. Es handelt sich um die größere Zahl. In meinem Fall also um die 212.


    Nun erstellen wir unseren LinuxContainer in Proxmox. Wenn dies erledigt ist, fahren wir den Container herunter und konfigurieren die Berechtigungen für die TV-Karte. Die entpsrechende Konfigurationsdatei für den Container finden wir unter. "/etc/pve/lxc/vmid.conf". Folgende beiden Zeilen ergänzen wir nun auf Basis unserer Erkenntnisse (Berechtigungs-ID, hier 212) in der LXC-Konfigurationsdatei:


    Code
    lxc.cgroup.devices.allow: c 212:* rwm
lxc.mount.entry: /dev/dvb dev/dvb none bind,optional,create=dir



    Nun starten wir unseren LXC und prüfen zunächst, ob die TV-Karte im LXC sichtbar ist:


    Code
    root@vdr:~# lspci
02:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter


    Dann prüfen wir, ob die dvb Devices verfügbar sind:



    Wenn das so alles vorhanden ist, haben wir es geschafft. Euer LXC-VDR hat nun Zugriff auf die TV-Karte.


    Viel Spaß mit LXC! ;)


    Gruß Hoppel

  • [solved] Proxmox 4.4 mit LXC und etobi's Repo - apt-get "Failed to fetch"

    OK, dann bin also nicht zu blöd und auch nicht allein mit meinem Problem. ;)


    Ich habe gestern testweise einfach mal versucht das Repository in einem anderen vorhandenen LX-Container, den ich für FHEM nutze, etobi's Repo einzubinden. Eigenartigerweise klappt das. Ich bin dann wie folgt vorgegangen:


    • Backup des vorhandenen FHEM-Containers erstellt
    • den FHEM-Container auf Basis dieses Howtos komlett bereinigt und alles was mit FHEM zu tun hat gelöscht
    • ein weiteres Backup dieses Containers erstellt und dieses in den Template-Ordner verschoben
    • den ursprünglichen FHEM-Container auf Basis des ersten Backups wieder hergestellt
    • auf Basis des von mir erstellten Templates einen neuen VDR LX-Container erstellt
    • etobis Repo eingebunden, läuft


    Ich habe keine Ahnung, was den FHEM-Container so besonders macht. Schließlich habe ich diesen auch erst mit Proxmox 4.4 erstellt. Alle Versuche einen neuen LX-Container auf Basis des Standard-Debian-Proxmox-Templates für etobis Repo zu erstellen, scheitern an der Einbindung von etobis Repo. Das bringt dich jetzt zwar nicht weiter. Aber wenn ich ehrlich bin, ist das ja auch keine richtige Lösung, mit der unbedingt jeder etwas anfangen kann. Hast du evtl. auch einen anderen LX-Container mit dem du das mal ausprobieren könntest?


    VDR habe ich zwar grundsätzlich fertig konfiguriert, aber der VDR-Service ließ sich noch nicht starten. Man muss den VDR-Service in einem LX-Container wohl als root ausführen, damit das klappt. Dazu hatte ich allerdings noch keine Zeit, mich weiter damit zu beschäftigen.


    Bleibt die Frage, wo man dieses Thema korrekterweise platziert. Bei etobi oder bei Proxmox... Naja, viellicht hat ja noch jemand eine Idee.


    Gruß Hoppel

  • [solved] Proxmox 4.4 mit LXC und etobi's Repo - apt-get "Failed to fetch"

    Hallo Leute,


    ich möchte meinen vdr gern in einem LXC (LinuxContainer) betreiben. Als Paketquelle verwende ülicherweise etobi's repository. Das funktioniert in einer KVM auch alles wunderbar, also keine Eile. ;) Momentan scheitere ich direkt beim "apt-get update" nach der Einbindung von etoi's Repository.


    Der LXC wurde ganz frisch aufgesetzt. Zu Beginn habe ich die LXC-Basis erstmal per "apt-get update && apt-get upgrade" geupdated.


    Dann habe ich etobi's Repo entsprechend dieser Seite eingebunden:


    Code
    root@vdr:~# nano /etc/apt/sources.list.d/etobis-vdr.list
deb http://e-tobi.net/vdr-experimental jessie vdr-multipatch base 
deb-src http://e-tobi.net/vdr-experimental jessie vdr-multipatch base


    Wenn ich nun ein "apt-get update" ausführe, erhalte ich folgende Meldungen:



    In der KVM funktioniert das repository wunderbar. Habe keine besonderen Netzwerk-Einstellungen oder Firewall konfiguriert. Wenn ich das emby repository einbinde, gibt es keine Probleme mit "apt-get update"


    Hat dazu jemand eine Idee? Was macht etobi's Repo für den LXC so besonders?



    Danke und Gruß Hoppel

  • Frequenzen NDR

    Hallo Leute,


    habe heute morgen übrigens nochmal die Aufnahme geprüft. Das war tatsächlich das Problem. Nachdem ich die Updates der PIDs wieder aktiviert habe, kann ich nun auch das Schleswig-Holstein Magazin wieder sehen. OK, dann lass ich das jetzt Mal bei der Einstellung in der Hoffnung, dass der Bug in Kodi zwischenzeitlich gefixt wurde. Zumindest bei github wurde der Issue geschlossen: https://github.com/kodi-pvr/pvr.hts/issues/172


    Das Problem hatte ich übrigens vor ca. einem halben Jahr mit Jarvis (Libreelec für den Odroid C2 und Kodi für Windows). Mittlerweile bin ich aber komplett auf Krypton umgestiegen.



    Also Danke nochmal für eure Unterstützung!


    Viele Grüße Hoppel

  • Frequenzen NDR

    Nö, darf er nicht.


    Das habe ich vor einiger Zeit mal als Workaround aufgrund eines Fehlers mit der tv29.db in kodi deaktiviert. Wenn ich diese automatischen ChannelUpdates aktiv hatte, kam es immer wieder vor, dass der ganze LiveTV-Bereich nach dem Start von kodi nicht eingeblendet wurde. Durch das Deaktivieren der ChannelUpdates habe ich das in den Griff bekommen.


    Das Ding ist allerdings, dass das SH Magazin anfangs definitiv auch ohne die ChannelUpdates funktioniert hat.


    Ich werde das morgen Abend aber auch nochmal ausprobieren.


    Danke für den Tip!


    EDIT: Habe vorhin übrigens noch meine setup.conf kurz umkonfiguriert (jetzt: UpdateChannels = 2) und heute Nacht irgendwann nehme ich das SH Magazin auf. Mal sehen, ob das klappt.

  • Frequenzen NDR

    ;) Das war auch nicht mein Anspruch.


    Ich formuliere nochmal um:


    Kannst du morgen oder die Tage mal, wenn du Zeit hast die Aufnahme zu prüfen und du tatsächlich das SH Magazin aufgenommen hast, bitte auch nochmal die Frequenz überprüfen? ;)


    Das hat keine große Prio!


    Danke nochmal

  • Frequenzen NDR

    Hallo fnu, bin gespannt, was dabei raus kommt.


    Kannst du evtl. morgen wenn du tatsächlich das SH Magazin empfängst nochmal die Frequenz prüfen?


    Vielen Dank schonmal

  • Frequenzen NDR

    Hallo Leute,


    ich habe vor knapp einem Jahr mal über yaVDR Channelpedia eine eigene Kanalliste zusammengestellt. Dort werden für den NDR folgende vier Frequenzen gelistet:


    Code
    NDR FS HH HD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5221=27:5222=deu@3,5223=mis@3;5226=deu@106:5224;5245=deu:0:10329:1:1025:0
NDR FS MV HD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5221=27:5222=deu@3,5223=mis@3;5226=deu@106:5224;5235=deu:0:10328:1:1025:0
NDR FS NDS HD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5221=27:5222=deu@3,5223=mis@3;5226=deu@106:5224;5225=deu:0:10327:1:1025:0
NDR FS SH HD;ARD:11582:HC23M5O35P0S1:S19.2E:22000:5221=27:5222=deu@3,5223=mis@3;5226=deu@106:5224;5255=deu:0:10330:1:1025:0


    Auf allen 4 Frequenzen wird abends zw. 19:30 und 20:00 Uhr "Hallo Niedersachsen" anstelle des "Schleswig-Holstein Magazins" ausgestrahlt. Mein EPG sagt zwar, dass es das Schleswig-Holstein Magazin sein soll, ist es aber nicht:



    Meine Kanlliste entspricht Channelpedia bzw. den 4 oben aufgeführten Frequenzen.

    Mein System:


    Code
    root@vdr:~# vdr -V
vdr (2.2.0/2.2.0) - The Video Disk Recorder
live (0.3.0) - Live Interactive VDR Environment
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
epgsearch (1.0.1.beta5) - search the EPG for repeats and more
quickepgsearch (0.0.1) - Quick search for broadcasts
vnsiserver (1.5.2) - VDR-Network-Streaming-Interface (VNSI) Server
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu


    Alle Pakete kommen aus etobis repo bis auf vnsiserver, der wurde direkt aus dem aktuellen git-master kompiliert.


    Woran könnte das liegen? Kann mal jemand der das Schleswig-Holstein Magazin noch emfängt die Frquenzen prüfen?



    Vielen Dank und Gruß Hoppel