Beiträge von KiLLERHOLiC

Ich glaube auch nicht das es notwendig ist das der ESXI die Karte erkennt. Nur das Betriebssystem in der virtuellen Maschine muss die Hardware erkennen.

Sent from my Galaxy Nexus using Tapatalk 2

Welche ESXI Version hast du installiert?
Mit der 5.1 hat es bei mir auch nicht funktioniert, mit der 5.0 läuft es.

Gesendet von meinem Galaxy Nexus mit Tapatalk 2

Zitat von Bernie7

Hallo Rio,

du kannst natürlich auch yaVDR nehmen. Im Web-Interface kannst Du die Ausgabe auf "headless" stellen, das ist genau das was Du willst.
....

Naja... seit der 0.5 Version ist das nur möglich wenn eine Nvidia Grafikkarte im System ist.
Hab es selbst erlebt, einmal in einer ESXI-Maschine installiert -> umschalten auf Headless war nicht möglich (dank dieser Anleitung gehts dann doch: yaVDR 0.5 auf ESXi 5.1 mit Mystique SATIX S2 XPRESS DUAL - running),
zweites mal auf einem physischen PC mit ATI Grafikkarte installiert -> umschalten auf Headless war nicht möglich (hab kurz gegen eine Nvidia getauscht, umgeschaltet und dann wieder die ATI eingebaut).

Zitat von da_oli

Hoi,

ich bin mir jetzt nicht sicher ob ich hier richtig bin und ob ihr das so schon gelöst habt.
Ich würd das gern so wie ihr, mit esxi, realisieren
Dort die Sat Karte oder auch Stick verbauen.

Und dann vom Client aus die Sat Programme streamen.

Geht so was oder bin ich hier im thread falsch?

Grüße

Oli

Alles anzeigen

genau richtig, an deiner stelle würde ich mal den ersten post genau lesen. dort steht schon alles wesentliche.

Zitat

Also ich habe nun eine Cine S2 v6 verbaut.
In einem PCIe-Port des ESXi stürzt der Hypervisor! kurz nach dem Aktivieren der Karte im VDR ab. In einem anderen Port läuft sie problemlos.
Etwas unschön ist noch, dass die Karte im ESX nur als Unknown Unknow erkannt wird. Stört aber niemand.
Also fast perfekt.

Inzwischen läuft auch die Aufnahme per NFS auf den Fileserver.
Als Client nutze ich auf meinem ehemaligen ION-VDR Openelec. Nur die HD-Kanäle habe komische Probleme beim Deinterlacen. Das ist aber jetzt eine andere Sache .;)

Welche ESXI Version verwendet du?
Mein erster Versuch war mit der 5.1 und damit konnte ich kein einziges Gerät durch reichen. Mit der 5.0 update 1 klappt es aber super.

Sent from my Galaxy Nexus using Tapatalk 2

Zitat von ralfk

...
Lösung hierfür war zunächst die Installation der VMWare-Tools in der virtuellen Maschine und anschließend die Installation des Pakets "xserver-xorg-video-vmware", dass den fehlenden VMWare-Treiber für X mitbringt. Nach einem Neustart der VM läuft auch das Backend und man kann auf Headless umschalten, was zwar auch mit einem "Einstellungen können nicht gespeichert werden!" quittiert wird, aber dennoch zumindest soweit funtkioniert, dass das WebIF nach einem Neustart als Frontend "Headless" ausgibt und das Backend auf "running" steht.
...

Herzlichen Dank für diesen Tipp, ich bin auch gerade dabei einen yaVDR 0.5 in einer ESXI Maschine zu konfigurieren und hatte genau dieses Problem.
Werde es gleich heute Abend probieren ob das bei mir auch funktioniert. Ich hab in der zwischenzeit ein eigenes upstart-Skript erstellt das den VDR startet... ist auch nicht ganz so sauber aber es lief zumindest mal.
Sonnst kann ich nur berichten das die Maschine jetzt ca. eine Woche läuft und zwei Clients versorgt (abwechselnd, es sind nie beide gleichzeitig aktiv).
Meistens funktioniert auch alles wie gewünscht, seltem bleibt das Bild am Client aber schwarz, da hilft nur ein weiteres mal umschalten dann läuft es wieder.
TV-Karte ist eine Satelco Easywatch DVB-C, ist aber nur solange ich noch nicht übersiedelt bin. Später werden 2 DVB-S2 Dual Karten reinkommen, freu mich wenn ich schon mal Erfahrungsberichte zu dem Thema lesen kann.

