[ANNOUNCE] VDR developer version 1.7.23

Kann das sein, dass bei 1.7.23 irgendwas im Start-Up-Prozess verschlimmbessert wurde?

Mein /var/log/messages:

Feb 11 00:00:06 localhost ntpd[2077]: Listen normally on 2 wlan0 192.168.109.111 UDP 123


Feb 11 00:00:06 localhost ntpd[2077]: peers refreshed


Feb 11 00:00:08 localhost vdr: [2475] max. latency time 1 seconds


Feb 11 00:00:08 localhost ntpd_intres[2079]: DNS 0.gentoo.pool.ntp.org -> 46.166.157.106


Feb 11 00:00:08 localhost ntpd_intres[2079]: DNS 1.gentoo.pool.ntp.org -> 87.106.21.237


Feb 11 00:00:09 localhost ntpd_intres[2079]: DNS 2.gentoo.pool.ntp.org -> 31.19.136.176


Feb 11 00:00:09 localhost ntpd_intres[2079]: DNS 3.gentoo.pool.ntp.org -> 80.237.238.143


Feb 11 00:00:09 localhost /etc/init.d/local[1767]: local: waiting for vdr (50 seconds)


Feb 11 00:00:18 localhost /etc/init.d/local[1767]: local: waiting for vdr (41 seconds)


Feb 11 00:00:27 localhost /etc/init.d/local[1767]: local: waiting for vdr (32 seconds)


Feb 11 00:00:36 localhost /etc/init.d/local[1767]: local: waiting for vdr (23 seconds)


Feb 11 00:00:39 localhost /etc/init.d/vdr[2882]: VDR errors from /var/log/messages:


Feb 11 00:00:39 localhost /etc/init.d/vdr[2883]:   Feb 10 23:59:59 localhost vdr: [2504] [discovery]    (ERROR (tools/vdrdiscovery.c,97): Das Netzwerk ist nicht erreichbar)


Feb 11 00:00:39 localhost start-stop-daemon: pam_unix(start-stop-daemon:session): session opened for user nobody by (uid=0)


Feb 11 00:00:39 localhost vdrwatchdog[2890]: Starting vdrwatchdog


Feb 11 00:00:39 localhost login[2902]: pam_unix(login:session): session opened for user xbmc by LOGIN(uid=0)


Feb 11 00:00:42 localhost kernel: [   50.364371] cx23885_wakeup: 2 buffers handled (should be 1)


Feb 11 00:00:42 localhost acpid: client connected from 2936[0:27]


Feb 11 00:00:42 localhost acpid: 1 client rule loaded


Feb 11 00:00:42 localhost kernel: [   50.720618] HDMI hot plug event: Codec=1 Pin=5 Presence_Detect=1 ELD_Valid=0

Distribution ist Gentoo. Kernel sollte halbwegs aktuell sein (3.2.5). Diese 30 Sekunden Wartezeit hatte ich bei 1.7.21 irgendwie nicht.

Schau doch mal ins VDR Log *) was der da die ganze Zeit macht.

cu

*) VDR Kommandozeile "-l 3.3", dann landen alle VDR Logmeldungen im Kanal 3. Benutzt du rsyslog kannst du die dann per
---
local3.* /var/log/vdr/vdr.log
local3.* ~
---
in ein extra Logfile lenken. Alles andere (da versuchen ohne Logs auszukommen) ist sinnlose Raterei.

Zitat von johns

Passt zwar nicht zum Announce, aber ich habe keinen besseren Platz gefunden.

Ich glaube ich habe einen Bug:

cDevice:: SetVideoDisplayFormat wird nur beim Kanalwechsel aufgerufen.

Das ist so nicht ganz richtig. Es wird aufgerufen, wenn ein cPlayer sich beim Ausgabedevice abmeldet, um wieder das Default-Format für den Live-Modus einzustellen.

Zitat

Beim ersten Kanal kommt nichts.

Es wird nur von cDevice::Detach aufgerufen, ich würde ja vermuten es sollte in cDevice::AttachPlayer

Die Anfangs-Einstellung erfolgt im Konstruktor von cDvbSdFfDevice durch den Aufruf von

