Beiträge von ralfk

    Beim Testen heute habe ich noch ein Problem gefunden ... timing ... das script ist schneller als der vdr ...


    Wenn zwei timer gleichzeitig anlaufen, packt der vdr die timers.conf auch zweimal an; sind ja auch zwei events.
    Leider bekam das script nur die erste neue Aufzeichnung mit, da der Zugriff auf die restful api "zu schnell" war und schaltet entsprechend den zusätzlichen reciever bei Bedarf nicht ein.


    Lösung: Einfach mal 15 sekunden warten nachdem die timers.conf angefasst wurde und dann starten.


    Änderungen im script sind eingetragen.

    Das hat mir keine Ruhe gelassen ... und ich hab mal was gebastelt:


    Ein nodejs-script, das die timers.conf überwacht und Aktivität entwickelt, wenn die Datei vom vdr (oder wem auch immer) angefasst wurde.
    Da der vdr die timers.conf bei Start und Ende einer Aufnahme anpackt, habe ich damit einen "echten" before recording_hook und einen Einstieg, um den Sundtek-Reciever zu mounten, wenn er gebraucht wird und später wieder abzuschalten.


    Das script kann vermutlich ziemlich einfach modifiziert werden, um timer-Konflikte rauszuwerfen und einen anderen trigger bekommen.


    Nodejs habe ich genommen, weil es event basiert ist - also den Trigger mitbringt, es die json-Objekte der restful api nativ versteht und http.gets schön einfach gehalten werden können.


    Möglicherweise hilft das script ja dem einen oder anderen mit einer ähnlichen Problemstellung.


    Achtung! ... ich bin kein Programmierer und schuster sowas nur zusammen - vieles geht sicher "kürzer" und "besser" ... nur keine Scheu ... das Script kann natürlich nach Wunsch verändert werden.


    Hi!


    Ich versuche gerade folgendes zu lösen:
    Ein yaVDR-Server mit einer "festen" S2-Karte und einem per Netzwerk gemountetem Sundtek-S2-Stick.


    Der Sundtek-S2-Stick hängt an einem Raspberry Pi in einem etwas "unfreundlichem" Klima unter dem Dach. Den Stick will ich wegen der Wärme eigentlich nur aktiv haben, wenn er wirklich gebraucht wird, der wird schon unter normalen Umständen selbst ziemlich heiss. Sprich der soll nur aktiv sein, wenn die interne Karte schon beschäftigt ist.
    Dank dem Dynamite-Plugin und dem wirklich guten Treiber von Sundtek kann ich den Stick dem VDR im Betrieb beliebig unterjubeln und auch wieder wegnehmen.


    Ich habe mir also zwei scripte gebastelt für das mounten des S2-Sticks und das unmounten.
    Wegen der festen S2-Karte im Server muss das mount-script für den Stick laufen, wenn bereits eine Aufnahme aktiv ist und eine zweite gestartet werden soll.
    -> Lösung recording-hook before benutzen.
    Das geht aber leider nur, wenn noch ein Empfänger frei ist ... nur dann läuft das recording an und der recording-hook wird aufgerufen ... das ist imho für "before" zu spät und für meinen Zweck sowieso :)


    Ganz genau kenne ich die Interna vom VDR natürlich nicht, aber sollte der recording-hook "before" nicht in dem Augenblick aufgerufen werden, wo der Timer auf is_pending=true gesetzt wird? (was vermutlich passiert bevor versucht wird die Aufnahme tatsächlich zu starten und auf einen Empfänger zu legen... oder liege ich falsch?)
    ... zumal ich gerade gesehen habe, dass es neben der Doku "before, after und edited" noch den hook "started" gibt.


    Dieses "Henne-Ei-Problem" könnte man mit einer while-sleep-Schleife sicher auch lösen, die aktiv wird sobal die interne Karte aufzeichnet ... aber eigentlich mag ich es immer nicht ein Computer mit sowas "nutzlosem" wie minütlichen Checkschleifen zu beschäftigen.


    Also: Ist der "before"-hook so wie er ist wirklich richtig eingehangen, oder war das mal anders gedacht oder bin ich doch völlig falsch?

    Zum sound device. Ich hatte ne Zeit lang auch einen virtuellen VDR allerdings unter KVM. Aber bei allen Virtualisierungslösungen kann man dem Gast doch ein sound device zuordnen. Damit hatte ich nie Probleme. Sollte doch bei esx auch gehen.

    Klar, das funktioniert solange wie der Hypervisor selbst ein Sounddevice erkennt ... wenn der nichts hat, kann er auch nichts durchreichen, aber das nehm ich ihm nicht mal übel auf meiner nicht zertifizierten Hardware - ich muss nur zusehen, wie ich die Klippen bequem umschiffen kann.


    Dann würde ich das an deiner Stelle mal genauer untersuchen. Bei uns geht das nämlich. Außerdem scheint mir das überhaupt nichts mit dem original Thread zu tun zu haben.


    Gerald

    Ich glaube, da hab ich noch was :)
    Wenn der yaVDR als Server auf einem Virtualisierungshost unter ESXi läuft, der KEIN erkanntes Sounddevice besitzt (Wozu auch?), dann bleibt er in den Stop-Scripten hängen. Passiert mir auch regelmäßig ... da ist irgendwo ein, ich nenn es jetzt unwissend, WAIT-Hook für die Soundausgabe, der natürlich keine Antwort bekommt, dass das Device "freigemacht" wurde.
    Ein ps -ef | grep vdr wird Dir den Prozess zeigen - man kann es herauslesen, dass dieser Prozess auf etwas "wartet" (wait halt). Bist Du dann unfreundlich und killst diesen Prozess mit kill -9, dann kommt wieder alles ohne Neustart der gesamten Maschine in Butter ... und ja das hat jetzt mit dem Original-Thread überhaupt nix mehr zu tun.

    Nach ein paar Wochen des Betriebs zerre ich den Thread noch mal vor :)


    Der ursprüngliche Enthusiasmus bezüglich der Mysthique-Karte ist gewichen ...
    Live-Programm schauen war kein Problem, nur leider hat mir die Karte alle Aufnahmen verwurstet, sprich mit Aussetzern gespickt - wobei ich nicht weiß wo die wirklich herkamen. Ich vermute mal, dass es doch Probleme des Treibers mit der Virtualisierung gab und der sich ein wenig mit dem HD-Controller um Zeitslots geprügelt hat. Es wurde etwas besser nachdem ich mein endgültiges Datengrab eingebaut hatte und die Test-Platte wieder im Regal lag - was mich zu dieser Vermutung treibt. Ich denke auch mit anderer (Server)Hardware wäre das anders, kann das aber nicht testen, mangels Zugriff auf selbige.
    Das reibungsfreie Aufnehmen klappte erst wieder mit meiner TT-Budget S2-4200 von Technotrend aus meinem alten "produktiv" VDR - und das läuft auch jetzt noch stabil.
    Damit fehlte mir allerdings ein zweiter Tuner, was meiner Frau den Plan verhagelte das Wohnzimmer umzustellen, da ja der VDR-Client dann nur Live-TV wiedergeben kann, wenn er nicht aufnimmt oder man ist aufs Bouque festgenagelt oder hat halt nen Sat-Kabel am Fernseher, was nicht mehr da wäre, wenn das Zimmer umgebaut wird und der Fernseher NATÜRLICH in die von der Antennendose weitest entfernte Ecke soll ... :)
    Nach schauen und den gemachten Erfahrungen und den ja auch hier noch geposteten Schwierigkeiten mit anderen Karten in der VM kam ich auf die USB-Sticks von Sundtek ... cool! und ja geht auch direkt an einem VM-Gast per USB_passthrough nur hatte ich Probleme das der Stick in dieser Konstellation kein HD-Empfang hinbekommen hat (VM und USB durchreichen ist wohl nicht so performant).
    Aber: Sundtek hat dieses geniale Netzwerkfeature, dass ein virtuelles DVB-Device über Lan anbindet (yeahaaa! die Lösung für Vitualisierungsprobleme ist: Virtualisierung) und das ist die Rettung aller, die auch evt. Standortprobleme (Satkabel nicht dort, wo man es haben will) haben.
    Mir ist zufällig ein ARM6-Board in Form des PogoPlugs (25,-- Euronen) über den Weg gelaufen ... Ursprungsfirmware runter und ArchLinux rauf ... Sundtek-Stick ran, Treiber von Sundtek installieren ... Treiber auf dem VM-YaVDR installieren und fertig ist die endgültige Lösung. HD auf allen Tunern und ich kann dank der Netzfunktionalität des Sticks meinen Server jetzt aus der heißen Heizungkammer unter dem Dach in den kühlen Keller umziehen und hätte sogar noch Platz für einen dritten Tuner am PogoPlug ... (Merke: Pogo ... nicht Popo) und nen DLNA-Server für die KinderCDs macht das Ding mal nebenbei noch mit.


    Fazit:
    Schwere Geburt - vermutlich mit unpassender ConsumerHardware doppelt problematisch.
    Sundtek-Sticks tun was sie versprechen und das mit einem simplen, scriptgesteuerten Setup.
    ARM-Linux erstaunt schon auf einem ARM6-Board in Punkto Leistung und gehört auf die Rechnung für Spezial-Lösungen.

    Vorweg: Ich kann keine 1 zu 1 Installationslösung anbieten, da es einfach zu viele Variablen in den Voraussetzungen für jedermann gibt und ich bitte im Zweifel zu den einzelnen Themengebieten im Netz nachzulesen; zumal Virtualisierung schon leider immer noch ein paar weitergehende Grundkenntnisse erfordert.


    Meine Idee war es nur noch einen Computer für den Hausgebrauch ständig am laufen zu haben.
    Er sollte meinen Mail-Server, die Heizungssteuerung und natürlich auch den VDR-Server beherbergen.
    Irgendwie war es mir nicht so ganz lieb das alles in einer Maschine zu realisieren, da dann der WAF des VDR unter gelegentlichen Systemarbeiten auch etwas leiden würde und ich mir unter Umständen durch Seiteneffekte die herausragende yaVDR-Umgebung zerlegen würde.
    Also fing ich an zu lesen und fand gelegentliche Erfolgsgeschichten zur Virtualisierung des VDR.
    Mein erster Versuch war Proxmox als Virtualisierungsplattform. Vielversprechend - und das PCI-Passthrough in die virtuelle Maschine war simpel und funktionierte.
    Im Endeffekt war die Mühe vergeblich, da sich die DVB-Karte im VDR nachher genau jeweils einmal auf einen Sender tunen lies und dann nicht mehr zum Umschalten zu bewegen war ohne den VDR neu zu starten. -> Schade ... wäre mir die liebste Lösung gewesen.
    Nächster Versuch: VMWare's für den Heimgebrauch freie ESXi-Version
    Der Host ist ein zwei Jahre alter Lenovo-Tower 9194A56 mit 4GB RAM und einem Intel(R) Core(TM)2 Duo E6550 @ 2.33GHz. VTx und VTd müssen im BIOS aktiviert werden.
    ESXi ist schnell installiert.
    Der erste Blick sollte in die erweiterten Einstellungen des ESXi-Hosts führen. Hier ist zunächst das PCI-Passthrough, welches die physische Hardware an die virtuelle Maschine durchreicht, nicht konfiguriert. Das PCI-Passthrough muss aktiviert werden und die gewünschte DVB-Hardware muss dieser Funktion zugänglich gemacht werden. Abschließend ist der ESXi-Host zu starten und nach dem Reboot taucht hoffentlich die Karte mit einem grünen Punkt im vSphere-Client auf.
    Jetzt kann eine virtuelle Maschine erstellt werden (noch ohne die PCI-Passthrough-Karte).
    yaVDR 0.5 läßt sich vom ISO aus installieren, hängt dann aber beim ersten Start. Das WebIF vom yaVDR läuft an dieser Stelle schon und man findet das Backend als "stopped" und als Frontend das "SoftHDDevice". Im syslog finden sich Hinweise auf ein Openbox, das etliche Male respawnt aber zu keinem Ergebnis kommt. Das X11-Log weist als Fehler auf "no screens found" und weiter oben im Log auf "Module vmware not found". Da der VDR nicht läuft, kann auch im WebIF nicht auf die gewünschte Headless-Betriebsvariante umgeschaltet werden, da dieses Script offensichtlich gerne eine PID vom VDR beenden würde, die es aber gar nicht finden kann.
    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.
    OK ... bis hierhin waren es für mich im ersten Anlauf sechs Stunden Bildungsurlaub in den Tiefen des yaVDR ...
    Jetzt kann die VM wieder abgeschaltet werden und man kann ihr die PCI-Karte über den vSphere-Client zuweisen.
    Nach dem Neustart der VM kann man mit einem lspci per SSH-Konsole kontrollieren, ob die Hardware auch in der Maschine angekommen ist. Findet man sie hier, stehen die Chancen auf einen Erfolg recht hoch.
    Von der Seite http://www.dvbsky.net/Support.html habe ich mir die Treiber und die Firmware für die Mystique SATIX S2 XPRESS DUAL geholt.
    Nach Schema make all - make install werden die Treiber installiert und gaaaanz wichtig die Firmware kopiert ( sonst bleibts Dunkel!).
    Ist man damit durch findet man die Karte im yaVDR WebIF (nach dem gefühlt 100. Neustart) unter System-Systeminformationen-DVBadapters -> gewonnen!
    Fix noch ein paar Channels in die channels.conf schreiben, die streamdevhost.conf in /etc/vdr/plugins und svdrphosts.conf in /etc/vdr anpassen und die VM nochmal durchstarten.
    Fertig ist der virtualisierte yaVDR-Server.
    Wie es sich mit der Stabilität verhält und ob die Lösung praktikabel bleibt wird sich zeigen.
    Zumindest läuft bei mir mittlerweile ein Client an dem Server. EPGsync und remoteosd tun schon ihre Dienste und die Umschaltzeiten am Client sind fix (und man kann mehr als zweimal Umschalten :] )


    Es wäre eine wirklich tolle Sache, wenn das yaVDR-Team auch in diese Richtung ein wenig schielen würde. Ich glaube der Wunsch zur Virtualisierung wird zunehmen. Das Arbeiten mit VMs ist einfach mal um Längen einfacher als mit realer Hardware - auch zu Hause und die Hypervisoren für den Heimgebrauch sind kostenlos verfügbar. Schnell mal nen Dev-System mit der neuesten Version nebenbei aufgesetzt; dem dann fix noch die "Speicher-Platte" des Produktiv-Systems untergeschoben ... ohhh! Kernel zerhackt update schiefgangen? ... egal Snapshot zurück und zwei Minuten später geht es weiter. Vorteile und Erleichterungen ohne Ende. Biiiiittttteeee yaVDR-Team :D

    Hallo!


    Dank der Superhilfe von LordZodiac hab ich jetzt bei der Kombo VDR 1.3.23 Nova-T / DXR3 auch beim DVD-Plugin Ton und kann auch die Tonspuren umschalten.
    Im DXR3-Plugin fehlen bislang die Anpassungen an den VDR >=1.3.18 - daher gibts wohl die eine oder andere Hakelei.


    Die Änderung in der DXR3-Pluginsource für DVD-Ton ist winzig - LordZodiac versucht in Kürze einen Patch bereitzustellen ...


    Na, dass nenn ich doch mal Usersupport! ThumbsUp @ LordZodiac :tup

    Hi!


    Gibt es jemand, der den 1.3.23 VDR mit ner DXR3-Karte und einer Budget-DVB-Karte betreibt und der mit dem DVD-Plugin Ton bekommt?


    Ich habe gestern die DVD-Plugin-CVS-Version gezogen und auch das aktuelle Release probiert ... Ergebnis: Die Menüs sind auf jeden Fall super benutzbar geworden -> good Job!
    Leider bekomm ich keinen Ton. Die Einstellung im DVB-Menü für Dolby-Digital-Ton steht auf "nein".


    Ich hab auch ein ernstes Problem eine ältere VDR-Version zu nehmen ... ein laufendes DXR3-Plugin für die jeweilige VDR-Version zu finden ist alles andere als einfach ... mein VDR davor war noch ein 1.2.5er also dringend Zeit ein Update zu basteln ... hat sich bisher auch gelohnt, nur leider ist das DVD-Plugin ein sehr wichtiges .... ich will nicht zurück auf 1.2.x

    Hi!


    Ich habe mir gerade das dvd-plugin aus dem cvs gezogen und eingebunden.


    Mein Problem:
    Ich bekomme keinen Ton :(
    "Dolby Digital Ton" benutzen hab ich im Einstellungen-DVB-Menu schon auf nein gesetzt.


    Ich benutze eine Nova-T (alte Version) in Kombo mit einer Creative DXR3-Karte unter einem 2.6.11.6 Kernel. VDR is 1.3.23


    Die libdvdnav ist frisch.


    Das Plugin liefert diese Ausgaben:


    Hat jemand ne Idee warum ich keinen Ton bekomme?

    Boaahhh ... DICKES DANKE!


    Der Link is genau richtig gewesen ... jetzt funzt es!
    Du glaubst gar nicht wie knapp ich vor nem rm -rf /* stand ...


    Ich werd mir jetzt erstmal ne "Wichtig-CD" brennen ... ua mit dem CVS-Snapshot aus Deinem Link ...

    Menno ... jetzt hab ich schon alles (?) gelesen und es auch tatsächlich geschafft den 1.3.23 VDR mit dem cvs dxr3-plugin von heute zu installieren - aber ich habe trotzdem ein Problem:
    Außer einem kurzen Zucken bekomm ich kein Bild auf dem TV.
    Da der VDR frisch installiert ist, hätte ich zumindest am Anfang das Keylerning per OSD erwartet. Im syslog wird der Prozess auch als gestartet angezeigt.
    Die Treiber der DXR3-Karte sind geladen und funktionieren - die Karte ist nicht defekt (eine alte 1.2.5-vdr-installation läuft noch auf einer anderen Platte)


    Neben der DXR3 werkelt eine alte Nova-T. Im Syslog ist erkennbar, dass diese auch angesprochen wird und fleißig beginnt die alte channels.conf zu modifizieren - eigentlich alles schön.


    Kann mir jemand sagen, wo ich den entscheidenden Denkfehler gemacht habe? Was ich übersehen haben könnte?


    Achso ... zugrunde liegt eine Sarge-Installation mit dem 2.6.11.6er Kernel.

    Ich hatte dasselbe Problem.
    Mit dem libc6-dev Paket werden die Kernelheader vom einem 2.5.999-X Kernel mit installiert und zwar debianlike fest in den Verzeichnissen /usr/include/linux und /usr/include/asm. Einige Software hat wohl noch Probleme mit diesen "zu neuen" Headern.
    Die Lösung für mich war:
    Eigene Kernelsource nach /usr/src/ entpacken und selbst nen Kernel kompilieren. Nach dem Kompilieren und installieren des Kernels dann die ursprünglichen /usr/include/linux und /usr/include/asm sichern und Symlinks zu den entsprechenden Verzeichnissen in Deine eigene Kernelsource legen, zB mit
    ln -s /usr/src/linux-2.4.22/include/linux /usr/include/linux und
    ln -s /usr/src/linux-2.4.22/include/asm /usr/include/asm.


    Danach funzt das Kompilieren bei mir wieder.
    Viel Glück


    (evt. sind Fehler in der Syntax der Beispiele!)

    Habe mal irgendwas gelesen, dass der Serielle-Port, an dem der Empfänger hängt erstmal für andere Anwendungen gesperrt werden muß.


    Z.B. sowas:
    setserial /dev/ttyS0 uart none


    Vorher bitte mal man setserial lesen und rausfinden, ob ttyS0 der richtige Port ist.

    Ja! 8)


    Bei mir lag es einfach am Startscript runvdr.
    Da wird ja die Variable VDRCMD (oä) definiert und zwar z.B. so:
    VDRCMD="vdr -Pdxr3 -Pmp3 -m mount.sh -w60"
    das ist aber nicht korrekt für das mp3-Plugin, das ja -Pmp3 "-m mount.sh" haben will.
    Diese Definition von VDRCMD klappt:
    VDRCMD="vdr -Pdxr3 -Pmp3 \"-m mount.sh\" -w60"


    Die \ sind wichtig um die " vor der Shellinterpretation zu schützen.
    Ob der Startaufruf so aussieht, wie man es möchte, kann man leicht prüfen wenn man noch ein
    echo Starte vdr mit Aufruf: $VDRCMD
    in das Startscript bastelt.


    Viel Erfolg

    Moin,moin Forum!


    Ich habe ein Debian für den VDR aufgesetzt (der Kernel ist ein selbstgebackener 2.4.20er mit dem Minimum für VDR). Ich benutze die "Budget-Variante" (DXR3 mit NOVA-T). Es gibt keine extra Soundkarte im System.
    DXR3, DVB-Treiber und VDR haben beim übersetzen nicht gemault und starten auch. Es gibt Bild und Ton. Auch ein mal probeweise installiertes DVD-Plugin tut seinen Dienst klaglos.
    Sobald ich aber das aktuelle mp3-Plugin installiere ... dann passiert's:
    Starte ich den VDR nach einem erfolgreichen make plugins mit aktiven mp3-Plugin ist der Ton weg ... :weinen ... egal ob beim normalen Fernsehen oder bei dem Versuch eine Audio-CD zu spielen.
    Starte ich den VDR dann wieder ohne mp3-plugin gibts auch wieder Ton ... in den messages ist kein Fehler zu finden ... Stell ich mich zu blöd an? Gibt es irgendwelchen Kerneloptionen, die ich vergessen habe?