Announce: VDR-1.4.2

Boergen · 31. August 2006

Zitat

Original von tüddelkopp
Gibt es diese Abstürze bei schlechtem Signal wirklich nur bei der 1.5er, hat das schon mal jemand mit 1.3er oder 1.6er FF Karte ausgiebig getestet ?

Meine 1.6er ist schon seit Jahren nicht mehr bei schlechtem Signal abgestürzt. Ich glaube aber, dass das eher software-/treiber- als hardwarebedingt ist.

KGM11 · 31. August 2006

Es gab irgendeine Art/Serie von FF-Karten, die ohne Satsignal instabil wurden, das hatte irgendjemand auch hier im Forum dokumentiert (komplett mit Oszi-Bildern wenn ich mich recht erinnere).

Davon abgesehen gibts die VDR- und ggf. DVB-Treiber-Neustarts, wenn bei Aufnahmen kein vernünftiger Empfang herrscht - die sind (oder waren zumindest mal) gewollt, für den Fall daß es sich doch nicht um ein Empfangs- sondern ein Software-/Treiberproblem handelt. In wie weit das mit aktuellen Treibern, Firmware, etc. noch sinnvoll/notwendig ist kann ich nicht sagen (hier läuft eine Rev. 1.3 mit Uralt-Treibern ohne irgendwelche Probleme - auch wenn wetterbedingt mal kein Empfang möglich ist).

Was anderes: Hatten wir nicht mal den Vorsatz getroffen, das Patch- und Plugingefrickel in einen separaten Thread auszulagern?

free-x · 31. August 2006

Ich hatte Erfahrung mit 1.3, 1.5 und S2300. Das trifft 1.5-er karten. Bei 1.3 gibt's nicht firmware probleme (firmware_cmd_timeout). Ich hab aber noch gehört mit 4MB-mod laufen 1.5er wesentlich stabiler

Scorp · 31. August 2006

Hi,

interessant. Anscheinend gibt es in diesem Bereich sehr unterschiedliche Erkenntnisse.

Moses123 · 1. September 2006

Hallo,

bei mir legt der vdr immer einen Neustart hin, wenn eine Aufnahme auf einem Kanal gemacht wird, der nicht aktiv ist. Die Aufnahme wird in der Regel auf einer Budget von Twinhan gemacht. Siehe z.Bsp mein Problem mit dem Technisat Infosat EPG.

Gruß,

Sascha

_Frank_ · 2. September 2006

Hallo Klaus,

hab mich ja eine Weile nicht getraut,, nochmal nachzufragen, aber scheint ja wirklich so zu sein, daß einige Plugins cStatus::MsgSetVolume() nutzen, eine kleine Ungereimtheit wäre mir da schon noch aufgefallen.

Wenn man "Stumm" schaltet, wird ja Lautstärke auf 0 gesetzt und dies absolut mitgeteilt, wenn man danach die Lautstärke über "Lauter" bzw. "Leiser" ändert, wohlgemerkt, "gemutet", wird die ursprüngliche Lautstärke + Lautstärkeänderung eingestellt, aber nur die Lautstärkeänderung über die Funktion mitgeteilt.

Theoretisch ist dies kein großes Problem, aber nun muß wieder jedes Plugin selbst mit"meiseln", welcher Wert zuvor eingestellt war. Ließe sich da evtl. noch was ändern? Sonst fand ich die ursprüngliche Lösung (nur absolut), wenn auch nicht beabsichtigt, irgendwie besser (schien weniger Rechnerei zu sein).

Gruß
Frank

FireFly · 2. September 2006

Hallo _Frank_,

nur um noch mal ganz sicher zu gehen, weil ich das Problem bisher nicht reproduzieren konnte: Steht bei Dir in der device.c in cDevice::ToggleMute wirklich zweimal
SetVolume (..., true)
drin? Das war nämlich der Fehler in der 1.4.1-2.

Grüße
FireFly

_Frank_ · 2. September 2006

