Posts by löwe

Hallo!

Ich hatte dieser Tage das selbe verflixte Problem und bin sogar mit den hier empfohlenen Windows-Tools gescheitert. Mein bestes Ergebnis dabei war ein funktionierender USB-Boot-Vorgang in das Installationssystem, danach aber blieb das Setup nach der Auswahl des von mir bevorzugten Spiegelservers bei blauem Hintergrund ohne Text hängen. Für Stunden, bis zum Abschalten des Systems durch mich.

Inzwischen weiß ich aber: Klappt die Installation, wird so eine Abfrage nach dem bevorzugten Mirror-Server erst gar nicht durchgeführt. Die Installation startet stattdessen schon.

Lösen konnte ich das Problem mittels dd, und zwar auch nicht auf den ersten Anlauf. Ein Kopieren des Images auf die erste Partition des USB-Sticks scheiterte insofern, als dass beim Boot zwar eine Meldung von wegen Isolinux, etc. erscheinte, der Rechner bootete letztendlich dann aber nicht das yaVDR-System vom Stick.

Geholfen hat ein Kopieren des Images direkt auf den Stick, mit Überschreiben der gesamten Partitionstabelle darauf. Ist der USB-Stick beispielsweise /dev/sdb, so klappt dieses Kommando:

sudo dd if=yavdr64-0.5.0.a.hybrid.iso of=/dev/sdb bs=4M

Um auf die diversen Probleme beim VDR-Logging einzugehen, hier nun eine Lösung, die mit einer Config-Änderung an nur einer Stelle so weit alle Fälle abdeckt.
Ergeben sich neue Einträge/Situationen ist die Config einfach anpassbar.

/etc/rsyslog.d/30-vdr.conf

# Enhanced VDR log handling. Redirect (and suppress) VDR-messages logged to syslog


## Suppress repeating messages with low relevance
# Messages related to the deactivated VDR-shutdown (on a server)
if $syslogtag startswith 'vdr-shutdown' and $msg contains 'Shutdown deactivated (see /etc/default/vdr)' then ~
if $syslogtag startswith 'vdr' and $msg contains 'executing \'/usr/lib/vdr/vdr-shutdown-message' then ~
if $syslogtag startswith 'vdr' and $msg contains 'saved setup to /var/lib/vdr/setup.conf' then ~


# PID changes
if $syslogtag startswith 'vdr' and $msg contains 'changing pids of channel' then ~




## redirect all remaining VDR related messages to a seperate log file
if $syslogtag startswith 'vdr' then -/var/log/vdr/vdr.log
& ~

Gestoßen bin ich bei der Loggin-Problematik unter Anderem auf folgende Probleme, die mich letztendlich zur obigen Lösung führten:

• Der VDR besteht nicht nur aus der VDR-Binary selbst, sondern auch aus diversen Shell-Scripts. Diese loggen allesamt wild umher und ignorieren dabei die Config-Einstellung in der /etc/default/vdr die besagt, dass der VDR in einen bestimmten Syslog-Kanal loggen soll
• Leider hält sich nicht einmal die VDR-Binary selbst an die Logging-Einstellungen der /etc/default/vdr. Insbesondere sind es Plugins, die scheinbar recht ungezwungen direkt ins Syslog schreiben ohne jegliche Konfiguration zu beachten

Deshalb die Syslog-Anpassung, welche praktischerweise an zentraler Stelle mit nur einer zusätzlichen Datei zu bewerkstelligen ist - ohne etwaige bereits vorhandene Dateien anpassen zu müssen. Zusätzlich habe ich so auch gleich die Gelegenheit genutzt, um nicht relevante Meldungen gleich ganz zu unterdrücken.

Nicht ganz schön dabei ist lediglich, dass in Ubuntu 12.04 scheinbar eine Uralt-Version des rsyslog-Daemons verwendet wird. Den RainerScript-Code oben musste ich deshalb unschön redundant gestalten, da mir der rsyslog-Daemon einfach keine spitzen Klammern und eine Strukturierung der Bedingungen über mehrere Zeilen zulässt.
[/list]

Um das Syslog sauber zu halten, fehlt hier noch ein wichtiger Aspekt: Der Auto-Shutdown des VDR-Rechners mit speziell den Meldungen, dass eben dieser Shutdown deaktiviert ist und nicht durchgeführt wird.

Gerade auf einem Server (den man aufgrund der Server-Eigenschaft nicht herunterfährt) ist das ein Umstand, der ein ansonsten sauberes Syslog im Abstand von ca. 10 Minuten vollknallt.

Ergänzend zum Vorschlag von oben ergibt sich dann folgende Config-Datei für den rsyslog-Deamon:

# VDR
local6.*        -/var/log/vdr/vdr.log
local6.*        ~


# VDR-Shutdown-Routinen
:syslogtag, startswith, "vdr-shutdown"  /var/log/vdr/vdr.log
&                                       ~

Das wäre Mal ein Anfang ...

Damit sind es dann nur noch einzelne wenige Meldungen, die sich dennoch ins normale Syslog verlaufen.

Bei einem aktuellen yaVDR zB

Jan 23 17:14:18 microserver vdr: [18891] cTimeMs: using monotonic clock (resolution is 1 ns)
Jan 23 17:14:18 microserver vdr: [18891] [general.debug] using new 1.7.11+ capture code

Besser geeignet für eine saubere Behandlung der VDR-Logs scheint mir daher ein Abstellen auf den Syslog-Tag beginnend mit "vdr" zu sein.
Zugleich würde man sich damit auch die Umleitung der (leider nur meisten) VDR-Meldungen nach localX über die Einstellung in der /etc/default/vdr ersparen, was die Sache gleich nochmal schöner macht (die Log-Umleitung ist nur mehr an einer zentralen Stelle im System konfiguriert --> rsyslog)

Nachdenken könnte man auch darüber, regelmäßige sinnlose Meldugen wie "Shutdown verhindert da Konfig-mäßig deaktiviert" (sinngemäß) inkl. der dazugehörigen Meldung vom VDR-Prozess selbst überhaupt zu unterdrücken. Ehrlich gesagt ist es mir bei diesen Meldungen zu schade um die Abnutzung der Speicherzellen meiner Server-SSD.

Vielleicht poste ich hier noch eine rsyslog-Config-Datei, die alle diese Überlegungen beinhaltet.

