Beiträge von ghostV

    Hallo,


    zunaechst einmal - ein OSD bekommst Du nur auf dem Primary device, sprich an einem Display direkt am VDR Rechner.


    Wenn ich mir deine Ausstattung so anschaue wuerde sich da das plugin-xineliboutput anbieten, dann bekommst Du per Xine "xvdr:\\localhost#nocache;demux:mpeg_block" ein direktes Bild auf den Monitor, auf dem auch das OSD angezeigt wird.


    Wenn ich die Frage mit dem Xineliboutput-sxfe richtig verstehe hast Du das auch probiert, allerdings fehlt Dir dazu das korrekte Plugin - das Xine Plugin arbeitet nicht mit dem xineliboutput-sxfe zusammen.

    Hallo zusammen,


    ich wuerde das ganze systematisch angehen. Im Fall wo 2 TwinHan Karten drin sind wuerde ich zunaechst auf eine Karte reduzieren. Sobald nur eine Karte im System ist koennt ihr die DMESG Meldungen vergleichen auf Unterschiede bei der Erkennung / beim Laden der Module. Moeglicherweise blockiert da ein Modul das eigentlich nicht fuer die TwinHan Karten gedacht ist.


    Die Meldungen unterschiedlich aussehen, je nach dem ob die Karte erkannt wurde oder nicht. In der Folge sollte sich aus diesem unterschied die Ursache erkennen lassen.


    Was die initiale Frage zu den read_dst Meldungen angeht - ich denke diese Meldungen sind weg wenn das Problem weg ist.

    Hallo zusammen,


    ich bin inzwischen wieder ein paar schritte weiter.


    a) Auch mit einem neuen Netzteil (standard 300W PC) stuerzt der ctvdr6 nach nicht vorhersehbarer Zeit ab. Ich gehe also von einem Problem in der Kombination Via C3 (mein Fall) oder C7 (votequimby's Fall) / Debian Etch / Vdr 1.4.5 oder 1.4.7 aus.


    b) die identisch gleiche Hardware laeuft inzwischen unter ctvdr5.1 seit 32 Stunden stabil durch. Der Versuch mit einem neu kompilierten 2.6.22er kernel (identisch kompiliert wie unter Etch) steht fuer heute abend an. Bisher fehlt allerdings noch der X-Server, da ich den selber kompilieren muss (Ich brauche Xorg > 7.0, damit ich die Mpeg dekodierung des CN400 Chips nutzen kann, ansonsten reicht die Rechenleistung nicht). Das ist aber aktuell nach hinten gestellt, da ich einen Kernel-Patch fuer einen hardwarebeschleunigten Framebuffer fuer den CN400 gefunden habe, das probiere ich jetzt zuerst aus. Sofern FBXine hinreichend Leistung gibt um in einzelfaellen per OSD Einstellungen am VDR machen zu koennen dann reicht mir das.



    Ohne VDR hab ich das mit dem TV schauen nicht probiert - damit habe ich mich ehrlich gesagt nicht auseinander gesetzt, da dieser VDR eher als Recorder im Hintergrund arbeiten soll. Deswegen auch die Loesung mit xine zur Darstellung an Stelle einer FF Karte.


    EDIT : Wer tippen kann ist klar im Vorteil.

    Hallo,


    soweit ich das gesehen habe hast du die aktuelle version des Plugins. Eine neuere Version bekommst Du meines wissens nicht per apt-get, sondern muesstest du aus den Plugin-quellen selber uebersetzen. Ich denke aber nicht das dies dein Problem mit dem erneuten Einschalten nach laengerer Zeit behebt.


    Gegebenenfalls gibt es fuer den aktuellen vdrdevel ein neu uebersetztes Plugin.


    A.

    Der einfachste Weg waere wohl sudo zu benutzen.


    Alternativ kannst Du natuerlich den Shutdown-Wrapper auf Set-Uid-Root setzen. Damit laeuft der immer mit Root-rechten. In dem Fall sollte das Ausfuehren aber ausschliesslich fuer die Benutzer Root und vdr erlaubt sein, ansonsten kann jeder den rechner herunterfahren.

    Hallo,


    das hoert sich stark danach an das die Umleitung der Tastatursteuerung und (standardmaessig ueber Konsole 8) nicht funktioniert. Entweder ist dort eine nicht existierende Konsole angegeben oder ein Schreibfehler in der konfiguration.


    Schau doch mal unter /etc/vdr/ nach. Da sollte eine Datei default oder defaults liegen, in der Angegeben wird, ob eine Tastatursteuerung aktiv ist, ueber welche Konsole diese laeuft, und ob automatisch auf diese Konsole umgeschaltet werden soll.

    VDR als Streaming Client waere nur auf Linux Systemen verfuegbar. Je nach Hardware wuerde die Ausgabe per Xineliboutput, DXR3 oder FF Karte erfolgen.


    Das ist aus meiner Sicht nur dann Sinnvoll, wenn diese Clients nicht anderweitig genutzt werden. Sobald die Clients auch als 'normale' Rechner oder zum Surfen eingesetzt werden wuerde ich eher auf die Kombination vlc und xxv setzen.


    Per xxv hast Du eine sehr schoene Uebersicht ueber die vorhandenen Kanaele, und kannst bei richtiger Einstellung die Sendungen direkt Streamen, waehrend ein sequentielles 'zappen' mit vlc machbar ist.


    Ansonsten kannst Du auch per xine / xineliboutput das OSD auf den remote Rechner uebertragen (das klappt afaik problemlos), allerdings schauen dann leider alle xine clients per definiton das gleiche Programm.


    Wie du siehst ist die Ideale Loesung noch vollstaendig vorhanden. Ich pruefe gerade ob ich ein Pseudo-osd mit einem Widget (da client=windows ein Konfabulator widget) erzeugen kann. Das liesse sich (hoffentlich) per Hotkeys steuern, und koennte von XXV oder per svdrp die notwendigen Informationen bekommen.

    Hallo Zusammen,


    nochmal danke fuer die Hinweise. Der Test mit einem normalen Netzteil laeuft gerade, ergebnisse hab ich dann morgen oder uebermorgen.


    was mich nun noch interessiert ist folgendes :


    ist ein Downgrade von Etch auf Sarge machbar, bzw. kann ich auf einem Standard-Sarge den den aktuellen 1.4.5er VDR mit XServer von Xorg (Wegen xineliboutput) fahren, oder gibt das probleme ? (Ich hatte etwas aehnliches (noch basierend auf ctvdr4, aber auch schon mit neuerem kernel und server von xorg, habe aber bei einem Upgrade des VDR massive probleme bekommen, siehe dieser thread)


    Sofern das prinzipiell geht wuerde ich einfach nochmal eine c'tvdr 5 installieren, und dann den xserver und kernel updaten. Die Arbeit moechte ich mir aber halt nicht machen, wenn es bekannte probleme vom VDR 1.4.5/1.4.7 auf Sarge gibt.

    Hallo,


    das mit Stromversorgung und Timings schau ich mir nochmal im Detail an. Thermik kann ich ausschliessen, die Komponenten sind wenn das System steht nicht einmal Handwarm (Prozessorkuehler, Chipsatzkueler, DVB-T Karte und Festplatten.


    Leider hat das VIA Board keine Temperaturueberwachung. Die haette ich gerne.


    Was ich bisher nicht finden konnte - was sind die Grenzen fuer die Spannungen an den verschiedenen Leitungen ? Ich benutze einen passiven Spannungswandler mit 120 W, was fuer die verwendete Hardware eigentlich gut reichen sollte, aber inzwischen mach ich mir da doch so meine Gedanken.


    A.

    Hallo,


    ich hab mich mal durch das Log durchgegraben. Auffaellig ist das projectx anscheinend das ganze anscheinend umgesetzt wird, aber von mplex dann in der Folge keine Meldung liefert wie weit es ist.


    Es waere also meiner Meinung nach zu pruefen :


    a) laeuft projectx wirklich durch ? ggf. einmal den Befehl aus dem Log manuell in einer Console eingeben und sich das Ergebnis anschauen

    Code
    /usr/bin/projectx -ini /var/lib/vdr/plugins/burn/ProjectX.ini -cut /var/lib/video.00/vdr-burn.Anne_Frank.cayjqE/VDRSYNC.0/px.cut -id 0xe0,0xc0,0x1f,0x20 -demux -out /var/lib/video.00/vdr-burn.Anne_Frank.cayjqE/VDRSYNC.0 -name vdrsync /var/cache/vdr-plugin-burn/vdr-burn.Anne_Frank.GsMAIe/VDRSYNC.0/convert/001.vdr /var/cache/vdr-plugin-burn/vdr-burn.Anne_Frank.GsMAIe/VDRSYNC.0/convert/002.vdr


    b) sind die Ausgabedateien 'sauber' ? ProjectX meldet einige Fehler bei der Umsetzung. Sprich, wie sehen die folgenden Dateien aus :

    Code
    /var/cache/vdr-plugin-burn/vdr-burn.Anne_Frank.GsMAIe/VDRSYNC.0/movie.mpg
    /var/cache/vdr-plugin-burn/vdr-burn.Anne_Frank.GsMAIe/VDRSYNC.0/requant.mpv
    /var/lib/video.00/vdr-burn.Anne_Frank.cayjqE/VDRSYNC.0/vdrsync.mpa


    c) wie laeuft mplex. Auch hier sollte der Befehl manuell einmal eingegeben werden


    Code
    mplex -f 8 -S 0 -M -o /var/cache/vdr-plugin-burn/vdr-burn.Anne_Frank.GsMAIe/VDRSYNC.0/movie.mpg /var/cache/vdr-plugin-burn/vdr-burn.Anne_Frank.GsMAIe/VDRSYNC.0/requant.mpv /var/lib/video.00/vdr-burn.Anne_Frank.cayjqE/VDRSYNC.0/vdrsync.mpa



    Je nach dem was da so passiert sollte sich klaeren wo das Problem ist.


    A.

    Hallo,


    falls die Datei da ist, stellt sich die Frage ob wirklich EPG Daten fuer die kommenden Sendungen vorliegen.


    Das kann man ueber das Menue vom VDR pruefen. Sofern da Daten vorhanden sind, sollten diese auch in der Datei liegen.


    Ansonsten macht es sinn, auch in der VDR Konfiguration nachzuschauen, wo er die EPG Daten ablegt.


    Ich hoffe damit kannst Du erst einmal suchen.


    A.

    Erst einmal danke fuer die Reaktion.


    An Hardware hab ich auch schon gedacht, und deswegen speicher, HD und so weiter ueberprueft. Der rest ist ja leider on board. Wobei interessanterweise die vorherige (leider verreckte) Installation mit einem 2.6.16er kernel (allerdings auf passende Hardware selbstgebaut) anstandslos und ohne Crash lief.


    Inzwischen bin ich (vielleicht) einen Schritt weiter. Gestern abend lief der VDR einfach mal durch - nachdem ich den lircd abgeschaltet hatte, der regelmaessig in Probleme kam. Zusaetzlich ist der auf meine Hardware zugeschnittene Kernel fast fertig, so das ich heute nacht den naechsten Test fahren kann.

    Hallo zusammen,


    nachdem es mir nicht gelungen ist, meine vorherige VDR Installation widerzubeleben habe ich mich schweren Herzens entschlossen, den VDR mit Hilfe der c't VDR 6 neu aufzusetzen.


    Das hat soweit auch funktioniert. Allerdings habe ich nun ein Problem das ich mit der alten 4.x Version nicht hatte :


    Nach einiger Zeit friert der VDR ein - vollstaendig. Ich muss den Rechner ausschalten. Nicht einmal die NumLock LED reagiert wenn ich auf Numlock druecke.


    Ungluecklicherweise passiert dies nicht immer zu bestimmten Zeiten, und eine Durchsicht der Logs zeigt keinerlei ungewoehnlichen Meldungen. Allerdings scheinen eintraege im Log zu fehlen :



    Nun frage ich mich wie ich heraus bekomme woran dies liegt. Leider habe ich keinen richtigen Anhaltspunkt.


    Folgende Hardware ist im Einsatz :


    Via SP13000 Mainboard (512 MB Ram, 80 GB IDE, 250 GB SATA fuer Aufzeichnungen) mit Technisat AirStar 2 DVB-T Karte, Ausgabe via Streamdev-server oder xineliboutput.
    Basis c'tvdr6, mit update von e-tobi.net.


    Code
    Aug 11 22:39:42 dubitoo vdr: [2556] VDR version 1.4.7 started
    Aug 11 22:39:42 dubitoo vdr: [2556] switched to user 'vdr'
    Aug 11 22:39:42 dubitoo vdr: [2556] loading plugin: /usr/lib/vdr/plugins/libvdr-burn.so.1.4.5
    Aug 11 22:39:42 dubitoo vdr: [2556] burn: couldn't stat /dev/dvd, assuming iso-creation only
    Aug 11 22:39:42 dubitoo vdr: [2556] loading plugin: /usr/lib/vdr/plugins/libvdr-undelete.so.1.4.5
    Aug 11 22:39:42 dubitoo vdr: [2556] loading plugin: /usr/lib/vdr/plugins/libvdr-xineliboutput.so.1.4.5
    Aug 11 22:39:42 dubitoo vdr: [2556] loading plugin: /usr/lib/vdr/plugins/libvdr-text2skin.so.1.4.5
    Aug 11 22:39:43 dubitoo vdr: [2556] loading plugin: /usr/lib/vdr/plugins/libvdr-vdrrip.so.1.4.5
    Aug 11 22:39:43 dubitoo vdr: [2556] loading plugin: /usr/lib/vdr/plugins/libvdr-streamdev-server.so.1.4.5
    Aug 11 22:39:43 dubitoo vdr: [2556] loading plugin: /usr/lib/vdr/plugins/libvdr-femon.so.1.4.5


    Leider bringt ein reduzieren auf nur die 2 plugins (streamdev server und xineliboutput) keine besserung - auch dann friert der Rechner von Zeit zu Zeit ein. Wie lange er genau laeuft ist stark unterschiedlich. Manchmal laeuft er 5 minuten, manchmal 4 Stunden.


    Wenn der VDR nicht laeuft scheint soweit alles ok, auch wenn ich viel mit X mache oder einen neuen Kernel uebersetze gibt es keine Auffaelligkeiten.


    Fuer Hinweise wie ich das Problem weiter einkreisen kann bin ich sehr dankbar. (die vollstaendigen DMESG habe ich angehaengt, falls das was bringt. Im Moment versuche ich einen neuen Kernel zu bauen, falls eins der Module sich mit der Hardware streitet.)


    A.

    Hallo zusammen,


    ich habe heute versucht, meinen VDR (ehemals ctvdr4.5) zu refreshen.


    Ein Aufruf von vdraptrefresh ging soweit gut, nur started der VDR nun nicht mehr.
    Beim Versuch den VDR manuell zu starten bekomme ich nur folgende Meldung :


    Code
    Searching for plugins (VDR unknown version)


    nach weiterem graben (und upgraden des Systems, entfernen aller nicht entscheidenden Plugins) haenge ich nun fest.


    in /tmp/vdr-err steht :

    Code
    /usr/bin/vdr: errorwhile loading shared libraries: libpthread.so.0: cannot open 
    shared object file: No such file or directory.


    Allerdings befindet sich unter /lib und unter /usr/lib besagte libpthread-2.6.so (mit dem entsprechenden symbolischen Link libpthread.so.0)


    Ich wuerde mich sehr freuen wenn mir jemand da einen Tip geben koennte, wo ich weiter suchen kann.


    Aktuelle Konfiguration :
    Basis ex ctvdr 4.5, selbst gebauter Kernel 2.6.16.
    VDR 1.4.7/1.4.5 mit streamdev/server (0.3.3-pre3-geni), femon (1.1.3) und vdrrip (0.3.0)


    Bis zum versuchten update des VDR lief alles sauber (version weiss ich aber nicht mehr)


    EDIT : Nachdem der neu installierte ctvdr 6 mit kleineren Problemen laeuft liegt dieses Problem zunaechst auf Eis. Danke an alle die sich Gedanken gemacht haben.

    Erstmal danke fuer die Info.


    Das kein Firmwareupload beim Boot stattfindet ist ok - die Firmware wird erst beim Start des VDR geladen (oder auch nicht)


    Was mich interessieren wuerde ist wie ich das ggf. vorziehen kann ? Als test ob es beim Boot geht waere das interessant. Ansonsten hab ich immer noch so 40% das die Karte nicht geht, allerdings musste ich leider feststellen das sich der Eintrag hinter mem jedesmal aendert, so das ich nicht mehr sicher bin, ob ich daraus irgendetwas erkennen kann.


    Anscheinend bin ich aber der einzige mit diesem Problem.


    Axel

    Hallo Zusammen,


    inzwischen bin ich ein Stueck weiter, allerdings nicht am ziel.
    Ich konnte feststellen, das immer wenn die Karte in dmesg mit der folgenden Zeile gelistet wird, dann geht der Firmware Upload :
    [code]
    saa7146: found saa7146 @ mem dcba4000 (revision 1, irq 11) (0x13c2, 0x1011)
    [code]


    manchmal wird sie aber auch so gelistet :
    [code]
    saa7146: found saa7146 @ mem dcb90000 (revision 1, irq 11) (0x13c2, 0x1011)
    [code]
    In diesem Fall geht es dann nicht.


    Gibt es eine einfache moeglichkeit, dieses zu beeinflussen ? Leider bin ich nicht so der Spezialist was diese Eintraege angeht, daher bin ich ueber jeden Hinweis dankbar.


    Axel

    Ich hab die kernel sourcen fuer den Kernel hier gefunden.


    Der entsprechende Eintrag in der sources.list ist

    Code
    deb http://www.heise.de/ct/ftp/projekte/vdr4 experimental/


    damit hoffe ich mir lirc 0.8 zu bauen.


    A.

    Hallo,


    erst einmal danke fuer den Vorschlag. Bei mir war die Firmware ausschliesslich unter /usr/lib/hotplug/firmware. Ich habe nun unter /lib ein link firmware erzeugt, das darauf verweist, ohne allerdings das Problem zu beheben.


    Das Update der Daten fuer lspci hat geklappt, damit sollte das also demnaechst dort weiter gehen.


    Nachtrag : die Firmware wird bei mir nicht beim Systemstart geladen, sondern erst beim Start des VDR ueber /etc/init.d/vdr start. In der dmesg sind also garkeine Eintraege ueber die Firmware.


    Axel.

    Hallo Zusammen,


    ich versuche gerade, auf Basis eines VIA SP13000 einen VDR aufzusetzen, bekomme aber schon recht frueh damit Probleme. Als DVB Karte habe ich eine TT 1300 (vor 3 wochen erst bekommen).
    Folgendes habe ich gemacht :


    von ct45'er cd installiert (2.6.12-ct-1 kernel), aber installation ohne vdr beendet, dann sources.list auf online gestellt und vdr 1.13.45 per ctvdrcfg installiert (nur vdr und streamdev-server).
    Zunaechst gab es probleme mit dem 'capability' modul - das habe ich mit dem Forum in den Griff bekommen. Nun habe ich aber probleme mit der Karte. Laut Dmesg wird die Karte auch sauber erkannt, allerdings bekomme ich beim Start des VDR die folgende Meldung :


    In der Folge versucht der VDR regelmaessig umzuschalten, schafft es aber nicht einen Kanal zu tunen. Ein Bild gibt es natuerlich auch nicht.


    Die Firmwaredatei ist anscheinend vorhanden.


    Nebenbei habe ich auch noch probleme die Unichrome unterstuetzung zum laufen zu bringen. Anders als die posts die ich dazu bisher gesehen habe wird bei lspci der Chipsatz nicht erkannt. Ich wuerde gerne die mpeg2 faehigkeiten des CN400 fuer die Fernsehausgabe nutzen. (Qualitaet ist nicht so wichtig, wird nur beim Schneiden benutzt)


    Ueber Hinweise was da ggf. falsch ist wuerde ich mich freuen.