Hi FireFly,

jo, zweimal, einmal im "if"- und einmal im "else"-Zweig.
War das das, was Du wissen wolltest, oder meintest Du was anderes?

[edit] hab auch nochmal ins original-archiv geschaut, dort steht es auch so, das Problem ist auch nicht das "Mute" bzw. "Unmute", sondern das Ändern der Lautstärke, wenn zuvor "gemutet" wurde. Nach einem "Unmute" ist es auf alle Fälle wieder korrekt, da in dem Fall der Wert absolut übergeben wird[/edit]

Gruß
Frank

UFO · 2. September 2006

Vielleicht noch mal das Problem im Klartext:
1. Mute -> SetVolume() meldet Lautstärke 0 (absolut)
2. Lautstärke+ -> SetVolume() meldet Lautstärke +5(relativ), Lautstärke wird aber in Wirklichkeit auf "letzter Wert vor Mute" +5 gesetzt.

@Klaus:
Ist dies so beabsichtigt?

Eigentlich wollte ich remote-0.3.8 announcen. Werde es jedoch aufschieben, bis klar ist, wie das SetVolume()-Verhalten endgültig sein wird...

CU
Oliver

FireFly · 2. September 2006

Zitat

Original von _Frank_
jo, zweimal, einmal im "if"- und einmal im "else"-Zweig.
War das das, was Du wissen wolltest, oder meintest Du was anderes?

ja, genau das meinte ich

Zitat

[edit] hab auch nochmal ins original-archiv geschaut, dort steht es auch so, das Problem ist auch nicht das "Mute" bzw. "Unmute", sondern das Ändern der Lautstärke, wenn zuvor "gemutet" wurde. Nach einem "Unmute" ist es auf alle Fälle wieder korrekt, da in dem Fall der Wert absolut übergeben wird[/edit]

Hmm, genau das kann ich nicht reproduzieren ....
Haut da vielleicht irgend ein Patch rein?
Hast Du mal Debug-Ausgabe eingebaut?

FireFly

kls · 3. September 2006

Zitat

Originally posted by UFO
Vielleicht noch mal das Problem im Klartext:
1. Mute -> SetVolume() meldet Lautstärke 0 (absolut)
2. Lautstärke+ -> SetVolume() meldet Lautstärke +5(relativ), Lautstärke wird aber in Wirklichkeit auf "letzter Wert vor Mute" +5 gesetzt.

@Klaus:
Ist dies so beabsichtigt?

Alles anzeigen

Ich denke nicht.
Versuch's mal hiermit:

Diff

--- device.c    2006/08/26 14:11:03     1.136
+++ device.c    2006/09/03 10:13:25
@@ -779,6 +779,7 @@
   int OldVolume = volume;
   volume = min(max(Absolute ? Volume : volume + Volume, 0), MAXVOLUME);
   SetVolumeDevice(volume);
