Beiträge von caps!

Hmmm...

* Messages for package sys-libs/glibc-2.10.1-r1:
 * Sanity check to keep you from breaking your system:
 *  Downgrading glibc is not supported and a sure way to destruction
 * ERROR: sys-libs/glibc-2.10.1-r1 failed:
 *   aborting to save your system

Schon wieder was gelernt...

Gute Idee mit dem neuen Thread... Nachdem herrlado (siehe anderer Thread) ebenfalls Probleme mit vdpau und xine nach einem Systemupdate hat...

Bei mir startet der VDR inkl. xine-plugin und xine-ui ganz normal, jedoch friert das Bild sofort ein, sobald ich umschalte. Der Sender spielt dabei keine Rolle. Mein System: siehe Signatur. Habe mehrere nvidia-Treiber und xine-lib-Kombis ausprobiert. Nichts... Leider keine Fehler im Log. Werde mal eine alte glibc ausprobieren...

Grüße, caps!

Zitat

Original von Razorblade
@caps: Konntest Du das Problem lösen? Ich glaube ich bin in die gleiche Falle getappt, ebenfalls nur noch schwarzes Bild nach Gentoo update (neben Gentoo auch aktuelle xine-lib und xine-ui aus hg und vdr 1.7.14 -> 1.7.15)

Hast Du auch einen segfault?
vdr[2274]: segfault at c ip b73d7d45 sp bfcc2330 error 4 in libc-2.11.2.so[b7362000+164000]

Razorblade: Leider bin ich mittlerweile ratlos. Habe jetzt wirklich viel ausprobiert und bekomm xine-vdpau mit xine-plugin nicht mehr zum Laufen. Lief bis zu dem Gentoo-Systemupdate einwandfrei. Ich verstehs nicht! Habe den nvidia-Treiber von vor dem Update ausprobiert, alte xine-libs (vom 15.06. wovon ich weiß das es lief)... nichts! Ich kappiers nicht. Mein VDR schmiert leider ohne Fehlermeldung ab. Schön langsam machst keinen Spaß mehr... Bist Du denn schon zu einer Lösung gekommen?

Grüße, caps!

Hmm, ich hab jetzt alle möglichen Kombis an xine-lib / xine-ui / xine-plugin mit und ohne Patches durch und muss feststellen, daß es GAR nicht mehr läuft. Liegt also bei mir wohl nicht am Patch... Ich werde später mal alles ganz neu auschecken. Mal sehen...

Oder kann es daran liegen, daß ich über dast Gentoo-System-Update eine neue Version des nvidia-Treibers installiert habe? Gibt es Probleme mit 195.36.31 in Verbindung mit vdr und vdpau??

Grüße, caps!

Hallo,

erstmal Danke für die gute Arbeit. Leider funktioniert bei mir seit V12 das Zusammenspiel von xine-plugin und xine auch nicht mehr. V13 (mit stream-start) und xine-plugin-0.9.3-vdpau-extensions-v13.diff haben das Problem auch nicht gelöst. Sobald ich auf einen anderen Kanal wechsle friert das Bild ein und der Watchdog schlägt zu...

