Sie sind nicht angemeldet.

Suchergebnisse

Suchergebnisse 1-30 von insgesamt 1 000. Es gibt noch weitere Suchergebnisse, bitte verfeinern Sie Ihre Suche.

Gestern, 13:03

Forenbeitrag von: »M-Reimer«

Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

Vielen Dank an alle beteiligten! Endlich gute DVB-Hardware ohne Ärger mit DKMS und Co!

Sonntag, 18. Juni 2017, 14:09

Forenbeitrag von: »M-Reimer«

Bundestag beschließt das Ende der UKW/MW/LW-Radios (Pro/Contra?)

Geht mir ehrlich gesagt genauso. Der VDR-Rechner ist lange Zeit nur rumgestanden ohne genutzt zu werden. Das hat sich etwas geändert seit ich Kodi als einziges Frontend auf der Kiste habe. Kodi soll ja jetzt auch Netflix-Unterstützung bekommen. Ab dann würde ich den HTPC noch deutlich öfter nutzen. Bisschen blöd ist der DAB+-Kram halt im Auto. Leider hat man schon vor vielen Jahren aufgehört die Radios in DIN-Schächte zu stecken und so ist Umrüsten entweder unkomfortabel, weil man sich irgendwas...

Samstag, 17. Juni 2017, 12:50

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Zitat von »utiltiy« Also nichts mit: Quellcode 1 2.3.1.r3.g51bc4fd Erst lesen... Zitat von »M-Reimer« Was im Live-Git aber tatsächlich fehlt sind Tags für die Releases. An der Stelle, wo "2.3.1" ist, wäre ein Tag praktisch. Ich habe das mal für das Commit 4f66113 nachgeholt: Quellcode 1 $ git tag v2.3.1 4f66113 Das habe ich natürlich nur lokal zur Demonstration nachgeholt. Ich habe keine Commit-Rechte auf das Live-Git. Und ja: Bei vdr4arch ist es durchaus üblich, dass wir im "prepare" eines PKG...

Samstag, 17. Juni 2017, 11:54

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Ich habe nie behauptet, dass man SHA-Hashes nutzen soll. Die sind nur ergänzend in den Versionsnummern. Was im Live-Git aber tatsächlich fehlt sind Tags für die Releases. An der Stelle, wo "2.3.1" ist, wäre ein Tag praktisch. Ich habe das mal für das Commit 4f66113 nachgeholt: Quellcode 1 $ git tag v2.3.1 4f66113 Jetzt kann man sich eine Version folgendermaßen holen: Quellcode 1 2 $ git describe --long --tags v2.3.1-3-g51bc4fd Links: Letztes Tag. Dann folgt die "3" die ein hochlaufender Zähler v...

Samstag, 17. Juni 2017, 11:24

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Zitat von »fnu« master braucht aber auch eine Versionsnummer, obwohl diese immer mit +git garniert werden wird. Leider kann man sich nicht auf die git SHA verlassen, das war bei Mercurial mit seinen eindeutig nummerierten Changesets besser ... https://wiki.archlinux.org/index.php/VCS….28.29_function Durchaus machbar. Sogar im Wechsel zwischen "Release" und "Git".

Samstag, 17. Juni 2017, 11:07

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Zitat von »jasminj« Für Vorschläge bezüglich des (Test)Version Hochzählens wäre ich noch immer dankbar. Mein Vorschlag: Testversionen garnicht erstellen. Dafür ist das Git-Repository da. Man kann von dort jeden beliebigen Stand bauen. Versionen würde ich nur vergeben, wenn ein bestimmter Stand erreicht ist, der so stabil ist, dass Distributoren den bauen können.

Sonntag, 11. Juni 2017, 11:57

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Zitat von »jasminj« @M-Reimer: Kommst du jetzt dazu die Sache mit der Playliste zu machen? Kurzfristig nicht. Ich habe erst in drei Wochen wieder Zeit.

Montag, 5. Juni 2017, 13:52

Forenbeitrag von: »M-Reimer«

Grundsatzdiskussion Funktionen aus STL in VDR bzw. Plugins

Zitat von »kls« Kann er "using namespace std;" nicht *nach* dem Include der tools.h schreiben? Ich konnte auf die Schnelle nicht herausfinden wie das dokumentierte Verhalten ist, wenn zwei "using namespace" hintereinander folgen. Wer gewinnt? Der erste? Der letzte? Oder gibt es direkt einen Compiler-Fehler weil Funktionsnamen kollidieren? Zitat Das sollte ja auch nur ein Workaround sein für ein Problem, das VDR selber ja gar nicht hat ;-). Stimmt. Aber Plugin-Autoren haben das Problem. Die "too...