+  Absolute |= mute;
   cStatus::MsgSetVolume(Absolute ? volume : volume - OldVolume, Absolute);
   if (volume > 0) {
      mute = false;

Falls es damit funktioniert würde ich das noch in den heutigen Maintenance-Patch einbauen.

Klaus

kls · 3. September 2006

Zitat

Originally posted by _Frank_
...
Wenn man "Stumm" schaltet, wird ja Lautstärke auf 0 gesetzt und dies absolut mitgeteilt, wenn man danach die Lautstärke über "Lauter" bzw. "Leiser" ändert, wohlgemerkt, "gemutet", wird die ursprüngliche Lautstärke + Lautstärkeänderung eingestellt, aber nur die Lautstärkeänderung über die Funktion mitgeteilt.

Siehe meine Antwort auf Olivers Posting.

Falls du für diesen Bugreport in VDR/CONTRIBUTORS eingetragen werden willst, dann bräuchte ich deinen richtigen Namen und Email-Adresse - ansonsten trage ich Oliver ein

Klaus

UFO · 3. September 2006

Zitat

Original von kls

Ich denke nicht.
Versuch's mal hiermit:

Diff

--- device.c    2006/08/26 14:11:03     1.136
+++ device.c    2006/09/03 10:13:25
@@ -779,6 +779,7 @@
   int OldVolume = volume;
   volume = min(max(Absolute ? Volume : volume + Volume, 0), MAXVOLUME);
   SetVolumeDevice(volume);
+  Absolute |= mute;
   cStatus::MsgSetVolume(Absolute ? volume : volume - OldVolume, Absolute);
   if (volume > 0) {
      mute = false;

Falls es damit funktioniert würde ich das noch in den heutigen Maintenance-Patch einbauen.

Alles anzeigen

Danke, so klappt's einwandfrei.

CU
Oliver

viking · 3. September 2006

Hallo,

vieleicht ist es hier nicht der richtige ort, aber vieleicht doch, es geht ja ums kompilieren von VDR.

ich wollte jetzt auf kernel 2.6.17 wechseln kriege aber VDR nicht mit neueren V4L (aus HG) kompiliert !?

HG vom 20060726 und heute (20060903) klappt beides nicht !?
Wenn ich die version vom 20060216 was ich bisher genutzt habe dann klappt es.
Hier die fehlermeldung aus den neueren treibern :

Code

g++ -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD -DREMOTE_LIRC -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\" -DVFAT  -I/usr/local/src/DVB/include dvbdevice.c
dvbdevice.c: In member function `virtual uchar* cDvbDevice::GrabImage(int&,
   bool, int, int, int)':
dvbdevice.c:539: error: aggregate `video_mbuf mbuf' has incomplete type and
   cannot be defined
dvbdevice.c:540: error: `VIDIOCGMBUF' undeclared (first use this function)
dvbdevice.c:540: error: (Each undeclared identifier is reported only once for
   each function it appears in.)
dvbdevice.c:545: error: aggregate `video_capability vc' has incomplete type and
   cannot be defined
dvbdevice.c:546: error: `VIDIOCGCAP' undeclared (first use this function)
dvbdevice.c:547: error: aggregate `video_mmap vm' has incomplete type and
   cannot be defined
dvbdevice.c:558: error: `VIDEO_PALETTE_RGB24' undeclared (first use this
   function)
dvbdevice.c:559: error: `VIDIOCMCAPTURE' undeclared (first use this function)
dvbdevice.c:559: error: `VIDIOCSYNC' undeclared (first use this function)

Alles anzeigen

Hat jemand eine idee was das sein könnte ?

Danke

Gruß
Viking

viking · 3. September 2006

Hallo noch mal,

antworte mal selber. Leider scheint es nicht so gut auszusehen :
http://www.linuxtv.org/pipermail/vdr/2006-July/010224.html

Welche version ist der letzte der mit VDR 1.4 noch geht ? Und wie kriegt man ältere versionen raus mit hg ?

EDIT: kann man eigentlich die alte noch funktionierende verion (20060216) nutzen zum kompilieren und dann die neueren 20060903 nutzen für's den betrieb ? Scheint zumindest auf dem ersten blick zu gehen aber funktioniert das auch im täglichen Produktionsbetrieb ?

Gruß
Viking

Dr. Seltsam · 3. September 2006

ich verwende fast tagesaktuelle hg-Treiber und kann trotzdem aktuelle vdr-Versionen kompilieren.
Allerdings das eine in Ubuntu und das andere unter woody

Unter woody habe ich schon seit Ewigkeiten parallel zu vdr (also in /usr/local/src/DVB) einen dvb-kernel-Ordner von 02/2006. Einige header davon hatte ich glaube ich noch in /usr/include/linux kopiert, weil woody nun gar zu alt war.

Mach das doch auch so. Die hg-Treiber, Die du wirklich verwendest, können ja in jedem beliebigen Ordner entpackt und kompiliert werden.

Dr. Seltsam · 3. September 2006

siehste, bist schon selbst drauf gekommen
bei mir klappt das seit Monaten problemlos

kls · 3. September 2006

Zitat

Originally posted by viking
...
ich wollte jetzt auf kernel 2.6.17 wechseln kriege aber VDR nicht mit neueren V4L (aus HG) kompiliert !?

Es gibt eine Config-Option VIDEO_V4L1_COMPAT.
Setz' die mal auf 'y', vielleicht geht es ja dann.

Ich hab's bisher noch nicht geschafft, den aktuellen Treiber aus dem Hg überhaupt zu übersetzen. Ich bekomme da

Code

CC [M]  /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.o
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function 'snd_bt87x_create_risc':
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:191: error: dereferencing pointer to incomplete type
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function 'snd_bt87x_interrupt':
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:303: warning: passing argument 1 of 'snd_pcm_period_elapsed' from incompatible pointer type
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: At top level:
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:308: error: variable 'snd_bt87x_digital_hw' has initializer but incomplete type

und dann geht's ellenlang so weiter.

Leider habe ich auf meine diesbezügliche Anfrage auf der Treiber-ML noch keine Antwort erhalten. Vielleicht ist ja mein Kernel 2.6.13 schon wieder aus der "Steinzeit"...

Klaus

FireFly · 3. September 2006

Ich hatte vor ca. 3 Wochen auch Probleme mit dem Kompilieren der hg-Treiber und zwar wollte er die Treiber für EM28xx nicht kompilieren. Da ich die aber eh nicht brauche habe ich sie kurzerhand in v4l/.myconfig herauskonfiguriert:

Code

CONFIG_VIDEO_EM28XX   := m  geändert in:
CONFIG_VIDEO_EM28XX   := n

Ok, das ist nicht ganz sauber, aber für meine Zwecke genügts

FireFly
PS: habe auch immer noch den "Steinzeit"-Kernel 2.6.13-15.11 von SuSE 10.0 ...

UFO · 3. September 2006

Zitat
Original von kls
Ich hab's bisher noch nicht geschafft, den aktuellen Treiber aus dem Hg überhaupt zu übersetzen. Ich bekomme da
Code
CC [M]  /home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.o
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function 'snd_bt87x_create_risc':
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:191: error: dereferencing pointer to incomplete type
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: In function 'snd_bt87x_interrupt':
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:303: warning: passing argument 1 of 'snd_pcm_period_elapsed' from incompatible pointer type
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c: At top level:
/home/kls/vdr/v4l-dvb-7a0daff8ed2c/v4l/bt87x.c:308: error: variable 'snd_bt87x_digital_hw' has initializer but incomplete type
und dann geht's ellenlang so weiter.

Leider habe ich auf meine diesbezügliche Anfrage auf der Treiber-ML noch keine Antwort erhalten. Vielleicht ist ja mein Kernel 2.6.13 schon wieder aus der "Steinzeit"...
Klaus
Alles anzeigen

Du brauchst doch sicher keinen bt87x-Treiber, oder? Wähle doch einfach den ganzen Quatsch ab.
Einmalig:
- make menuconfig
- Konfiguration auswählen/speichern
- Treiber bauen
Wenn alles tut, .config sichern.

Nach jedem Treiberupdate die gesicherte .config einfach ins Treiberverzeichnis kopieren. Sollte funktionieren, bis wieder jemand etwas Entscheidendes am Build-System ändert. Dann halt wieder nach demselben Schema.

Ich baue/teste nur noch Treiber für Karten, die ich besitze. Habe einfach keine Lust mehr, meine Zeit mit irgendwelchen Build-Problemen totzuschlagen, die irgend so ein Schlaumeier verbrochen hat...

CU
Oliver

P.S.:
Hat natürlich auch den angenehmen Nebeneffekt, daß das Treiberbauen sehr schnell erledigt ist.

Announce: VDR-1.4.2

Jetzt mitmachen!

Teilen