Zitat von DocViper

Und du bist dir sicher das der VDR ansich nicht läuft ?

Der Upstart Job von VDR wartet eigentlich auf nichts außer auf Netzwerk wenn ich mich nicht täusche.
Fürchte da musst du dich selbst mit dem Thema upstart beschäftigen.

top liefert für den user vdr keine prozesse, und sonnst läuft auch nichts was mit vdr zu tun hat.
Und initctl list liefert immer vdr start/starting. Und im syslog steht auch nix von einem vdr-Prozess.
Hab es jetzt anders gelöst, hab mir ein eingenes upstart Skript gemacht (das im wesentlichen auf dem original vdr Skript basiert):

start on (net-device-up and local-filesystems and runlevel [2345])
stop on runlevel [016]


script
# load default values and overrides from /etc/default/vdr
. /usr/lib/vdr/config-loader


mkdir -p /var/run/vdr
chown -R vdr:vdr /var/run/vdr




# load all plugins from plugin folder
. /usr/lib/vdr/plugin-loader


# extract and prepare all commands
. /usr/lib/vdr/commands-loader
mergecommands "reccmds"


# Set shutdown command
test "$ENABLE_SHUTDOWN" = "1" && VDRSHUTDOWN="/usr/lib/vdr/vdr-shutdown.wrapper" \
                              || VDRSHUTDOWN="/usr/lib/vdr/vdr-shutdown-message"


# enable debug measures
if [ "$(basename $DAEMON)" = "vdr-dbg" ]; then
   ulimit -c unlimited
   OPTIONS="$OPTIONS --userdump"
   echo "/var/log/vdr/core.%p" > /proc/sys/kernel/core_pattern
fi


# set language (default by environment, else by /etc/default/vdr)
LANG=$VDR_LANG
LC_ALL=$VDR_LANG
export LANG LC_ALL


if [ -n "$VDR_CHARSET_OVERRIDE" ] ; then
   export VDR_CHARSET_OVERRIDE=$VDR_CHARSET_OVERRIDE
fi


export HOME=/var/lib/vdr


exec $DAEMON --lirc=$LIRC -v $VIDEO_DIR -c $CFG_DIR -L $PLUGIN_DIR -r $REC_CMD -s $VDRSHUTDOWN -E $EPG_FILE -u $USER -g /tmp --port $SVDRP_PORT $OPTIONS "${PLUGINS[@]}" $REDIRECT
end script

Damit wird der vdr beim hochfahren gestartet und alle Konfigurationsfiles etc.. werden auch berücksichtigt.

Zitat von DocViper

Dann probier das hier mal. Das ist nicht update sicher (sprich wenn ein update von yavdr der yavdr-util rauskommt musst du das erneuern)

[solved] [yavdr0.5-beta] SoftHDDevice kommt nicht hoch
Das war mein Ansatz zur Lösung

Blöde Frage aber warum willst du eigentlich yavdr auf einer virtuellen Maschine verwenden ?
Nimm ein Ubuntu Server Minimum und füge vdr, streamdev und falls du xbmc auf den clients verwenden willst nach xvdr hinzu (aus dem yavdr ppa) .

Was versprichst du dir davon im speziellen bzw. welche Funktionen benötigst du ?

Alles anzeigen

Das mit dem wait-forever hab ich auch schon getestet, hab ca. 5 min. gewartet und der vdr wollte immer noch nicht starten.
Zum Thema yavdr in virtueller Maschine: Ich hab noch 2 richtige yavdr Systeme bei den TV-Geräten und die integration die yavdr bietet ist einfach super (automatische mounts, senderliste nach neu installieren vom server holen...).

Zitat von DocViper

Dass das Speicher nicht funktioniert hat vermutlich was mit der nicht korrekt erkannten Soundkarte zu tun. Bei der 0.5 alpha lief das noch Problemlos und hat sich bei der beta und stable verändert.

Hier mal prüfen in der /etc/init/sound-device.conf

[solved] [yavdr0.5-beta] SoftHDDevice kommt nicht hoch