Die Österreich-Kanäle sind nun richtig gruppiert und meiner Meinung nach auch vollständig.

Danke dass du das so schnell hingebogen hast

Auch ein paar "Ausreißer" die ich von meinem damaligen Test im Kopf hatte sind nun vorhanden und auch richtig gruppiert. Einzig "MTV Live HD" ist derzeit unter "uncategorized" in einer kleinen MTV-Gruppe gelistet, obwohl der Sender (auch) über Sky verfügbar ist. (siehe hier: http://www.sky.at/web/cms/de/senderlayer-187-mtv-live-hd.jsp?TB_iframe=true&height=530&width=615). Wo man den Sender zuordnet dürfte aber wohl eine Glaubensfrage sein, denn abonnierbar ist MTV so weit ich weiß bei verschiedensten Anbietern.

Deine Wiederholungen dessen habe ich durchaus vernommen, allerdings darauf bezogen, dass damit das Problem nicht aktueller Kanal-Einträge des Thread-Erstellers behoben sei, und deiner Ansicht nach ein Bemühen Channelpedia aktuell zu halten damit obsolet sei. Bis auf die Beiträge die ich direkt an den Threadersteller gerichtet habe, stand mir aber immer die Aktualität der Channelpedia-Listungen im Vordergrund.

Was "CP" sein soll das ich hepi überlassen soll, das weiß ich nicht.
Ich hoffe aber, dass es nicht meine Aktualisierungs-/Löschvorschläge sind die ich sein lassen soll, denn darum hat hepi weiter vorne audrücklich gebeten. (Es ist ja hoffentlich nicht so, dass die linke Hand nun nicht haben will, worum die rechte gebeten hat ...)

@DaKilla: Ich halte nichts von haltloser pauschalierter Kritik die am Thema völlig vorbei geht. Ausführliche Stellungnahmen bedürfen deshalb möglichst detaillierte Erläuterungen. (wer lieber kürzere Lektüre so spät am Abend genießt und deshalb runter scrollen muss, der möge mir bitte verzeihen). Und man sieht ja am Beitrag von hepi weiter hinten, dass mein Beiträg trotz seiner vielen Punkte die Warheit noch nicht vollständig zu 100 % abdeckt.

hepi: Ich hoffe du verstehst mich nicht falsch, aber wenn die ganze Diskussion (die woanders natürlich treffender zu führen wäre als in diesem Thread; obwohl: das Thema Channelpedia-Update habt genau ihr angeschnitten uns ins Rollen gebracht, so viel muss ich schon festhalten) dazu geführt hat, dass eine irrtümliche Update-Einstellung von 3 auf 5 geändert wurde, dann sehe ich das als ganz deutlichen Erfolg dieses Threads.

Mangels anderen Thread den ich gerade zur Hand habe, hier noch ein paar Verbesserungs-/Anpassungs-Hinweise, die hoffentlich konkret genug sind um zweckdienlich zu sein (der Thread hier wird es hoffentlich noch aushalten):

S19.2E - Section at - Gruppe "Private HDTV FTA"
Hier sind alle Sender ungültig (gibt es nicht mehr), bis auf "ServusTV HD Oesterreich"

Demnach ungültig:
ALT RTL HD Austria
ALT RTL2 HD Austria
ALT VOX HD Austria

Die Sender gibt es unter neuen Frequenzen, ohne dem Präfix "ALT" im Namen, in deiner jetzt dann neuen channels.conf findest du sie sicher. Gruppenmäßig gehören diese neuen Kanäle zu "Private HDTV scrambled".
Was ganz fehlt (oder nur anderswo gruppier ist), ist TELE 5 HD Austria (findest du sicher auch bald in richtiger Form in deiner channels.conf), was auch "Private HDTV scrambled" zuzuordnen ist.

Durch Zufall habe ich auch entdeckt, dass im jetzigen Datenbestand der Kanal "AXN HD" fehlt, der thematisch wohl zu den Sky HD Kanälen zu zählen ist.

So weit zu dem, was mir vor eineinhalb Wochen bei einem kurzen Test der Channelpedia-Listungen auf Aktualität ins Auge gestochen ist, bzw. was ich dann bei aus reinem Interesse durchgeführten tieferen Nachbohren noch gefunden habe.

--edit--
Ich sehe gerade, dass die fehlenden Sender in diesem Moment scheinbar in der Channelpedia ergänzt wurde. Super Sache! Offen ist damit noch der Löschvorschlag der "ALT ..." Sender von oben, für sich alleine ist das aber wohl halb so schlimm ...

Der Prozess so eines Updates kann mannigfaltiger Natur sein, was für mich so weit auch voll und ganz nachvollziehbar ist (mit meinen Leuten habe ich schon ganz andere Projekte entwickelt, als so eine kleine Kanal-Parser/Sortierungs/Gruppierungs Webanwendung)

Nach vielen Beiträgen mit nicht weiter relevanten Infos und Verlinkungen wissen wir nun, dass channels.conf-Uploads von zusätzlichen Personen in der derzeitigen Implementation von Channelpedia gar nicht möglich / vorgesehen sind. Demnach war die hier von mir als 1. Schritt und ohne weitere Nachfrage völlig selbstständig vorgenommene Aktion, die neuen channels.conf nackt zur Verfügung zu stellen - damit andere sie bei eventuell vorhandenem Bedarf nach Channelpedia einpflegen können - das sich daraus ergebende einzig richtige Vorgehen, welches in dieser Situation möglich ist.

Dennoch die vielen Beiträge, die für sich sehr aufschlussreich sind, um nicht zu sagen lächerlich. Es wäre falsch die channels.conf "nackt" zur Verfügung zu stellen und darauf hinzuweisen, ich müsste sie stattdessen hochladen, dann viele Beiträge die vieles erläutern - nur nicht wie man die Datei nach Channelpedia hochladen kann - der Hinweis ich würde Beiträge nich lesen, und schlussendlich die Info man kann eine channels.conf gar nicht hochladen wenn man sie zur Verügung stellen möchte.

Ich bin sehr weit weg vom yaVDR-Projekt und seinem Umfeld, vermutlich habe ich deswegen eine sehr neutrale Sicht darauf, aber einen Orden verdient ihr euch mit diesem Vorgehen nicht.

Deine Bemühungen, hepi, weiß ich zu schätzen, dennoch aber kannst du mich ruhigen Gewissens direkt in deinen Beiträgen anschreiben. Wenn du meinst mir etwas mitteilen zu müssen, ist die 3. Person (die gute alte Form, wie einst Kaiser mit ihren Untertanen zu reden pflegten) wirklich nicht notwendig.

Die Vakanz deiner hier 2 zitierten Probleme ist mir durchaus bekannt, auch sehe ich hier Lösungsansätze, ganz besonders betrffend Problem 2.)

