Beiträge von Fourty2

    HelmutB

    Die Fehler in den Aufnahmen waren der Grund, warum ich das Markad mal testhalber von während auf nach der Aufnahme umgestellt habe. Hatte zunächst die Last in Verdacht, aber ...


    kfb77

    ... nichtsdestotrotz ist da in Bug in der Taskverwaltung der sich finden wird:

    Aktuelles Log von Nachtaufnahmen / 2 Stück / VDR noch an, obwohl idle. Diesmal alles dabei, von PID-Update, über SignalMonitoring bis Neustart. :-}


    @Webserver:

    Zeige die max. 10k Zeichen doch mal in der Vorschau an, Danke...


    Stefan

    a) "Verstehe ich nicht, was meinst du damit ?"


    Die erste Aufnahme (auch nach (Timer-)Neustart des VDR-Systems), bleibt im Zustand "Pause", bis das Ende der zweiten Aufnahme das Resume auslöst, scheint mir.


    Vermutung: Indexfehler (ab 0 und ab 1). Habe aber dazu im Code so direkt nichts gefunden (kurz geguckt).


    b) "Edit: Und du hast die Spielregeln geändert, jetzt ist ein richtiger Crash drin."


    Weiblicher VDR... :)


    c)

    Ja, es lief eine Aufnahme, dann hätte der VDR abschalten sollen, was er nicht tat, sondern erst nach der zweiten Aufnahme nachmittags.


    Stefan

    Beim Markad-Resume scheint die Prüfung die Zahl der noch wartenden Prozesse falsch (-1) zu berechnen. Sobald die zweite Aufnahme (Stunden später gestartet) beendet wird, werden beide Prozesse wiederaufgenommen, bearbeitet und beendet:


    Ursächliches Problem ist offenbar eine Unterbrechnung der Aufnahme "durch Signalverlust".


    Das macht ein Patch von HelmutB (vdr-2.4.7-SignalMonitoring2.patch). Ob es einen realen Signalverlust gab (Sat-Schüssel), die DVB-S Karte bisweilen spinnt, oder der Patch zu nervös ist, läßt sich nicht sagen.


    Es unterbricht die Aufnahme aber kurz, dann geht es weiter. Danach kommt markad durcheinander (Aufnahme doppelt). Eine spätere Aufnahme (es lief morgens nichts parallel) wurde sofort korrekt bearbeitet ...


    Setup:


    Grep auf Markad (und das Syslog zur Aufnahme morgens anbei).


    Grüße,

    Stefan

    Doch es kommt, nur halt ... viel später als gedacht.

    Mir scheint, er hat erst mit/nach der nächsten Aufnahme weiter gemacht:


    Es könnte sein, das das Suspend-Video nach 3h stört, gucke die Logs gleich mal durch...


    Stefan

    Kurze Frage:

    Funktioniert "nach Ende der Aufnahme" noch nicht?


    Code
    Tue Jun 22 08:00:01 [22088] INFO:  starting markad v3.0.5 (c23de76) (64bit)
    Tue Jun 22 08:00:01 [22088] INFO:  using libavcodec.so.58.91.100 with -1 threads
    Tue Jun 22 08:00:01 [22088] INFO:  on /srv/vdr/video/local/[...]/2021-06-22.08.00.109-0.rec
    Tue Jun 22 08:00:02 [22088] INFO:  paused by signal
    Tue Jun 22 09:05:23 [22088] INFO:  continued by signal
    Tue Jun 22 09:05:23 [22088] INFO:  broadcast aspect ratio 16:9 (from vdr info)
    Tue Jun 22 09:05:23 [22088] INFO:  no logo found in logo directory, trying to find logo in recording directory
    Tue Jun 22 09:05:23 [22088] INFO:  no logo found in recording directory, trying to extract logo from recording
    Tue Jun 22 09:05:25 [22088] INFO:  paused by signal


    Aufnahme ist >1h vorbei, andere Aufnahmen laufen derzeit nicht, markad wartet - worauf auch immer...


    Stefan

    Ich verstehe es so, dass die Aufnahme im OSD des abspielenden vdr ja schon zu sehen ist - sonst könnte man sie nicht abspielen.

    Da ließe sich doch ein Command zum Kopieren einbauen, oder?

    Oder kann der vdr das von sich aus schon? Oder extrecmenu?

    Ja, genau.


    Der Abspiel-VDR kann über LAN und Router mit VPN-Hardware-Netzkopplung auf den Fileserver zugreifen. Das mountet sich bei Zugriff per AutoFS alles selbst.


    Problem war: < 5s Film, Pause, Sync -1s, nächstes Stück, REPEAT.


    Hab die Pufferung jetzt geändert. Gerade die 12 MBit/s Aufnahme ging stressfrei durch.

    Sobald ich die Änderungen etwas aufgeräumt und fein getuned habe, hänge ich den Patch an. (War im aber Prinzip alles schon da ...)


    Stefan

    Kannst du die Aufnahme nicht einfach kopieren und dann lokal abspielen? Oder gibt es am Ziel nicht genug Platz?

    Die Video-Over-HDD Verbindung ist bezüglich der Auswahl etwas eingeschränkt, aber existiert, klar.

    Außerdem muß man immer vorher wissen, was man wohl schauen möchte.


    Einzelne FIlme kann ich natürlich einfach übers Netz kopieren. Aber das geht nicht per FB, sondern braucht SSH...


    War auch nur die Frage, ob schon jemand was hat, aber dann muß ich halt selber ran. :)


    Stefan

    FADVISE habe ich schon durch. Inclusive Änderung der readahead Parameter und Funktion.

    Das Grundproblem bleibt.


    Um das zum Funktionieren zu bekommen, müßte der VDR erst einen Abspielpuffer füllen und diesen gefüllt halten (so gut wie möglich).

    So ähnlich wie es Linux beim Kopieren über das Netz macht: lokal jeweils lesen bis Puffer-Speicher voll und wegschreiben, so schnell es das Netz halt zuläßt.


    Wir basteln mal weiter,

    Stefan

    Ein Abschlußwiderstand ist aber vermutlich kein Verschleißteil? Kann der im Lauf der Zeit Schaden nehmen? Oder geht es darum zu prüfen, ob überhaupt einer da ist?

    Klar können auch passive Bauteile Schaden nehmen (Überspannung, Produktionsfehler, ...).


    Wenn er (durch Defekt) fehlt oder einen niederohmigeren Schluß verursacht, könnte dies auch durch Reflexionen oder Dämpfung das Signal ausreichend stören.


    Die beiden F-Stecker nebst Muffe oben sollten nicht großartig stören. Hatte mal einen Experten, der die Sat-Zuleitung per Lüsterklemme verlängert hat. Ging auch noch ohne sichtbare Probleme.


    Würde an der Trennstelle mal die Leitung trennen und extern zum VDR verlängern, wenn besser, liegt es am Stück dahinter, sonst davor ... :)


    Stefan

    Das streamdev Plugin könnte/kann doch den Stream herunterrechnen lassen: http://www.vdr-wiki.de/wiki/index.php/Streamdev-plugin

    Vielleicht geht das auch mit Aufnahmen?

    Soweit mir bekannt, macht Streamdev nur LiveTV (so ist das hier als VDR-VDR Streaming im Einsatz). Das läuft auch ohne Rechnerei durch WAN. Die Aufnahmen kommen regulär per CIFS/NFS ... was im LAN ja kein Problem darstellt. Im WAN stört das Handshake der Netzwerkprotokolle das ruckelarme Abspielen.


    Der VDR realisiert da offenbar sein eigenes 128kB ReadAhead (Parameter scheinen im wesentlichen aus einem Patch von um 2006 zu stammen) - gefunden in dvbplayer.c / tools.c.


    Mal sehen ... :)


    Stefan

    Hallo zusammen,


    ich versuche gerade, das VDR-Aufnahmen-Archiv per WAN (über VPN) verfügbar zu machen.


    Die getestete Verbindung ist schnell genug, um die Testaufnahme (~10 MBit/s) in einem Viertel der Spielzeit per CIFS auf den Abspiel-VDR zu kopieren.

    Leider mag der VDR die Latenz nicht und spielt das nur mit heftigen Aussetzern (auch bei 2 MBit/s Aufnahme) ab - so unguckbar.

    Jemand eine Idee (oder schon einen Patch), wo man dem VDR beim nicht rechtzeitigen Eintreffen der Abspielpackete zu ein wenig ReadAhead auffordern könnte?


    Stefan

    Ich hatte das immer auf den Undelete-Patch geschoben, aber offenbar ... Kernfunktion.


    Ist das dann auch der Grund, warum bei einer einmal vollen Platte, auch wenn man (unvollständige) Aufnahmen gelöscht hat, die *.del Verzeichnisse nicht mehr abgeräumt und freigegeben werden?

    (Muß die dann ggf. per Undelete-Patch-Funktion oder SSH "richtig" löschen).


    Stefan

    Zumindest meine Großhändler haben getauscht und da ist es eher schwieriger als im Einzelhandel, kann ja nicht einfach vom Kauf zurücktreten.


    Starke, deutlich wahrnehmbare Vibrationen gehen auf die Lager, also Lebenszeitbegrenzung.

    WD bewirbt die EFAX Serie (WD Red (Pro)) ja explizit mit Raid-Fähigkeit und Vibrationsdämpfung.

    Da Unwucht also ein Mangel ist => Retour.


    Stefan

    Die Frage ist halt zunächst:

    ( kls ) Setzt der VDR bei externem EPG-Datenupdate die VPS-Timer neu, oder ist es das Plugin?


    Denn der erste "Stop" kommt beim Daten-Update:


    Die Timeränderung dann mit dem "Das Erste HD" Update.


    Edit: grep sagt, Meldung ist aus VDRs timer.c:


    Grüße,

    Stefan

    Warum? Gute Frage ... also mal ein Log, was passiert:


    Timer auf heute ARD 22:50, VPS aktiviert (noch mit VDR 2.4.7, ändert aber nichts):

    Bis zum "entered VPS margin" ist alles ok.

    Code
    May 25 22:48:01 vdr: [6369] timer 37 (1 2250-0020 VPS 'Die Einzelteile der Liebe') entered VPS margin
    May 25 22:48:01 vdr: [6369] switching device 2 to channel 1 S19.2E-1-1019-10301 (Das Erste HD)
    May 25 22:49:42 vdr: epg2vdr: --- EPG 'refresh' started ---
    May 25 22:49:57 vdr: epg2vdr: --- EPG refresh finished ---
    May 25 22:50:57 vdr: epg2vdr: Updating table timers (and remove deleted and finished timers older than 2 days)
    May 25 22:50:57 vdr: epg2vdr: Updating table timers done
    May 25 22:51:57 vdr: epg2vdr: Updating table timers (and remove deleted and finished timers older than 2 days)
    May 25 22:51:57 vdr: epg2vdr: Updating table timers done


    Die Aufnahme wird mit epg2vdr nicht starten, wenn man nicht live auf "Das Erste" schaltet - beobachtet, also vorsichtshalber mal auf Kanal 1 schalten:


    Die Aufnahme startet dann sofort und läuft, bis zum nächsten epg2vdr EPG Update des VDR wenig später:


    Kurz darauf wird der Timer wieder aktiv / inaktiv / aktiv / ... bis zum Ende des Timers

    Also das hier:

    Code
    23:02:19 vdr: [6407] timer 37 (1 2250-0020 VPS 'Die Einzelteile der Liebe') set to no event
    23:02:19 vdr: [6407] timer 37 (1 2250-0020 VPS 'Die Einzelteile der Liebe') set to event Di. 25.05.2021 22:50-00:20 (VPS: 25.05. 22:50) 'Die Einzelteile der Liebe'


    Was da genau passiert, ist mir nicht ganz klar.

    Endweder mag der VDR die (externen) EPG Updates dann nicht, oder epg2vdr greift aktiv in die Timer ein.


    Soweit die Beobachtung,

    Stefan