Montag, 5. Juni 2017, 13:30

Forenbeitrag von: »M-Reimer«

Grundsatzdiskussion Funktionen aus STL in VDR bzw. Plugins

Zitat von »kls« Deswegen alle .c Files zu ändern kommt nicht in Frage. Wäre es denn denkbar das "using namespace" in ein "#ifdef" zu wrappen und dieses Define dann nur zu setzen wenn der VDR selbst kompiliert? Zitat Das Problem war doch, seweit ich das mitbekommen habe, daß die Deklarationen zwischen VDR und STL kollidierten. Wenn VDR nun seine Templates in einen eigenen Namespace verpackt, dann können die Deklarationen nicht mehr kollidieren. An der Aufrufstelle kann sich der Programmierer dan...

Montag, 5. Juni 2017, 13:26

Forenbeitrag von: »M-Reimer«

Grundsatzdiskussion Funktionen aus STL in VDR bzw. Plugins

Zitat von »Copperhead« Zitat von »M-Reimer« Mein Dozent an der Hochschule legt uns nahe, dass wir so oft wie möglich gut getestete Bibliotheken nutzen sollen. Begründung: Je weniger Code man selber schreibt umso weniger Fehler kann man machen. Ahh. Also programmieren wir ab jetzt auch alles mit z.B. Boost. Wird ja häufig verwendet, ist also gut getestet. Genau so ist es. Boost ist gut getestet und hat zudem das Ziel möglichst alle seine Funktionen zum C++-Standard zu machen: Zitat von »http://w...

Montag, 5. Juni 2017, 13:17

Forenbeitrag von: »M-Reimer«

Grundsatzdiskussion Funktionen aus STL in VDR bzw. Plugins

Nein. Reicht nicht weil die ".h" direkt "using namespace" macht. Das "using namespace" müsstest du in die ".c"-Dateien packen. Nur so hat ein Plugin-Autor die Wahl.

Montag, 5. Juni 2017, 12:43

Forenbeitrag von: »M-Reimer«

Grundsatzdiskussion Funktionen aus STL in VDR bzw. Plugins

Zitat von »kls« Zitat von »M-Reimer« Warum kommt es überhaupt zu der Situation? Kann der VDR nicht einfach die STL-Definitionen nutzen? Wozu das Rad neu erfinden? VDR benutzt die STL nicht. Klaus Eigentlich hätte mich ja eher der technische Hintergrund interessiert. Mein Dozent an der Hochschule legt uns nahe, dass wir so oft wie möglich gut getestete Bibliotheken nutzen sollen. Begründung: Je weniger Code man selber schreibt umso weniger Fehler kann man machen.

Sonntag, 4. Juni 2017, 20:21

Forenbeitrag von: »M-Reimer«

Grundsatzdiskussion Funktionen aus STL in VDR bzw. Plugins

Zitat von »kls« Irgendwie muß tools.h ja "erfahren", daß STL-Header inkludiert werden, die Templates definieren, die auch VDR selber definiert. Und das geht nunmal nur, wenn die STL-Hedaer vor tools.h inkludiert werden. Warum kommt es überhaupt zu der Situation? Kann der VDR nicht einfach die STL-Definitionen nutzen? Wozu das Rad neu erfinden?

Mittwoch, 31. Mai 2017, 08:39

Forenbeitrag von: »M-Reimer«

Neuorganisierung der VDR Plugins auf Github (vdr-projects.github.io)

Ich stimme fnu in soweit zu, dass "weiterpflegen" ohne Einverständnis des Autors nur nach Umbenennen erfolgen sollte.

Sonntag, 28. Mai 2017, 11:05

Forenbeitrag von: »M-Reimer«

Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

Die ganze Sache würde eigentlich nur Sinn machen, wenn man mehr oder weniger das gesamte RCS-Repository öffentlich duplizieren würde. Bei einem öffentlichen RCS wäre das zwar für die Masse wenig hilfreich, würde aber zumindest in der Theorie ein moderiertes Übertragen in ein GIT erlauben bei dem dann auch die Commit-Messages und Versions-Tags stimmen. Ein GIT, das zwar "Nightlies" trägt, aber keine sauberen Commit-Messages, halte ich für wenig hilfreich. Eventuell wäre es da nach aktuellem Stand...