Dies ist xine (X11 gui) - Ein freier Video-Player v0.99.7hg.
(c) 2000-2010 The xine Team.
Kompiliert mit xine Bibliothek 1.1.90 (1.1.90hg)
xine Bibliothek, Version 1.1.90 (1.1.90hg) gefunden.
...
vo_vdpau: vdpau API version : 1
vo_vdpau: vdpau implementation description : NVIDIA VDPAU Driver Shared Library  195.36.31  Tue Jun  1 23:24:02 PDT 2010
vo_vdpau: using 3 output surfaces for display queue
video_out: thread created
...
set_speed 1000000
vo_vdpau: deinterlace: temporal
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: vdpau_update_csc: hue=0,000000, saturation=1,000000, contrast=1,000000, brightness=0,000000, color_standard=1 studio_levels=0
vo_vdpau: skip_chroma = 0
vo_vdpau: background_color = 0
video_out: Verwerfe Bild mit pts 177487, weil es zu alt ist (Unterschied: 2499).
video_out: Verwerfe Bild mit pts 178580, weil es zu alt ist (Unterschied: 1406).
video_out: Verwerfe Bild mit pts 181996, weil es zu alt ist (Unterschied: 1592).
video_out: Verwerfe Bild mit pts 188282, weil es zu alt ist (Unterschied: 2503).
video_out: Verwerfe Bild mit pts 190964, weil es zu alt ist (Unterschied: 1636).
video_out: Verwerfe Bild mit pts 197923, weil es zu alt ist (Unterschied: 1862).
video_out: Verwerfe Bild mit pts 205200, weil es zu alt ist (Unterschied: 1783).
video_out: Verwerfe Bild mit pts 214284, weil es zu alt ist (Unterschied: 1698).
video_out: Verwerfe Bild mit pts 226876, weil es zu alt ist (Unterschied: 1705).
video_out: Verwerfe Bild mit pts 244869, weil es zu alt ist (Unterschied: 1710).
video_out: Verwerfe Bild mit pts 275444, weil es zu alt ist (Unterschied: 1731).
video_out: Verwerfe Bild mit pts 379768, weil es zu alt ist (Unterschied: 1795).
200 Bilder angezeigt, 0 Bilder übersprungen, 14 Bilder verworfen
vdr: osdflush: n: 5, 51,8, timeout: 0, result: 0
vdr: osdflush: n: 2, 20,1, timeout: 0, result: 0
vdr: osdflush: n: 4, 40,2, timeout: 0, result: 0
vdr: osdflush: n: 4, 40,3, timeout: 0, result: 0
ao_flush (loop running: 1)
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none
video discontinuity #7, type is 0, disc_off 0
waiting for audio discontinuity #7
ao_close
audio_out: no streams left, closing driver
audio discontinuity #7, type is 0, disc_off 0
waiting for in_discontinuity update #7
vpts adjusted with prebuffer to 2152242
ao_flush (loop running: 1)
video discontinuity #8, type is 0, disc_off 0
waiting for audio discontinuity #8
audio discontinuity #8, type is 0, disc_off 0
waiting for in_discontinuity update #8

Grüße, caps!

Hab ich's doch falsch verstanden...

Laut http://www.ietf.org/rfc/rfc4344.txt:

This document describes the following new methods:


     aes128-ctr       RECOMMENDED       AES (Rijndael) in SDCTR mode,
                                        with 128-bit key
     aes192-ctr       RECOMMENDED       AES with 192-bit key
     aes256-ctr       RECOMMENDED       AES with 256-bit key
     3des-ctr         RECOMMENDED       Three-key 3DES in SDCTR mode
     blowfish-ctr     OPTIONAL          Blowfish in SDCTR mode
     twofish128-ctr   OPTIONAL          Twofish in SDCTR mode,
                                        with 128-bit key
     twofish192-ctr   OPTIONAL          Twofish with 192-bit key
     twofish256-ctr   OPTIONAL          Twofish with 256-bit key
     serpent128-ctr   OPTIONAL          Serpent in SDCTR mode, with
                                        128-bit key
     serpent192-ctr   OPTIONAL          Serpent with 192-bit key
     serpent256-ctr   OPTIONAL          Serpent with 256-bit key
     idea-ctr         OPTIONAL          IDEA in SDCTR mode
     cast128-ctr      OPTIONAL          CAST-128 in SDCTR mode,
                                        with 128-bit key

Die "höchste" Verschlüsselung scheint also 256 bit zu sein, ja. Das kannst Du übrigens auch in der /etc/ssh/ssh_config unter "Cipher" global einstellen. Dann musst Du es nicht per Schalter immer angeben. Bei mir ist da "Cipher 3des" eingestellt...

Grüße, caps!

Du meinst einen DSA- oder RSA-Schlüssel, um sich passwortlos anzumelden?

ssh-keygen -b 2048 -t rsa

Oder -t dsa, dann müssen aber laut Spezifikation auch 1024 bits angegeben werden.

Das erzeugt Dir den privaten und öffentlichen Schlüssel. Den öffentlichen speicherst Du auf dem Zielrechner unter ~/.ssh/authorized_keys

Ist auch alles in "man ssh-keygen" beschrieben.

Grüße, caps!

helau: Danke! Das war's...

Copperhead: Kein Stress... Kommt Zeit, kommt v5...

Grüße, caps!

Danke für die Korrekturen! Leider kompiliert vdr-1.7.14 mit v4 hier bei mir nicht mehr (egal welche Patches ich ein-/ausschalte):

