Probleme nach Update

xxx123455 · 6. Oktober 2013

Zitat von seahawk1986

oder man nutzt einen pastebin-Service

Danke! Kannte ich bislang noch nicht. Ist ja echt praktisch!

Hier eine Syslog mit dem Problem. Der Aussetzer war kurz nach dem Umschalten auf Kanal 1 (Zeile 1189):
http://paste.ubuntu.com/6201851/

Ursprunglich hatte ich gedacht, der VDR startet dann neu, da das VDR Logo kurz eingeblendet wurde, bevor das Bild
zurück kamm. Im Syslog ist davon aber nix zu sehen. Der VDR hängt also wohl nur (wie bei Tommy.Z)

Norbert

Tommy.Z · 6. Oktober 2013

So, syslog des Systemstarts

seahawk1986 · 6. Oktober 2013

Zitat von Norbert42

Ursprunglich hatte ich gedacht, der VDR startet dann neu, da das VDR Logo kurz eingeblendet wurde, bevor das Bild zurück kamm. Im Syslog ist davon aber nix zu sehen.

Was da genau passiert, sieht man leider nicht:

Code

Oct  6 20:10:18 vdr02 rsyslogd-2177: imuxsock lost 277 messages from pid 1455 due to rate-limiting

Daher würde ich vorschlagen die /etc/rsyslog.conf so abzuändern: http://paste.ubuntu.com/6201955/
bzw. diese Zeilen zu ergänzen:

Code

# Don't skip messages
$IMUXSockRateLimitBurst 10000
$SystemLogRateLimitInterval 10
$SystemLogRateLimitBurst 10000

seahawk1986 · 6. Oktober 2013

Zitat von Tommy.Z

So, syslog des Systemstarts

Wer setzt bei dir die Systemzeit? Falls du es dem VDR erlaubst, würde ich es mal abschalten, da das bekanntermaßen mit softhddevice Probleme macht, wenn man da plötzlich minutenweise in der Zeit zurück springt.

Code

Oct  6 18:05:56 origen vdr: [1992] system time changed from Sun Oct  6 18:07:17 2013 (1381075637) to Sun Oct  6 18:05:56 2013 (1381075556)

Tommy.Z · 6. Oktober 2013

Wird gemacht (Zeit, wird glaub ich per VDR gesetzt)
Neustart nach Tatort.
Danke erstmal fürs drüberschauen.

xxx123455 · 6. Oktober 2013

Danke schon mal!

Hab die Änderung in rsyslog.conf gemacht und stelle nachher auch das Setzen der Zeit im VDR aus.
Auch bei mir kommt der Syslog dann noch, sobald ich wieder freien Zugang zum VDR habe.

Ich hatte übrigens irgendwo was gelesen, dass das es evlt. Probleme gibt, wenn nvidia sich einen Interrupt mit
USB teilt. Da wurde empfohlen die folgenden Anpassungen in "/etc/modprobe.d/options.conf" zu machen:

Code

options nvidia-current NVreg_EnableMSI=1 NVreg_UsePageAttributeTable=1
options nvidia NVreg_EnableMSI=1 NVreg_UsePageAttributeTable=1
options nvidia-304 NVreg_EnableMSI=1 NVreg_UsePageAttributeTable=1

Hab ich versucht. Jetzt hat nvidia wieder einen eigenen Interrupt, aber das Problem ist geblieben:

Code

cat /proc/interrupts 
           CPU0       CPU1
  0:         46          9   IO-APIC-edge      timer
  1:          1          1   IO-APIC-edge      i8042
  8:          1          0   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 12:          1          3   IO-APIC-edge      i8042
 16:       2162       2138   IO-APIC-fasteoi   uhci_hcd:usb3, pata_jmicron
 18:     171646     172130   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8, saa7146 (0)
 19:       8042       8108   IO-APIC-fasteoi   ata_piix, ata_piix, uhci_hcd:usb7
 21:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 23:     187359     186956   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb6
 44:       7886       7754   PCI-MSI-edge      eth0
 45:     268273     267699   PCI-MSI-edge      nGene
 46:      49811      50101   PCI-MSI-edge      snd_hda_intel
 47:      89892      90183   PCI-MSI-edge      nvidia
NMI:        211        253   Non-maskable interrupts
LOC:    1897512    1923028   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:        211        253   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
RES:     582192     571229   Rescheduling interrupts
CAL:        433        461   Function call interrupts
TLB:       9132       8764   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:         15         15   Machine check polls
ERR:          0
MIS:          0

Alles anzeigen

Norbert

xxx123455 · 6. Oktober 2013

Hi,

ich glaube der TIPP mit der Systemzeit hat es gebracht (Danke seahawk1986)!!!!