Dienstag, 23. Mai 2017, 17:41

Forenbeitrag von: »M-Reimer«

Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

Auch wenn eine Organisation bei Github erstmal kein Fehler ist, sehe ich nach wie vor hier nicht das Problem, das zu lösen ist. Letztlich könnt ihr und solltet ihr den potentiellen Entwicklern nicht vorschreiben welches "Tool" sie zu verwenden haben. Und wenn jemand sein Plugin nicht in einer zentralen Organisation will, dann eben nicht. Was wirklich fehlt ist eine Auflistung, wo man welches Plugin aktuell bekommen kann. Gerade wenn ein Plugin in den Status "ungepflegt" geht, könnte man hier dan...

Montag, 22. Mai 2017, 23:28

Forenbeitrag von: »M-Reimer«

Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

Zitat von »CvH« Du sagst ja im Endeffekt das kompliziert, aufwendig und verborgen besser ist als einfach, schnell und transparent. Nein. Worauf ich hinaus wollte, ist, dass es mehrere Wege gibt zum Ziel zu kommen. Der Issue-Tracker von projects.vdr-developer.org ist z.B. komplett öffentlich einsehbar.

Montag, 22. Mai 2017, 20:21

Forenbeitrag von: »M-Reimer«

Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

Zitat von »Copperhead« Was projects.vdr-developer.org gerade so veraltet macht ist genau, dass es keine Pull Requests gibt. Ein "Pull-Request" ist ganz förmlich eine Anfrage, von einem anderen Repository zu pullen. Das kann ich über jeden beliebigen Weg machen. Wie ich noch beim Skindesigner mitgeholfen habe, ging das schlicht über VDR-Portal PNs. Könnte man aber auch über einen Kommentar zu einem Ticket in Redmine machen. Das ist aber erstmal ein Git-Standardfeature und wurde nicht von Github ...

Montag, 22. Mai 2017, 18:53

Forenbeitrag von: »M-Reimer«

Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

Zitat von »kls« GIT benutze ich selber nicht, und ich habe auch nicht vor, das zu ändern. Ich arbeite ganz klassisch mit einem lokalen RCS, auf das nur ich Zugriff habe. Bugfixes und Verbesserungsvorschläge nehme ich gerne als Patches an, behalte mir aber die Entscheidung über deren Einbau jeweils vor. Hast du dir GIT wenigstens einmal angeschaut? GIT ist erstmal auch rein lokal. Ich selber erstelle neue Projekte immer erst lokal. Man kann ganz ohne Server alle Funktionen von GIT verwenden und ...

Montag, 22. Mai 2017, 18:39

Forenbeitrag von: »M-Reimer«

Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

Zitat von »SurfaceCleanerZ« BTW: zu vdr-developer: Ich denke mal etobi als Betreiber könnte bei Bedarf die Rechte für verschollene Autoren weitergeben... Ob das rechtlich geht ist die Frage... Klar geht das. Der Serverbetreiber hat das "Hausrecht". Angemessene Reaktionszeit des ursprünglichen Autors natürlich vorausgesetzt. Ich finde projects.vdr-developer.org auch nicht so schlecht wie es einige machen wollen. Letztlich wird dort auch GIT als Versionsverwaltung angeboten und auch wenn es bei G...

Montag, 22. Mai 2017, 12:06

Forenbeitrag von: »M-Reimer«

Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

Ein Wiki lebt vom Mitmachen und letztlich kann jeder, der Fehler findet, diese auch direkt korrigieren. Die große Frage ist doch, wie man mit ungepflegten Plugins in Zukunft umgehen will. Ich hatte "projects.vdr-developer.org" mal so verstanden, dass man dort ein Plugin weiterpflegen kann, wenn der ursprüngliche Entwickler "nicht mehr aufzutreiben ist". Also sollte im Prinzip sowas wie eine Art "direkte Übernahme ohne Zustimmung" nach akzeptabler Wartezeit möglich sein. Keine Ahnung wie es letzt...

Sonntag, 21. Mai 2017, 20:47

Forenbeitrag von: »M-Reimer«

Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

Meiner Meinung nach ist das wesentliche Problem bei dem Thema eigentlich, dass es je nach Plugin schwierig geworden ist, noch zu wissen, wo es nun die nötigen Sources und/oder Patches zu finden gibt. Als Beispiel kann man da mal wieder softhddevice nennen. Es gibt, soweit ich mich erinnere, nun schon mindestens 3 separate Abspaltungen. Eine davon das "Original". Hier wäre es überfällig alles mal wieder zusammenzuführen. Am besten natürlich wieder auf das "offizielle" GIT auf projects.vdr-develop...

