Beiträge von mahlzeit


    Nach dem Flash erfreut festgestellt, dassder Login über SSH nicht mehr mit einem beliebigen Passwort funktioniert, aber das eingestellte war nicht wirklich schwer zu erraten. Schon beim 2. Versuch hatte ich Erfolg: "MEG-8000". Passwortänderung ging zwar über SSH, der Server war auch danach nur noch über das neue Passwort erreichbar, aber nach einem Reboot war es wieder das Standardpasswort. Die anfängliche Freude war wieder dahin... Ein nicht (dauerhaft) änderbares (für alle Server gleiches) Passwort ist genauso gut wie kein Passwort :(


    cu
    Markus

    das klingt sehr interessant. Das würde ja bedeuten, greift man mit einem MiniSatIP Server auf den Megasat SAT2IP Server 3 zu, könnte das die bisher beschriebenen Probleme ggf. umschiffen?! Eine weiter Frage die offen bleibt ist der EPG Scan.


    Wo genau die Probleme am Anfang waren, weiß ich nicht. Ich hatte mir die Logfiles nicht gesichert (Log2Ram) und seitdem ist es nicht wieder aufgetreten. Aber es reichte aus, den MiniSatIP Server neu zu starten. Die Tuner des Megasat können es nicht gewesen sein, die wurden nicht neu gestartet, es muss etwas mit dem Netzwerk zu tun haben. Ob das jetzt eine Schwäche der Sat2IP Implementierung auf Seiten des Megasat oder auf Seiten des MinisatIp ist, kann ich nicht beurteilen.


    Mahlzeit

    Servus,


    jetzt muss ich auch mal meinen Senf dazugeben. Ich habe den Server 3 (aktuelle Firmware) jetzt seit ca. 4 Wochen im Produktiveinsatz. Probleme gab es nur kurzzeitig am Anfang und die waren vermutlich auch nicht dem Server 3 zuzuschulden.


    Ich habe eine etwas "andere" Konstellation in meinem Rechnerpark, vieles ist virtualisiert und das war auch, neben den 8 Tunern für diesen Preis, der Hauptgrund, weshalb ich mir den Megasat angeschafft habe. Seit ~4 Jahren hatte ich eine Digital Devices 6.5 mit zusätzlichen Doppeltuner im Einsatz, durchgereicht zuerst in eine virtuelle Maschine mit yaVDR, zuletzt in ein virtuelle Maschine mit MiniDVBLInux 5.1. Basis waren verschiedene Proxmox Versionen, mit dem Umstieg auf den SatIPServer und der Verbannung der Digital Devices aus dem Rechner ist jetzt die 4.4 drauf. Neben dem VDR laufen noch ein paar andere virtualisierte Linux-Kisten (u.a. OpenMediaVault, welches die vom Host direkt durchgereichten SATA Platten verwaltet und den restlichen Windows Clients SMB Dienste sowie den virtualisierten und physikalischen VDRs per NFS die Aufnahmeverzeichnisse zur Verfügung stellt) sowie ein Windows 10.


    Der 24/7 (virtualisierte) VDR Server greift nicht direkt auf den SAT2IP Server zu, sondern holt sich die Datenstreams von einem (für hellere Bilder gepatchten) MiniSatIP Server (ebenfalls virtualisiert auf Basis von MLD 5.3). Bislang hatte in Anfangs 2x den Effekt, dass der VDR Server keine Stream mehr empfangen hat. Das lies sich mit einem Neustart des MiniSatIP Server beheben. Ob das Problem am Megasat lag (der ohne Restart etc. auskam) oder am MiniSatIPServer (der danach wieder brav alles lieferte, was der VDR verlangt hat) weiß ich noch nicht. Aber nachdem der Megasat weiterhin reagiert hat und auch nicht neu gestartet werden musste... Neben dem VDR gibt es auch noch 2 RasPi mit MLD 5.1 als Clients sowie 2 Laptops, die sich das Bild noch per StreamdevServer Plugin vom VDR holen.


    Das ganze Gespann läuft seit 14 Tagen (da gab es eine Zwangspause wegen Umbau mit Stromabschaltung) ohne Ausfall oder Probleme, täglich werden mehrere Aufnahmen gemacht und parallel dazu noch LiveTV geschaut. Ich bin also mit dem Gerät zufrieden und kann bisher nichts negatives berichten. Einzip den EPG Scan habe ich deaktiviert, da das über EPGd läuft.


    Mahlzeit

    Servus,


    konkret zu Deinem Problem kann ich nix sagen, aber der Reboot der VM und/oder des Hosts kann evtl. vermieden werden, wenn Du nur die Cine einen Reset machen lässt. Ich habe das hier beschrieben. Die Probleme, dass die Karte nicht mehr reagiert, hatte ich aber seitdem auch nicht mehr. Da es ja nur sporadisch war, kann ich nicht sagen, ob der Kernel-Downgrade oder der Upgrade auf einen neue Proxmox-Version damals die Aussetzer behoben hat. Aber da Du das ja jetzt mit der aktuellen Version hast...


    Blacklist habe ich keine angelegt, lediglich eine "iommu_unsafe_interrupts.conf" mit Inhalt "options vfio_iommu_type1 allow_unsafe_interrupts=1" angelegt, weil ich ein paar Kernel-Panics auf dem Host hatte. Module für die DD sind auf dem Host geladen, stören aber nicht, die Karte funktioniert seit langer Zeit einwandfrei in der VM mit MiniDVBLinux.


    cu
    Markus

    Der FireStick ruckelt und liefert unscharfe Bilder.


    Ich hab sowohl die FireTv Box (an einem 42" LG TV) als auch den Stick (an einem Samsung 23" Monitor), bei beiden kann ich nicht klagen. Vielleicht sind die Augen nicht mehr die besten, aber Unschärfe kann ich keine feststellen (geeignetes Ausgangsmaterial vorausgesetzt). Ich denke eher, dass bei Dir eine falsche Auflösung bzw. der Overscan für ein matschiges Bild sorgt (Sowohl bei meinem LG als auch beim Samsung kann ich mehrere "Presets" am Eingang auswählen, schau mal ob Du da was umstellen kannst). Ebenso kann ich bei beiden kein Ruckeln feststellen. Das könnte bei Dir wiederrum auch mit einer falschen Auflösung bzw. mit der einhergehenden falschen Bildwiederholfrequenz zusammenhängen.


    cu
    Markus


    PS: Da OT, könnte einer der Mods das evtl. als eigenen Fred umhängen?

    Servus,


    ich weiß nicht ob das Problem noch aktuell ist. Ich bin heute auch auf Proxmox 3.4-1 und Kernel 3.10.0-8-pve umgestiegen. Prompt wollte natürlich meine CineS2 nicht mehr durchgereicht werden. Abhilfe schaffte folgendes in der vm config:

    Code
    1. machine: q35
    2. hostpci0: 02:00.0,driver=vfio,pcie=1


    Danach klappte alles wieder ohne Probleme beim Start der VM, das PCIe Device war auch wieder in der VM nutzbar.


    Infos waren aus http://forum.proxmox.com/threa…10-kernel-in-pvetest-repo


    cu
    Markus

    Servus,


    hier meine funktionierende Konfiguration:


    • CPU und Mainboard müssen vt-D unterstützen und im BIOS muss die Funktion auch aktiviert sein. Ist per Default gerne mal deaktiviert.
    • Mein Eintrag in /etc/default/grub:
      Code
      1. GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fcb=1 i915.lvds_downclock=1"

      . Config neu erzeugen nicht vergessen ;)

    • in /etc/modprobe.de/blacklist.conf:
      Code
      1. #dvb
      2. blacklist dvb_usb_dw2102
      3. blacklist ir_lirc_codec
      4. blacklist lirc_dev

      Das "blacklist pci-stub" kannst Du entfernen, den pci-stub brauchst du auf dem host.

    • in (Bsp.) 102.conf:
      Code
      1. hostpci0: 02:00.0

      , hostpci entsprechend deinen Gegebenheiten anpassen, mein lspci auf dem Host:


    • Reboot und sollte tun.


    Meine Hardware:
    Mainboard: MSI Z68MA-G43 (G3) (MS-7676)
    CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz

    Servus,


    nicht mein tag heute. Jetzt habe ich bei vdr-plugin-svdrposd ein Problem in testing-vdr als auch in unstable-vdr.


    Eine Suche nach dem Paket bringt folgendes:

    Code
    1. root@trusty:/etc/apt/sources.list.d# aptitude search vdr-abi-2.0.0-debian
    2. v vdr-abi-2.0.0-debian -
    3. v vdr-abi-2.0.0-debian:i386


    Any hints?


    cu
    Mahlzeit


    PS:

    Das main-PPA hast du auch eingebunden? Da ist ein ffmpeg 2.2.2 Paket drin, von dem markad (und u.a. auch die Version von softhddevice in dem PPA) abhängen: https://launchpad.net/~yavdr/+archive/ubuntu/main


     :wand Danke... Funktioniert jetzt... ;)


    Zitat

    Generell ist testing-vdr für trusty ganz schön veraltet, aktuell ist bei mir die Zeit etwas knapp und ich habe mich in letzter Zeit nur um unstable-vdr für trusty gekümmert (das zusätzlich von unstable-main abhängt).


    Was ist den aktuell für trusty besser geeignet? vdr-unstable oder vdr-testing (was die relative Stabilität angeht. Muss nicht das neueste sein, nur eben so stabil wie möglich für trusty)?


    cu
    Mahlzeit

    Servus,


    ich habe gerade auf einem Ubuntu trusty das yavdr-testing PPA eingebunden und habe Probleme bei der Installation von vdr-plugin-markad:


    Die Pakete "libavcodec55-ffmpeg" sowie "libavutil52-ffmpeg" finden sich nirgends. Ist da beim Build im PPA was schief gelaufen oder ist das ein Fehler in den Abhängigkeiten von vdr-plugin-markad? Wer kann Licht ins Dunkel bringen? ;)


    Danke!
    Mahlzeit

    Entsprechende Stromsparfunktionen sind im BIOS des Mainboards auch aktiviert? War bei meinem MSI Board am Anfang auch so, EIST war (aus welchem Grund auch immer) deaktiviert, was wirkungsvoll verhindert hat, dass der Kernel die CPU in den Stromsparmodus bringen kann. Wär evtl. auch noch nen Blick wert.
    Was die DVB Karten angeht, die werden nur dann in den "Schlafmodus" versetzt, denn Du das dynamite Plugin installiert hast. Leider weckt das wohl zur Zeit die Cine S2 nicht immer zuverlässig wieder auf, da gibts schon nen anderen Thread dazu. Sonst würde das auch noch mal ein paar Watt sparen.


    cu
    Markus


    Woho!! Ich hab einen Core i7 3770 (Quad mit HT), 16 GB DDR3, 1 DD Cine 6.5 (4 Tuner), 3 3,5" Platten (insgesamt 8TB) und 2 2,5" Platten (jeweils 500GB), yaVDR mit PCI Pass Through, Win8 und einige Linux VMs bei 44W (3,5" Platten im Sleep, wenn alle laufen sind es so um die 60-65W, je nachdem was auf der Platte grad los ist, wenn das Dynamite Plugin die Cine wieder zuverlässig aufwecken würde, wären es sogar nur um die 38W Idle (1 Tuner aktiv)). Gemessen mit Conrad C3000 und den Pollin Funkteilen (Unterschied ~2W, also Messungenauigkeit). Da erscheinen mir Deine 120W etwas[tm] viel! Selbst wenn man die Nvidia abzieht (die ja eigentlich gar nicht gebraucht wird), bleibt da noch zu viel übrig :(


    Als System nutze ich ProxMox PVE (nutzt kvm als Hypervisor auf einem Debian Unterbau) mit einem selbst zusammengestellten Verbrauchsoptimierungsskript.

    Hallo,
    ich bin Amazon.de Prime Kunde und wohne in Frankreich.
    ...
    Das Eintragen eines deutschen Proxies bringt nichts.
    ...


    Vermutlich reicht dieser Proxy Deine IP durch (bei Squid müsste es die Option "forwarded_for [on|off]" sein). Du bräuchtest also einen deutschen Proxy, der das nicht tut. Ad hoc kann ich Dir jetzt aber keinen nennen.


    cu
    Markus