vdr start zu schnell, sogar für lokale mounts, ein wenig grundsätzlich

FJe · 27. November 2013

moin,

auch bei mir: vdr & frontend (xineliboutput) startet zu früh,
nämlich bevor die video-partition auf 2. HD gemountet ist.
Man merkt es auch beim Starten wenn der TV an ist, es kommen sehr schnell Bild&Ton für 1sec,
dann restartet das FE und nach 3 sec. ist dan Ton&Bild stabil da.

Die Lösungen mit dem sleep usw. sind eher Kandidaten für die permenente Pflege (neue / zus. Plugins,
dann geht es evt. schon nicht mehr so richtig oder ist überflüssig), darum wollte ich nach meinen
Jugend-forscht-Ansätzen mal folgendes zur Diskussion stellen.

Man sieht man am log, dass vdr vor mounts startet:

Code

Nov 24 15:30:25 yvsz kernel: [	4.702419] init: vdr-frontend main process (1063) terminated with status 252
Nov 24 15:30:25 yvsz kernel: [	4.702443] init: vdr-frontend main process ended, respawning
Nov 24 15:30:25 yvsz kernel: [	4.726237] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
                                        	#####################################
Nov 24 15:30:25 yvsz kernel: [	4.733200] init: vdr-frontend main process (1071) terminated with status 252
Nov 24 15:30:25 yvsz kernel: [	4.733225] init: vdr-frontend main process ended, respawning
Nov 24 15:30:25 yvsz kernel: [	4.755998] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
Nov 24 15:30:25 yvsz kernel: [	4.756731] SGI XFS Quota Management subsystem
Nov 24 15:30:25 yvsz kernel: [	4.757268] XFS (sda3): Mounting Filesystem
                                        	#####################################
Nov 24 15:30:25 yvsz kernel: [	4.765870] init: vdr-frontend main process (1091) terminated with status 252
Nov 24 15:30:25 yvsz kernel: [	4.765893] init: vdr-frontend main process ended, respawning
Nov 24 15:30:25 yvsz kernel: [	4.796521] init: vdr-frontend main process (1110) terminated with status 252
Nov 24 15:30:25 yvsz kernel: [	4.796547] init: vdr-frontend main process ended, respawning
Nov 24 15:30:25 yvsz kernel: [	4.797171] XFS (sda3): Ending clean mount
Nov 24 15:30:25 yvsz kernel: [	4.801131] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
Nov 24 15:30:25 yvsz kernel: [	4.803501] XFS (sdb7): Mounting Filesystem
                                        	#####################################
Nov 24 15:30:25 yvsz kernel: [	4.828270] init: vdr-frontend main process (1123) terminated with status 252
Nov 24 15:30:25 yvsz kernel: [	4.828295] init: vdr-frontend respawning too fast, stopped
Nov 24 15:30:25 yvsz kernel: [	5.063179] XFS (sdb7): Ending clean mount
Nov 24 15:30:25 yvsz kernel: [	5.083479] RPC: Registered named UNIX socket transport module.

Alles anzeigen

Im vdr-frontend.conf im upstart wird das fe nach vdr, openbox und sound gestartet:

Code

start on started vdr or stopped openbox-tools or started sound-device \
     	or vdr-frontend-restart
stop on stopping vdr or stopping openbox

ich würde das gerne ergänzen (templated natürlich) durch das filesystems statement, damit er erst die mounts der fstab abwartet.
Als autodidaktischer Diletant, komplett frei von upstart-Wissen, wollte ich die Profis fragen, wie der start-TEil richtig wäre.
Aus anderen conf'S hab ich mal diese Varianten im Angebot, welche startet sicher und tut, was sie soll?

Code

start on (filesystem and \
      	(started vdr or stopped openbox-tools or started sound-device \
     	or vdr-frontend-restart))
stop on stopping vdr or stopping openbox

oder

Code

start on filesystem and \
      	(started vdr or stopped openbox-tools or started sound-device \
     	or vdr-frontend-restart)

oder

Code

start on filesystem and \
      	started vdr or stopped openbox-tools or started sound-device \
     	or vdr-frontend-restart

Eigentlich müsste die Bedingung durch stopped openbox-tools bereits erfüllt sein, da die erst nach openbox starten, das erst nach filesystems startet:

Code

start on (filesystem and \
      	started dbus and \
      	(start-xorg or stopped udevtrigger))
stop on runlevel [!2345]