Das möchte ich noch näher erläutern, da euch das offenbar vor ernsthafte Probleme stellt:

Zitat: 2) Mehrere User laden konkurrierend Kanäle des gleichen DVB-Providers hoch: Welche Daten sind neuer, welche älter?

Anregungen:
Ein beachtenswerter Punkt ist hier klar die Automatisierung (wurde ja auch von gda zuletzt ganz *deutlich* hervorgehoben). Gestaltet man den Prozess bei seiner Umsetzung nun so, dass der automatischen Erstelung der channels.conf auch der Upload danach automatisch, und zwar möglichst zeitnah erfolgt (ein Upload kann deinen eigenen alten Beiträgen nach mittels cron-Jobs und curl erfolgen; kennst du deine Beiträge noch?)

... wenn der Upload also "unmittelbar" nach der automatischen Erstellung der channels.conf auch automatisch erfolgt, so gilt, dass eine später eintreffene channels.conf unterm Strich auch eine höhere Akualität aufweist (als Ausnahme davon wäre denkbar, dass im Upload involvierte Komponenten wie Netzwerk, Server, Server-Prozesse etc. ausfallen und dieser etwa verzögert durchgeführt wird).

Das ist aber eine Unschärfe die man so weit eingrenzen kann, bzw. verliert das Problem mit einer Erhöhung der Intervalle der channels.conf-Updates sowieso an Relevanz. Wird die channels.conf ganz plakativ täglich neu hochgeladen, und passiert es tatsächlich, dass einmal ein Upload erfolgt der nicht ganz frisch ist sondern bereits 20 Stunden alt (und damit auch älter als ein bereits anderer vorgenommenen Upload), so befindet sich ein darin vorkommender veralteter Kanal-Einträg nur bis zum nächsten channels.conf-Upload in der Channelpedia-Liste - und das wäre beim hier geschilderten Update-Intervall 1 Tag und damit weit besser als die derzeit vorhandenen fehlerhaften Einträge, die schon seit Wochen (oder Monaten?) nicht mehr funktionstüchtig sind.

Kurz: Das Problem Nr. 2) wäre eine Unschärfe die greifbar ist, zumdem ist ein Gegensteuerung durch Justierung der Upload-/Update-Intervalle möglich ...
... wo genau neue User ins Spiel kommen die auch regelmäßig Dateien bereit stellen würden (wie ich es zB wöchentlich, oder auf Wunsch auch täglich gemacht *hätte*). Mehr User = kürzere Intervalle bei gezielter Festlegung ihrer Update-Zeitpunkte.

Auch zu Problem 1) - dem Löschen von in Channelpedia gelisteten, nicht mehr vorhandenen Kanälen - fallen mir in sehr kurzen 30 Sekunden auch schon mehrere Lösungsansätze ein:

Unter obiger Prämisse, dass neue channels.conf-Dateien möglichst regelmäßig und zeitnah erstellt und hochgeladen werden (erreichbar zB durch mehrere User die sich beteiligen), wäre es durch mit einer gewissen Treffergenauigkeit zu bewerkstelligen, inzwischen aus dem Satelliten-System verschwundene Kanäle auch aus Channelpedia zu löschen.

Nach vorangeganenen statistischen Tests ("Erfahrungswerten") könnte zB so etwas raus kommen:
Wenn ein Kanal der Channelpedia in *X* (= "Erfahrungswerte" ) neu hochgeladenen channel.conf-Dateien NICHT MEHR vorhanden ist, dann wird er auch aus Channelpedia gelöscht.

Zur Schärfung des Algorithmus denkbare Vorgehensweisen: Bei der Zählung der letzten *X* channel.conf-Uploads werden nur solche Listen gezählt, die auch Neuerungen / neue Kanäle beinhaltet haben (Ziel: nur "verifiziert" valide, aktuelle, neue Listen berücksichtigen - so weit das halt alogrithmisch möglich ist)

Eine daraus resultierende Löschung in Channelpedia könnte man zudem so vornehmen, dass man in der SQL-Datenbank den Kanal in einer Spalte mittels Zeitstempel (oder Job-ID des jeweiligen Update-Runs der zur Löschung führte) nur als gelöscht markiert, was dann im Webfrontend draußen wie eine tatsächliche Löschung behandelt wird --> bei Fehlgriffen der automatischen "Löschung" wäre der Kanal mittels SQL-Update wiederhergestellt.

So weit zu den zitierten Problemen, in denen ich durchaus keine Einbahnstraße in die Unlösbarkeit sehe ...

Ansonsten gibt es nicht viel zu sagen, gepostet wurde an mich gerichtet wieder (wie gewohnt) das Übliche. Zusammenfassen würde ich es mit "Viel heiße Luft um nichts"
Das kann sehr wohl als Kritik verstanden werden, und ich hoffe, dass ich jeder der Leser der Beiträge hier eine eigene Auffassung darüber verschaffen kann.

Nach vielen langen Beiträgen wird mein Hilfsangebot damit abgelehnt - endlich, danke! - dass es bei verschiedenen Uploads verschiedener Stellen eventuell zu Inkonsitenzen bei den einzelnen Kanal-Listen kommen kann.
Das wäre so weit nachvollziehbar (und auch Lösungsvorschläge habe ich oben zumindest angeschnitten) ...

... wenn du nicht unmittelbar darauf im nächsten Absatz kategorisch ausschließen würdest, dass auch nur irgend jemand außer du selbst Daten hochlädt. Es gibt also nur 1 User, wodurch das Problem das bedingt durch mehrere User enstehen würde gar nicht auftritt.

Die Aktualität der Channelpedia zeigt zudem, dass nicht einmal der einzige User der Uploaded dies in den letzten Wochen (Monaten?) durchgeführt hat.

Es laden derzeit also genau 0 User regelmäßig hoch, womit durch regelmäßige Uploads eines neuen User (dadurch laden dann 1 User hoch), die bei >= 2 Usern auftretende Problemsituation auch nicht schlagend wird. Das Problem ist also irrelevant.

