vdr-1.3.6 langsam beim springen zu Schnittpositionen

Hallo!
Habe dasselbe Problem unter 1.3.6.
Hinzu kommt noch, dass das Verschieben von Schnittmarken auch
sehr lange dauert.
Es kommt auch vor, dass VDR crasht und restartet.
Wie siehts denn unter 1.2.6 aus?
Habe da das Schneiden noch nie getestet.

ich habe LinVDR 0.5 - das dürfte ja dann VDR 1.2.6 sein?

Ich schneide sehr viel (händisch) - mal in Files von 40-90 Minuten länge aber auch in Files von 190 Minuten länge. Ich habe noch keinen Unterschied bemerkt.

Ich spule halt mit GELB oder FF an die Stellen, lasse mit PLAY laufen und drücke irgendwann '0'
Dann drücke ich die '7' um zu der Marke zu springen (weil die ist i.d.R. zu weit hinten weil verzögert gesetzt gesetzt wird um 2-3 Frames) und korrigiere die Position mit '4' nach vorne.

Das geht: zapp - zapp - zapp... ich merke da nicht wirklich eine Verzögerung.

AMD Athlon 800 MHz, 256 MB Arbeitsspeicher

Hallo,

kann dieses Problem mit vdr 1.3.6 nicht nachvollziehen.

Springen zu Schmittmarken geht ruck-zuck, ebenso das verschieben der Schmittmarken.

ich verwende zum Schneiden kvdr unter KDE3.2 und nicht die Fernbedienung.
Vielleicht liegts ja daran ...?

System siehe Sig (neuer vdr

Hi mgoeben
Habe das gleiche Problem. Mit vdr 1.2.6 anspringen und verschieben von Schnittmarken kein Problem, mit vdr 1.3.6 endlos langsam (10-20 Sek.!!! pro Aktion!!!) Dabei ist unerheblich welcher Treiber verwendet wird. Hab es mit dem original ct-Kernel und Treibern ebenso versucht (1.0.0 sowie 1.0.1), wie mit den aktuellen Treibern aus dem 2.6er Kernel (2.6.4 und 2.6.5, als Module oder fest einkompiliert). Überall das gleiche Ergebnis, weshalb ich die Treiber als Quelle ausschließe. Auch die verwendeten Patches scheinen keinen Einfluß zu haben, der Effekt tritt bei mir sowohl in der plain Version auf, wie auch mit Elchi4d-, Mini- und DoubleEPG-Patch.
Eine Lösung oder zumindest die Ursache ist mir völlig rätselhaft, zumal sonst keiner dieses Problem zu haben scheint.
Ach ja, vdr läuft bei unter SID unstable, also gcc 3.3 (oder ist es schon 3.4?), und wurde auch dort gegen den fest einkompilierten Kernel-DVB-Treiber im Kernel 2.6.5 kompiliert.
Irgendjemand eine Idee???

Gruß, Sat-Opa

hi,

gesehen habe ich das bei meiner 1.3.6 auch schon ein paar mal, aber ein kleiner vdr restart hat es behoben (zumindest bei mir), scheint irgend ein überlauf zu sein der nach einer gewissen aktivität auftritt

Hi,

trage halt mal in der runvdr (oder in dem Skript, wo vdr gestartet wird)

export LD_ASSUME_KERNEL=2.4

ein. Sollte das NPTL-Problem mit Kernel 2.6 umgehen.

HTH
Oliver