Da das aber mit vdr-Start ver-"oder"t ist und der nicht auf filesystems wartet, zieht das nicht.
Daher wäre evt. auch

Code

start on (started vdr and stopped openbox-tools and started sound-device) \
     	or vdr-frontend-restart
stop on stopping vdr or stopping openbox

(also and statt or) der richtigere Befehl für das frontend?
-------###

Statt das frontend warten zu lassen, könnte man auch den vdr auf filesystems warten ölassen:
vdr.conf:

Code

start on ( (filesystems and started dbus and started udev and stopped networking) or \
       	# neu ##########
       	stopped vdr-exit-other or \
       	resume )
stop on runlevel [!2345]

Das wäre wahrscheinlich mein Favorit, weil es z.B. auch die Probleme der NAS-mounts in fstabs lösen würde,
was meint Ihr?

Und sagt nicht "probier doch einfach", das wär zu einfach

bye
Frank

seahawk1986 · 27. November 2013

Hallo,
ich bin momentan in unstable sowieso dabei dieses Upstart-Gewirr zu vereinfachen. Das mit den Mounts ist ein guter Hinweis, den Fehler hatte ich mangels seperater Platte und NFS-Mounts in der fstab auf meinen Test-Rechnern noch nie (und mein produktiv genutzer yaVDR scheint nicht schnell genug zu booten, um in den Fehler zu laufen).

Der Upstart-Job vdr-frontend braucht die Abhängigkeit zu filesystem eigentlich nicht, sondern der Upstart-Job für den VDR.

mini73 · 27. November 2013

Ja, den vdr darauf warten zu lassen ist sinnvoller, denke ich.

Lars.

FJe · 27. November 2013

Denke ich auch. Wenn Ihr mir ein upstart-statement dazu schickt, probier ich's gern.

Meine beiden VDR sind da auch unterschiedlich. Der mit der "schnellen" Samsung SSD hat das Problem nicht, der mit der "langsamen" Kingston SSD hat es. Allerdings hat der VDR mit der Kingston eine GT620, da ist der X-Server superfix oben, der braucht mit der GT430 sichtbar länger. (Darum wäre auch eine sleep-Lösung für die beiden unterschiedlich oder für beide lange.)

Bye
Frank

CKone · 27. November 2013

sind dann damit auch alle auf der sicheren Seite die jetzt nicht den Linker verwenden und klassisch /srv/vdr über fstab einlinken? - dann wäre es ja universell hilfreich

Christian

mini73 · 27. November 2013

http://upstart.ubuntu.com/cookbook/#filesystem
"filesystem" kommt, wenn alle Mounts durch sind, das betrifft ja nur die fstab, oder? Der avahi-linker hat damit eigentlich nichts zu tun (vermute ich).

Ein "filesystem and" vor das "started dbus" innerhalb der Klammer ist ok, aber "filesystem", nicht "filesystems".
Gab's das eigentlich auch schon bei Upstart 1.6? Oder braucht man Upstart 1.8 dafür?

Lars.

CKone · 27. November 2013

ok, denke du hat mich missverstanden

Zitat

die jetzt nicht den Linker verwenden

aber passt schon

Christian

mini73 · 27. November 2013

Das kann natürlich sein. Ist ja auch noch mitten am Tag, da bin ich noch nicht so fit...

Lars.

saccara · 27. November 2013

Ich finde diese Diskussion hier bzg. NAS Einbindung sehr gut. Ich habe 2003 mit meinem ersten VDR angefangen, damals hat man noch 2 bis 4 Platten verbaut um ordentlich Speicher zu bekommen Aber mittlerweile nutzen ja immer mehr ein NAS und auch SSD's etc so dass ich denke das eine saubere NFS Anbindung sicherlich viel Frust vermeidet.

Wie sieht das denn überhaupt aus, ich habe ja die letzten Jahre eine Reelbox gehabt, soweit ich das sehen kann wurde das NAS nicht mittels fstab eingebunden. Ich glaube die haben am Ende irgendein Plugin oder Script genutzt. Man braucht ja nicht zwingend eine OSD Lösung für die Anbindung. Ich denke das Augenmerk sollte wirklich darauf liegen dass die Verbindung dauerhaft stabil zustande kommt damit Timer-Aufnahmen vernünftig laufen oder nicht?

mini73 · 27. November 2013