Selber setzte ich überigens - auf allen VDRs die ich betreue - channel.conf-Dateien ein, die zur vollsten Zufriedenheit funktionieren und auch vollständig sind (das kann ich so weit auch erklären, denn die stammen mittlerweile nicht mehr aus der Channelpedia). All meine Beiträge hier im Thread haben also nur die Hilfestellung anderen gegenüber betroffen.

Möge sich jeder selbst ein Bild darüber machen, wie die Prozesse hinter Channelpedia hier gerade ablaufen ...

Quote from gda

Und du willst einfach nicht verstehen, dass ein einzelner Upload nichts bringt, sondern es um die Regelmäßigkeit geht. Es geht darum das jemand regelmäßig auch die veränderte Liste uploaded und zwar automatisch im Hintergrund.
Was nützt deine Liste die du großzügig anbietest, wenn sie in einer Woche wieder veraltet ist?

Gerald

In 3 Postings hier im Thread habe ich genau das insgesamt 3x angeboten, und selbst im letzten Beitrag noch ein viertes Mal erwähnt. Eine nachträglicher Fakten-verändert-darstellen-Anlauf verliert genau dann für den Leser völlig seinen Charme, sobald die Beiträge über deinen obigen hier betrachtet werden

Überdies wäre im derzeitigen Zustand auch mit einer einmaligen Aktualisierung sehr wohl und definitiv geholfen, wenn die hier im Thread genannten mittlerweile ungültigen Kanal-Einträge (und die wurden genannt lange bevor ich dazu kam) *einmalig* gelöscht werden (ein jetzt bereits aufgrund Einstellung toter Kanal ist auch nach regelmäßigen Updates immer noch tot) und neu hinzugekommene Kanäle *einmalig* hinzugefügt werden (womit sie bis zum nächsten Kanal-Update funktionierend über Channelpedia beziehbar wären - jetzt sind sie es gar nicht)

Ja sehr schön, dann habe ich lokal eine Channelpedia-Instanz laufen - ganz alleine für mich.

Was denkst du? Wenn ich den Inhalt von Wikipedia an unvollständigen Stellen vervollständigen möchte bzw. an einer Mithilfe daran interessiert bin, werde ich mir dafür dann lokal eine (leere) Wikipiedia-Instanz installieren?

Ihr wollt einfach nicht. Selbst auf mein drittes Angebot die Senderlisten in Channelpedia (und zwar DER Channelpedia-Liste - nicht eine lokale Version die sich ein Nerd in seinem dunklen Keller installiert) zu vervollständigen durch Zuverfügungstellung aktueller channels.conf-Einträge (oder auch mehr, also echte Entwicklungsarbeit auf meiner Seite) kommt wieder nur ein allgemeiner Link, der das hier von mir geforderte Hochladen (ein Posten der channels.conf hier ist ja zu wenig) zu Channelpedia (zu DER Channelpedia-Liste) genau nicht behandelt.

In der Suche auf eine konkrete Antwort auf meine konkrete Frage, meine insgesamt 3x konkret angeführtes Angebot der Mithilfe in die Tat umsetzen zu können habe ich deine Beiträge sehr wohl ausführlichst gelesen (selbst die von dir hier als Antwort-Post auf meine Frage geschriebenen) und musste den Inhalt bezogen auf das konkrete Vorhaben und die daraus resultierte Fragestellung als unzutreffend (=Mist) klassifizieren.

Quote

Warum soll ich Deine Postings lesen, wenn Du meine nicht liest?

Meine Postings hast du sehr wohl gelesen, wie der Art deines Beitrags weiter oben zu entnehmen ist. Der Frage ist demnach keine Relevanz zuzuerkennen, so wie anderen "Hilfestellungen" vom hohen Ross herab kommend. Überdies habe ich auf dieser Seite keine anderen Beiträge gepostet, als mein Angebot zur Mithilfe in einer Form wie auch immer notwendig immer wieder nur zu wiederholen - alleine deshalb schon ist man voll im Bilde worum es geht.

Meine Tür in Sachen regelmäßige und vor allem nachhaltige Channelpedia-Senderlistenpflege (was die Qualität real gehoben hätte) ist nun zu - mehr als euch wiederholt anzubieten genau das tun zu wollen was ihr schreibt das ihr in der Situation brauchen würdet, das ist eben nun mal nicht möglich wenn ihr nicht herausrückt mit den nötigen Infos, ihr also nicht wollt.

Von mir aus geht unter in den nicht (mehr) funktionierenden Sendern der Channelpedia, und genießt die Leere, dort wo Sender wären, euch aber schlichtweg die aktuellen Einträge fehlen (beim Aufruf zur Hilfe verweigert ihr mir meine die hier anfangs geschilderten Probleme behenbende channels.conf zur Channelpedia hochzuladen; und einen User um die Liste selbst hochzuladen - sogar das würde ich euch abnehmen - gebt ihr mir nicht)

Ich bin mir sicher ihr macht das schon mit der Channelpedia-Wartung - wie weiß ich nicht, (und die augenscheinlich vorhandene Aktualität und Qualität lässt Zweifel offen an der prakizierten Vorgangsweise), irgendwie aber sicher. Was ich aber definitiv weiß, ist, dass es ab sofort ohne mich geschieht und sich das auch nicht ändern wird - so weit kann ich mich festlegen. Untergehen wird das Kanalverzeichnis damit heute zwar nicht, besser wird es aber auch nicht wenn ihr es nicht besser haben wollt.

Ach du bist dafür zuständig, warum konnte mir gda das nicht gleich sagen, anstatt mich mit Anleitungen und Links in die Wüste zu senden (die Infos wurden sicher sehr schön zusammengesucht, wie ich meine Datei zur Verfügung stellen kann bzw. uploaden wie von gda erläutert, erfährt man daraus aber genau nicht)

Eine channels.conf kann ich gerne mittels w_scan erstellen und hochladen, sogar ein Programm würde ich schreiben welche die Schritte regelmäßig und automatisiert durchführt - das biete ich nun schon zum 3. Mal in genau dieser Form hier an, wenn hilfreich dann bitte um Infos wie und in welcher Form die Sache ablaufen soll. Der Aufruf zu helfen kam ja schon mehrmals hier im Thread an mich gerichtet, wie man es tatsächlich machen soll und kann wurde aber nicht verraten, obwohl es sehr wohl bekannt ist

