VDR Portal

Hi Reinhard,

Bin wieder da.

Neue Version läuft super, leider besteht das Schnittmarken-Problem auch hier.

Habe herausgefunden wo er sich anscheinend totläuft.

Sobald ich z.B. Taste 9 drücken kommen 100.000 dieser Meldungen.
input_vdr: (internal_read:873) got VIDEOSIZE

Vielleicht sagt's Dir ja etwas.
Habe nämlich nicht runvdr sondern direkt vdr gestartet.

Gruß
Peter

Hi,

in xineDevice.c kannst du mit dem LOG_ME define wieder die Ausgabe einschalten, die du in 0.4.3 nach dem Patch erhalten hast.

Die Ausgabe zeigt, ob für lockups anfällige Funktionen noch betreten bzw. verlassen werden. Vv ist dabei das Pärchen für PlayVideo(), Aa für PlayAudio() und einige andere Funktionen geben am Schluss eine ähnliche Anzahl an '-' aus.

Das Kommando VIDEOSIZE wird verwendet, um die Auflösung des Video-Bildes zu ermitteln, damit das OSD entsprechend skaliert werden kann. Auch wenn sich am OSD nichts zu ändern scheint, ruft VDR dennoch cOsd::Flush() auf. Dort wird dann erst entschieden, ob überhaupt Änderungen vorliegen, oder das OSD vollständig skaliert und übertragen werden muss, da sich die VIDEOSIZE geändert hat.

Es ist also normal, wenn das Kommando häufig erscheint. Die Frage ist nur wie schnell hintereinander diese 100000 Meldungen auftauchen.

Leider kann ich noch immer keine Vorstellung davon bekommen, wo das Problem herkommt. Vielleicht könntest du selbst in alle Schnittstellen-Methoden (cXineDevice, cXineOsd, cXineStatus, cXineRemote) zu VDR solche printf-Pärchen einbauen, denn irgendwo muss das Ding ja hängen.

Bye.

Hi,

jetzt siehts so aus:

Play
----
VvVvVvVvVvVvVvTaste9Clear
StillPicture: 0xbffcf850, 54941
VvVvVvVv------------

aus

Ich denke damit liegst nicht an xineOsd.c

Die 100000 Meldungen kommen von einer Enlosschleife (also schnell hintereinander, sehr schnell).

Wenn ich den VDR weiterlaufen lasse, xine beende und neu starte sehe ich noch das OSD aber kein Bild mehr.
----------------
xine-Fenster
Wenn ich das OSD aufschalte kommt zwischen VIDEOSIZE immer OSDRAWBITMAP und OSDSHOW

input_vdr: (internal_read:335) got OSDDRAWBITMAP
input_vdr: (internal_read:262) got OSDSHOW
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:335) got OSDDRAWBITMAP
input_vdr: (internal_read:262) got OSDSHOW
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:873) got VIDEOSIZE
input_vdr: (internal_read:335) got OSDDRAWBITMAP
input_vdr: (internal_read:262) got OSDSHOW
input_vdr: (internal_read:873) got VIDEOSIZE

nach der Taste 9 kommt nur mehr got VIDEOSIZE
Wo sollte man am ehesten ansetzen?

Gruß
Peter

Hi,

ich habe noch immer keine Idee, was schief gehen könnte. Irgendwie lebt VDR und vdr-xine, da das OSD Aktivität zeigt.

dvbplayer.c:

in cDvbPlayer::Goto() wird das StillPicture() ausgegeben und der Still-Mode aktiviert. In cDvbPlayer::Action() kommt dann ein usleep(1) zum Tragen (// this keeps the CPU load low). Evtl. hier mal ein printf() einbauen.

menu.c:

cDvbPlayer::Goto() wird über cReplayControl::MarkJump() aufgerufen, welches über cReplayControl:rocessKey() aufgerufen wird. Evtl. auch hier mal ein printf() einbauen, um zu sehen, ob noch irgendwelche Tastendrücke ankommen.

Bye.

Hi,

komm gerade zu nichts, nur soviel:

Wenn ich mit <menü> und <rot> Aufnahme starte und dann mit <menü> und <gelb> (Pause) aktiviere, sagt der vdr LiveBild wird angehalten, danach wird NoSignal angezeigt.
Dann wieder <menü> (ich sehe 2 gleiche Aufnahmen-Einträge) und <blau> (Wiedergabe), vdr restart.

Ist dieses Verhalten bei Euch auch so?

Gruß
Peter

Hi,

Quoted

Original von peter_weber69
Wenn ich mit <menü> und <rot> Aufnahme starte und dann mit <menü> und <gelb> (Pause) aktiviere, sagt der vdr LiveBild wird angehalten, danach wird NoSignal angezeigt.

Bei mir kommt dann ordnungsgemäß das Standbild und das OSD zeigt an, dass die Wiedergabe pausiert ist. Ich kann die Wiedergabe dann problemlos fortsetzen.

Quoted

Original von peter_weber69
Dann wieder <menü> (ich sehe 2 gleiche Aufnahmen-Einträge) und <blau> (Wiedergabe),

Das ist bei mir auch so. Auch im Timer-Menü sind zwei Einträge vorhanden.

Quoted

Original von peter_weber69
vdr restart.

Ist dieses Verhalten bei Euch auch so?

Nein. Der Neustart kommt wohl durch den Watchdog-Timer von 60 Sekunden.

Irgendwie scheint sich hier (wie auch beim Anspringen der Schneidemarken) VDR nach der Anzeige des Standbildes zu verlaufen.

Benutzt du irgendwelche Patches oder Plugins?

Kannst du mal die Minimal-Konfiguration (plain VDR 1.3.12 + vdr-xine 0.5.0) testen?

Bye.

Hi,

gleiches Verhalten mit VDR1.3.12 Plain und xine0.5.0
Zusätzlich streamdev3.1

Muß anscheinend an meiner Installation liegen.
kanotix hd-Installation -> debian
(kernel sourcen wurden nicht installiert)

Irgendetwas stimmt bei mir nicht, ich konnte z.B. nie VDR1.3.1 bis VDR1.3.6 kompilieren.

Gruß
Peter

Hi,

kannst du mal ein wenig zu der Konfiguration von streamdev mitteilen. Ich möchte das Plugin bei mir zum Testen auch so einrichten, wie du es verwendest.

Bye.

Hi,

vdr:
VFAT=1 DEBUG_OSD=1

Habe jetzt geraden nur den client zur Hand:

streamdev-client.RemoteIp = 169.254.159.182
streamdev-client.RemotePort = 2004
streamdev-client.StartClient = 1
streamdev-client.StreamPIDS = 1
streamdev-client.StreamType = 0
streamdev-client.SyncEPG = 1
xine.audioMode = audioDolbyOn
xine.modeLiveTV.prebufferFrames = 32
xine.osdMode = osdScaled

Was mir vom Server so aus dem Stegreif einfällt (Werte folgen morgen):
Streamtyp = TS
HTTP Stream starten ist ausgeschaltet
Client darf pausieren: ja
Immer pausieren ist: nein

streamdev-server.AllowSuspend = 1
streamdev-server.HTTPServerPort = 3000
streamdev-server.HTTPStreamType = ? (TS bei mir)
streamdev-server.MaxClients = 2
streamdev-server.ServerPort = 2004
streamdev-server.StartHTTPServer = 0
streamdev-server.StartServer = 1
streamdev-server.SuspendMode = 0

xine config

xine keymap

-----------------------
Angemeldet bin ich als root:

Was mir noch aufgefallen ist:

1.) Aufnahme: Menü + Rot
2.) 2 min warten
3.) Menü - Aufnahmeverzeichnis - Aufnahme wiedergeben
4.) nach 2 min rums/vdr restart

Aufnahmeverzeichnis liegt auf vfat /mnt/hda5/Filme
/video link darauf