SetVideoFormat(Setup.VideoFormat);

Klaus

Gut wenn ich aber kein FF Device habe, gibt es auch kein Setup.

Da ich ein Software Device schreibe, dann vermute ich es soll dann in meinen Konstruktor aufrufen werden.

Johns

Zitat von johns

Gut wenn ich aber kein FF Device habe, gibt es auch kein Setup.

Da ich ein Software Device schreibe, dann vermute ich es soll dann in meinen Konstruktor aufrufen werden.

Hmmm, dieser Parameter ist zwar ursprünglich wegen der FF-DVB-Karte reingekommen, aber da er ganz allgemeiner Natur ist wäre es vielleicht sogar sinnvoll, den Aufruf von SetVideoFormat(Setup.VideoFormat) für das Ausgabedevice in vdr.c unter "// Primary device:" zu machen. Dann würde das für alle Arten von Ausgabedevices passieren.
Wäre das OK?

Klaus

Zitat von kls

Hmmm, dieser Parameter ist zwar ursprünglich wegen der FF-DVB-Karte reingekommen, aber da er ganz allgemeiner Natur ist wäre es vielleicht sogar sinnvoll, den Aufruf von SetVideoFormat(Setup.VideoFormat) für das Ausgabedevice in vdr.c unter "// Primary device:" zu machen. Dann würde das für alle Arten von Ausgabedevices passieren.

Tja, und wie ich mir das etwas näher anschaue sehe ich, daß in cDevice::SetPrimaryDevice() ja eh schon

primaryDevice->SetVideoFormat(Setup.VideoFormat);

gemacht wird. Somit wird es beim Programmstart aufgerufen.

Bleibt lediglich die Erkenntnis, daß die Aufrufe von SetVideoFormat() in den jeweiligen Konstruktoren überflüssig sind. Ich werde diese daher entfernen.

Klaus

Mir geht es um: SetVideoDisplayFormat(eVideoDisplayFormat(Setup.VideoDisplayFormat));

Johns

Zitat von johns

Mir geht es um: SetVideoDisplayFormat(eVideoDisplayFormat(Setup.VideoDisplayFormat));

Sorry, da hab' ich wohl nicht genau genug hingeschaut und das "Display" überlesen

Das wird von cDvbSdFfDevice::SetVideoFormat() aufgerufen:

void cDvbSdFfDevice::SetVideoFormat(bool VideoFormat16_9)
{
  CHECK(ioctl(fd_video, VIDEO_SET_FORMAT, VideoFormat16_9 ? VIDEO_FORMAT_16_9 : VIDEO_FORMAT_4_3));
  SetVideoDisplayFormat(eVideoDisplayFormat(Setup.VideoDisplayFormat));
}

In deinem Software-Device wäre es wohl am besten, du implementierst SetVideoFormat() und rufst da drin SetVideoDisplayFormat() auf.

Klaus

Zitat von Keine_Ahnung

Schau doch mal ins VDR Log *) was der da die ganze Zeit macht.

Ich hab jetzt erstmal einige Zeit gebraucht, mich in das Loggingverhalten mit rsyslog auseinanderzusetzen, was nicht wirklich notwendig war. Ich hab syslog im Einsatz. Und der Fehler, weshalb sich vdr soviel Zeit lässt, stand auch schon im Log mit drin.

