VDR server not given, searching ...

  • Hallo,


    ich habe folgendes Problem nach dem Start über vdr-sxfe:



    Meine letzte Erinnerung ist, dass ich über das vdr-plugin-live timer programmiert habe.
    Zuvor ist der VDR eigentlich anstandslos gelaufen, bis auf die Meldung: Kanal nicht verfügbar.


    War aber nicht weiter beunruhigend und lief nach einem erneuten starten auch wieder.


    Habe schon im Forum und Netz nach meinem Problem gesucht. Leider keine Lösung gefunden bei denen die das gleiche Problem hatten.


    Was kann ich tun damit mein VDR über vdr-sxfe wieder läuft ?
    Der VDR ansich scheint zu laufen.

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

    Einmal editiert, zuletzt von VDRFirtie ()

  • Hallo,


    nun habe ich das Netz durchforstet und wollte mich erneut an das Werk machen ... starte den VDR ... und siehe da: Alles funktioniert wie gehabt !


    Was soll ich davon halten ?
    Bahnt sich hier etwas an ?


    Das Einzige was ich zwischenzeitlich gemacht habe: vdr-plugin-live deinstalliert und wieder installiert.


    Aber das kann es eigentlich nicht gewesen sein.


    Nun weiß ich auch nicht weiter.

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Hallo,


    dass Einizge was noch abweichend gewesen ist: Ich hatte über das vdr-plugin-live Timer programmiert und über die Fernbedienung in dem live plugin den VDR ausgeschaltet.
    Das hatte ein wenig gehackt und musste ich 2x ausführen.
    Auch konnte ich mich auf der Weboberfläche des plugins nicht mehr abmelden, bevor der VDR heruntergefahren ist. Aber das hatte bisher (soweit ich mich erinnern kann) auch keine Probleme bereitet.


    Was auch merkwürdig gewesen ist: Nach einer Aufnahme (über Timer) ist der VDR nicht ausgegangen, was dieser für normal ja macht. Habe dann manuell beendet.


    Ansonsten fällt mir nichts ein was anders gewesen wäre.


    Über das live plugin programmiere ich öfters und dabei gibt es keine Probleme.


    Mich würde schon interessieren woran das gehangen hat und ob da etwas im Busch ist.
    Auch die Nr. das kein Signal vorhanden ist, bereitet mir Sorgen, da dies für gewöhnlich nicht vorkommt.

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Keiner eine Idee ?


    Bisher verhält sich der VDR unauffällig und macht keinen Ärger, aber der kann ja wieder kommen :)

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Hallo,


    ich habe den selben Fehler.
    Seit dem 11.3. habe ich auch keine neuen Aufnahmen mehr. Bzw. ich habe zwar schon Aufnahmen nach diesem Datum, aber die Größe der Dateien ist dann 0.


    Wo kann ich denn nachschauen, um das Problem einzugrenzen?


    Edit:
    In /var/log/messages steht:
    Mar 14 19:08:13 Atlas runvdr: restarting VDR
    Mar 14 19:08:30 Atlas kernel: [193052.724030] tda1004x: setting up plls for 48MHz sampling clock
    Mar 14 19:08:32 Atlas kernel: [193055.004029] tda1004x: found firmware revision 0 -- invalid
    Mar 14 19:08:32 Atlas kernel: [193055.004034] tda1004x: trying to boot from eeprom
    Mar 14 19:08:35 Atlas kernel: [193057.380037] tda1004x: found firmware revision 0 -- invalid
    Mar 14 19:08:35 Atlas kernel: [193057.380042] tda1004x: waiting for firmware upload...
    Mar 14 19:08:35 Atlas kernel: [193057.380052] saa7134 0000:03:02.0: firmware: requesting dvb-fe-tda10046.fw
    Mar 14 19:08:49 Atlas kernel: [193071.924524] tda1004x: found firmware revision 0 -- invalid
    Mar 14 19:08:49 Atlas kernel: [193071.924529] tda1004x: firmware upload failed
    Mar 14 19:08:49 Atlas vdr: [25553] [xine..put] Listening on port 37890
    Mar 14 19:08:49 Atlas vdr: [25553] [xine..put] Listening for UDP broadcasts on port 37890
    Mar 14 19:08:50 Atlas recordingaction: executing /usr/share/vdr/recording-hooks/R90.custom before recording /var/lib/video.00/nano/Die_Welt_von_morgen/2011-03-14.18.29.50.10.rec as shell script
    Mar 14 19:09:25 Atlas recordingaction: executing /usr/share/vdr/recording-hooks/R90.custom after recording /var/lib/video.00/nano/Die_Welt_von_morgen/2011-03-14.18.29.50.10.rec as shell script


    Hmmm, warum wird denn die firmware plötzlich nicht mehr gefunden???
    Die Datei /lib/firmware/dvb-fe-tda10046.fw existiert


    Der Rechner fungiert als Server. Außer den üblichen Updates passiert da nichts weiter.


    Danke für jeden Tipp


    mfg, Paul

  • Hallo,


    bei mir ist alles wieder OK, aber ein ungutes Gefühl bleibt.


    Ist schon merkwürdig.
    Vielleicht melden sich noch mehr Leute die das gleiche Problem haben.

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Hallo,


    gestern Abend hatte ich das gleiche Problem wieder.


    Die Situation ist folgende gewesen:


    TV aufgenommen und zeit versetzt geschaut.
    Werbung gespult und an das Ende vom laufenden Stream gekommen.
    VDR ist ausgestiegen.
    Timer ist programmiert gewesen und der weilen gestartet.
    VDR ist nicht mehr zu erreichen gewesen (auch über Admin tool nicht).
    Obwohl ein starten des VDR`s keine Fehlermeldung gezeigt hat.


    Timer ist abgelaufen und VDR ist wieder zu erreichen gewesen sowohl die Ausgabe über xineliboutput hat wieder funktioniert.


    Logdateien habe ich leider keine.


    Könnt Ihr hier einen Fehler erkennen ?

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Hallo,


    mittlerweile kann ich den Fehler reproduzieren.


    Zuerst hatte ich die Vermutung das ein Zusammenhang zwischen Sender und
    Aufnahmezeit besteht, aber ich habe bei dem letzten Vorfall genau hin
    geschaut.




    Ich hatte zwei Timer gesetzt:




    • 07.04.11, RTL, Bones


    • 07.04.11, RTL, CSI


    Dabei entsteht um 22:08 Uhr eine Überlappung (die bisher keinerlei
    Probleme bereitet hat), da ich dem VDR eine Vorlaufzeit für die Timer
    gebe. Wobei ich über EPG programmiere.


    Exakt um 22:08 Uhr wird der VDR beendet (oder stürzt ab ???) und lässt
    sich zu keiner weiteren Mitarbeit bewegen (weder ein STOP --> START,
    noch RESTART).




    Erst wenn der zweite Timer abgelaufen ist (CSI), kann ich den VDR
    wieder ganz normal benutzen, sprich ich habe keine Fehlermeldung mehr
    "VDR server not given, searching ..." und ich kann via xine-Frontend
    wieder TV schaun, ... alles ist gut.




    Was ich nicht verstehe: Diese Konstellation, dass ich zwei
    Sendungen hintereinander via EPG programmiere und aufnehme, habe ich
    öfter. Bisher ist aber nur in dieser oben beschriebenen Konstelation
    (Bones/CSI auf RTL am Do) der Fehler aufgetreten.




    Bisher ist das mit den beiden Sendungen auch kein Problem gewesen. Erst
    vor ein paar Wochen (wo ich Dir das erste Mal deswegen geschrieben
    habe) ging das los und ich habe keine Ahnung, was anders sein soll !


    Ich kann sagen, dass ich nichts an dem VDR Rechner verändert habe.




    Wie kann ich die Timer via Konsole (ohne VDR zugriff --> Texdatei
    ???) löschen ?


    Scheinbar gibt es ja einen Zusammenhang mit den Timern, da ja nach
    Ablauf des zweiten wieder alles in "Butter" ist.


    Anbei die Log-Dateien mit den Daten vom 31.03. bis zum 08.04.11.
    Somit sind zwei Sendetermine abgedeckt.

  • Ich habe da noch eine Idee:


    Gestern Abend, nachdem ich nochmals in der Log-Datei gestöbert habe, ist mir eine Idee gekommen:


    Wie beschrieben passiert ES nur in der Konstallation Bones/CSI. Bei keiner anderen und vorher hatte das auch funktioniert.
    Wenn der Timer CSI gestartet wird, dann bricht der VDR ab und zeigt den beschriebenen Fehler.


    Was ist passiert ?
    Ich hatte wegen einem ACPI Problem das Board ausgetauscht und in dem Zuge auch die Festplatte ?
    Die die aufgezeichneten Sendungen habe ich von der alten HDD auf die neue kopiert. Darunter waren auch CSI Folgen.
    Auf Grund der fehlenden Schreibrechte für die jetzige VDR Installation, habe ich die angeschauten CSI Folgen via root von der Platte gelöscht.


    Ich erinnere mich aber, dass wenn von einer Serie mehrere Folgen aufgezeichnet werden, der VDR eine Unterstruktur anlegt und darin die Folgen abgelegt werden.
    Nun habe ich diese Unterstruktur von Hand gelöscht.


    Meine These (durch die Log bin ich darauf gekommen): Der CSI Timer wird gestartet und möchte in die Unterstruktur die Aufnahme ablegen. Diese gibt es aber ja nun nicht mehr (oder ist verändert/beschädigt, ...) und der VDR kann den Stream nicht ablegen.
    Dadurch nimmt der Fehler seinen Lauf !


    Warum nun erst nach Ablauf des programmierten CSI Timer das Problem behoben ist und warum das Xine-Frontend keinen Kontakt mehr bekommt, ... vielleicht hat einer von Euch eine Idee dazu ?


    Wenn dem so sein sollte, wie kann ich das wieder gerade biegen mit der Ablage für die Sendung und wie könnte ich das Timer Problem beheben, falls ich nochmals eine solche Situation habe ?


    Hier mal die derzeitige Struktur in /var/lib/video.00 für CSI:


    Code
    CSI#3A_Den_Tätern_auf_der_Spur


    Code
    2010-12-16.22.09.50.99.rec


    Darunter liegen:

    Code
    index.vdr


    Code
    oo1.vdr


    Code
    info.vdr

    Diese hänge ich mal mit an.


    Bedeutet "CSI#3A_Den ..." das dort drei Folgen beinhaltet sein sollten ?
    Ich meine mich erinnern zu können, dass ich drei Folgen aus dem Ordner gelöscht habe.


    Reicht das aus, einfach den vollständigen Ordner zu löschen und den VDR bei der nächsten Aufnahme selber wieder alles neu anlegen zu lassen (sollte meine Theorie stimmen), oder muss ich nur einen Eintrag verändern, ...?

  • hoi,


    kann natürlich sein wenns ne serienaufnahme ist und er den ordner nicht findet dass er dann aussteigt...



    verschiebe doch testweise man die beiden ordner auf ne andere platte und lasse die aufnahmen in einem leeren video-verzeichnis laufen...wenn er dann nicht aussteigt kopierst den inhalt der serienordners (also die ordner mit .rec) wieder in den ordner auf die video.00 und gut ist....



    vorsichtshalber vorher nochmal die berechtigungen prüfen...besitzer vdr gruppe vdr und für den besitzer rwx...

    Client 1 Hardware : MSI Z87-G43, I5-4570, 4 GB Ram (oversized aber war über :) ),Zotac NVidia GT630 (25 Watt),Thermaltake DH202 mit iMon-LCD ( 0038 ) und vdr-plugin-imon
    Software : yaVDR 0.6,sofhhddevice @ 1920x1080@50Hz
    Server Hardware : MSI Z87-G43, I7-4790, 16 GB RAM, 5x3 TB WD Red, Digibit-R1 (2 Devices)
    Software : Ubuntu 16.04 LTS mit yavdr-Paketen,virtualbox,diverse VM's


    Yoda: Dunkel die andere Seite ist...sehr dunkel!
    Obi-Wan: Mecker nicht, sondern iss endlich dein Toast ...

  • Hallo,


    nach und nach bestätigen sich meine Annahmen.


    Für den CSI Ordner hat der jetzige VDR keine Zugriffsrechte.


    Das ist ein Relikt aus der alten Installation.


    Hier der Log-Auszug:


    Code
    ERROR: 
    /var/lib/video.00/CSI#3A_Den_Tätern_auf_der_Spur/2011-04-07.22.09.50.99.rec: 
    Keine Berechtigung


    Des weiteren scheint noch ein Problem mit dem Skin vorzuliegen:


    Code
    segfault at 28 ip 00007fdaa656d92c sp 00007fffe7994d70 error 4 in 
    libvdr-skinelchi.so.1.6.0[7fdaa6539000+40000]


    Ich werde für die nächste Aufnahme (Do. wieder) die Schreibrechte für den Ordner ändern.


    Das Skin warte ich mal ab, da ich bisher keine Probleme damit hatte.


    Gut das es Log-Dateien gibt:-)


    Mal schau ob es das dann gewesen ist.


    Was mich aber noch auf jeden Fall interessieren würde: Wie kann ich das Problem mit dem Zugriff auf das Xine-Frontend lösen, sollte ich nochmals solch ein Problem haben ?


    Dafür noch eine Lösung wäre super.
    Donnerstag weiß ich mehr.

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

  • Hallo,


    ich habe den Fehler gefunden !


    Die fehlenden Schreibrechte sind das Problem gewesen.


    Nun läuft alles bestens (für dieses Problem).


    Interessieren würde mich aber wie ich aus einer solchen Nummer heraus kommen kann, wenn so etwas (oder ähnliches) wieder auftreten sollte ?


    Ein anderes Problem was ich noch habe:


    Aufnahmen die ich bei den Sendern ZDF und Neo gemacht habe, zeigen bei der Wiedergabe Artefakt ähnliche Erscheinungen, die bis zum Absturz des VDR`s führen.


    Die Bildstörungen fangen leicht an und werden immer stärrker --> Absturz !
    Bei diesem Fehler kann ich für gewöhnlich den VDR durch STOP --> START wieder zur Zusammenarbeit bewegen.


    Vermeiden kann ich den Absturz in dem ich bei leichter Bildstörung den Abschnitt vorspule. Dann ist auch gut.
    Ist natürlich voll nervig !


    Das passiert nur bei diesen zwei Sendern (eigentlich ja einer).


    Nun ist meine Überlegung folgende gewesen: Die channel.conf habe ich mir seiner Zeit aus bestehenden für Schleswig-Holstein zusammen gebaut. Das hat auch super funktioniert, bis auf einmal die Probleme mit ZDF/Neo angefangen haben (glaube das ging auch nach dem Motherboard wechsel los ???).


    Da das Erzeugen und Bearbeiten der channel.conf scheinbar ein wenig sensibel zu sein scheint, ist vielleicht auch da der Wurm drin.


    Deswegen würde ich nun den Weg über

    Zitat

    w_scan -c DE >> channels.conf

    gehen und so eine neue erzeugen lassen (wenn ich alles richtig verstanden habe). Meine jetzige bringe ich als Backup in Sicherheit.


    Bisher habe ich die channel.conf mit einem normalen Texteditor bearbeitet. Habe gesehen, dass es auch channel.conf Editoren gibt. Ist das erforderlich ?


    Eine Log habe ich dazu leider nicht.


    Kennt einer diesen Fehler ?

    Intel NUC BOXNUC6CAYH (2x 4GB Kingston RAM, 120GB SSD) mit MLD 5.4, DD OctopusNET S2, OneForAll URC-7960 FB, OMV NAS

    Einmal editiert, zuletzt von VDRFirtie ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!