Die hier angesprochene Lösung hat nichts mit dem OSD zu tun, sondern greift in den Bootprozess ein. Eine "OSD-Lösung" wäre auch nicht das, was ich haben wollen würde.
Keine Ahnung wie die Reelbox das gemacht hat, aber natürlich gibt es mindestens tausend Varianten und Möglichkeiten.
Ein Plugin kann ich mir nicht vorstellen, denn dann läuft der vdr ja schon. Obwohl, man kann natürlich ein Plugin schreiben, dass während der Initialisierung so lange wartet, bis ein bestimmtes Ereignis eingetreten ist, dann läuft man aber Gefahr, den vdr-Watchdog auszulösen (wenn man ihn benutzt).

Und "irgendein Script" wäre auch nichts anderes als ein upstart-Job, der den vdr-Start verzögert bzw. der vdr-Job direkt, der gewisse Warteschleifen drin hat (was auch immer die Reelbox für einen Startmechanismus benutzt hat, keine Ahnung).

Ich vermute stark, dass die oben angesprochene vdr-Job-Modifikation mit "filesystem" für die NAS-Aufnehmer mit fstab-Einträgen das richtige ist.

Lars.

FJe · 27. November 2013

Habe genau das, /srv ist auf sda3, /mnt/sdb7/video ist auf /srv/vdr/video.00 verlinkt.
Also fstab mounting, Netz geht über avahi, das beste System für Vernetzung, das ich kenne.
(Habe mein NAS avahi-fit gemacht, er exportiert ein VDR-dir, wie findet man hier im Forum)

Mit filesystem im start-on wartet der vdr auf Netz-Mount's aus der fstab.
wenn das nicht sein soll (weil dann könnte sein, dass der vdr nicht startet, wenn der Netz-Mount nicht da ist),
sollte man local-filesystems eintragen, schaut mal auf den Link von mini73, da steht ein sehr gutes Bild dazu drin.

Probiere heute Abend vdr.conf aus mit

Code

start on ( (filesystem and started dbus and started udev and stopped networking) or \
       	### neu ##########
       	stopped vdr-exit-other or \
       	resume )

Schau'n mer mal.
bye
frank

FJe · 28. November 2013

moin,

geht wie's Brezelbacken.
Der Flackereffekt ist weg, Rechner startet sehr schnell hoch,
Bild&Ton sind nach weniger als 10sec stabil da, ohne die Unterbrechung,
die sich vorher immer zeigte.

Laut log startet allerdings das frontend immer noch zu früh:

Spoiler anzeigen

