Beiträge von SED9

    Hallo,


    ja das ist der Nvidia Quirk den FernetMenta dann mal nach einiger Zeit herausgerückt hat, nachdem er aber zwischen


    f6264876 and ce28cb6 im Kodi Git oder seinen


    VideoPlayer commits einen anderen Nvidia Quirk entfernt hat. Denn bis f626487 trat dieses Problem nicht auf.


    Auch behebt er das Frame-skipping in Fullscreen nur teilweise, das Problem mit der CPU Last wird dadurch aber behoben.


    Dem Frame-skipping zu 100% entgegenwirken kann nur, indem man Kodi "windowed" betreibt, dann sollte man aber


    die Fensterdekoration des Windowmanagers abstellen.


    Ein echte Lösung wird sich aber bestimmt in nächster Zeit finden.



    Beste Grüße

    Hallo,


    ich habe die nötigen AddOns für Kodi 17 mal gebaut, die sind kompatibel zu Kodi 17 für Ubuntu LTS 14.04, 16.04 und yavdr 0.6 aus dem


    Team Kodi - Kodi Nightly Builds PPA sowie Libreelec 8.0, andere Distributionen habe ich bis jetzt nicht getestet.


    Auf Inputstream AddOn's - Kodi 17 findet ihr inputstream.mpd für Amazon Prime, enthält auch die libssd_wv.so, inputstream.smoothstream für SkyGo,


    sowie den aktuellen Confluence Skin (3.0.17) für Kodi 17, als installierbares .zip.


    Die libssd_wv.so ist kompatibel zur letzten Google libwidevinecdm.so aus dem aktuellen Google Chrome Browser.



    Die ganze Angelegenheit ist schon recht stabil, jedoch treten mit Kodi 17 und VDPAU in unregelmäßigen Abständen extreme Framedrops bei 25/fps Material (Amazon Prime, SkyGo) auf, eine Lösung konnte ich ich bis jetzt nicht finden,


    ich kann diese Framedrops auch nicht forcieren, die sind mal da und mal nicht, das Debuglog gibt da auch nichts her, eventuell könnte das jemand mal gegen checken oder meine VDPAU config ist fehlerhaft.


    Mit VAAPI oder dem RPi 2/3 gibt es diese Probleme jedoch nicht.






    Beste Grüße


    Kay

    Hallo,


    ist natürlich schwer zu erkennen wo der Fehler liegt.


    Wird denn bei dir

    Zitat

    /usr/bin/signal-event first-vdr-start


    ohne Fehler abgearbeitet, bzw. ist die Datei

    Zitat

    /etc/init/first-vdr-start.conf


    noch vorhanden?


    Löse /usr/bin/signal-event first-vdr-start mal händisch aus und stell den Output online, oft
    klemmt es wohl an dieser Stelle.


    Was mir noch eingefallen ist, wie installierst du yavdr, mit oder ohne GPU passthrough?


    Installierst du mit GPU passthrough, darfst du

    Code
    <features>
        <features>
        <acpi/>
        <apic/>
        <kvm>
          <hidden state='on'/>
        </kvm>
        <vmport state='off'/>
      </features>


    In der XML nicht vergessen, soweit du eine Nvidia Karte benutzt.


    Beste Grüße

    Hallo,


    Da gebe ich Dir recht, die 0.6.0 yavdr ISO war etwas buggy, UEFI ging bei mir nur nach dem ISO-rebuild, auch nach der Installation
    war etwas Nacharbeit angesagt, da wurden, soweit ich mich erinnere, teilweise verschiedene Kernelfragmente aufgespielt.<- oder in dieser Art


    Ich hatte, bei den älteren Ubuntu Versionen, das PPA von Jacob Zimmermann eingebunden,
    dieses war immer aktueller als die Ubuntu Repos.
    Zum Schluss hatte ich mir dann die Pakete aus den jeweiligen Git's gebaut, bis ich die Abhängigkeiten nicht mehr auflösen konnte, mein 14.10 war ja schon ewig abgelaufen.


    Jetzt läuft bei mir alles unter 16.04 ohne Probleme.


    Beste Grüße

    Hallo,


    in letzter Zeit hat sich doch viel getan.


    Kernel Patches sind nicht mehr nötig, da man jedes OS via OVMF betreiben kann, so hat ein Host mit Intel IGPU auch wieder seine Berechtigung,
    da er ohne Einschränkungen betrieben werden kann.


    Mir ist nur aufgefallen, Win sowie OSX Gäste, konnte ich nicht von Ubuntu 14.10 auf 16.04 übertragen, die USB Maus wden Command prompt urde via USB Pass trough vom Gast nicht erkannt,
    die Tastatur hingegen schon.


    Der Virt Manager zusammen mit der libvirt macht die Angelegenheit doch sehr komfortabel, missen möchte ich dieses Komfort feature nicht mehr, auf Scripting
    kann man getrost verzichten.


    Mal ein kurze Liste was via OVMF, Nvidia möglich ist, als Host Ubuntu 16.04, KVM/Qemu sowie Virt Manager und Libvirt aus dem Ubuntu PPA:


    Code
    OS         I440FX       Q35
    Win7         +           -        (unter Q35 kommt Fehler Code 12, beim durch reichen der Nvidia Karte)
    Win10        +           +
    Linux        +           +        (Ubuntu, Arch, Fedora, Suse bei Debian 8 wurde der Nvidia Treiber nicht erkannt, auf Gentoo habe ich verzichtet, ist nicht mein Fall)
    OpenElec     ?           +        (den I440FX habe ich nicht getestet)
    yaVDR 6      +           +
    Solaris      +           +
    FreeBSD      +           +
    OS X         -           +        (getestet mit 10.10 Yosemite und 10.11 El Capitan, via I440FX ist kein OVMF möglich, nur Bios)


    Recht aufwendig sind die Installationen von OpenElec sowie OS X, alles andere wurde mit der Standard ISO installiert.
    Android_X86 werde ich eventuell einmal testen, obwohl ich keine Ahnung habe wie es Nvidia Treiber seitig aussieht.


    Beste Grüße

    Hallo,


    dann schau dir doch mal auf der Fritzbox an was da abläuft.


    Oder richte mal kurzzeitig auf der Fritzbox einen Exposed Host für einen geblockten Client ein,
    so kannst du schon mal feststellen ob es die Fritzbox ist oder der Client selbst.


    Beste Grüße

    Hallo,


    nach einem dist-upgrade heute weigert sich der VDR die vom Sat>IP Server bereitgestellten Devices zu benutzen.


    Der Aufbau ist ein Mischsystem aus einer lokalen DD 5.4 DVB Karte und diversen Sat>IP Devices.


    Die lokale Karte stellt nur Astra 19.2′ bereit, die Sat>IP Devices 19.2°E, 28.2°E, 13°E und 9°E, mit folgernder


    diseqc.conf


    sources.conf


    Im vdr-plugin-satip Setup steht der Schalter, Betriebsmodus auf Normal, dann sollte normal
    ja das erste freie Device gewählt werden welches die gewünschte Sat Position auch zur Verfügung stellt.
    Es werden aber immer nur die lokalen Devices gewählt. auch wenn diese, die Sat Position nicht
    zur Verfügung stellen, außer beide lokalen Devices sind belegt, dann wird ein Sat>IP Device gewählt
    und es funktioniert alles ohne Probleme.
    Mit dem femon Plugin kann ich auch ohne Probleme zwischen lokalen und Sat>IP Devices umschalten.


    Ich bin der Meinung dieses Problem ist bei mir mit vdr-2.2.0-12yavdr0~trusty aufgetreten, welche Version davor
    lief kann ich nicht mehr sagen.


    Als Sat>IP Server habe ich es mit Minisatip, TVheadend und der OctoNet durchgespielt, überall zeigt
    der VDR das gleiche verhalten.


    Mit einer Parallelinstallation, von yaVDR 0.5.0, gibt es auf dem selben System kein Problem.


    Eventuell hat jemand einen Tip für mich was die Ursache sein könnte.


    Beste Grüße

    Hallo,


    dann tippe ich mal, dein Problem liegt an anderer Stelle.


    Ich konnte das iso von Lars leider nicht via EFI boot benutzen weder direkt noch unter KVM/QEMU, da half nur der oben genannte mkisofs Aufruf.


    Hast du denn einmal versucht ubuntu-server-14.04 via EFI aufzuspielen?


    Hier einmal die boot catalogs:


    yavdr64-0.6.0.iso



    yavdr64-0.6.0.iso mit oben genannten mkisofs Aufruf



    Ubuntu Server 14.04 iso



    Best regards

    Hi tanom,


    eventuell kann Mini das korrigieren,


    entpacke mal das .iso und dann mit:


    Code
    mkisofs -U -A "yavdr64-0.6.0" -V "yavdr64-0.6.0" -volset "yavdr64-0.6.0" -J -joliet-long -r -v -T -o ./yavdr64-0.6.0-efi.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e boot/grub/efi.img -no-emul-boot .


    ein neues .iso packen, so kannst du dann via EFI installieren.


    Legacy habe ich jetzt nicht getestet, sollte aber normal funktionieren.


    Best regards

    Hallo,


    hier mal ein kleines Beispiel:


    Code
    RTL HD IPTV;IPTV:40:S=1|P=0|F=HTTP|U=192.168.1.73/TS/3|A=3000:I:0:255=27:0;259=deu@106:32;48=deu:1A:61200:1:1057:0


    wird zusammengesetzt aus


    Code
    Name		Source	UnID	SNT-scn	PID-scn	Proto	URL			StrPara	S-Typ	Symbr	VPID	APID		TxtPID		CAID	SID	NID	TID	RID
    RTL HD IPTV;	IPTV:	40:	S=1|	P=0|	F=HTTP|	U=192.168.1.73/TS/3|	A=3000:	I:	0:	255=27:	0;259=deu@106:	32;48=deu:	1A:	61200:	1:	1057:	0


    Ist natürlich ein Beispiel für Sat, solltest du aber leicht übertragen können.


    Beste Grüße

    Hallo,


    Durch eure Posting,


    Damals war für die ganzen Receiver ein Firmware-Update nötig, um damit kompatibel zu sein (http://www.heise.de/newsticker/meldung/H…cht-931678.html) und es wurden einige der Einschränkungen, die die CI+ Module engeführt hatten, übernommen - sicher, dass das mit x-beliebigen Geräten mit CI-Steckplatz funktioniert?



    Soweit ich weiß haben die Legacy-Module eben nicht in jedem Receiver funktioniert, sondern nur in den Receivern die dafür ein spezielles Softwareupdate erhielten. Für CI-Interfaces für PCs gab es nie eine solche software, deshalb auch keine Funktion, das war Absicht.


    bin ich selbst etwas Skeptisch geworden und habe mal ein paar kleine Tests gemacht und meine HD01 und HD03 mal für einen Monat aufgeladen.


    Ist natürlich VDR Off Topic.


    Ergebnis:


    PHP
    DMM 7080HD mit Lagacy Modul          - HD01 O.K.   - HD03 N.O.K. mit CI+ Modul HD01,03 N.O.K.
    Samsung UE46ES mit Lagacy Modul      - HD01 O.K.   - HD03 N.O.K. nach Firmwareupdate wird das Lagacy Modul gar nicht mehr erkannt, mit CI+ Modul HD01,03 O.K.
    TechniSat-Receiver mit Lagacy Modul  - HD01 O.K.   - HD03 N.O.K. mit CI+ Modul HD01,03 N.O.K.
    Vantage-Receiver mit Lagacy Modul    - HD01 N.O.K. - HD03 N.O.K. mit CI+ Modul HD01,03 N.O.K.


    Einen VDR Test kann ich mir dann wohl sparen, jedenfalls können die beiden Receiver sowie das Lagacy Medul jetzt zum Wertstoffhof.


    Und wieder etwas dazu gelernt, danke Jungs.


    Beste Grüße

    Hallo,


    es gibt aber auch ein HD+ Legacy CI Modul, ohne CI+, damit funktionieren die Kartengenerationen HD01 und HD02
    in jedem normalen CI Schacht, also bestimmt auch mit dem VDR.
    Legal sollte es auch sein, soweit die CI Implantation im VDR selbst legal ist, wovon ich aber ausgehe.


    Beste Grüße

    Hallo,


    der i915 vga arbiter patch, ist nur nötig sollte kein OVMF EFI Bios verwendet werden können, nach meinen Erkenntnissen kann man so , WIN Vista - 7 - 8 - 10, Linux, FreeBSD, Solaris problemlos betreiben.
    Möchte man jedoch einen OSX Gast, ist bei Benutzung eines Sockel 1150 Boards und CPU mit integrierter Grafikeinheit ist der i915 vga arbiter patch Pflicht.


    Jetzt hat diese Kombination aber gravierende Nachteile, wie ich schon beschrieben habe,


    1. der Kernel Parameter: i915.enable_hd_vgaarb=1 deaktiviert DRI auf dem Host
    2. der Kernel Parameter: intel_iommu=on deaktiviert den Sound des HDMI/Displayports auf dem Host
    3. der Kernel Parameter: intel_iommu=on,igfx_off behält den Ton bei, deaktiviert aber DMAR


    Diese Szenarien habe ich mit Ubuntu, Fedora und Arch durchgespielt, es gibt da keine Unterschiede im Verhalten, egal ob Kernel 3.16, 3.18 oder 3.19.


    Für nicht OVMF Gäste rate ich zu einer XEON CPU ohne Grafikeinheit oder alternativ zum deaktivieren der Grafikeinheit solange man den IGP noch nicht an einen Gast
    weiterreichen kann und einer dezidierten Nvidia Grafikkarte für den Host sowie den ACS override patch.


    Obige ist meine persönliche Lösung, benötigt zwar ca. 4 Watt mehr aber behält die volle HW-Beschleunigung der Grafikeinheit den Ton über HDMI und die Möglichkeit jegliches OS
    mit GPU HW-Beschleunigung zu virtualisieren, in diesem Fall ist es egal ob die Gast Grafikkarte UEFI/GOP tauglich ist oder nicht da man ja nicht auf OVMF angewiesen ist.


    Für OVMF Gäste, reicht der Intel IGP, solange man auf den Ton über HDMI auf dem Host verzichten kann, eine UEFI/GOP taugliche Grafikkarte für den Gast einsetzt und der ACS override patch.


    Best regards

    Hallo,


    ich bin immer noch vollauf begeistert, was mit KVM-QEMU und der libvirt so alles möglich ist.


    zu OVMF:


    MS Produkte lassen sich nur mit Original Microsoft ISO Images unter OVMF installieren, meine selbst erstellten ISO Images unter Benutzung
    der Installations DVDs habe ich nicht installiert bekommen.
    Unsere IT war dann so nett mir MSDN Iso Images zur Verfügung zu stellen mit denen gibt es keine Probleme.


    Linux Iso Images lassen sich OOTB via OVMF installieren, getestet habe ich Ubuntu/Linux Mint 15.4, Fedora 21 Workstation und Arch 2015.02.01.


    Solaris sowie FreeBSD machen da keinen Unterschied.


    Bei allen oben genannten war es nötig KVM-QEMU vor dem Nvidia Treiber zu verstecken,


    Code
    <features>
      <kvm>
        <hidden state='on'/>
      </kvm>
    </features>


    mit diesem Eintrag in der XML, hat man volle Hardwarebescheinigung mit der Nvidia Grafikkarte.


    Mir ist da noch ein nettes - Its not a bug, its a feature - aufgefallen,


    OVMF setzt ja normal eine UEFI/GOP taugliche Grafikkarte vorraus, installiert habe ich auch mit GTX750ti, doch nach
    der Installation konnte ich ohne Probleme eine GT520, die kein UEFI/GOP Bios hat, an den Gast weiterreichen, inklusive
    Hardwarebescheinigung.
    Dieses ist mir nur dadurch aufgefallen, da ich die Grafikkartensteckplätze auf dem Mainboard getauscht habe und der Loginscreen
    auf dem anderen Monitor erschien.


    ---------


    Ich hatte dann, im laufe meiner Tests mein System umgebaut, da z.B. der Kernel Parameter, i915.enable_hd_vgaarb=1, DRI auf dem Host deaktiviert - gleich Verlust
    der Hardwarebescheinigung auf dem Intel Host oder intel_iommu=on, den Ton über HDMI/Displayport deaktiviert,
    intel_iommu=on,igfx_off schaltet den Ton wieder ein aber deaktiviert DMAR, was zur Folge hat, es ist kein durch reichen der GPU an den Gast mehr möglich.
    Mein Fazit ein Intel I5/I7/XEON mit Grafikeinheit ist nicht der ideale Gastgeber für KVM-QEMU, aber nur bezogen auf meine Hardware mit Intel z97 Chipsatz,
    ich habe keine Ahnung wie es sich mit anderen Chipsets verhält.


    Mein System schaut jetzt wie folgt aus:
    Intel Xeon E3-1246V3 (Grafikeinheit deaktiviert via pci_stub, wird so nicht initialisiert, lspci listet sie so auch nicht)
    Asrock Z97 Extreme6, mit 32(2x16) GB DDR3 Ram
    Asus GT520 für den Host
    2 x MSI GTX750ti für die Gäste
    Samsung 850 Evo 500GB, für Host und Gäste


    Ubuntu 14.10 als Host mit Kernel 3.18 und acs override patch, Kernelparameter intel_iommu=on, pcie_acs_override=downstream(zum trennen der iommu Gruppen)
    KVM-OEMU 2.2, libvirt 1.2.12, virt-manager aus dem Git


    virt-manager OVMF Gäste:
    WIN 7SP1
    WIN 8.1
    yavdr testing
    Arch Linux


    virt-manager Seabios Gäste:
    Der Nationalpark aus Cupertino in der Version 10.10.2, Vanilla ohne H...in..sh patches (OVMF habe ich nicht hin bekommen, eventuell schafft es jemand anderer mit mehr know how als ich)


    Die Installation war wesentlich aufwendiger als die anderen, liegt nicht an OVMF sondern am OS selbst.



    best regards