Empfehlenswert ist noch der Befehl:

Code

sudo initctl list | grep vdr

stat vdr halt was auch immer interessiert

Damit kannst du testen welcher upstart job hängt bzw. was läuft

Alles anzeigen

Ich hab überhaupt keine Soundkarte im System, liegt es etwa daran? Es bringt mir auch nichts mit der card-Nr herumzuspielen da ja überhaupt keine Karte da ist.
Syslog: http://pastebin.com/kLKqkDFZ

Zitat

Na ich vermute Openbox wird nicht funktionieren weil keine Nvidia Grafikkarte gefunden wird.

Yavdr als virtuelle Maschine laufen zu lassen ist wohl möglich - aber benötigt Expertenwissen.
Wie wäre es mal per Webinterface auf Headless Modus umzustellen. Dann wird auch kein XServer mehr gestartet würde ich behaupten.

Joe

Headless modus habe ich bereits versucht, allerdings klappt das speichern nicht, siehe startpost.

Sent from my Galaxy Nexus using Tapatalk 2

Zitat

Hi,

vielleicht mal ein komplettes Syslog vom Booten ?
Und ein Syslog von service vdr restart.

Syslog kann ich später noch liefern aber vom vdr Prozess ist darin nichts zu sehen. vdr restart liefert auch nichts.

Sent from my Galaxy Nexus using Tapatalk 2

Hallo,

ich hab heute Vormittag yaVDR 0.5 Final in einer virtuellen Maschine auf meinem ESXI Server (5.0) installiert.
Allerdings habe ich das Problem das der VDR nicht startet.
Ein status vdr liefert vdr start/starting
Im syslog finde ich überhaupt nichts vom vdr-Prozess, wenn ich nach vdr suche finde ich nur einige Treffer vom avahi-mounter.
Im Webinterface wollte ich auf headless umstellen, allerdings funktioniert das auch nicht (Meldung: Fehler beim speichern der Daten) syslog:

Oct 20 15:01:48 yavdr01 /usr/bin/signal-event.real[2515]: processing signal change-frontend
Oct 20 15:01:48 yavdr01 /usr/bin/signal-event.real[2515]: processing action /usr/share/yavdr/events/change-frontend/10_change-frontend change-frontend
Oct 20 15:01:48 yavdr01 /usr/bin/signal-event.real[2515]: processing action /usr/share/yavdr/events/change-frontend/15_create-menuorg-xml change-frontend
Oct 20 15:01:48 yavdr01 /usr/bin/signal-event.real[2515]: processing action /usr/share/yavdr/events/change-frontend/20_stop-vdr change-frontend

Starte ich den VDR manuell funktioniert dieser auch wie erwarted:
sudo vdr -c /var/lib/vdr -v /var/lib/video.00/ -u vdr -P streamdev-server -P control

sehr oft steht auch folgendes im syslog:

Oct 20 09:12:46 yavdr01 kernel: [   18.582553] init: openbox main process (840) terminated with status 1
Oct 20 09:12:46 yavdr01 kernel: [   18.582574] init: openbox main process ended, respawning
Oct 20 09:12:46 yavdr01 kernel: [   18.595568] init: plymouth-stop pre-start process (1261) terminated with status 1

openbox ist ja die grafische Oberfläche (X) wenn ich das richtig verstanden habe. Diese started überhaupt nicht und wird in meinem Fall auch nicht benötigt.

Was kann ich noch machen?

Zitat

Nein kann sie nicht, aber das hindert KVM nicht eine PCI-Karte an einen Client durchzureichen, ich meine auch ESXi zickt da nicht sonderlich rum ...

Directed I/O aka VT-d aka IOMMU bedarf recht aktuelle CPUs und Chipsätze. Bei Intel z.B. min. einen Q-Chipsatz und einen Core i5, wobei das nicht alle von denen können, Specs beachten. Bei AMD muß es IIRC schon einer der FX CPUs sein, evtl. konnte das schon der ein oder andere Phenom, bei den AMD Chipsätzen bin ich grad nicht auf dem laufenden ...

Aber es funktioniert sehr wohl auch ohne, nur eben nicht ganz mit dem Datendurchsatz wie bei nativer Ansteuerung oder Directed I/O ...

Regards
fnu