Nov 28 08:31:13 yvsz kernel: [ 3.712764] snd_hda_intel 0000:01:00.1: setting latency timer to 64
Nov 28 08:31:13 yvsz kernel: [ 4.433526] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
Nov 28 08:31:13 yvsz kernel: [ 4.462263] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
Nov 28 08:31:13 yvsz kernel: [ 4.463454] SGI XFS Quota Management subsystem
Nov 28 08:31:13 yvsz kernel: [ 4.463960] XFS (sda3): Mounting Filesystem
Nov 28 08:31:13 yvsz kernel: [ 4.480991] XFS (sda3): Ending clean mount
Nov 28 08:31:13 yvsz kernel: [ 4.484678] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
Nov 28 08:31:13 yvsz kernel: [ 4.487768] XFS (sdb7): Mounting Filesystem
Nov 28 08:31:13 yvsz kernel: [ 4.529528] HDMI status: Codec=0 Pin=5 Presence_Detect=0 ELD_Valid=0
Nov 28 08:31:13 yvsz kernel: [ 4.557488] HDMI status: Codec=1 Pin=5 Presence_Detect=0 ELD_Valid=0
Nov 28 08:31:13 yvsz kernel: [ 4.581453] HDMI status: Codec=2 Pin=5 Presence_Detect=0 ELD_Valid=0
Nov 28 08:31:13 yvsz kernel: [ 4.605415] HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
Nov 28 08:31:13 yvsz kernel: [ 4.605497] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input17
Nov 28 08:31:13 yvsz kernel: [ 4.605588] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input18
Nov 28 08:31:13 yvsz kernel: [ 4.605658] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input19
Nov 28 08:31:13 yvsz kernel: [ 4.605724] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input20
Nov 28 08:31:13 yvsz kernel: [ 4.656915] init: vdr-frontend main process (1062) terminated with status 252
Nov 28 08:31:13 yvsz kernel: [ 4.656942] init: vdr-frontend main process ended, respawning
Nov 28 08:31:13 yvsz kernel: [ 4.689725] init: vdr-frontend main process (1071) terminated with status 252
Nov 28 08:31:13 yvsz kernel: [ 4.689749] init: vdr-frontend main process ended, respawning
Nov 28 08:31:13 yvsz kernel: [ 4.724538] init: vdr-frontend main process (1089) terminated with status 252
Nov 28 08:31:13 yvsz kernel: [ 4.724561] init: vdr-frontend main process ended, respawning
Nov 28 08:31:13 yvsz kernel: [ 4.741797] XFS (sdb7): Ending clean mount
Nov 28 08:31:13 yvsz kernel: [ 4.762911] RPC: Registered named UNIX socket transport module.
Nov 28 08:31:13 yvsz kernel: [ 4.762914] RPC: Registered udp transport module.
Nov 28 08:31:13 yvsz kernel: [ 4.762916] RPC: Registered tcp transport module.
Nov 28 08:31:13 yvsz kernel: [ 4.762917] RPC: Registered tcp NFSv4.1 backchannel transport module.
Nov 28 08:31:13 yvsz kernel: [ 4.765335] FS-Cache: Loaded
Nov 28 08:31:13 yvsz kernel: [ 4.773031] FS-Cache: Netfs 'nfs' registered for caching
Nov 28 08:31:13 yvsz kernel: [ 4.776649] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Nov 28 08:31:13 yvsz kernel: [ 4.780498] input: eventlircd as /devices/virtual/input/input21
Nov 28 08:31:13 yvsz kernel: [ 4.784856] init: vdr-frontend main process (1098) terminated with status 252
Nov 28 08:31:13 yvsz kernel: [ 4.784880] init: vdr-frontend main process ended, respawning
Nov 28 08:31:13 yvsz kernel: [ 4.793831] init: irexec main process (1133) terminated with status 1
Nov 28 08:31:13 yvsz kernel: [ 4.793856] init: irexec main process ended, respawning
Nov 28 08:31:13 yvsz kernel: [ 4.854255] init: vdr-frontend main process (1174) terminated with status 252
Nov 28 08:31:13 yvsz kernel: [ 4.854283] init: vdr-frontend main process ended, respawning
Nov 28 08:31:13 yvsz vdr: [1188] VDR version 2.0.3 started
Nov 28 08:31:13 yvsz vdr: [1188] switched to user 'vdr'
Nov 28 08:31:13 yvsz vdr: [1188] codeset is 'UTF-8' - known
Nov 28 08:31:14 yvsz vdr: [1188] found 28 locales in /usr/share/locale
Nov 28 08:31:14 yvsz vdr: [1188] loading plugin: /usr/lib/vdr/plugins/libvdr-xineliboutput.so.2.0.0
Nov 28 08:31:14 yvsz vdr: [1188] [xine..put] Listening on address '127.0.0.1' port 37890
Nov 28 08:31:14 yvsz vdr: [1188] loading plugin: /usr/lib/vdr/plugins/libvdr-dbus2vdr.so.2.0.0

Zumindest gibt es Kontaktversuchsmeldungen (5* 252er Meldung, aller kein terminating wie vorher) bevor der VDR log-Einträge liefert.
Mir scheint, der upstart-job vdr.conf meldet "startet", aber der vdr-daemon braucht natürlich Zeit,
bis er xineliboutput-kontakt-fähig ist, aber das frontend startet schon wg. des "started" des
upstart-scriptes.
Is nich schlimm, nur bei vielen Plugins und vielen Aufnahmen könnte das dauern.
Ein sleep 1 vor dem exit im vdr.con evt.?

Code

export HOME=/var/lib/vdr


exec $DAEMON -v $VIDEO_DIR -c $CFG_DIR -L $PLUGIN_DIR -r $REC_CMD -s $VDRSHUTDOWN -E $EPG_FILE -u $USER -g /tmp --port $SVDRP_PORT $OPTIONS "${PLUGINS[@]}" $REDIRECT 
sleep 1
## neu ##
end script

Oder andere start-bedingungen für das frontend?

Danke jedenfalls für Eure Inputs, startet jetzt viel angenehmer und
sollte auch eine Lösung sein für alle, die ein Netz-Laufwerk in der fstab mounten..

Bye
Frank

mini73 · 28. November 2013

"Eigentlich" (TM) darf vdr-frontend gar nicht vor dem vdr starten. Wie sieht /etc/init/vdr-frontend.conf aktuell bei dir aus?

Lars.

seahawk1986 · 28. November 2013

Und schau mal in die /var/log/upstart/vdr-frontend.log (da sieht man z.B. wenn das wait-for-job-state nicht klappt, das wir hoffentlich bald loswerden)