Quote from gda

So funktioniert channelpedia aber nicht, Da musst du schon regelmäßig selbst uploaden.

Und du kannst die Datei nicht uploaden?
Schließlich bist du es, der offenbar Wert darauf legt dass so eine Datei zur Verfügung gestellt wird. Wenn man dazu aber auch ein spezielles Vorgehen braucht, dann sollte man auch damit rausrücken ...
Mehr kann ich ansonsten nicht machen, als eurem Wunsch nach der neuen channels.conf entgegen zu kommen.

Mein Angebot von oben (1 Absatz unter der channels.conf zur Ansicht) steht aber nach wie vor.
Von mir aus erstelle ich regelmäßig eine channels.conf und lade sie wo auch immer hin hoch (muss nicht per SMTP/Mail sein) - natürlich automatisiert, also wirklich in regelmäßigen Abständen.

Der Qualität der Channelpedia-Liste würde ein (einmaliges) Update aus heutiger Sicht jedenfalls nicht schaden, was zB dort noch nicht gelistete Sender betrifft.

Bezogen auf Channelpedia geht es ja mehr um solche Einträge:

Dieser Sender fehlt völlig:

TELE 5 HD Austria;BetaDigital:12574:hC23M5O35S1:S19.2E:22000:511:0=deu;515:33:9c4,98c,648:5421:1:1109:0

Dieser hier ist völlig veraltet gelistet, ist nicht mehr aktuell (hier gepostet der richtige, per heute gültige Eintrag):

RTL HD Austria;CBC:11082:hC56M2O0S0:S19.2E:22000:100:0=deu;110:120:648,9c4,98c:11911:0:0:0

gda: Ich kann die Kanalliste gerne zur Verfügung stellen:

Direkt-Download: http://pastebin.com/download.php?i=SP7b69jP

Erstellt wurde sie wie folgt:

w_scan -o 7 -O 0 -f s -s S19E2

Inhalt: Astra 19,2° Ost, Radio- und TV-Kanäle, ohne "Other Services" (Datendienste)
Erstellungsdatum: 23.12.12

In der Liste sind natürlich hunderte von Sendern. Um fehlende Einträge oder zwischenzeitliche Anpassungen tatsächlich nach Channelpedia einzupflegen würde ich das jedenfalls mit irgend einem Automatismus machen. Trägt man die hier weiter oben genannten Sender manuell in das Verzeichnis nach, ist das zwar sicher sehr schön, die Channelpedia wird damit aber vermutlich auch wieder nicht die gesamte Wahrheit an verfügbaren Kanälen abbilden.

Ich habe keinen Kontakt beim Channelpedia-Projekt - da aktuelle Senderlisten dort aber scheinbar zumindest teilweise ein Problem sind, kann ich meinetwegen gerne regelmäßig eine vollständige channels.conf zur Verfügung stellen (monatlich, wöchentlich?), zB mittels automatisiertem w_scan-Aufruf und Versand des Ergebnisses per automatischem Mail ...

ako673de: Ohne deine channels.conf-Dateien jetzt genauer angesehen zu haben fällt mir auf, dass dein w_scan-Aufruf den Parameter -cDE enthält --> das ist eine Einstellung die man nur bei Kabel-Empfang benötigt, nicht aber bei Satelliten-Transpondern wie du sie hier ja vorliegen hast. Vielleicht ist das ja eine Ursache für das seltsame Verhalten deiner channels.conf?

--edit--
Ich habe nun deine hochgeladene channels.conf vom 31.12.2012 mit der von mir mittels w_scan erstellten Datei auszugsweise verglichen, und zwar den Eintrag für EUROSPORT CZ

1. Zeile: dein Eintrag aus der Datei vom 31.12.2012
2. Zeile: mein Eintrag, von w_scan erstellt, vom 23.12.2012

EUROSPORT CZ;CANALDIGITAAL:12343:HC34M2S0:S19.2E:27500:517+8190=2:114=cze@4,113=eng@4,115=hun@4:36:624,D96:2026:53:1097:0
EUROSPORT CZ;CANALDIGITAAL:12343:hC34M2O0S0:S19.2E:27500:517+8190:114,113=cze,115=eng:36:624,d96:2026:53:1097:0

Hallo!

Ich hatte das Problem vor ein paar Monaten auch:
Gewisse Kanäle funktionierten zwar mit den Einträgen aus Channelpedia, in der eigenen channels.conf wurden sie aber nach einiger Zeit kaputt geupdated.

Habe ich einen kaputt gegangenen Kanal aus der channels.conf mit dem Eintrag aus Channelpedia verglichen, so waren hier Unterschiede festzustellen - ich denke auch mit Groß- und Kleinbuchstaben bei der Polarisation.

Letztendlich gelöst wurde das aber durch diverse Updates - mittlerweise passt wieder alles einwandfrei.

Ich an deiner Stelle würde auf deinem yaVDR-Rechner mal ausführen:

sudo apt-get update
sudo apt-get dist-upgrade

Und zu deinem anderen Problem mit den noch immer nicht funktionierenden Kanälen:

Erst diese Woche konnte ich beobachten, dass vor allem exotische Kanäle nicht immer richtig in den Channelpedia-Listen eingetragen sind - die dortigen Einträge sind einfach falsch, nicht aktuell, und funktionieren demnach auch nicht.

Dieses Problem konnte ich aber so lösen, indem ich mir mit w_scan eine eigene vollständige channels.conf erzeugt habe. Daraus habe ich die nicht funktionierenden Kanäle dann in die channels.conf meiner VDR-Installation übernommen, was seither problemlos funktioniert.

Hallo!

Ich verwende auf meiner lokalen yaVDR-Installation das streamdev-client-Plugin in Kombination mit dem remotetimers-Plugin.

Der Rechner selbst ist ein reiner Client und hat keine TV-Karte verbaut (Programme werden zwingend über das streamdev-Plugin empfangen). Ebenso sollen Aufnahmen ausschließlich am Server aufgenommen werden.

Dazu habe ich das remotetimers-Plugin installiert, das so weit auch hervorragend funktioniert.

Einzig die Funktion Live-Pause (Druck der Pause-Taste während ein TV-Sender völlig normal läuft) funktioniert nicht:

Für ein paar Sekunden wird die Meldung "Pausing live video..." angezeigt, danach aber stoppt das Video nur kurz und der Sender wird in Folge wieder völlig normal wiedergegeben.
Im Hintergrund wird dabei die Aufnahme am Server - wie eben konfiguriert - gestartet und der Server beginnt mit der Aufzeichnung.

Was nicht klappt, das ist die Pausierung des Videos am Client.

Log Client bei Druck der Pause-Taste:

Dec 31 00:17:26 htpc vdr: [2436] Text2Skin: message display update thread started (pid=2380, tid=2436)
Dec 31 00:17:27 htpc vdr: [2380] SvdrpService: connected to 192.168.1.205:2001
Dec 31 00:17:27 htpc vdr: [2399] cStreamdevFilter::PutSection socket overflow, Pid   18 Tid  64
Dec 31 00:17:31  vdr: last message repeated 91 times
Dec 31 00:17:31 htpc vdr: [2380] timer 1 (6 0017-0317 '@DELUXE MUSIC') start
Dec 31 00:17:31 htpc vdr: [2380] replay /var/lib/video.00/remote/@DELUXE_MUSIC/2012-12-31.00.17.6-0.rec
Dec 31 00:17:31 htpc vdr: [2380] playing '/var/lib/video.00/remote/@DELUXE_MUSIC/2012-12-31.00.17.6-0.rec/00001.ts'
Dec 31 00:17:41 htpc vdr: [2380] [softhddev]SetPlayMode: 0
Dec 31 00:17:41 htpc vdr: [2380] [softhddev]SetVideoDisplayFormat: 1
Dec 31 00:17:41 htpc vdr: [2380] [softhddev]SetPlayMode: 1
Dec 31 00:17:41 htpc vdr: [2437] dvbplayer thread started (pid=2380, tid=2437)
Dec 31 00:17:41 htpc vdr: [2436] Text2Skin: message display update thread ended (pid=2380, tid=2436)
Dec 31 00:17:41 htpc vdr: [2438] non blocking file reader thread started (pid=2380, tid=2438)
Dec 31 00:17:41 htpc vdr: [2438] non blocking file reader thread ended (pid=2380, tid=2438)
Dec 31 00:17:41 htpc vdr: [2437] dvbplayer thread ended (pid=2380, tid=2437)
Dec 31 00:17:41 htpc vdr: [2380] [softhddev]SetPlayMode: 0
Dec 31 00:17:41 htpc vdr: [2380] [softhddev]SetVideoDisplayFormat: 1
Dec 31 00:17:41 htpc vdr: [2431] ERROR (device.c,1843): Bad file descriptor
Dec 31 00:17:41 htpc vdr: [2431] TS buffer on device 10 thread ended (pid=2380, tid=2431)
Dec 31 00:17:41 htpc vdr: [2430] buffer stats: 159236 (7%) used
Dec 31 00:17:41 htpc vdr: [2430] receiver on device 10 thread ended (pid=2380, tid=2430)
Dec 31 00:17:41 htpc vdr: [2380] switching to channel 6
Dec 31 00:17:41 htpc vdr: [2439] receiver on device 10 thread started (pid=2380, tid=2439)
Dec 31 00:17:41 htpc vdr: [2440] TS buffer on device 10 thread started (pid=2380, tid=2440)
Dec 31 00:17:41 htpc vdr: audio/alsa: wait underrun error? 'Broken pipe'
Dec 31 00:17:41 htpc vdr: video: slow down video, duping frame
Dec 31 00:17:41 htpc vdr: video: decoder buffer empty, duping frame (358/2124) 0 v-buf
Dec 31 00:17:41 htpc vdr: video: --:--:--.---   +0    0 240/\ms   0+5 v-buf
Dec 31 00:17:42 htpc vdr: [2380] [softhddev]SetPlayMode: 1
Dec 31 00:17:42 htpc vdr: audio/alsa: using device 'mixed-digital'
Dec 31 00:17:42 htpc vdr: audio/alsa: start delay 336ms
Dec 31 00:17:42 htpc vdr: audio/alsa: using device 'mixed-digital'
Dec 31 00:17:42 htpc vdr: audio/alsa: start delay 336ms

Gibt es hierfür eine Lösung, sodass ein Druck auf die Pause-Taste das gerade ablaufende Programm tatsächlich pausieren lässt?

Danke für den Tipp. Es ist so einfach, dass ich gar nicht daran gedacht habe

Ein Problem hatte ich aber bei meinem VDR-Server, bei dem VDR noch mittels Init-Script gestartet wird (hier ist "nur" das Paket VDR aus eurem yaVDR-Repository installiert --> mit dem Paket alleine wird scheinbar noch ein Init-Script angelegt)

Um auch hier einen sauberen Mount vor dem VDR-Start durchzuführen habe ich ein LSB-konformes Init-Script erstellt, welches lt. den Regeln VOR dem Start von VDR ausgeführt werden soll. Das möchte ich euch nicht vorenthalten, denn vielleicht kann es jemand brauchen.

Leider funktioniert es nicht unter einer Standard-Installation von Ubuntu 12.04, da dort die LSB-Abhängigkeiten der Init-Scripts scheinbar überhaupt nicht berücksichtigt werden (vermutlich wegen der dortigen Verwendung von upstart; leider bemerkt man dies erst nachdem man das Script fertig gestellt hat )

Aber wie gesagt, es würde funktionieren, und deshalb hier das Script.

/etc/init.d/vdr-mount-recordings

#! /bin/sh
### BEGIN INIT INFO
# Provides:          vdr-mount-recordings
# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog
# X-Start-Before:    vdr
# Default-Start:     2 3 4 5
# Default-Stop:      
# Short-Description: initscript for mounting the VDR recordings via cifs
# Description:       Mounts a cifs share containing the VDR recordings. The script waits for the cifs resource to become available.
### END INIT INFO




# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="initscript for mounting the VDR recordings via cifs"
NAME=vdr-mount-recordings
SCRIPTNAME=/etc/init.d/$NAME




# settings for VDR recordings dir
CIFS_SERVER=nas
CIFS_SHARE=media/recordings
CIFS_OPTIONS=credentials=/etc/fstab-credentials-recordings,uid=vdr,gid=vdr,forceuid,forcegid
MOUNTPOINT=/mnt/recordings