Nachdem ich im VDR (System>Einstellungen>EPG) "Systemzeit stellen" auf "Nein" gesetzt habe funzt es jetzt wieder problemlos.
Hab jetzt sicher 10x rebootet und es war jedesmal OK. Auch den Gegencheck habe ich gemacht und der Fehler war sofort wieder da.

SUPER! Danke!!!

Was wäre denn jetzt der richtige Weg, die Zeit automatisch (wohl am besten bevor der VDR startet) zu setzen?
Mir würde noch einfallen die Zeit per "/usr/sbin/ntpdate ptbtime1.ptb.de ptbtime2.ptb.de >/dev/null 2>&1"
über die crontab zu setzen. Aber dann würde das ja auch wieder bei laufendem VDR passieren, oder?

Danke
Norbert

Tommy.Z · 7. Oktober 2013

Dito
Danke für die Hilfe

DocViper · 7. Oktober 2013

Zitat von Norbert42

Nachdem ich im VDR (System>Einstellungen>EPG) "Systemzeit stellen" auf "Nein" gesetzt habe funzt es jetzt wieder problemlos.

@Yavdr Team: Wäre es nicht sinnvoll dies als Standardwert vorzugeben (sofern es nicht bereits so ist) bei einer Neuinstallation ?

Oder andersrum: Ist dies eventuel ein Bug den sich Klaus ansehen müsste? Immerhin ist dies ja eine VDR Funktion und sollte auf allen Systemen auftreten?

lg,
Joe

seahawk1986 · 7. Oktober 2013