Samstag, 20. Mai 2017, 10:25

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Kannst du in deinem GIT einen Branch anlegen, der mit VDR 2.2 noch geht? Ich könnte dort versuchen das mit Playlisten hinzubekommen. Sollte dann kein Problem sein die Änderung in den anderen Branch zu mergen. So könnte ich eventuell bei Gelegenheit auch ein paar andere Dinge ausprobieren die man dann ggf. jeweils wieder mergen könnte.

Freitag, 19. Mai 2017, 19:42

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Den externen Player hat man bisher auch gebraucht. Ich halte nichts davon, wieder etwas in den Browser zu basteln. Erst recht nicht wenn man Transcoding braucht. Kleine Playliste ist viel einfacher und die mit VLC zu verknüpfen ist keine große Sache.

Freitag, 19. Mai 2017, 11:00

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Zitat Die Logik kann ich nicht nachvollziehen, Entwicklung ist jetzt mit 2.3.x, damit dann bei VDR 2.4.0 alles zur Verfügung steht? Die Logik ist ganz einfach die, dass ich kein System mit VDR 2.3 habe und auch weder Zeit noch Lust habe eines aufzusetzen. Entwickeln kann und werde ich also nur an einem Plugin welches auf meinem System läuft. Und da die Entwicklung aktuell an einer Version gemacht wird, die mit VDR 2.2 nicht läuft, bin ich erstmal außen vor.

Freitag, 19. Mai 2017, 09:46

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Zitat von »jasminj« Bis jetzt hat ein Maintainer geantwortet, aber Diter Hametner hat nicht geantwortet. Frage nochmal nach. Eine Mail kann schon mal verloren gehen. Nach angemessener Wartezeit sollte dir ein Admin Commit-Rechte geben können. Zitat Aha, wollen die in den Browsern schon wieder was entfernen Plugins entfallen. Eigentlich allerhöchste Zeit die endlich abzuschaffen. Bleiben zwei Optionen. Transcodieren am VDR um im Video-Tag von HTML5 wiederzugeben oder Playliste ausliefern um eine...

Donnerstag, 18. Mai 2017, 09:10

Forenbeitrag von: »M-Reimer«

vdr-plugin-live für VDR 2.3.x ...

Zitat von »fnu« @M-Reimer Dazu müsste man erstmal die Kontrolle über das GIT bekommen. Sollte aber machbar sein, oder? https://projects.vdr-developer.org/git/vdr-plugin-live.git/ Ich warte jetzt erstmal ein VDR 2.4 ab, aber im Prinzip hätte ich in absehbarer Zeit auch Interesse daran einiges an Live beizutragen. Kanaleditor für Live hatte ich hier schonmal angesprochen: Wie Kanäle komfortabel verwalten? Dann wäre da noch der Player für das Live-TV-Signal der in absehbarer Zeit so nicht mehr geh...

Donnerstag, 18. Mai 2017, 09:03

Forenbeitrag von: »M-Reimer«

Wie Kanäle komfortabel verwalten?

Wenn man das VDR-OSD nicht mehr nutzt wird es aber problematisch. Man kann in Kodi durchaus vom VDR abkoppeln. Dann speichert Kodi die Senderliste in der eigenen Datenbank. Allerdings sehe ich in gewisser Weise schon einen Reiz darin bei mehreren Kodi-Clients die Kanalliste zentral zu pflegen. An der channels.conf selber zu gurken ist aber keine Option. Schon garnicht für einen Bekannten, der so ein "Multi-Room-Kodi-Setup" von mir aufgesetzt bekommen hat. Ich warte mal ab bis VDR 2.4 und schaue ...

Mittwoch, 17. Mai 2017, 10:39

Forenbeitrag von: »M-Reimer«

Wie Kanäle komfortabel verwalten?

Zitat von »Ein Eike« Wie würdest du's dir denn wünschen? Am besten als Webinterface. Eventuell in Live integriert. Kanäle einfach per Drag&Drop mit der Maus schieben. Man könnte die Liste zum Beispiel doppelt darstellen. Ähnlich wie die zweigeteilten Dateimanager. Das ganze auf jeden Fall direkt an den VDR angebunden. Kein Offline-Editieren der channels.conf

Immortal Romance Spielautomat