Gruß
Peter

Hi,

meine Stremdev Server Einstellungen

streamdev-server.AllowSuspend = 1
streamdev-server.HTTPServerPort = 3000
streamdev-server.HTTPStreamType = 1
streamdev-server.MaxClients = 5
streamdev-server.ServerPort = 2004
streamdev-server.StartHTTPServer = 0
streamdev-server.StartServer = 1
streamdev-server.SuspendMode = 0
-----------------------------------------------------------
zusätlich habe ich vdr mit der -r Option gestartet. Programm wie in der Beschreibung von VDR vorgeschlagen.

Bei Abspielen einer noch laufenden Aufnahme wie in vorhergehenden Tread beschrieben: Menü+Rot, Menü Aufnahmen
Film wiedergeben
SetPlayMode: 0
SetPlayMode: 1
VvVvVvVvPVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVvVv [Zeitspanne zwischen Aufnahmebeginn und Wiedergabebeginn erreicht, Vv hört ca. 1-2 sec. vor SetPlayMode: 0 auf] SetPlayMode: 0
SetPlayMode: 1 [es kommt aber kein Bild mehr sondern NoSignal (watchdoglänge), danach xine Verbindungsabbruch, es kommt diese Meldung]
After recording /mnt/hda5/Filme/@Doku#3A_Epochen_der_Luftfahrt_-_Die_ersten_Düse_Doku#3A_Epochen_der_Luftfahrt_-_Die_erste/2004-08-26.21.14.50.99.rec
SetPlayMode: 0
Do Aug 26 21:15:27 CEST 2004
restarting VDR

Before recording Meldung kommt nie

Gruß Peter

Hi,

ich habe heute folgendes in der ML gelesen:

Quoted

On Fri, 17 Sep 2004 08:50:42 -0400
Peace Monk wrote:


>> VDR version is 1.3.12 and dxr3 plugin is vdr-dxr3-0.2.3-pre2
>>
>> When I use the remote to mark points to edit in my recording, it works
>> fine, but when I jump between the markings, VDR hangs for a while, and
>> then crashes.
>>
>> Is this a known problem, and is there any fix available?
>>
>> Thank you
>> Monk.
>>



Hi Monk,

I had the same problem (occurred only with the combination of
dxr3 and subtitles plugins, though...) and I was just about to ask the
same question when I noticed that running vdr with

LD_ASSUME_KERNEL=2.4.0 vdr -P dxr3 <and so forth>

helps. It has something to do with threads (NPTL to be exact, don't
know the details, but it was discussed here earlier) which vdr doesn't
handle well(at least with dxr3, it seems). Now the cutting works,
although the frames are not updated when pressing 7 or 9, and only
occasionally with 4 and 6, so tuning the cut points is a bit of
guess-and-try at the moment... Any solutions to this?

Best Regards,

Timo

Ist das evtl. die Lösung für dein Problem?

Bye.

Hello, sorry if this is a faq but I cant seem to find the answer. After upgrading to 0.5.0 the keymap changed so that there's nomore VDRButtonRed = ... etc in my .xine/keymap. Instead there's some vdr-stuff atleast in xine-ui's actions.h. So as a result I can't anymore control vdr from the keyboard (change channels, select red,green etc), only the menucommands (from KP) work.

I tried copying the old keymap back to it's place but it keeps getting over-written by xine. Any hints on this one?

Another thing is what version of xine this vdr-xine-0.5.0 is against? I'm asking because the patches included won't apply cleanly to current cvs or to the cvs-20040826230000. Looks like some stuff is already in xine-ui so a patch wont be needed?

