Beiträge von gandalf

    Also ich habe das jetzt mal eine Weile beobachtet, die Fehlermeldung wegen der Datanbank die nicht upgedated war erscheint nicht mehr. Leider hat das aber noch nichts am Verhalten geändert (siehe vorhergehende Postings). In xxv unter "Gruppiere alle Aufnahmen in einem Verzeichnis" angegebene Verzeichnisse werden bei mir seid Umstellung auf 0.5n nicht mehr berücksichtigt, Verzeichnisstrukturen die sich aufgrund von Serienname und Folgentitel ergeben hingegen schon. Weiss jemand noch einen Tip?


    Gruss,
    gandalf

    Hmm, auf der anderen Seite sagt mir das update-xxv script folgendes:


    Was denn nu?


    Bei einem Neustart nörgelt der xxvd jedenfalls wieder die nicht passende Version an.


    Frust, gandalf


    P.S.: xxvd gibt den Tip doch das contrib/upgrade-xxv.sh laufen zu lassen, an besagter Stelle findet sich aber nur ein update-xxv mit gar keiner Endung, ist aber ein Skript und erzeugt den oben wieder gegebenen Output. Mein Skript liegt in /usr/share/vdr-xxv/contrib


    P.P.S.: Und noch eine Fehlermeldung im Log von der ich nicht weiss ob sie wichtig ist oder nicht:

    Code
    17 (550) [20:18:33] Encode: Can't locate Encode/ConfigLocal.pm in @INC (@INC contains: /usr/bin/../lib /usr/bin /usr/share/perl5/vdr-xxv/ /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/lib/perl/5.8/Encode.pm line 52.
    18 (550) [20:18:33] Stream: Can't locate Net/DNS.pm in @INC (@INC contains: /usr/bin/../lib /usr/bin /usr/share/perl5/vdr-xxv/ /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at (eval 65) line 1.
    Zitat

    Originally posted by wilderigel
    Eventuell update der Datenbank fehlgeschlagen?


    Einträge in der xxvd.log in /var/log/vdr-xxv?


    Update der DB werde ich mal prophylaktisch wiederholen. Im Log finden sich Fehler der Art:

    Code
    95 (250) [17:45:14] TIMERS: DBD::mysql::st execute failed: Column 'ChannelID' cannot be null at /usr/share/perl5/vdr-xxv
    //XXV/MODULES/TIMERS.pm line 641.
    96 (250) [17:45:22] TIMERS: DBD::mysql::st execute failed: Column 'ChannelID' cannot be null at /usr/share/perl5/vdr-xxv
    //XXV/MODULES/TIMERS.pm line 641.


    And yes, die folgende Zeile habe ich dann auch noch gefunden:

    Code
    6 (550) [15:01:36] main: Upps, you have a incompatible database. Please use the script contrib/upgrade-xxv.sh to convert
     the database!


    Wie immer ist der wilde Igel auf der richtigen Fährte. Also erst mal Kommando zurück ich werde das DB Skript anwenden.


    Danke vorerst mal,
    gandalf

    So, jetzt habe ich nach sehr vielen Monaten der dankbaren XXV Nutzung tatsächlich mal wieder einen Fehler zu vermelden. Ich fahre die ct3 Distribution und die hat seid einiger Zeit per automatischem aptitude upgrade auf die 0.50(585) upgedated. Leider ist seither eine wichtige Funktion "verloren" gegangen:


    In den Autotimern konnte/kann man ein Verzeichnis angeben, in dem die Aufnahmen gruppiert werden sollten. Unterhalb dieses Verzeichnisses greift dann die XXV-interne Logik der Verzeichnisstruktur Serientitel~Folgentitel. Das klappte bislang immer hervorragend und half mir meine 200 Kinderserienfolgen unter Kontrolle zu halten. Schön und gut! Leider hält sich meine aktuell installierte Version des xxv (s.o.) nicht mehr an die gemachten Vorgaben und platziert die Serien munter im Root-Verzeichnis. Die weitere Verschachtelung nach Serientitel und Folgen in jeweils einem Unterverzeichnis klappt dann aber wieder einwandfrei.


    Hat jemand eine Ahnung woran das wieder liegen kann. Der von mir gewählte Verzeichnisname ist "Kinderserien" und ja nun wahrlich nicht aussergewöhnlich.


    Gruß,
    gandalf

    maec
    Ja das sind die Standard ct3 Kernel und Treiber


    kilroy
    Leider ist der Rechner, Monitorlos, weit weg von von meinen Arbeitsrechnern fest eingebaut. Wir eine Weile dauern entweder den Monitor zum Rechner oder den Rechner zum Monitor zu bringen, um einen Speichertest durchzuführen. Aber vielleicht ist das ja die Ursache. Was mich wundert, es passiert immer während des "complex"


    Gruß,
    gandalf

    OK,
    Du hast ja recht. Man sollte sich nicht immer darauf verlassen, dass der Fehler am Ende der Logdatei zu finden ist. Danke aber mal für die Geduld und den entscheidenden Hinweis. Bin jezt auch auf mplex umgestiegen und habe seither auch ein paar DVD brennen können. Immer mal wieder kommt es aber auch dazu:


    Wobei wie gesehen der vdr aussteigt und neu startet. Leider kommt man anschliessend weder per FB noch SSH oder PING an den vdr Rechner ran. Ein Cold Reset ist also angesagt. Dabei sagt das Log nichts mehr aus. Es gibt nur die üblichen Startmeldungen des VDR aus, abschliessend mit:


    Das entsprechende Logfile sieht eigentlich harmlos aus, ich habe es aber auch mal angehängt.


    Vielleicht ist jemandem anderen das auch schon mal vorgekommen?


    Gruß,
    Gandalf

    Hallo,


    Nun ist also wieder mal so weit, ich brauche eure Hilfe. Da vdrconvert in letzter Zeit seehr wählerisch ist mit dem was er brennen will und was alles nicht, wollte ich auf das vdr-plugin-burn ausweichen. Zudem gefiel mir das Konzept die Hintergründe und Button-Oberflächen leicht austauschen zu können, die Möglichkeit Texte über zwei Seiten anstatt den Font gegen Null Punkt gehen zu lassen ...


    Leider bricht das Plugin seine Arbeit nach dem dmuxen mit einer nicht viel sagenden Fehlermeldung ab, offenbar weil es der Meinung war einen AC3 Stream in der Aufnahme entdeckt zu haben ("Das fünfte Element"). Das ist auch, da ProSieben, durchaus möglich. Leider ist das entsprechende File nach dem Demuxxen aber sehr kurz geraten, 0 bytes. Das veranlasst dann natürlich im nächsten Schritt mplex zum Abbruch. Das Logfile habe ich beigelegt.


    Ich denke ich mache da noch einen Denkfehler der sich leicht beheben lässt, aber leider war eine ausführliche Suche im Forum nicht erfoglreich.


    Kann jemand helfen?
    Gruss,
    gandalf

    Zitat

    Original von TomG
    Seltsam ist natürlich, dass du das Problem vorher nicht hattest. Ich kann mir nicht vorstellen, dass die Installation der vdrdevel-Pakete das bewirkt hat. Wurden auch andere Pakete aktualisiert?


    Tom


    Ich aktualisiere generell mein System über
    apt-get update;apt-get upgrade
    Da kommen auch schon mal andere Pakete, Debian z.B., dazwischen.


    Wie ich vermutet habe, das wird eine langwierige Geschichte.


    Danke jedoch erstmal,
    Gandalf

    Hallo Leute,


    seid dem Update auf den .27er vdr habe ich ein "Phänomen" das ich vorher nicht hatte :)


    Nach etwa 2 Tagen verabschiedet sich der gesamte Kernel in einer Weise das ich nicht mal mehr übers Netz an den Rechner rankomme, kein ping kein gar nichts. Ich habe dem Teufelchen jetzt mal eine Falle gestellt indem ich auf einem Rechner im Netzwerk ein tail -f /var/log/syslog mitlaufen liess. Hier ist der Output:


    Ich kann mir daraus keinen Reim machen aber ich bin ja auch nicht der Kernelspezialist.


    Bin für jeden Hinweis dankbar.
    Gandalf

    Ich würde mich nicht als Experten für DVB unter Linux bezeichnen, aber unter dem 2.4.27 Kernel gab es ein HowTo (einfach mal :suche) das in etwa folgendes enthielt.


    1. unter /etc/modutils liegende Dateien dienen zum Beschreiben der beim Booten zu ladenden Module. Hier wurde unter dem Kernel 2.4.27-ctvdr-1 eine Datei namens linuxtv-dvb.2.4.27-ctvdr-1 angelegt, bzw. erweitert, die essentiell folgende Zeilen enthielt:
    add probeall dvb dvb-bt8xx dvb-bt8xx
    below dvb-bt8xx mt352


    2. mit update-moduls wurden die Dateien dann geparst und das Resultat ist die /etc/modules.conf.


    Es gibt also einen Weg die Sache automatisiert laden zu lassen ohne gleich zu den weiter oben beschriebenen Verzweifelungsskripten zu greifen. Jetzt heisst es nur noch die wirklich notwendigen Module auszutesten und entsprechend zu verfahren.


    Wie gesagt ich würde im Leben nicht behaupten ein Linux-Guru zu sein, deshalb bitte beim Testen vorsichtig sein.


    Und natürlich gilt immer noch:
    Wenn es einer besser weiss, bitte melden !!
    Gandalf

    Zitat

    Original von peter_weber69
    :
    :
    Vorteil wäre, es könnte auch ein Windows Laptop sein und müßte nicht einmal Linux drauf installieren, falls dies hier überhaupt wer nicht will!
    :
    :


    Leider(?) sind die meisten meiner Clients Windows "Maschinen". Ich war bislang der Meinung Xine würde es nur für Linux geben. Hab ich mich da geirrt? Wenn ja wäre ich für einen Link dankbar.


    Gruss,
    Gandalf

    Ich denke auch dass 350 GHy eventuell zur Spassbremse werden können.


    Je nach Empfangslage dürfte die Bandbreite auf dem WLAN auch ein kritischer Faktor sein. Versuch den Accesspoint so "nah wie möglich" am Rechner aufzustellen. Die Aufnahmen beanspruchen in etwa 4MBit/s.


    Eine Grafikkarte würde ich in jedem Fall drinlassen. Erstens wird die Installation einfacher, zweitens soll es auch schon vorgekommen sein, dass der Rechner im Bootvorgang stecken bleibt. Bei Verwendung der ersten Versionen von xxv entsorgte z.B. die Verwendung der mySQL Datenbank hin und wieder zuverlässig allen freien Plattenplatz, was mySQL beim Booten mit einer langen Bedenkzeit quittiert. Für diese Fälle ist es einfach essentiell einen Monitor anschliessen zu können. Aber das ist dir sicher auch schon vorgekommen


    Viel Spass beim Basteln,
    Gandalf

    Zitat

    Original von wilderigel
    Hat bei mir eigentlich keine Probleme verursacht.
    Paket ist von Backports von Tobi:

    Code
    deb [URL]http://www.e-tobi.net/vdr/sarge/experimental/binary[/URL] backports/


    Und das war genau der Bringer.
    Danke wilder Igel,
    Gandalf


    Ich habe exakt dasselbe Problem. Und es half auch kein rumprobieren und auch kein installieren von pwgen. Wie man vermuten kann führt auch ein

    Code
    apt-get install dbconfig-common

    nicht zum Ziel sondern lediglich zur Antwort:

    Code
    vdr:/var/lib/vdr-xxv# apt-get install dbconfig-common
    Paketlisten werden gelesen... Fertig
    Abhängigkeitsbaum wird aufgebaut... Fertig
    Paket dbconfig-common ist nicht verfügbar, wird aber von einem anderen
    Paket referenziert. Das kann heißen, dass das Paket fehlt, dass es veraltet
    ist oder nur aus einer anderen Quelle verfügbar ist.
    E: Paket dbconfig-common hat keinen Installationskandidaten


    Leider liessen sich die neuen Skins sehr wohl installieren und das führt jetzt zu einer etwas uneinheitlichen Darstellung.


    Wer weiß Rat?
    Gandalf


    Sorry das ich noch nicht Vollzug gemeldet habe. Aber es war lediglich ein Konfigurieren auf

    Code
    MEDIAWRITER="/dev/hdc"

    notwendig und schon schwuppte die Sache, auch mit meinem Antik-Kernel 2.4.27


    Gruß,
    Gandalf

    OK ok thc und Aileenis,


    ihr habt vollkommen Recht. Allerdings ist dieses Log vollkommen unauffällig. Gerade habe ich aber beim Durchforsten des Verzeichnisses gesehen, dass es auch noch ein burn.log gibt. Dort wird der Schreiber unter /dev/sdc0 gesucht was bei mir nicht klappen kann, hdc0 wäre bedeutend besser ;(


    Also dann mal frisch gegrept und siehe da, die vdrconvert.conf definiert dieses. Und ich hatte mich nur auf die vdrconvert.dvd.conf gestürzt. Erschien mir irgendwie logisch. Also werden wir gleich einen neuen Versuch ansetzen, nachher mehr.


    Danke für den Denkanstoß,
    Gandalf