Posts by tecfreak

    Mach es so wie johns es beschrieben hat, also mit "hdmi:..." statt "hw:...".


    In deinem Fall ist es eines der folgenden devices:


    ...also dev 0,1,2 oder 3.


    Mach den speaker-test mit -c2 um zu ermitteln welches der devices es ist.

    Code
    speaker-test -c2 -D hdmi:CARD=NVidia_1,DEV=0

    Ich glaube einfacher wäre es erstmal der Karte die zusätzliche Stromversorgung zu gönnen. ;D


    Ich habe zwar erst vor zwei Monaten eine V7 verbaut, kann mich aber beim besten willen nicht mehr dran erinnern ob ich da einen Stromstecker angeschlossen habe.

    Bei einem paravirtualisierten guest Sytem ist für das Durchreichen der Hardware VT-d nicht nötig. Auch message-signaled interrupts stellen kein Problem mehr dar.
    Mein server (siehe signatur) zieht im Normalbetrieb um die 45W.


    Als CPU könnte je nach Anforderung auch schon ein Pentium G reichen oder ein i3. Für VT-d müsste es dann schon ein i5 sein.
    RAM nimmst du einfach den günstigsten und von der Taktung her passend zum Controller. Ggf. drauf achten, dass die Riegel mit 1,5V bzw. 1,35 (DDR3L) laufen.


    Was das Board angeht und wenn VT-d gewünscht ist, dann kannst du dich hier mal umschauen -> http://wiki.xenproject.org/wiki/VTd_HowTo
    Ansonsten alles ab H87/H97 und nach gewünschter Anzahl an Erweiterungssteckplätzen, NIC(s), Formfaktor usw...


    Platten würde ich weiterhin die WD Red empfelen. Den komischen Seagate Platten traue ich irgendwie nicht über den Weg. kann aber sein, dass ich mich da täusche.


    Beim Netzteil auf hohe Effizienz im niedrigen Leistungsbereich achten. Da gibt es schöne Vergleichsseiten. Einen Link habe ich grad aber nicht parat. PicoPSU kannst du dir bei solchen Installationen sparen. Fürs gleiche Geld oder gar etwas weniger gibt es schon ATX Netzteile die genauso effizient sein können.



    Gruss
    tec

    speed


    wie hast du das hinbekommen?
    Bei allen meinen Versuchen mit vdr 2.2.0 und dem bösen d*** plugin (d* und o* jeweils aus dem git bzw. svn) gibt es meist ein schwarzes Bild beim Umschalten bis dann irgendwann nur noch "Kanal nicht verfügbar" kommt und einem nur noch ein restart des vdr bleibt.


    Was hast du sonst noch für plugins auf dem server laufen?
    Client auch vdr 2.2.0 und streamdev-client auf dem gleichen stand wie der server?
    Läuft o* im network oder im klassischen Modus?
    Welche patches hast du beim vdr benutzt?

    In dieser Leistungsklasse bringt dir mehr Speicher garnichts.
    Um dir eine Empfehlung geben zu können, müsste man wissen welche Spiele gespielt werden.
    Gaming und passive Kühlung sind aber zwei Sachen die sich nicht vertragen.


    Ein preiswerter und sparsamer allrounder wäre eine GTX 750 mit 2GB. Die Radiatoren bei den passiv gekühlten Modellen sind aber monströs.
    Alternativ ein Modell mit GK208 und mit GDDR5 statt DDR3 für etwas mehr 3D-Leistung, aber diese Kombination gibt es leider nur mit aktiver Kühlung und zum spielen taugt die nicht wirklich was. Kommt aber wie gesagt auf die Spiele an.


    Was ist denn aktuell in dem System drin?



    Gruss
    tec

    Probier mal ob es was bringt wenn du die maximale Anzahl an receiver- und device-PIDs erhöhst:

    Bei verlustfreien Formaten wie WAV oder FLAC und bei Bitstream von DTS-HD o. Dolby TrueHD (betrifft auch die verlustbehafteten Vorgänger) macht das keinen Unterschied ob du über HDMI rausgehst oder streamst. Eine mp3 dagegen kann sich je nach DSP am AVR dekodiert u.U. besser anhören als wenn diese vorher am PC per Software dekodiert und zu PCM gewandelt wird.
    D/A-Wandler spielen bis hier hin auch keine Rolle außer man geht am PC Analog raus was heutzutage aber kaum noch Sinn macht.

    Auf eine Aussage von Manio auf seinem git-repo. Hab aber die ML und Changelogs durchforstet und nichts diesbezüglich gefunden.
    Denke dass das cam-handling damit nicht wirklich was zu tun hat und Manio in dem Punkt nicht ganz richtig lag mit seiner Vermutung.


    Hab vdr 2.1.6 auch mit xvdr getestet und da gab es keinerlei Probleme beim Umschalten. Den Fehler führe ich mittlerweile auch auf die channelchange Funktion zurück soweit ich das als Laie überhaupt beurteilen kann oder das erneute GetDevice ist nur ein workaround und das cam-handling des vdr seit 2.1.4 in der Tat nicht ganz korrekt. Ich teste das am WE mal und mach die Änderung aus 2.1.4 wieder rückgängig.



    Gruss
    rec

    Das Ticket habe ich aufgemacht. Mittlerweile gehe ich davon aus, dass es nicht am Cam-handling liegt, denn streamdev hat ja keinen Einfluss drauf. Ich schätze es liegt an dem ChannelChange.
    Wenn ich mir das bei plugin-xvdr anschaue, so sehe ich beim ChannelChange ein Detach und anschließend ein GetDevice was bei streamdev nicht der fall ist. Ausserdem wird auch vorher geprüft ob ein cam vorhanden ist (generell bei swictchannel) das den Sender auch entschlüsseln kann.
    Das ganze hängt vermutlich damit zusammen, dass der VDR neuerdings bei jedem geänderten PID ein re-tune durchführt was mMn. nur in den seltensten Fälle nötig ist (hat ja bisher auch so funktioniert).


    schmirl
    Falls du hier mitliest - kannst du dir das evtl. mal aschauen?



    Gruss
    tec

    knebb


    noad/markad und epgsearch hast du beim vdr ja nach wie vor. Nur wenn du im xbmc mit einem pvr-addon am vdr andockst um xbmc mit Hilfe des vdr um die Live-TV Funktionalität zu erweitern hast du eben diese Funktionen nicht. Die meisten nutzen aber den VDR direkt für Live-TV & Aufnahmen und alles was so dazu gehört mit einem seiner Ausgabeplugins und schalten um auf xbmc wenn andere Medien geschaut/gehört werden sollen. Wie seahawk1986 bereits schrieb ist der Wechsel von VDR-Frontend zu XBMC und umgekehrt mittlerweile Bestandteil der meisten VDR-Distributionen.
    Spielereien wie damals mit dem dvd-, cdda-, mplayer- oder music-plugin tut sich heutzutage keiner mehr an.


    rkp
    Silverstone ML04