Alles anzeigen

Hast du zum Thema ESXI mehr Infos?
Hab es auf einem Asus P5Q Pro mit Q9450 CPU installiert und dort funktioniert das durch reichen von PCI Geräten nicht. Laut den Infos die ich gefunden habe ist ein Q-Chipsatz Pflicht.

Gesendet von meinem Galaxy Nexus mit Tapatalk 2

Zitat von Mreimer

Braucht es denn epgsync? Schau dir mal die Man-Page von streamdev genauer an. Streamdev sollte fähig sein, dein DVB-Signal so zu streamen, dass dein Client-VDR über ganz normale VDR-Funktionen zum EPG kommt.

Wenn ich im streamdev Filter Streaming aktiviert habe ist da zappen langsamer bzw. das zappen selbst geht schon schnell aber das bild bleibt nach ca. einer Sekunde kurz hängen.
Ausserdem hab ich mit epgsync für alle Sender gleich ein EPG ohne das ich draufgezappt habe. Das ist vorallem für das zappilot Plugin praktisch.
Allerdings hab ich seit einigen Tagen ein neues Problem, teilweise stehen Sendungen doppelt oder sogar dreifach im EPG. Bei manchen ist die Start-Zeit identisch, bei manchen um ein paar Minuten unterschiedlich. Es ist aber nicht bei allen Sendern. Noch hab ich keine Ahnung woran das liegen könnte...

Hier nochmal ein kurzes Update:
Bin mit der streamdev Lösung sehr zufrieden, bei meinem Client im Wohnzimmer hatte ich seit dem dist-upgrade überhaupt kein Problem mehr.
Beim Client im Schlafzimmer hatte ich das Problem das nach etwa einer Minute das Bild stehen geblieben ist und für ca. 30 Sekunden kein umschalten möglich war.
Hab mir dann die Logs am Server und Client angesehen und nach etwas googlen fand ich den Thread:
PANIC: watchdog timer expired
Problem ist das egpsync-Plugin das in meinem Fall den VDR am Server zum neustart zwingt. Hab jetzt wie vorgeschlagen bei epgsync auf Kanalweise synchronisieren umgestellt und jetzt läuft es.
Bin immer noch begeistert davon, vor allem die flotten Umschaltzeiten sind cool. Kann mich noch an meine Versuche mit Windows und DVBViewer erinnern. Wenn das zappen unter 3 Sekunden lief war das schon super. So wie es mit dem VDR und streamdev läuft erkenne ich keinen wesentlichen unterschied zu der früher eingebauten DVB-Karte.

Zitat von schmirl

Über Port 2004 übermittelt streamdev lediglich die Befehle. Der eigentliche Stream wird über dynamisch ausgehandelte Ports übertragen. Eventuell genügt es Dir, anstelle des Ports einfach auf die Client-IP zu filtern. Ansonsten müsstest Du auf das DSCP/ToS-Feld gehen. Folgender Filter sollte passen:

Code

sudo tc filter add dev eth0 parent 1: protocol ip u32 match ip protocol 6 0xff match ip tos 0x88 0xfc flowid 1:1

[EDIT]Streamdev nutzt 0x88, nicht 0xb8[/EDIT]

Danke, das würde ja bedeuten das die Bandbreite trotz dem Kopiervorgang noch ausreichend war... Oder wertet der Kernel vielleicht die DSCP-Informationen aus den streamdev-Paketen aus?
Sicher, 96Mbyte/s sind 768MBit/s. Da ist noch etwas Luft bis 1GBit/s.
Dann wären meine Sorgen ja total unbegründet. bei über 200MBit/s Reserve könnte man noch einige Clients versorgen....

Mit dem Thema QoS bin ich auch schon ein Stück weiter.
Hab hier eine Seite gefunden die einfach erklärt wie man mit tc umgeht: http://mirrors.bieringer.de/Linux+IPv6-HOWTO-de/x2496.html

Daraus ist dann das entstanden:

sudo tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 bandwidth 1000Mbit
sudo tc class add dev eth0 parent 1: classid 1:1 cbq rate   100Mbit allot 1500 bounded
sudo tc filter add dev eth0 parent 1: protocol ip   u32 match ip  protocol 6 0xff match ip dport 2004 0xffff flowid 1:1