device.c: In member function »bool cDevice::SwitchChannel(const cChannel*, bool)«:
device.c:724: Fehler: a function-definition is not allowed here before »{« token
device.c:1862: Fehler: expected `}' at end of input
make: *** [device.o] Fehler 1

Hab ich was übersehen? Grüße, caps!

Hey spitze! Danke Dir für die schnelle Umsetzung. Werde mit der neuen Version gleich mal testen...

Grüße, caps!

Zitat

Original von FireFly
@caps: die Größe wird immer für beides (geschnitten und ungeschnitten) berechnet. Je nach Einstellung im Brenndialog/Einstellungen des Plugins werden die Aufnahmen geschnitten oder nicht (natürlich wird dafür ne marks(.vdr) benötigt).

Es wurde gestern also im Fortschrittsbalken die richtige Größe angezeigt, aber die konvertierten Files waren größer?

Wir müssten uns auch über die Reihenfolge einigen: Lt. Log ist der erste Film der kleinste, bei Deinen Beschreibungen immer der zweite ...
Folgendes ist im Log zu sehen:
Film1 (Nüsse): 150.805.416 = 143 MB ohne Schnittmarken
Film2 (Dinos): 2.332.159.420 = 2224 MB mit Schnittmarken
Film3 (Jagd..): 2.096.089.208 = 1998 MB ohne Schnittmarken
Da man Schneiden nur pro Job und nicht pro Aufnahme einstellen kann würde das bedeuten, dass Film 1 und 3 keine Schnittmarken hatten...

Alles anzeigen

Stimmt. Die Reihenfolge hab ich nicht immer beibehalten. Es ist fast so, wie Du jetzt aufgelistet hast. Konnte das mit den Schnittmarken gestern nicht nachvollziehen, weil ich nicht direkt davor saß. Hab nur per ssh und control-Plugin die jeweilige Aufnahme gestartet, Schneiden für jedem Film aktiviert, gewartet bis Schneiden fertig war und dann diese Filme per burn-Plugin gebrannt. Film 2 (Dinos) & Film 3 (Jagdfieber) enthalten Schnittmarken. Wurden die bei Film 3 nicht vom burn-Plugin berücksichtigt???

Die tatsächliche Größe der (ungeschnittenen) Film-Ordner (.vdr und .ts) beträgt 4925 MB. Das burn-Plugin zeigt gesamt 3778,3 MB an, auch wenn man die einzelnen Filme zusammenzählt.

Nach dem Schneiden ergibt sich:

# du -sm Ice_Age\:_Keine_Zeit_für_Nüsse
145	Ice_Age:_Keine_Zeit_für_Nüsse


# du -sm Ice_Age_3_-_Die_Dinosaurier_sind_los %Ice_Age_3_-_Die_Dinosaurier_sind_los
2763	Ice_Age_3_-_Die_Dinosaurier_sind_los
2299	%Ice_Age_3_-_Die_Dinosaurier_sind_los


# du -sm Jagdfieber %Jagdfieber
2017	Jagdfieber
1360	%Jagdfieber

Also tatsächlich 3804 MB. Das passt natürlich ohne shrinken und ergibt auf der gebrannten DVD 3838 MB. Dann liegt das Problem wohl darin, daß die Schnittmarken im Film 3 (Jagdfieber) nicht berücksichtigt wurden? Die marks.vdr sieht ganz normal aus, enthält eine gerade Anzahl an Schnittmarken und hat auch beim Schneiden keine Probleme gemacht!?

Zitat

Original von FireFly
ProjectX demuxt die Filme zu folgenden Größen:
Film1: 150.805.416 = 143 MB
Film2: 2.332.159.420 = 2224 MB
Film3: 2.096.089.208 = 1998 MB
Macht zusammen ca. 4365 MB. Da kommt dann noch etwas Overhead für Menüs, NAV-Blöcke der DVD dazu, so dass es mit 4495 MB knapp nicht langt.
Evtl. ist bei einem Film ein größerer Block rausgeschnitten? Lt. Log wird nur der zweite Film (...Dinosaurier...) geschnitten.
Geshrinkt wird nicht, da burn bei 3778MB dafür keine Notwendigkeit sieht; außerdem müsste man das im Log sehen (requant-Aufruf und Meldungen).
Welche Größe zeigt denn der Fortschrittsbalken im burn-Plugin wenn Du nur jeweils einen Film auswählst? Irgendwie passt die 3378 nicht zur realen 4365 ...

Alles anzeigen

Hmm, in der Fortschrittsleiste im burn-Plugin ergeben die drei Aufnahmen einzeln auch die errechneten 3778 MB. (1350,7 MB + 144,0 MB + 2283,6 MB). Ich habe jetzt die Aufnahmen, die Vor- und Nachläufe enthielten (Schnittmarken) geschnitten und das ganze nochmal ausprobiert. Das hat funktioniert! Kann es sein, daß die Größe mal ohne und mal mit Schnittmarken berechnet wird?

EDIT: Die gebrannten Filme auf der DVD ergeben dann aber zusammen nur noch 3838 MB...

Habe versucht insgesamt drei Aufnahmen auf die DVD zu packen. Einen sehr kurzen und zwei "normal" lange. Zwei PES-Aufnahmen und eine TS-Aufnahme. Dabei stimmt aber die berechnete Größe im Plugin nicht mit der tatsachlichen über ein.

# du -sm /video/Film_1(PES)
2017	Film_1(PES)


# du -sm /video/Film_2(PES)
145	Film_2(PES)


# du -sm /video/Film_3(TS)
2763	Film_3(TS)

Ergibt 4925 MB. Im Plugin (wie schon geschrieben) angezeigt: 3778,3 MB. "Geshrinkt" wird ja aber offensichtlich, nur eben um die paar MB zu wenig.

Habe mal mit der aktuellen vdr-Version den Index der TS-Aufnahme neu erzeugen lassen. Leider kein Erfolg...

Zitat

Original von FireFly
caps!: Welche DVD-Größe hast Du denn eingestellt? Dual-Layer oder custom? Bei Single Layer sollte er eigentlich shrinken. Was zeigt er Dir beim Zusammenstellen als Größe an?

Als berechnete Größe zeigt das Plugin 3778,3 MB an. Eingestellt ist Single Layer. Hab es grad nochmal durchlaufen lassen und einen anderen Rohling genommen. Selbe Fehlermeldung... Ein du -ch in dem Arbeitsverzeichnis DVDAUTHOR ergibt 4,4G insgesamt. Es passt grad so nicht drauf. Welches Programm ist denn für die Größenberechnung verantwortlich? Hab ich da vielleicht eine alte Version?

Mann, hab ich mich jetzt mit ProjectX unter Gentoo geärgert. Mit der CVS-Version geht es nun. Endlich wieder DVDs brennen! Leider gibt es noch ein Problem beim Brennen:

[burn] + growisofs -use-the-force-luke=tty -speed=4 -dvd-compat -Z /dev/sr0 -V Animationsfilme -dvd-video /pub/vdr-burn/vdr-burn.Animationsfilme.V0H8O4/DVDAUTHOR
[burn] Executing 'mkisofs -V Animationsfilme -dvd-video /pub/vdr-burn/vdr-burn.Animationsfilme.V0H8O4/DVDAUTHOR | builtin_dd of=/dev/sr0 obs=32k seek=0'
[burn] mkisofs: Permission denied. Cannot open '/root/.mkisofsrc'.
[burn] Setting input-charset to 'UTF-8' from locale.
[burn] :-( /dev/sr0: 2297888 blocks are free, 2301875 to be written!
[burn] :-( write failed: No space left on device
[burn] mkisofs: Broken pipe. cannot fwrite 2048*2
[vdr] process burn (pid = 2503) exited gracefully (exit code 156)
[vdr] process "burn" exited
[vdr] starting sh -c 'eject /dev/sr0' (pid = 2506)
[vdr] process eject (pid = 2506) exited gracefully (exit code 0)
[vdr] wait_for_user

Wurde hier die Größe falsch berechnet oder hab ich irgendwo vergessen etwas einzustellen?

Zitat

Original von hotzenplotz5

bitte nicht !! nicht jeder hat/will den ext-patch.
es gibt auch menschen die haben den TTXTSUBS-Patch aber ohne ext-patch ...

??? Das eine schließt doch das andere nicht aus, oder? Aber Du hast recht, man kann ja nur prüfen, ob es definiert ist. Naja, vielleicht läßt sich FireFly ja was einfallen. Ich wäre auch mit der Lösung durch Ändern des Makefiles einverstanden. Dann fänd ich aber einen kurzen Hinweis im README nicht schlecht...

Grüße, caps!

Zitat

Original von FireFly
Ich habs mit dieser Version extra automatisiert, damit ttxtsub nur dann mitkompiliert wird, wenn im VDR Verzeichnis die vdrttxtsubshooks.h vorhanden ist, was gleichbedeutend mit einem gepatchten VDR ist .... Ist bei Dir die Datei im VDR-Verzeichnis vorhanden?

Jap, habe ich... Entschuldigung. Ich habe gerade bemerkt, daß es doch kompiliert, wenn ich vom aktuellen Extension-Patch das TTXTSUBS "aktiviere". Wenn nicht, dann kommt es bei mir zu folgendem Fehler:

scanner.c: In member function »vdr_burn::track_info_list& vdr_burn::pes_scanner::ts_scan(cPatPmtParser&, const std::pair<int, int>&, const std::pair<int, int>&)«:
scanner.c:459: Fehler: »class cPatPmtParser« hat kein Element namens »Tpid«
scanner.c:460: Fehler: »class cPatPmtParser« hat kein Element namens »Tpid«
scanner.c:460: Fehler: »class cPatPmtParser« hat kein Element namens »TotalTeletextSubtitlePages«
scanner.c:461: Fehler: »class cPatPmtParser« hat kein Element namens »TotalTeletextSubtitlePages«
scanner.c:462: Fehler: expected initializer before »*« token
scanner.c:463: Fehler: »class cPatPmtParser« hat kein Element namens »Tpid«
scanner.c:464: Fehler: »class cPatPmtParser« hat kein Element namens »TeletextSubtitlePages«
scanner.c:465: Fehler: »ttxtSubtitlePage« wurde in diesem Gültigkeitsbereich nicht definiert
scanner.c:466: Fehler: »class cPatPmtParser« hat kein Element namens »Tpid«
make[1]: *** [scanner.o] Fehler 1
make[1]: Leaving directory `/usr/local/src/vdr-1.7.14/PLUGINS/src/burn-0.2.0-beta2'

Müsste ich also zwingend den Patch im Extension-Patch aktivieren, wenn ich am Makefile das Plugins nicht verändern möchte?

EDIT: Ah, jetzt verstehe ich. Die "vdrttxtsubshooks.h" wird auch vom Extension-Patch erzeugt, aber man kann eben den TTXTSUBS-Patch deaktivieren... Könnte man zusätzlich im burn-Plugin prüfen, ob die TTXTSUBS in der Make.config gesetzt ist oder nicht?

Hmm, wenn ich das DEFINE in Z. 92 rausnehme kompilierts durch. Habe den aktuelle Extenionspatch für vdr-1.7.14 drauf (ExtP-NG-vdr-1.7.14-V1.diff von Copperhead). Das TTXTSUBS-Define dazu in der Make.config ist bei mir aber nicht "aktiviert". Habe es vorher mal aktiviert und dann versucht. Dabei hat sich aber rausgestellt, daß sich der TTXTSUBS-Patch von Deinem mitgelieferten Patch ein wenig unterscheidet. Dort wird dann nicht "tpages[0] = 0;" definiert sondern irgendwas mit "teletextSubtitlePages". Zwickt sich irgendwie...

Leider bin ich da sehr unerfahren. Könnte man die ttxtsubs-Unterstützung im burn-plugin irgendwie optional machen, ohne das Makefile anzupassen? Wobei das eigentlich nicht ja nicht das Problem ist. Ein Schalter am Anfang wäre vielleicht "schöner".

Ich werde jetzt erstmal testen. Vielen Dank für die Hilfe und Deine Arbeit am Plugin!

Grüße, caps!

Hallo FireFly,

vielen Dank für das Update! Wollte es grad ausprobieren, scheitere aber leider schon beim Kompilieren des Plugins. Kann es sein, daß man mit vdr-1.7.14 den Patch "vdr-1.7.12-tpid-Parser.diff" anwenden muß, damit es kompiliert? Der Patch beißt sich nämlich mit dem TTXTSUB-Patch aus dem Extension-Patch. Der macht nämlich das gleiche glaub ich, ist nur ein bisschen anders geschrieben. Ich könnte das jetzt einfach ändern, aber es gefällt mir nicht da rumzudoktoren. Dann hab ich bei der nächsten Version wieder gefrickel... Gibt es dafür eine Lösung? ttxtsub-Plugin benötige ich nicht...

Viele Grüße, caps!

Äh... Dann nehm ich lieber v3... Aber Danke für den Hinweis.