PING_WAIT_SECONDS=5
PING_MAX_TRIES=6




# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME


# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh


# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions


#
# Function that starts the daemon/service
#
do_start()
{
	echo "Mounting vdr recordings directory //$CIFS_SERVER/$CIFS_SHARE on $MOUNTPOINT ... "


	# 1. check if dir is already mounted
	if df | grep $CIFS_SERVER/$CIFS_SHARE | grep $MOUNTPOINT >/dev/null
	then
		echo "Cifs share //$CIFS_SERVER/$CIFS_SHARE already mounted on $MOUNTPOINT. Doing nothing!"
		return 0
	fi


	# 2. wait for cifs server to become available
	local ping_counter=0


	while ! ping -W $PING_WAIT_SECONDS -c 1 -q $CIFS_SERVER >/dev/null 2>&1
	do
		ping_counter=`expr $ping_counter + 1`


		if [ $ping_counter = "$PING_MAX_TRIES" ]
		then
			echo "CIFS server $CIFS_SERVER not available. Mounting of share $CIFS_SHARE not possible!"
			return 1
		fi
 
		sleep 1
	done


	# 3. mount cifs share
	local MOUNT_COMMAND="mount -t cifs -o $CIFS_OPTIONS //$CIFS_SERVER/$CIFS_SHARE $MOUNTPOINT"
	local return_code


	# echo "DEBUG: mount-command: $MOUNT_COMMAND"


	# wait for the samba server
	sleep 5


	$MOUNT_COMMAND


	return_code=$?


	if [ "$return_code" = "0" ]
	then
		echo "done!"
	fi

	return $return_code
}


#
# Function that stops the daemon/service
#
do_stop()
{
	return 0
}


case "$1" in
  start)
	[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
	do_start
	case "$?" in
		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
	esac
	;;
  stop)
	[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
	do_stop
	case "$?" in
		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
	esac
	;;
  status)
       echo "No status available. Call the script with paramter 'start' to mount the recordings dir"
       ;;
  restart|force-reload)
	;;
  *)
	echo "Usage: $SCRIPTNAME start" >&2
	exit 3
	;;
esac

Da die Lösung sehr angenehm ist, leider aber nicht funktioniert, habe ich mich letztendlich dazu entschieden, das Init-Script von VDR zu ändern --> unmittelbar vor dem Start von VDR rufe ich mein Mount-Script auf.

Einfügen dieser 2 Zeilen in /etc/init.d/vdr

### try to mount recording directory, if not already mounted
            /usr/local/sbin/vdr-mount-recordings

Die Funktion startvdr() im Init-Script sieht dann so aus:

startvdr()
{
    if [ "$ENABLED" != "0" ] ; then
        # only start vdr if there is no other instance running
        if start-stop-daemon --start --startas $DAEMON --test \
            --name $(basename $DAEMON) --pidfile $PIDFILE >/dev/null
        then
            getplugins
            mergecommands "commands"
            mergecommands "reccmds"
            configure_console_input


            if [ "$VFAT" == "1" ]; then
                OPTIONS="--vfat $OPTIONS"
            fi


            if [ -n "$LIRC" ]; then
                LIRC_OPT="--lirc=$LIRC"
            else
                LIRC_OPT="--lirc"
            fi


            ### try to mount recording directory, if not already mounted
            /usr/local/sbin/vdr-mount-recordings


            start-stop-daemon --start --quiet --startas $DAEMON --background \
                --name $(basename $DAEMON) --pidfile $PIDFILE --make-pidfile -- \
                -v $VIDEO_DIR -c $CFG_DIR -L $PLUGIN_DIR -r $REC_CMD \
                -s $VDRSHUTDOWN -E $EPG_FILE -u $USER -g /tmp \
                --port $SVDRP_PORT $LIRC_OPT $PLUGINS $OPTIONS $REDIRECT
        else
            echo -n " - seems to be running already"
        fi
    else
        echo -n " - aborted (to enable the daemon, edit /etc/default/vdr)"
    fi
}

Angelegt werden muss dafür die Datei /usr/local/sbin/vdr-mount-recordings

#! /bin/bash


# settings for VDR recordings dir
CIFS_SERVER=nas
CIFS_SHARE=media/recordings
CIFS_OPTIONS=credentials=/etc/fstab-credentials-recordings,uid=vdr,gid=vdr,forceuid,forcegid
MOUNTPOINT=/mnt/recordings


PING_WAIT_SECONDS=5
PING_MAX_TRIES=6




function mount_vdr_recordings_dir()
{
	echo
	echo "Mounting vdr recordings directory //$CIFS_SERVER/$CIFS_SHARE on $MOUNTPOINT ... "


	# 1. check if dir is already mounted
	if df | grep $CIFS_SERVER/$CIFS_SHARE | grep $MOUNTPOINT >/dev/null
	then
		echo "Cifs share //$CIFS_SERVER/$CIFS_SHARE already mounted on $MOUNTPOINT. Doing nothing!"
		return 0
	fi


	# 2. wait for cifs server to become available
	local ping_counter=0


	while ! ping -W $PING_WAIT_SECONDS -c 1 -q $CIFS_SERVER >/dev/null 2>&1
	do
		ping_counter=`expr $ping_counter + 1`


		if [ $ping_counter = "$PING_MAX_TRIES" ]
		then
			echo "CIFS server $CIFS_SERVER not available. Mounting of share $CIFS_SHARE not possible!"
			return 1
		fi
 
		sleep 1
	done


	# 3. mount cifs share
	local MOUNT_COMMAND="mount -t cifs -o $CIFS_OPTIONS //$CIFS_SERVER/$CIFS_SHARE $MOUNTPOINT"
	local return_code


	# echo "DEBUG: mount-command: $MOUNT_COMMAND"


	# wait for the samba server
	sleep 5


	$MOUNT_COMMAND


	return_code=$?


	if [ "$return_code" = "0" ]
	then
		echo "done!"
	fi

	return $return_code
}


mount_vdr_recordings_dir

Vielleicht nützen die Scripts bzw. Fragmente daraus ja jemandem der vor einem ähnlichen Mount-Problem steht wie ich - deshalb der Post hier.