Against cvs-20040826230000:
[13:18:39] (a) #patch -d. -p0 < ../VDR/PLUGINS/src/xine/patches/xine-lib.patch
patching file xine-lib/configure.ac
Hunk #1 succeeded at 2048 (offset -51 lines).
Hunk #3 succeeded at 2252 (offset -51 lines).
patching file xine-lib/include/xine.h.in
patching file xine-lib/src/Makefile.am
patching file xine-lib/src/vdr/Makefile.am
patching file xine-lib/src/vdr/input/Makefile.am
patching file xine-lib/src/vdr/input/input_vdr.c
patching file xine-lib/src/vdr/input/input_vdr.h
patching file xine-lib/src/vdr/post/Makefile.am
patching file xine-lib/src/vdr/post/post_vdr.c
patching file xine-lib/src/vdr/post/post_vdr.h

[13:19:52] (a) #patch -d. -p0 < ../VDR/PLUGINS/src/xine/patches/xine-ui.patch
patching file xine-ui/src/fb/actions.c
Hunk #1 FAILED at 210.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/fb/actions.c.rej
patching file xine-ui/src/fb/actions.h
Hunk #1 FAILED at 154.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/fb/actions.h.rej
patching file xine-ui/src/xitk/kbindings.c
Hunk #1 FAILED at 438.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/xitk/kbindings.c.rej
patching file xine-ui/src/xitk/kbindings.h
Hunk #1 FAILED at 171.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/xitk/kbindings.h.rej

And against todays cvs:
[13:28:33] (a) #patch -d. -p0 < ../VDR/PLUGINS/src/xine/patches/xine-lib.patch
patching file xine-lib/configure.ac
Hunk #1 FAILED at 2099.
Hunk #2 succeeded at 2158 (offset 2 lines).
1 out of 3 hunks FAILED -- saving rejects to file xine-lib/configure.ac.rej
patching file xine-lib/include/xine.h.in
Hunk #1 succeeded at 1463 (offset 6 lines).
patching file xine-lib/src/Makefile.am
Hunk #1 succeeded at 28 (offset 1 line).
patching file xine-lib/src/vdr/Makefile.am
patching file xine-lib/src/vdr/input/Makefile.am
patching file xine-lib/src/vdr/input/input_vdr.c
patching file xine-lib/src/vdr/input/input_vdr.h
patching file xine-lib/src/vdr/post/Makefile.am
patching file xine-lib/src/vdr/post/post_vdr.c
patching file xine-lib/src/vdr/post/post_vdr.h

[13:29:58] (a) #patch -d. -p0 < ../VDR/PLUGINS/src/xine/patches/xine-ui.patch
patching file xine-ui/src/fb/actions.c
Hunk #1 FAILED at 210.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/fb/actions.c.rej
patching file xine-ui/src/fb/actions.h
Hunk #1 FAILED at 154.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/fb/actions.h.rej
patching file xine-ui/src/xitk/kbindings.c
Hunk #1 FAILED at 438.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/xitk/kbindings.c.rej
patching file xine-ui/src/xitk/kbindings.h
Hunk #1 FAILED at 171.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/xitk/kbindings.h.rej

Thanks, Tomi

Quoted

Originally posted by thauta
Hello, sorry if this is a faq but I cant seem to find the answer. After upgrading to 0.5.0 the keymap changed so that there's nomore VDRButtonRed = ... etc in my .xine/keymap. Instead there's some vdr-stuff atleast in xine-ui's actions.h. So as a result I can't anymore control vdr from the keyboard (change channels, select red,green etc), only the menucommands (from KP) work.

Hmm, I played a bit with xine-ui's source and added #define ENABLE_VDR_KEYS to actions.[ch] and kbindings.[ch]. That fixed the problem.

What is the proper method for doing this defining, an option in the Makefile or?

Tomi

Hi,

Quoted

Original von thauta
Hmm, I played a bit with xine-ui's source and added #define ENABLE_VDR_KEYS to actions.[ch] and kbindings.[ch]. That fixed the problem.

What is the proper method for doing this defining, an option in the Makefile or?

from HISTORY of the upcoming 0.5.1 release (on schedule for over 4 weeks now, but most likely this week):

- Reorganized directory structure of the xine part once again. xine-ui now
needs the configure switch "--enable-vdr-keys" to support vdr-xine's remote.

Bye.