FJe · 28. November 2013

Die ganz normale Standard vdr-frontend.conf von yavdr.
Startet mit

Code

start on started vdr or stopped openbox-tools or started sound-device \
     	or vdr-frontend-restart
stop on stopping vdr or stopping openbox

Meine These:
vdr.conf-script startet daemon und beendet sich
=> Meldung vdr startet wird getriggert und frontend kriegt signal
=> frontend startet
parallel fährt vdr hoch, braucht aber Zeit zum Laden des plugins für frontend,
daher erst dann der Kontakt möglich (was wohl nach start frontend ist
=> frontend braucht start-signal erst, wenn auch plugin geladen und kontaktfreudig.

bye
Frank

FJe · 28. November 2013

hier die frontend.log:

Leider keine Zeitmarken drin, daher hab ich meine Vermutungen eingefügt.

Er wartet erst 5-mal auf dbus-Verbindung zum VDR, dann noch einmal ein wait-for-job-state.
bye
frank

Code

vo_vdpau: disable noise reduction.
vdpau_set_property: property=4, value=128
vdpau_set_property: property=1, value=0
#
#### hier wurde wohl das frontend beendet, nächste Zeilen sind Meldung vom Reboot ##########
#### Es folgen die fünf Versuche, die man auch im syslog findet (252 respawn Meldungen #######
#
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
vdr-sxfe 1.0.90-cvs  (build with xine-lib 1.2.2, using xine-lib 1.2.2)


Post plugins: tvtime:method=use_vo_driver
Automatic reconnection enabled
Audio driver: alsa
Error opening display
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
vdr-sxfe 1.0.90-cvs  (build with xine-lib 1.2.2, using xine-lib 1.2.2)


Post plugins: tvtime:method=use_vo_driver
Automatic reconnection enabled
Audio driver: alsa
Error opening display
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
vdr-sxfe 1.0.90-cvs  (build with xine-lib 1.2.2, using xine-lib 1.2.2)


Post plugins: tvtime:method=use_vo_driver
Automatic reconnection enabled
Audio driver: alsa
Error opening display
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
vdr-sxfe 1.0.90-cvs  (build with xine-lib 1.2.2, using xine-lib 1.2.2)


Post plugins: tvtime:method=use_vo_driver
Automatic reconnection enabled
Audio driver: alsa
Error opening display
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
vdr-sxfe 1.0.90-cvs  (build with xine-lib 1.2.2, using xine-lib 1.2.2)


Post plugins: tvtime:method=use_vo_driver
Automatic reconnection enabled
Audio driver: alsa
Error opening display
start: You do not have permission to modify job: wait-for-job-state
start: You do not have permission to modify job: wait-for-job-state
start: You do not have permission to modify job: wait-for-job-state
vdr-sxfe 1.0.90-cvs  (build with xine-lib 1.2.2, using xine-lib 1.2.2)


Post plugins: tvtime:method=use_vo_driver
Automatic reconnection enabled
Audio driver: alsa
vo_vdpau: Use lock display synchronization for some vdpau calls
vo_vdpau: vdpau API version : 1
vo_vdpau: vdpau implementation description : NVIDIA VDPAU Driver Shared Library  319.32  Wed Jun 19 14:58:31 PDT 2013
vo_vdpau: maximum video surface size for chroma type 4:2:2 is 4096x4096
vo_vdpau: maximum video surface size for chroma type 4:2:0 is 4096x4096
vo_vdpau: maximum output surface size is 16384x16384
vo_vdpau: hold a maximum of 10 video output surfaces for reuse
vo_vdpau: using 4 output surfaces of size 1920x1080 for display queue
[?25l[?1c[9;0][?25h[?0cvdpau_set_property: property=8, value=100
vdpau_set_property: property=2, value=0
vdpau_set_property: property=3, value=128
vdpau_set_property: property=5, value=0
vdpau_set_property: property=24, value=0
vo_vdpau: disable sharpness.
vdpau_set_property: property=25, value=0
vo_vdpau: disable noise reduction.
vdpau_set_property: property=4, value=128
vdpau_set_property: property=1, value=0
vo_vdpau: deinterlace: none
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: skip_chroma = 1
vo_vdpau: background_color = 0
vdpau_set_property: property=0, value=1
vo_vdpau: deinterlace: temporal_spatial
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none
vdpau_set_property: property=0, value=1
vo_vdpau: deinterlace: temporal_spatial
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none
vdpau_set_property: property=0, value=1
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: skip_chroma = 1
vo_vdpau: background_color = 0
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none
vdpau_set_property: property=0, value=1
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: skip_chroma = 1
vo_vdpau: background_color = 0
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none
vdpau_set_property: property=0, value=1
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: skip_chroma = 1
vo_vdpau: background_color = 0
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none
vdpau_set_property: property=0, value=1
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: skip_chroma = 1
vo_vdpau: background_color = 0

Alles anzeigen

mini73 · 28. November 2013

vdr.conf liefert das "started"-Signal erst, wenn dbus2vdr das erste mal vom mainloop aufgerufen wird.
Bis dahin sollten alle Plugins vollständig initialisiert sein, sonst sind sie "defekt".

Vermutlich geht irgendwas beim Warten auf openbox oder so schief. Vielleicht hilft das frontend-Log.

Lars.

seahawk1986 · 28. November 2013

Zitat von FJe

Meine These:
vdr.conf-script startet daemon und beendet sich
=> Meldung vdr startet wird getriggert und frontend kriegt signal
=> frontend startet
parallel fährt vdr hoch, braucht aber Zeit zum Laden des plugins für frontend,
daher erst dann der Kontakt möglich (was wohl nach start frontend ist
=> frontend braucht start-signal erst, wenn auch plugin geladen und kontaktfreudig.

Alles anzeigen

Also gedacht war es so:
Der VDR startet und das dbus2vdr-Plugin setzt sobald der VDR die Mainloop erreicht ein SIGSTOP ab, das vom Upstart-Job vdr.conf als Signal erwartet wird, dass der Dienst gestartet wurde. Dadurch setzt Upstart dann das Signal "started vdr" ab.

Der vdr-frontend.conf Upstart Job hat bislang einen ziemlich verworrenen Start-Mechanismus. Er beginnt mit dem Start, wenn entweder "started vdr", "stopped openbox-tools" oder "started sound-device" erreicht wurde und soll dann mit Hilfe von wait-for-job-state.conf auf die übrigen Upstart-Jobs warten (weil man bei Upstart nicht so einfach sagen kann "Starte einfach immer dann, wenn alle Kriterien erfüllt sind", weil das z.B. nach einem Crash des VDR durch ein Plugin Probleme machen würde, da ja dann nach dem Restart des VDR nur das Signal "started vdr" gesendet wird...

Code

pre-start script


# wait for vdr, Xorg (after wm is running) and the sound devices to be loaded
start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:


start wait-for-job-state WAIT_FOR=sound-device TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:
start wait-for-job-state WAIT_FOR=openbox-tools TARGET_GOAL=stop WAIT_STATE=waiting WAITER=vdr-frontend WAIT_FOREVER=1 ||:
[...]
end script

Alles anzeigen

Zitat von FJe

Code

start: You do not have permission to modify job: wait-for-job-state
start: You do not have permission to modify job: wait-for-job-state
start: You do not have permission to modify job: wait-for-job-state

Und genau hier liegt eines der Probleme - wait-for-job-state kann offenbar nicht wie gedacht aufgerufen werden.

mini73 · 28. November 2013

Das ist ja merkwürdig. Werden die Jobs nicht als root aufgerufen?

Mach mal bitte ein "grep wait-for-job-state /etc/init/*"...

Lars.

seahawk1986 · 28. November 2013

Zitat von FJe

start: You do not have permission to modify job: wait-for-job-state
start: You do not have permission to modify job: wait-for-job-state
start: You do not have permission to modify job: wait-for-job-state

Zitat von mini73

Werden die Jobs nicht als root aufgerufen?

Mit xineliboutput und xine offenbar nicht:
https://github.com/yavdr/yavdr…_xineliboutput-01-cs-sxfe
https://github.com/yavdr/yavdr…/25_xine-03-setuidgid-vdr

Das ist ja gut gemeint (und prinzipiell sinnvoll), passt aber nicht zum Weg über wait-for-job-state, weil ja dann der ganze Upstart-Job im Kontext des Users vdr ausgeführt wird.

FJe: wie bastel- und experimentierfreudig bist du? Wenn du willst können wir das mal ausgehend von dem Stand in unstable-yavdr mit meinem neuen Ansatz, der ohne root-Rechte und wait-for-job-state auskommt probieren.

vdr start zu schnell, sogar für lokale mounts, ein wenig grundsätzlich

Jetzt mitmachen!

Teilen