Feb 15 19:36:57 localhost /etc/init.d/local[1767]: local: waiting for vdr (50 seconds)
Feb 15 19:37:00 localhost kernel: [   19.272370] wlan0: deauthenticated from 00:24:fe:a8:38:6c (Reason: 2)
Feb 15 19:37:00 localhost wpa_cli: interface wlan0 DISCONNECTED
Feb 15 19:37:00 localhost wpa_cli: executing 'false /etc/init.d/net.wlan0 --quiet stop' failed
Feb 15 19:37:00 localhost kernel: [   19.368659] cfg80211: Calling CRDA to update world regulatory domain
Feb 15 19:37:01 localhost kernel: [   20.557160] wlan0: authenticate with 00:24:fe:a8:38:6c (try 1)
Feb 15 19:37:01 localhost kernel: [   20.561398] wlan0: authenticated
Feb 15 19:37:01 localhost kernel: [   20.580004] wlan0: associate with 00:24:fe:a8:38:6c (try 1)
Feb 15 19:37:01 localhost kernel: [   20.584223] wlan0: RX ReassocResp from 00:24:fe:a8:38:6c (capab=0x431 status=0 aid=1)
Feb 15 19:37:01 localhost kernel: [   20.584231] wlan0: associated
Feb 15 19:37:01 localhost wpa_cli: interface wlan0 CONNECTED
Feb 15 19:37:01 localhost wpa_cli: executing '/etc/init.d/net.wlan0 --quiet start' failed
Feb 15 19:37:02 localhost ntpd_intres[2062]: DNS 0.gentoo.pool.ntp.org -> 31.19.224.115
Feb 15 19:37:03 localhost ntpd_intres[2062]: DNS 1.gentoo.pool.ntp.org -> 188.138.107.156
Feb 15 19:37:03 localhost ntpd_intres[2062]: DNS 2.gentoo.pool.ntp.org -> 178.63.143.169
Feb 15 19:37:03 localhost ntpd_intres[2062]: DNS 3.gentoo.pool.ntp.org -> 131.188.3.222
Feb 15 19:37:06 localhost /etc/init.d/local[1767]: local: waiting for vdr (41 seconds)
Feb 15 19:37:15 localhost /etc/init.d/local[1767]: local: waiting for vdr (32 seconds)
Feb 15 19:37:24 localhost /etc/init.d/local[1767]: local: waiting for vdr (23 seconds)
Feb 15 19:37:28 localhost /etc/init.d/vdr[2899]: VDR errors from /var/log/messages:
Feb 15 19:37:28 localhost /etc/init.d/vdr[2900]:   Feb 15 19:36:48 localhost vdr: [2511] [discovery]	(ERROR (tools/vdrdiscovery.c,97): Das Netzwerk ist nicht erreichbar)

Oder die Erkärung dazu:
Mein Wlan startet, braucht aber für die Authentifizierung einige Zeit. VDR startet erst, wenn die Netzverbindung funktioniert. Wieso braucht VDR Internet beim Start? Kann ich das irgendwo abstellen?

Zitat von musv

Mein Wlan startet, braucht aber für die Authentifizierung einige Zeit. VDR startet erst, wenn die Netzverbindung funktioniert. Wieso braucht VDR Internet beim Start? Kann ich das irgendwo abstellen?

Das hat nix mit dem VDR zu tun. Vermutlich liegt das an den Abhängigkeiten deiner Init Scripte (also ist ein Problem deiner Distribution). Schau mal ins VDR Initscript, evtl. ist unter "Required-Start:" eine Abhängigkeit vom Netz.

cu

Ich das Problem wieder festgestellt. Kann das jemand bestätigen? ich habe jetzt erst alles neu aufgesetzt., es könnte also auch noch an Anderem liegen. Am Server funktioniert das Plugin.

Meine Versionen:
media-plugins/vdr-femon-1.7.13
media-plugins/vdr-xineliboutput-9999 (von vor ca. 7 Tagen)
und aktuelle Versionen von http://vdr.schmirler.de/

Edit:
Sorry, der SVDRP-Port war falsch gesetzt. Jetzt funktioniert das Plugin, doch die Signalbalken beim Umschalten im OSD kommen nicht.

@ musv

Du bist hier im falschen tread,
deine localen probleme haben nix mit dem ankündigungstread zu tun

Ich will dir trotzdem kurz Antworten

vdr brauch zumindestens net.lo um den svdrp service handeln zu können --> überprüfen ob net.lo gestartet
tools/vdrdiscovery.c kommt imho vom xineliboutput plugin, da scheint deine plugin configuration fuer das netzwerk nicht zu stimmen

Bitte weitere Fragen/Anworten in

http://www.vdr-portal.de/board…iebssystem/board56-gentoo

Da kann deinem Problem distributions abhängiger eher geholfen werden.

Cheers

/bin/joerg