Das reserviert 100 MBit/s für den Port 2004 auf dem Server.
Hab es mit iperf getestet und bin auf 94,xx MBit/s gekommen. Danach hab ich mit meinem PC eine große Datei vom Server runterkopiert und gleichzeitig mit iperf gemessen und bin wieder auf 94,xx MBit/s gekommen.
Ich hab beim kopieren auch schön gesehen wie die Transferleistung runter ging und nach dem iperf Test wieder rauf.

Bin mir nur noch nicht sicher ob ich die tc Befehle irgendwo noch eintragen muss damit es auch einen Neustart überlebt oder ob das automatisch gespeichert wird.

Außerdem hab ich meinen zweiten Client auf streamdev umgestellt (ebenso DVB-C Karte raus). Läuft wie auf meinem anderen Client sehr gut.
Mal schauen was die Zeit bringt...

EDIT:
Gerade noch einen Test mit einem Client schauen und Datei vom Server auf PC runterkopieren: TV-Bild läuft ohne aussetzer, zappen geht auch sehr schnell und der Kopiervorgang läuft mit 96,xx MByte/s

Zitat von schmirl

Wenn Server und VDR-Client an den Switch-Ports A und B hängen, können Rechner an Ports C und D problemlos Daten austauschen ohne dass es die Kommunikation zwischen A und B stört. Insbesondere bei billigen Switches mag es sicherlich eine Obergrenze geben, wieviele Gigabit der Switch maximal übermitteln kann, aber die sollte bei mehreren Gigabit liegen. In diesem Szenario brauchst Du den Switch also nicht weiter beachten.

Wenn C und D mit dem Server auf A intensiv Daten austauschen während A und B streamen sieht es dagegen anders aus. Die Priorisierung kann hier aber entweder im Switch oder eben mit tc im Server passieren.

Stimmt, nachdem wir ja Switches verwenden und keine Hubs...
Gestern lief das ganze einwandfrei über mehrere Stunden. Egal ob man gezappt hat oder länger eine Sendung geschaut hat, es lief immer ohne Probleme.
Ausserdem ist mir aufgefallen das der PC schneller hochfährt und früher ein TV-Bild anzeigt.

Zitat von speefak

Irgentwie find ich ihr schießt über das ziel hinaus ?!

ich habe vor 2 jahren eine Wisi Schüssel ( 110 € ) mit nem quad/ttro ( den für den Multiswitch halt ) LNB und 12er Multiswitch von kathenhein installiert, läuft super bnei sturm schnee hagel etc. daran müsste man dann nur einen VDR mit 4 Tunern anschließen und dann kann man per VNSI/XVDR/Streamdev jede sendung ins netzwerk stremen zu jeder zeit und unendlich parrallel ( wenn man die bandbreite hat ) mit GBit lan kein ding.

Darum versteh ich grad nicht wiso von 8 Satkarten geredet wird ?! 4 reichen doch für alle bänder ?!

Von 8 Tuner hab ich nicht geredet, 6 waren es (3 Doppeltuner Karten).
Warum? Hab jetzt auch 4 Karten im Server + je eine pro Client. Aber stimmt schon mit 4 wird man auch ganz gut Leben können. Sind ja immerhin 4 Transponder mit zig Sendern...

Zitat von schmirl

Streamdev markiert alle IP-Pakete von Streams mit höchster Prioritätsklasse gemäß DSCP (Nachfolgestandard zu den ToS-Flags). Sofern der Switch Priorisierung anhand von DSCP oder ToS kann, sollte schon alles geritzt sein. Andernfalls müsstest Du Dich unter Linux mit dem tc-Befehl auseinandersetzen. Aber wie Mreimer schon sagt: Das ist starker Tobak.

Aber mit tc kann ich ja nur am Server priorisieren, somit bevorzugt der Server dann zwar die streamdev Pakete aber wenn im Netzwerk viel Traffic ist hilft das vermutlich nicht sehr.
Wird zwar vermutlich nicht vorkommen aber man weis ja nie. Und gerade dann kommt man wahrscheinlich nicht gleich drauf warum das Fernsehen nicht ordentlich funktioniert.
Ich glaub das ich mir einfach einen Switch zulegen werde der die die Priorität aus den streamdev-Paketen auswerten kann.