Verbessern könnte man noch das Warten auf das Verfügbar-Werden der Netzwerkfreigabe. Derzeit wartet das Script nach einem erfolgreichen Ping auf den NAS-Server noch fixe 5 Sekunden bis der Fileserver-Prozess gestartet wurde und die Shares anbietet. Für Vorschläge wie man das besser lösen könnte bin ich natürlich gerne zu haben

Hallo!

Mein VDR verfügt nur über eine kleine Mini-SSD, weshalb der Inhalt des Aufnahmeverzeichnisss auf einer NAS liegt, die über eine ausreichend große Festplatte verfügt. Das Aufnahmeverzeichnis wird also als Sama/Cifs-Share am VDR-Rechner gemountet.

Leider ist es nun aber so, dass mit dem Start des VDR-Rechners der NAS-Rechner gleichzeitig mit gestartet wird, wobei der VDR-Rechner schneller startet.
Ist der VDR so weit, dass der VDR-Prozess startet, ist das Cifs-Share also noch nicht verfügbar --> VDR crasht mit der Meldung, dass auf das Aufnahmeverzeichnis nicht verfügbar ist.

Als mögliche Lösung habe ich es schon mit autofs probiert - also einen Automatismus, der /var/lib/video.00 erst unmittelbar beim Zugriff darauf einhängt.
Leider funktioniert aber auch das nicht, da der VDR-Rechner eben viel schneller als der NAS-Rechner startet. Sobald der VDR-Prozess startet und auf das Aufnahmeverzeichnis zugreifen möchte, versucht autofs zwar den Mount-Befehl für das Cifs-Share aufzuführen, dieser wird aber mit einem Fehler abgebrochen.

--> es ist kein Zugriff auf das Aufnahmeverzeichnis möglich und VDR wird sofort wieder beendet.

Gibt es hierfür eine Lösung?
Beim Start des Rechners soll VDR automatisch gestartet werden, ebenso soll aber die Cifs-Freigabe automatisch gemountet werden ...

Auch hier konnte ich inzwischen selbst eine Lösung finden: Das Problem war eine zu große channels.conf am VDR-Server.

Dazu ein paar Sätze zu meiner ursprünglichen (die Probleme hervorrufenden) Konfiguration:

Der Einfachheit halber habe ich am VDR-Server eine komplette und vollständige channels.conf verwendet (Donwload aus Channelpedia).
Aus dieser so dann am Server vorhandenen Datei habe ich dann einen kleinen Auszug bestehend aus den benötigten Sendern auf die Clients hin übernommen.

Leider führte genau das zu meinen Problemen:
Besonders dann, wenn beide Clients zugleich aktiv waren, konnte manchmal nicht zu neuen Transpondern gewechselt werden --> das Bild blieb einfach schwarz, ohne Fehlermeldungen in den VDR-Logs (nach deren Infos sehr wohl ein Bild wiedergegeben wird). Trat das Problem auf, wurden keine Kanäle innerhalb des selben Transponders wiedergegeben, auf den soeben gewechselt wurde. Als Abhilfe musste auf einen Kanal eines anderen Transponders gewechselt werden. In einem nächsten Schritt konnte dann aber sofort wieder auf den vorherigen Transponder zurück gewechselt werden, wo der gewählte Kanal dann in der Regel auch sofort wiedergegeben wurde.

War nur ein Client aktiv, funktionierte das Wechseln von Kanälen seltsamerweise problemlos.

Inzwischen habe ich in der channels.conf der VDR-Servers nur mehr jene Kanäle gelistet, die auf den Clients auch tatsächlich verwendet werden - die hunderten nicht verwendeten Kanäle habe ich entfernt.

Damit funktioniert das Wechseln zwischen den Kanälen nun (vorerst) problemlos

Hallo!

Ich konnte das Problem inzwischen lösen, die Info darüber möchte ich dem Forum natürlich nicht vorenthalten:

Die Tonausgabe des SoftHDDevice-Plugins erfolgte lt. Logs über das ALSA-Gerät "default" (im yaVDR-Webadmin ist gewählt, den Ton nur auf den Front-Lautsprechern auszugeben).

Genau das führte zum auftretenden Problem: Der Ton konnte so scheinbar nicht ganz synchron mit dem Bild ablaufen, über die Zeit füllten sich die Puffer des Streamdev-Plugins (das dortige Material wurde langsamer abgeholt als angeliefert), und schlussendlich kam es zum Pufferüberlauf und zum Crash.

Abhilfe schaffte, die Audio-Ausgabe nicht nach "default" zu leiten, sondern direkt zum Hardware-Device der Soundkarte: hw:0,0

aplay -l gibt mir die verfügbaren Geräte aus:

user@htpc-eg:~$ aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: Intel [HDA Intel], Gerät 0: ALC892 Analog [ALC892 Analog]
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0
Karte 0: Intel [HDA Intel], Gerät 1: ALC892 Digital [ALC892 Digital]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 7: HDMI 1 [HDMI 1]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 8: HDMI 2 [HDMI 2]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

Der analoge Ausgang den ich benutze ist gleich der 1. Eintrag (Karte 0, Gerät 0) was ergibt: hw:0,0

Um das SoftHDDeve-Plugin anzuweisen, dieses Gerät (anstatt "default") für die Tonausgabe zu nutzen, muss die Datei /etc/vdr/plugins/plugin.softhddevice.conf angepasst werden.

Dafür muss am Ende dieser Datei die folgende Zeile hinzugefügt werden:

-a hw:0,0

Normalerweise sollte die Datei zwar so nicht geändert werden (dafür gibt es yaVDR-Config-Templates), auf die Schnelle funktioniert es aber.

Meine Probleme mit Bildhängern und Crashes sind damit Geschichte

Das ist wirklich verflixt: Gerade eben habe ich mir einen Account im yaVDR-Bug-Tracker angelegt und die Freischaltung dafür erhalten, und plötzlich funktioniert die Lifeguard bei mir wie vorgesehen

Grundsätzlich ist das nun ja sehr schön, mit dem Reproduzieren des Fehlers wird es nun aber nichts mehr ...

Zur Lösung meines Problems habe ich die Web-Admin-Seite aufgerufen und dort die angezeigten Lifeguard-Einstellungen einfach nochmal gespeichert, ohne sie auch nur irgendwie zu ändern.

Das Resultat: Die Config-Datei unter /etc/... hat nun den richtigen Inhalt und der Lifeguard bzw. ein Shutdown verhält sich so wie eingestellt