Der VDR setzt im Auslieferungszustand die Systemzeit nicht ( http://projects.vdr-developer.…dr.git/tree/config.c#n398 ), die yaVDR Pakete tun es bei der Installation auch nicht: https://github.com/yavdr/yavdr…ib/vdr/setup.conf/10_main
Das Problem gibt es soweit ich weiß nur mit softhddevice - ich johns hatte da mal was zur Nutzung der monotonic clock geschrieben, im Code ist da aber noch ein FIXME drin:
http://projects.vdr-developer.…ce.git/tree/video.c#n8384

johns · 7. Oktober 2013

Im letzten Thread hatte ich gefragt, ob die Änderungen nötig sind:

[softhddevice] Dropping frame/Duping frame - Lösung bzw. Bug entdeckt

CLOCK_MONOTONIC -> CLOCK_MONOTONIC_RAW

war die Aussage, daß es nicht gebraucht wurde,
Johns

seahawk1986 · 7. Oktober 2013

Zitat von johns

war die Aussage, daß es nicht gebraucht wurde

Ich hatte es so verstanden, dass es nicht gebraucht wird, wenn der VDR die Systemzeit nicht selbst stellt bzw. wenn keine großen Sprünge auftreten.
Die Frage ist ja einfach: Was macht das Plugin bzw. der Decoder, wenn die Systemzeit so stark springt? Offenbar kommt er da doch so aus dem Tritt, dass er keine neuen Pakete mehr annimmt:

Code

Oct  6 18:07:17 origen vdr: [2023] XVDR: Recordings state changed (819)
Oct  6 18:05:56 origen vdr: [1992] system time changed from Sun Oct  6 18:07:17 2013 (1381075637) to Sun Oct  6 18:05:56 2013 (1381075556)
Oct  6 18:05:56 origen vdr: [2023] XVDR: Recordings state changed (894)
Oct  6 18:05:56 origen vdr: [2023] XVDR: Recordings state changed (974)
Oct  6 18:05:56 origen vdr: [2023] XVDR: Recordings state changed (1048)
Oct  6 18:05:56 origen vdr: [2023] XVDR: Recordings state changed (1124)
Oct  6 18:05:56 origen vdr: [2216] video directory scanner thread ended (pid=1555, tid=2216)
Oct  6 18:05:57 origen vdr: [2215] video directory scanner thread ended (pid=1555, tid=2215)
Oct  6 18:05:57 origen vdr: [2023] XVDR: Recordings state changed (1182)
Oct  6 18:05:59 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:05:59 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:05:59 origen vdr: [2023] XVDR: Starting garbage collection in recordings cache
Oct  6 18:05:59 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:05:59 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:02 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:02 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:02 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:02 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:06 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:06 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:06 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:06 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:10 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:10 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:10 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:10 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:13 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:13 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:13 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:13 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:17 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:17 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:17 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:17 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:21 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:21 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:21 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:21 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:24 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:24 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:24 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:24 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:28 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:28 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:28 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:28 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:32 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:32 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:32 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:32 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:35 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:35 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:35 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:36 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:39 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:39 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:39 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:39 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:43 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:43 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:43 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:43 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:46 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:46 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:46 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:47 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:50 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:50 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:50 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:50 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:54 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:54 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:54 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:54 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:06:57 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:06:57 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:06:57 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:06:57 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:07:01 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:07:01 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:07:01 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:07:01 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:07:05 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:07:05 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:07:05 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:07:05 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:07:08 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:07:08 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:07:08 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:07:08 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:07:12 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:07:12 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:07:12 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:07:12 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:07:16 origen vdr: [2140] [softhddev]Clear:
Oct  6 18:07:16 origen vdr: [2140] ERROR: TS packet not accepted in Transfer Mode
Oct  6 18:07:16 origen vdr: audio/alsa: using device '51to20'
Oct  6 18:07:16 origen vdr: audio/alsa: start delay 336ms
Oct  6 18:07:17 origen vdr: video: slow down video, duping frame
Oct  6 18:07:17 origen vdr: video/vdpau: missed frame (2/171)
Oct  6 18:07:17 origen vdr: video: slow down video, duping frame
Oct  6 18:07:17 origen vdr: video: 21:23:49.912 +324 1347   0/\ms  68+3 v-buf
Oct  6 18:07:18 origen vdr: video/vdpau: synced after 38 frames

Alles anzeigen

BOP · 7. Oktober 2013

Zitat von Norbert42

Was wäre denn jetzt der richtige Weg, die Zeit automatisch (wohl am besten bevor der VDR startet) zu setzen?

Wenn ich richtig liege, passiert das bereits ootb. Deswegen ist die Einstellung im VDR auch unnötig.

Frodo · 7. Oktober 2013

Das Zeit setzen im YaVDR sollte automatisch gehen ich musste allerdings in der /etc/default/ntpdate die Optionen anpassen: NTPOPTIONS="-u".

johns · 8. Oktober 2013

Zitat von seahawk1986

Ich hatte es so verstanden, dass es nicht gebraucht wird, wenn der VDR die Systemzeit nicht selbst stellt bzw. wenn keine großen Sprünge auftreten.
Die Frage ist ja einfach: Was macht das Plugin bzw. der Decoder, wenn die Systemzeit so stark springt? Offenbar kommt er da doch so aus dem Tritt, dass er keine neuen Pakete mehr annimmt:

Große Sprünge waren ein Problem, habe jetzt CLOCK_REALTIME mit CLOCK_MONOTONIC ausgetauscht, nun sollten Sprünge durch setzten der Systemzeit kein Problem mehr sein.

ntpd und ich denke auch VDR lassen die Zeit langsam ändern, dies sollte kein Problem sein, deshalb sollte CLOCK_MONOTONIC_RAW unnötig sein.

Johns

seahawk1986 · 8. Oktober 2013

Danke, ich habe mal die aktuelle Version aus dem Git für das yaVDR testing-vdr PPA gebaut.

Guido17 · 8. Oktober 2013

Schön, dass ich dies lesen konnte, war schon fast dabei mein vdr zu zerlegen.
Ich habe nun mein yavdr seit Februar und hatte bis letzte Woche kein Problem.
Letzten Mittwoch hatte ich den ersten Hänger und zwar kurz nach dem Einschalten,
ich konnte nicht umschalten und nur über ein Reboot lief mein System wieder.

Dann am Sonntag kurz nach 20:00 plötzlich ein Schrei aus dem Wohnzimmer und
Bild war wieder eingeforen (Anmerkung: vdr lief schon seit mehreren Stunden).
Reboot mit dem selben Ergebnis und dann ging es
mit Pro8 wieder, aber beim Umschalten auf ARD Verpixelung und dann ging
gar nichts mehr.

Jetzt habe ich das hier gelesen, dass das Stellen der Systemzeit Probleme hervorruft
und in meinem syslog sehe ich das selbe Problem mit großen Sprüngen

Z. B.
system time changed from Sun Oct 6 20:16:13 2013 (1381083373) to Wed Mar 6 14:00:09 2013 (1362574809)

Das sind noch ein paar Anpassung, aber ohne so große Sprünge.

Jetzt habe ich die Einstellung der Systemzeit über den Transponder abgeschaltet, aber wie macht
man nun die Systemzeitsynchronisation?

Tommy.Z · 8. Oktober 2013

Ich hab jetzt mal per
sudo apt-get install ntp
den ntpd installiert, der die Uhrzeit "fließend" anpaßt.
Bis jetzt keine Probleme mehr.

ATD · 8. Oktober 2013

Zitat von Tommy.Z

sudo apt-get install ntp

Hm, ntpdate ist doch bei yaVDR per Default darauf.

Code

root@Patty:~# dpkg --get-selections | grep ntp
ntpdate                                         install

Albert

Tommy.Z · 8. Oktober 2013

ntp ändert aber die Zeit nicht hart, sondern beschleunigt bzw. verlangsamt die Uhr (so oder ähnlich hab ich das irgendwo gelesen )

Probleme nach Update

Jetzt mitmachen!

Teilen