[ANNOUNCE] VDR developer version 1.7.37

Zitat von kls

Vielleicht weil das etwas ganz anderes zeichnen würde als das, was gewünscht ist?

Diese komischen Ellipsen-Funktionen habe ich nie verstanden. Hat da jemand mal Bilder zu den Parametern?

Lars.

Zitat von reufer

Spricht etwas dagegen, bei LIRC nicht nur den Tasten- sondern auch den Fernbedienungsnamen zu berücksichtigen?

Ich glaube nicht. Letztlich werden ja nur Strings verglichen.
Du müsstest dafür in lirc.c in der Ecke

int count;
           char KeyName[LIRC_KEY_BUF];
           fprintf(stderr, "'%s'\n", buf);//XXX
           if (sscanf(buf, "%*x %x %29s", &count, KeyName) != 2) { // '29' in '%29s' is LIRC_KEY_BUF-1!

auch den nach dem Tastennamen kommenden Fernbedienungsnamen parsen und diesen dann am besten dem KeyName voranstellen, weil in der remote.conf

LIRC.UR-8.Ok         ok
LIRC.UR-8.Back       back
LIRC.UR-8.Left       left

wohl besser aussieht als

LIRC.Ok.UR-8         ok
LIRC.Back.UR-8       back
LIRC.Left.UR-8       left

(obwohl es genau genommen natürlich egal ist).

Klaus

Zitat von mini73

Diese komischen Ellipsen-Funktionen...

Wieso "komisch"?

Zitat

...habe ich nie verstanden. Hat da jemand mal Bilder zu den Parametern?

Anbei ein Bild, das alle Möglichkeiten zeigt (bis auf den Vollkreis).
Das grüne Rechteck ist jeweils das, was mit den Koordinaten angegeben wird.
Das rote Objekt ist das jeweilige Kreissegment, hier zur Verdeutlichung um ringsum ein Pixel kleiner dargestellt als das grüne Rechteck.

Klaus

Moin!

Zitat von kls

Anbei ein Bild, das alle Möglichkeiten zeigt (bis auf den Vollkreis).

Vielen Dank, jetzt ist es mir klar geworden, was die negativen Indizes sollen.

"Komisch" im Sinne der Parameter. Sieht man sonst nirgendwo, dass man nur einen bestimmten Quadranten zeichen lassen kann. Meistens gibt es einen Start- und einen Endwinkel.
Aber ich verstehe die Intention und Realisierbarkeit hinter diesem Parameter.

Lars.

Danke für die neue Version!
Ich hätte da noch einen kleinen Featurewunsch:
Wenn im System mehrere Tuner verbaut sind, aber nicht alle an ein LNB
angeschlossen sind, wäre es nett, wenn man im Menü einstellen kann,
wieviele Tuner verwendet werden sollen. Ich hab die Option nur in der
Kommandozeile. Oder geht das schon, und ich hab's übersehen?

Zitat von Mase

Ich hätte da noch einen kleinen Featurewunsch:
Wenn im System mehrere Tuner verbaut sind, aber nicht alle an ein LNB
angeschlossen sind, wäre es nett, wenn man im Menü einstellen kann,
wieviele Tuner verwendet werden sollen. Ich hab die Option nur in der
Kommandozeile. Oder geht das schon, und ich hab's übersehen?

Für die Version 2.0 wird es keine neuen Features mehr geben.
Irgendwann muß mal Schluß sein

Klaus

Dank für die neue Version.
Alle meine Plugins funktionieren wider auf Anhieb.
Auch wenn ich noch die alten Makefiles nutze.
Ich wünsche mir für den VDR2.x ein Zentrales git in dem alle Plugins enthalten sind.

Zitat von kasper-ls

Ich wünsche mir für den VDR2.x ein Zentrales git in dem alle Plugins enthalten sind.

http://projects.vdr-developer.org/git/

Da sind zwar nicht alle Plugins vertreten, aber doch relativ viele. Wenn man es drauf anlegt wäre das zudem mit erträglichem Aufwand auf "alle" aufrüstbar, wenn man für die Projekte, die woanders gehostet sind, einfach einen GIT-Mirror dort ablegt.

Im Grunde gibts das ja, nur müssten die Plugin-Ersteller diese dort auch einpflegen.

http://projects.vdr-developer.org/

Ich wünsche mir das Klaus den vdr mit der Version 2.0 unter
http://projects.vdr-developer.org/
bereitstellt. So richtig schön mit redmine bugtracker (Tickets) usw.
Ich fände es schön wenn es darüber eine zentralle Stelle gibt wo man die Entwicklung verfolgen kann, Bugs und Feature Request posten kann.
Derzeit wird meines Wissens dafür hier das Forum und die Mailingliste verwendet, funktioniert zwar aber meiner Meinung nach nicht ganz auf dem Stand der Technik besonders wenn die Platform schon vorhanden ist und nur noch genutzt werden muss.

Vielleicht gibt es dafür ja schon Pläne oder Klaus du denkst mal darüber nach

Grüße
Martin

Einen Bereich dafür gibt es streng genommen jetzt schon. Inklusive GIT-Repo das aber nur ein Commit pro Version hat:
http://projects.vdr-developer.org/projects/vdr

Denn kenn ich und ist ja schon ein Anfang aber wie gesagt es wird nicht komplett genutzt und damit meiner Meinung nach das Potential was dahinter steckt verschenkt.

Grüße
Martin

In vielen Jahren ist mir noch nie usbremote abgestürzt.
Jetzt das:

Feb 13 21:55:42 vdr kernel: [ 6916.760568] vdr[3550]: segfault at a9 ip b6c37a40 sp acdf628c error 4 in libvdr-usbremote.so.1.7.37[b6c36000+3000]

Kann das an den Änderungen mit lirc remote liegen?
Ich frag nur, weil das so ungewöhnlich ist, und jetzt mit 1.7.37 auftritt.
Die Fernbedienung hab ich gar nicht angefasst in dem Zeitraum, war während einer Aufnahme in Abwesenheit, die dann natürlich abbrach.

Zitat von Mreimer

Einen Bereich dafür gibt es streng genommen jetzt schon. Inklusive GIT-Repo das aber nur ein Commit pro Version hat:
http://projects.vdr-developer.org/projects/vdr

Der Nachteil ist aber, dass man i.d.R. mehrere Stunden warten muss, bis eine neue VDR-Version dort verfügbar ist, weil sie eben nicht von kls dort hochgeladen wird.

Da würde ich Sonntag nachmittags ganz unruhig werden, wenn ich wüsste das eine neue VDR-Version da ist und ich könnte sie nicht ziehen

Moin!

Zitat von lostinspc

Da würde ich Sonntag nachmittags ganz unruhig werden, wenn ich wüsste das eine neue VDR-Version da ist und ich könnte sie nicht ziehen

Dafür gibt es

git-import-orig --pristine-tar ../vdr_<neue Version>.orig.tar.bz2

Damit aktualisiere ich sehr erfolgreich mein eigenes git...

Lars.

@Klaus: ich hätte mal ne Frage zum Returncode von cOsdProvider:: StoreImage():
lt. osd.h liefert StoreImage() im Fehlerfall 0 zurück (was ja von StoreImageData() kommt), aber StoreImage() kann auch -1 zurück liefern wenn kein osdProvider existiert. Müsste dann nicht auch 0 zurück geliefert werden? Negative Handles sollen ja lt. der Beschreibung von StoreImageData() einer abgeleiteten Klasse vorbehalten bleiben.

Zitat von FireFly

@Klaus: ich hätte mal ne Frage zum Returncode von cOsdProvider:: StoreImage():
lt. osd.h liefert StoreImage() im Fehlerfall 0 zurück (was ja von StoreImageData() kommt), aber StoreImage() kann auch -1 zurück liefern wenn kein osdProvider existiert. Müsste dann nicht auch 0 zurück geliefert werden? Negative Handles sollen ja lt. der Beschreibung von StoreImageData() einer abgeleiteten Klasse vorbehalten bleiben.

Da hast du vollkommen Recht.

--- osd.c       2013/02/13 12:53:18     2.37
+++ osd.c       2013/02/14 15:50:19
@@ -2057,7 +2057,7 @@
 {
   if (osdProvider)
      return osdProvider->StoreImageData(Image);
-  return -1;
+  return 0;
 }
 
 void cOsdProvider::DropImage(int ImageHandle)

Klaus

Zitat von mini73

Moin!

Du meinst sicherlich softhddevice_service.h, oder?
Sollten noch andere Dateien in das "softhddevice-dev"-Paket?

Ich habe vor, nächste Woche dann mal ein paar Beispiel-Patches zu schreiben. softhddevice und seduatmo scheinen übersichtliche Kandidaten zu sein.

Ja, das ist das richtige Headerfile. Wobei die einfach ins Plugin zukopieren, die einfachste Lösung ist.
Im Prinzip muss alles sowieso zusammen passen. Und über die Strings werden ja die Versionen abgeglichen.

Johns

Zitat von mini73

Nein, von müssen hab ich nie gesprochen. Das abhängige Plugin (nehmen wir mal live als Beispiel) hat immer noch seine lokale Kopie der epgsearch-Header (für den Fall, dass kein -dev-Paket angeboten werden kann). Die werden aber nur dann benutzt, wenn es keine global installierten epgsearch-Header gibt.

Das führt die Idee dann endgültig ad-absurdum. Entweder die Header-Files sind so stabil, dass sie Plugin-Autoren (so wie es wohl auch ursprünglich gedacht war) einfach kopieren können oder sie ändern sich so oft, dass man sie global halten muss.

Letzteres würde dann auch voraussetzen, dass man dann erst die "Service-Plugins" bauen muss und danach die abhängigen Plugins.

Und diese Schlussfolgerung führt dann vor allem dann zu einem grundlegenden Problem wenn man einen Paketsatz (halb)automatisch bauen will. Was zum Beispiel, wenn das "Service-Plugin" aktualisiert wird? Alle davon abhängigen Plugins versionieren und auch neu bauen? Oder beiim Paketieren selber die alte gegen die neue Header-Datei "diffen"

So schön das mit dem FHS ist, aber ich fürchte ernsthaft, dass die Idee, die Service-Schnittstelle vom Vorhandensein des Service-Plugins abhängig zu machen, letztlich im Wesentlichen die Komplexität erhöht.

Zitat von mini73

Wenn ich in meinem Paket zwei unabhängige install-Targets anbieten würde (z.B. install und install-dev), dann könntest du wahrscheinlich leicht zwei Pakete daraus machen, oder?
Oder was wäre dafür nötig?

Dev-Pakete gibt es bei Archlinux per Definition nicht.

Zitat von johns

Ja, das ist das richtige Headerfile. Wobei die einfach ins Plugin zukopieren, die einfachste Lösung ist.
Im Prinzip muss alles sowieso zusammen passen. Und über die Strings werden ja die Versionen abgeglichen.

Das habe ich weiter vorne schon versucht zu erklären. Aber im Prinzip sind wir hier einer Meinung

Zitat von Mreimer

Letzteres würde dann auch voraussetzen, dass man dann erst die "Service-Plugins" bauen muss und danach die abhängigen Plugins.

Warum? Die anhängiegen Plugin laufen doch auch immer ohne die Service Plugin.

BTW: Die Kopie dann doch zusätzlich dem Plugin beizulegen finde ich aber auch seltsam. Liegt dem VDR ne Kopie der DVB API bei falls der User sie gerade nicht im System hat?

Zitat von Mreimer

Und diese Schlussfolgerung führt dann vor allem dann zu einem grundlegenden Problem wenn man einen Paketsatz (halb)automatisch bauen will. Was zum Beispiel, wenn das "Service-Plugin" aktualisiert wird? Alle davon abhängigen Plugins versionieren und auch neu bauen? Oder beiim Paketieren selber die alte gegen die neue Header-Datei "diffen"

Wenn Versionsabhängig ist kann man im Plugin ne Abhängigkeit gegen eine bestimmte dev Version des Serverplugins festlegen. Das ist klarer als wenn eine falsche Kopie des Headerfiles (was nicht zum geänderten Serverplugin passt) beim Plugin liegt. Dann muss man nämlich anfangen zu diffen und zu fummeln.

Am Ende geht ja nur darum Redundanzen aufzulösen und die Sache etwas klarer zu machen.

Zitat von Mreimer

Dev-Pakete gibt es bei Archlinux per Definition nicht.

Ist doch kein Problem, dann gehört das Headerfile halt zur normalen Plugininstallation.

cu