[Announce] VDR developer version 1.7.35


  • VDRDIR ist imho ok. Ich würde allerdings das "../../../vdr.pc" rauswerfen. Denn entweder greift man auf $(VDRDIR)/vdr.pc oder das System-vdr.pc zu. Mehr braucht's nicht.


    CU
    Oliver


  • Wenn du "einfach so" ../../../vdr.pc nimmst, dann könnte das auch reiner Zufall sein, daß sich dort eine solche Datei befindet.
    In der jetzigen Variante kann man über VDRDIR genau festlegen, wo die VDR-Source ist (die muß nicht zwingend in ../../.. sein).
    Ist kein VDRDIR gesetzt, dann wird ein installiertes vdr.pc genommen, und wenn es auch kein solches gibt, dann wird als letzter Versuch ../../../vdr.pc genommen. Ich bin also nach wie vor der Meinung, daß es so, wie es jetzt ist, richtig ist.


    Klaus


  • Das ist nötig für den Fall, daß man ein Plugin in seinem Source-Directory bauen will.


    Ok, hast recht.


    CU
    Oliver

  • Klar könnte zufälligerweise in ../../../ eine vdr.pc Datei liegen.


    Mir ging es da eigentlich drum wenn ich in VDR-Source/PLUGINS/lib/hello make ausführe, zuerst die vdr.pc Datei aus dem VDR-Source genommen wird.


    Weil VDRDIR ist in diesem Fall nicht gesetzt, nächster Schritt wäre dann, dass die vdr.pc aus dem System genommen wird, diese könnte aber von einer alten VDR-Version sein.

  • Klar könnte zufälligerweise in ../../../ eine vdr.pc Datei liegen.


    Mir ging es da eigentlich drum wenn ich in VDR-Source/PLUGINS/lib/hello make ausführe, zuerst die vdr.pc Datei aus dem VDR-Source genommen wird.


    Weil VDRDIR ist in diesem Fall nicht gesetzt, nächster Schritt wäre dann, dass die vdr.pc aus dem System genommen wird, diese könnte aber von einer alten VDR-Version sein.


    Wenn jemand einen VDR ins System installiert hat, dann muß er halt beim Bauen eines Plugins im Plugin-Source-Directory VDRDIR angeben, und sei's "../../..".
    Auf jeden Fall ist man *mit* VDRDIR flexibler als ohne.


    Klaus


  • Aus VDR-Sicht (lokaler Build):


    - "make (all)" wie oben, aber zusätzlich werden die *.so-Dateien aller Plugins nach ./PLUGINS/lib und die *.mo-Dateien von VDR selber und der Plugins nach ./locale kopiert (hierfür ist es zwingend, daß die *.so Dateien im jeweiligen Source-Verzeichnis des Plugins entstehen, und die *.mo im jeweiligen "po"-Verzeichnis; wenn ein Plugin meint, sich nicht an diese Vorgabe halten zu müssen, dann funktioniert es eben nicht).


    Machbar und vor allem auch ohne getrennten "Buildtype" lösbar. Allerdings hätte meine Variante (über "make install" gehen) den großen Vorteil gehabt, dass auch vom Plugin-Autoren vorgesehene Ergänzungen im "CONFDIR" und "RESDIR" nachgezogen worden wären. Ohne solche zusätzlichen Dateien funktionieren manche Plugins nicht und gerade hier sehe ich den sehr großen Vorteil der nun geschaffenen "make install"-Routine, dass die Plugin-Entwickler nun eine Stelle haben, an der solche Daten automatisch platziert werden können. Bisher musste man sich sowas in einer README oder INSTALL erst selber raussuchen und manuell platzieren.


    Wenn dich das aber nicht stört, dann ist die von dir skizzierte Lösung in der Tat die simpelste Variante. Wenn Plugin-Autoren dann, weil ja im Makefile schon in Sourcecode-Form hinterlegt, in Zukunft auf separates Dokumentieren von "wo muss noch was hinkopiert werden" verzichten, dann müsste ein "in-place-Kompilierer" dann halt im Makefile nachlesen, was noch zu tun ist...

  • Moin!


    Ich sehe, ihr kommt gut voran, ich wollte mal zwischendurch ein Lob aussprechen. Macht bitte weiter!


    Prominentes, nicht-standard-konformes Plugin ist übrigens streamdev, falls ihr etwas "komisches" zum Testen haben wollt... :)
    Mal abgesehen von den Unterverzeichnissen haben die Plugins "ungültige" Namen, da dort ein Minuszeichen auftaucht. Hat bisher aber auch nie gestört...


    Lars.

  • Mir reichts für heute erstmal. Ich habe Klaus's "Skizze" fast umgesetzt. Ich schaffe es nur noch nicht die Locale an die richtige stelle zu kopieren.



    Irgendwie nehmen die Plugins da ein Prozentzeichen, ich sehe aber irgendwie nicht, wo/wie das definiert wird.

  • Das Hauptproblem ist das UP3-Makro. Folgende Variante funktioniert für mich. 'make' erzeugt auch alle Files in PLUGINS/lib und locale, unabhängig davon, wohin die Install-Verzeichnisse zeigen.


    Gruß
    e9hack


  • Genaugenommen ist Rom immer noch nicht fertig... ;)


    Schon richtig, aber länger als 6 Tage sollte es auch nicht dauern ;)

    Zitat

    Und er sah, dass es gut war


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Rom ist nicht an einem Tag erbaut worden... Nimm dir die Zeit, die du brauchst, bitte.


    Lars.


    Dem kann ich mich nur voll umfänglich anschließen. Du hast da ein sehr komplexes Problem angefaßt. Und ich wündche Dir (und und uns), dass Dich der Frust nicht dazu hinreißt, auf halbem Weg aufzuhören. Wie Lars schon sagt: nimm Dir die Zeit, die Du brauchst (auch um den ein oder anderen Unsinn, den Du Dir anhören musstest, abprallen zu lassen) und mache es gründlich!


    In diesem Sinne: frohes und erfolgreiches neues Jahr für alle!
    Ingo


  • Das mag bei dem Debian Zeugs wohl so sein, bei Gentoo hat man die Sourcen immer (gepackt) auf der HDD.


    Sprich nicht von Gentoo wenn Du den Kram von Hand installierst ?(


    Die von Klaus erdachten änderungen habe ich bereits fuer vdr-1.7.35 umgesetzt,
    wo möglich, hab ich das "neumodische" ;) Zeug von klaus dafuer benutzt.
    Die install der Plugins functioniert mit alter und neuer Makefile structur.


    Anyway, da da alles in einer Sandbox kompiliert wird, müssen/werden die notwendign Umgebungsvariablen je nach bedarf fuer das gentoo build system herangeholt, ggf. korrigiert.
    Das funtioniert natürlich nur, wenn man per paketmanger installiert.


    Selbstgepresst ist eigenverantwortung und hat nix mit gentoo zu tun :prost2
    Dazu kann jede Distributione herhalten, soweit irgendein compiler installiert ist.


    btw. Gesundes Neues @all

  • Mir reichts für heute erstmal.


    Laß dir Zeit, es drängt dich doch niemand!
    Wie schon an anderer Stelle gesagt wurde, wenn es aufhört, Spaß zu machen, dann ist es Arbeit - und das soll dieses Hobby doch nicht werden ;)


    Zitat


    Ich habe Klaus's "Skizze" fast umgesetzt. Ich schaffe es nur noch nicht die Locale an die richtige stelle zu kopieren.


    Irgendwie nehmen die Plugins da ein Prozentzeichen, ich sehe aber irgendwie nicht, wo/wie das definiert wird.


    Meinst du diese Zeile hier?

    Code
    $(I18Nmsgs): $(LOCDIR)/%/LC_MESSAGES/vdr-$(PLUGIN).mo: $(PODIR)/%.mo


    Hier bildet "$(PODIR)/%.mo" einen Pattern, und der '%'-Anteil davon wird jeweils in "$(LOCDIR)/%/LC_MESSAGES/vdr-$(PLUGIN).mo" eingesetzt um ein Target zu bilden. Auf diese Weise werden für alle *.mo-Dateien die vollständigen Pfadnamen im $(LOCDIR) ermittelt.


    Klaus

  • Ich finde Rom ist ganz schoen fertig ;)


    Und ganz schön Pleite ... :whistling:


    SCNR

    HowTo: APT pinning

  • ...wenn Ihr den Berlusconi ans Makefile lasst, nur weil der gerade Zeit hat und behauptet, dass er eh alles besser kann als alle anderen... ;)

  • Hallo,


    ich möchte einmal das Thema wechseln.
    Mit vdr-1.7.35 (1.7.34 habe ich übersprungen) habe ich das Problem, dass HD-Aufnahmen nicht korrekt bis zum Ende abgespielt werden.
    Ca. 20 Sekunden vor dem Aufnahmeende verfällt der vdr in eine extrem langsame Zeitlupe und reagiert auch nur noch schlecht auf die Eingaben der Fernbedienung.
    Ton kommt nur sporadisch!
    Wenn ich nicht mehrfach mit der STOP-Taste die Wiedergabe beende, braucht er ca. 2 min. um das Ende zu erreichen!
    Mit meiner aktuellen Konfiguration (siehe Signatur) läuft alles Bestens. ** Hierfür mal ein großen DANKE an Klaus und alle anderen Entwickler! **
    Hat sonst noch jemand das Problem?


    Gruß
    grappi

    Wohnzimmer-VDR: Hardware: ASRock Mainboard M3N78D; AMD 240e CPU; Zotac GeForce GT220 passiv; Mystique Dual SaTiX-S2; TT-DVB-S2 3200 Software: VDR-2.0.0; softhddevice (aktuelle git) ; NVIDIA-Treiber 313.26

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!