Beiträge von Lernt's_nich

    Also gut, dass ich ein altmodischer Witzbold bin, hätten wir dann schonmal festgestellt.


    vdr-err heißt aktuell vdr-err.XfHZa8 und ist seit heute Morgen 620k groß. Exemplarisch ein paar Inhalte:



    Das ist mein Rumgebrowse auf dem live Webinterface. Fehler gibt es zwischendurch einige wenige, aber die sind eher vernachlässigbar.


    Es scheint, Quelle ist runvdr, bei mir in /usr/sbin liegend. In dem Skript findet sich



    D.h. da wird wohl stderr in eine Datei im Temp-Verzeichnis umgeleitet, und die produziert dann derartige ... Debug-Ausgaben von Live.


    Sagt das jemandem was? Ich habe keine Ahnung von dem Sinn, aber wenn niemand dazu eine gute Idee hat, dann würde ich einfach in runvdr stderr nach /dev/null umleiten.


    Und schließlich noch zur Distribution: Das ganze stammt aus dem Frodo-PPA, welches auf dem yaVDR ppa beruht, s. Thread: [Frodo PPA] vdr 2.2.0 für testing yaVDR


    Du bist ja ein Witzbold, wenn du es selber umleitest, dann funktioniert logrotate natürlich nicht. Allerdings frage ich mich warum du es für die Übersichtlichkeit umleitest, aber dann nicht rein siehst?

    Ich habe das aus dem Syslog umgeleitete /var/log/vdr.log und zusätzlich /tmp/vdr-err*. Letzteres heute Morgen bis zu einer Größe von 450 MB. Und letzteres möchte ich mindestens in einem anderen Verzeichnis haben.


    Es gibt, wenn man nach vdr-err googelt, einige Treffer, die mich darauf schließen ließen, dass es durchaus normal ist, dass in tmp sowas angelegt wird. Deswegen dachte ich, das ließe sich konfigurieren/abstellen/umleiten.


    Ich poste nachher mal einige exemplarische Inhalte, wenn sich wieder was angesammelt haben sollte.

    vdr selbst loggt "normal" in /var/log/vdr.log (vorher im Syslog, ich hab's durch Anpassen der Config von rsyslog umgeleitet, der Übersichtlichkeit halber.)
    Die Menge an Daten in diesem Log von vdr ist durch diverse Searchtimer ziemlich hoch. Aber der Teil funktioniert, einschließlich logrotate etc., wunderbar.


    vdr-err im temporären Verzeichnis scheint davon unabhängig zu sein. Dort stehen andere Dinge drin. U.a. erzeugt das live plugin dort Statusmeldungen etc. Wirkliche Fehler konnte ich da auf Anhieb nicht finden. Aber mir fehlte auch ein wenig die Zeit. Finde ich da Fehler, untersuche ich das (und mache dazu ggf. einen neuen Thread auf).


    Bis dahin bleibt die Frage: Kann ich den Speicherort für vdr-err ändern? Ich hätte das als Logfile, als das es offensichtlich gedacht ist, lieber in /var/log irgendwo.

    Hi,


    gibt es eine Option, mit der ich den Speicherort von vdr-err* ändern kann? Vielleicht auch die Größe beeinflussen?


    Hintergrund: /tmp ist eine RAM-Disk hier, aktuell 500 MB. Die ist gerade vollgelaufen wg. eines vdr-err mit 450 MB. Ich habe jetzt erstmal einen täglichen cronjob angelegt, der /tmp/vdr-err* löscht, aber das scheint mir eher ein Notbehelf zu sein.

    Kommt alles aus den yaVDR Quellen, natürlich.


    VDR aktualisiere ich gerne. Aber die ganzen Audio-Treiber, dkms, etc., würde ich gerne sein lassen (wenn VDR headless da nicht auf spezielle Versionen zwingend angewiesen ist). Läuft ja noch mehr auf der Kiste neben meinem Spielzeug :D . (Am liebsten hätte ich den VDR in eine VM verschoben, dann könnte ich da einfacher dran rumspielen. Aber ich bekomme meine SAT-Karte da nicht vernünftig hin durchgereicht...)


    If it ain't broken, don't fix it! ;D

    In der Hoffnung, das richtige Forum und den richtigen Thread getroffen zu haben: Ich habe hier VDR als headless server auf Ubuntu 12.04 aus den yavdr Quellen laufen. Die bieten mir ja nun ein Update an, yaVDR auf 2.0.6 und diverse weitere Pakete:


    Code
    The following packages have been kept back:
      tntnet-runtime vdr vdr-plugin-epgsearch vdr-plugin-live
      vdr-plugin-streamdev-server
    The following packages will be upgraded:
      debootstrap dkms liblircclient0 libpulse-mainloop-glib0 libpulse0
      libpulsedsp linux-firmware-nonfree lirc oscam-upstart pulseaudio
      pulseaudio-esound-compat pulseaudio-module-bluetooth
      pulseaudio-module-gconf pulseaudio-module-x11 pulseaudio-utils


    Da die Kiste ein Server ist (daher auch noch 12.04, 12.04 server hat ja noch keinen offiziellen Upgrade-Pfad zu 14.04), würde ich tatsächlich nur den oberen Teil updaten (tntnet-runtime, vdr, vdr-plugin-*) und den unteren Teil sein lassen.


    Es wäre schön, wenn mir kurz jemand bestätigen könnte, dass ich das richtig verstanden und keine weiteren Abhängigkeiten übersehen habe. :engel2


    Danke!

    Hi, ich nutze Suchtimer in epgsearch, um alle Folgen und Staffeln bestimmter Serien aufzuzeichnen. Zur Vermeidung von Wiederholungen verwende ich Subtitle, if present. Das klappt. (Yay!)


    Manchmal gibt es Probleme mit einzelnen Folgen, z.B. dass die Vor- oder Nachlaufzeit nicht lang genug war und deswegen was abgeschnitten ist. Solche Folgen sollen dann natürlich bei der nächsten Ausstrahlung nochmal aufgezeichnet werden. Aktuell gehe ich dazu so vor, dass ich vdr beende, in epgsearchdone.conf den Eintrag für die Folge (Zeilen R bis r) mit einem Editor lösche und dann vdr wieder starte. Ist das so richtig? Oder gibt es ein besseres/einfacheres Vorgehen?


    Ach ja, gibt es eigentlich eine Maximalgröße für epgsearchdone.conf? Da ich auch Filme über Suchtimer aufnehme, damit im Fall von Konflikten vdr die nächste Ausstrahlung aufnimmt, wächst diese Datei recht zügig...


    Danke!

    :gemein


    Nachdem das hier jetzt vielleicht 12 Stunden mit 2 Plugins in eher Minimalkonfiguration läuft, woher soll ich wissen, wie es um Langzeitstabilität, Kompatibilität mit weiteren Plugins etc. bestellt ist? Ich muss nicht zwingend alles durch eigene Erfahrung mühsam erlernen, sondern bin auch gerne bereit, von anderen zu lernen. Allerdings läuft auf der Kiste hier noch mehr, so dass ich nicht einfach neue Kernel draufwerfe, sondern vorher gerne verstehe, warum.


    Aber ich stelle die Frage gerne für einen weiteren Versuch um: Was ist der Grund dafür, dass oben der raring statt des quantal-Kernels empfohlen wurde?

    Hi, ich habe ein paar Suchtimer für Serien eingerichtet. Das funktioniert nach einigem Rumbastln, sogar recht gut mit Vermeidung von Wiederholungen.


    Wenn ich jetzt einen anderen Timer einrichte (z.B. um irgendwo einen Film aufzunehmen), und es einen Konflikt gibt, dann gibt mir Live einen Konflikt aus, den ich lösen kann, indem ich Timer lösche. Da die Serien häufiger kommen, löse ich den Konflikt dann durch löschen des Timers für die kollidierende Episode. Das klappt auch. Aber: Meine (naive?) Hoffnung war, dass epgsearch dann (automatisch oder beim nächsten manuellen Anstoßen von "Trigger search timer update" eine der vorher deaktivierten Wiederholungen der Serie stattdessen aktivieren würde. Klappt aber nicht, es passiert nichts bzw. ich muss manuell die Wiederholungen raussuchen und dann für die Alternativen einzelne Timer erstellen.


    Gibt es irgendwo eine Möglichkeit, das Vermeiden von Konflikten in dieser Form zu automatisieren, dass epgsearch automatisch auf alternative Sendetermine/Wiederholungen für einzelne Folgen ausweicht? Oder dass epgsearch bei einzelnen deaktivierten Sendeterminen automatisch einen anderen wählt?


    Danke!

    Wunderbar, danke, dann lasse ich das so. VDR habe ich gerade mal wie oben angegeben installiert, scheint zu laufen und EPG Daten zu sammeln. Und ich muss dringend die mitgelieferte channels.conf dramatisch ;D reduzieren.


    Was mir aufgefallen ist:

    • Dauernde lirc-Fehler im syslog ("ERROR (lirc.c,43): /var/run/lirc/lircd: No such file or directory"). Dazu gibt es einen Thread, demzufolge sich das Problem weghacken lässt, wenn man den Test auf die lirc-Installation im init.d-Script auskommentiert. Ich nehme an, das ist state of the art, was anderes habe ich bei Google nicht finden können.


    • /etc/vdr enthält einen Link auf /var/lib/vdr/setup.conf - die Datei gibt es aber nicht und wurde auch nicht erzeugt, d.h. der Link geht ins Leere. Die Suche hierzu führte einiges zu Templates zutage, allerdings habe ich das so verstanden, dass aus den Templates eigentlich bei der Installation erst- und einmalig eine setup.conf erzeugt werden sollte. Aber wie jetzt weiter?


      Brauche ich eine setup.conf? Kann ich die aus dem Wiki als Startpunkt kopieren? Soll ich nur eine leere Datei erzeugen (touch)?