Mich kannst du jetzt aber ausnahmsweise mal nicht gemeint haben, oder?
hab ich das gesagt??? 
stand da nicht das Wort "allgemein"?
irgendwie dünkte es mich, das da "schlechte Schwingungen" in dem Thread wären....
und die wollte ich mit einem gebrummelten "ööööööm....ichwerderuhig....öhm" entfernen 
und nun ist gut
jo01
Freu mic schon auf VDR-2.1 jetzt muss ich mir doch mal einen zweiten bauen
geronimo
Das was du da machst sind doch keine konstruktiven Vorschläge. Du willst dem entwickler vorschreiben wie er seine Software zu programmieren hat.
Hast du ja auch im anderen Thread mit deiner FF Karte auch gemacht ohne die Lösungen von KLS auch nur zu testen.
Ich bin zwar kein Programmierer evt. ein kleiner patcher 
aber ich finde den Code von KLS sehr übersichtlich und gut dokumentiert. Und das was er einbaut hat meiner Meinung nach Hand und Fuß.
mfg Thomas
Vorerst: Ich bewundere absolut die Arbeit von KLS und seinem Enagement.
Doch denke ich mir wieso die Entwicklung nicht öffentlich passiert, es ist hier
so enorm viel Wissen und Bereitschaft vorhanden.
Rein von der Arbeit die Entwickler hier leisten würden wäre das doch:
1) eine massive Arbeitserleichterung von KLS
2) ein schnellerer Fortschritt in der Entwicklung des VDR
Natürlich würde KLS stets die Zügel in der Hand haben und die Ziele bestimmen,
aber was denkt ihr darüber? Das Thema ist ja schon öfters angeschnitten aber irgenwie
nie zu einem Ende gekommen.
Ich sehe schon dass es viele Patche/Bugfixes gibt die einmal in den core fließen, aber an
den Zielen/Visionen an denen KLS arbeitet, arbeitet er meist alllein.
Ich will niemandem ans Bein pinkeln, wie seht ihr das?
Ich will niemandem ans Bein pinkeln, wie seht ihr das?
Na ja, ich lasse mir bei meinen eigenen kleinen Projekten auch ungern reinreden.
Gerald
Wenn kls den VDR aus SPass am Programmieren macht - dann funktioniert der Gedankengang so nicht.
1.) Projektmanagment und Leute anleiten ist nicht Programmieren
2.) Um Code von anderen dann zu übernehmen muss das Vertrauen da sein und der Stil ziemlich genau den von kls treffen.
3.) kls müsste keine Lust drauf haben den Teil selbst zu machen
Insofern kann ich das gut nachvollziehen.
Was Zusagen angeht: Wenn man eine Roadmap aufstellt verpflichtet man sich an etwas ganz bestimmten zu programmieren, anstatt sich einfach aus Lust ranzusetzen, etwas fertig zu machen und es der Meute vorzuwerfen, muss man an etwas ganz bestimmten arbeiten, und es evtl nach bestimmten Vorgaben fertig stellen. Kein Spaß.
Meiner Meinung nach gibt es genug Baustellen bei den Plugins. Wenn sich jemand austoben will, kann er das dort tun.
Oder anders gesagt: Ich verstehe was du schreibst und es ist teils richtig, aber so funktioniert es nicht.
Alles anzeigenWenn kls den VDR aus SPass am Programmieren macht - dann funktioniert der Gedankengang so nicht.
1.) Projektmanagment und Leute anleiten ist nicht Programmieren
2.) Um Code von anderen dann zu übernehmen muss das Vertrauen da sein und der Stil ziemlich genau den von kls treffen.
3.) kls müsste keine Lust drauf haben den Teil selbst zu machen
Insofern kann ich das gut nachvollziehen.
Was Zusagen angeht: Wenn man eine Roadmap aufstellt verpflichtet man sich an etwas ganz bestimmten zu programmieren, anstatt sich einfach aus Lust ranzusetzen, etwas fertig zu machen und es der Meute vorzuwerfen, muss man an etwas ganz bestimmten arbeiten, und es evtl nach bestimmten Vorgaben fertig stellen. Kein Spaß.
Meiner Meinung nach gibt es genug Baustellen bei den Plugins. Wenn sich jemand austoben will, kann er das dort tun.
Oder anders gesagt: Ich verstehe was du schreibst und es ist teils richtig, aber so funktioniert es nicht.
Full ACK!
Klaus
Hi Gerald,
da ich Dich anderweitig nicht erreichen kann, melde ich mich hier nomml.
Zitat von gdaDas hört sich an, als wüsstest du schon wie Klaus das implementieren wird. Ich sehe da jetzt nicht warum sich sowas ausschließen sollte.
Nun, egal wie es implementiert wird - wenn es keine übergeordnete Instanz/Zentrale/Server gibt, lässt sich Zugriffsberechtigung nicht wirklich umsetzen.
Auch wenn mir Deine Idee der Peerlösung gefällt, peer und restriktiv geht nicht zusammen. Zumindest nicht zuverlässig.
Vergleiche nur mal yp mit kerberos unter sicherheitstechnischen Aspekten.
Die ausschließliche Verwendung von Peers ist akzeptabel in einer "laissez faire" Umgebung.
MIr gefällt der Ansatz den die Fritzbox verfolgt. Dort kann man die Kindersicherung lax handhaben und verbietet nur manchen Geräten den Zugang - oder man kehrt den Default um und dann kommen nur noch registrierte/zugelassene Kisten zu den netten Indern. So betreibe ich meine Box.
In dem Kontext hätte ich auch gerne den VDR betrieben - aber das muss ich jetzt wohl selber machen 
Zitat von steffen_bWenn kls den VDR aus SPass am Programmieren macht - dann funktioniert der Gedankengang so nicht.
1.) Projektmanagment und Leute anleiten ist nicht Programmieren
2.) Um Code von anderen dann zu übernehmen muss das Vertrauen da sein und der Stil ziemlich genau den von kls treffen.
3.) kls müsste keine Lust drauf haben den Teil selbst zu machen
Nun, wenn Klaus sich einen Projektleiter "anlachen" würde, könnte Punkt 1 abgehakt werden, ohne dass er selbst es tun muss. Wenn also menschlich schon eine Vertrauensbasis da ist, sollte der Rest doch Pillepalle sein. Zum Leute anleiten könnte eine weitere Person ins Boot geholt werden. Natürlich gelten die Vorgaben von Klaus - aber es gibt reichlich unterschiedliche Menschen mit ebenso unterschiedlichen Interessen. Diesen Umstand könnte man so nutzen, dass alle was davon haben.
Man müsste nur wollen
Für Punkt 2 wäre auch ein Projektleiter zuständig.
Ich sehe nur Vorteile in Teamarbeit - zumindest wenn die Basis stimmt.
Und der Umstand, dass man ein Ticketsystem einführt, heißt noch lange nicht, dass man keine Freude mehr am Programmieren hat. Auch sowas ließe sich organisieren.
Gruß Gero
Die ausschließliche Verwendung von Peers ist akzeptabel in einer "laissez faire" Umgebung.
MIr gefällt der Ansatz den die Fritzbox verfolgt. Dort kann man die Kindersicherung lax handhaben und verbietet nur manchen Geräten den Zugang - oder man kehrt den Default um und dann kommen nur noch registrierte/zugelassene Kisten zu den netten Indern.
Auch wenn es vielleicht müßig ist, weil du ja für dich schon was besseres gefunden hast: freilich wird jederVDR festlegen können, für welche anderen VDRs er erreichbar sein soll (alle, keine, nur bestimmte oder nur bestimmte nicht) und welche anderen VDRs er (sofern erlaubt) erreichen möchte (dto.).
Klaus
Die ausschließliche Verwendung von Peers ist akzeptabel in einer "laissez faire" Umgebung.
MIr gefällt der Ansatz den die Fritzbox verfolgt. Dort kann man die Kindersicherung lax handhaben und verbietet nur manchen Geräten den Zugang - oder man kehrt den Default um und dann kommen nur noch registrierte/zugelassene Kisten zu den netten Indern. So betreibe ich meine Box.
Was hast du denn für ein LAN? Eines für nen ganzen Mietblock? Warum lässt du Leute oder Geräte, denen du offensichtlich nicht vertraust, in dein LAN?
Davon abgesehen, dass die Fritz!Box LAN-Intern keinerlei echte "Sicherheitsfeatures" bietet. Die Kindersicherung ist z.B. ein einfacher NAT-Filter. Wer es drauf anlegt kann sowas einfach umgehen.
Zitat
Ich sehe nur Vorteile in Teamarbeit - zumindest wenn die Basis stimmt.
Ich finde die Teamarbeit im VDR-Bereich funktioniert durchaus. Sie läuft nur in freieren Strukturen ab, wie man sie von anderen Projekten kennt. Also ich finde diese Liste doch recht imposant:
http://projects.vdr-developer.…vdr.git/tree/CONTRIBUTORS
Zitat
Und der Umstand, dass man ein Ticketsystem einführt, heißt noch lange nicht, dass man keine Freude mehr am Programmieren hat. Auch sowas ließe sich organisieren.
Ticketsysteme werden überbewertet und um ehrlich zu sein habe zumindest ich es langsam gehörig satt nur um für ein Projekt einen Fehler zu melden eine Registrierungsprozedur für deren Ticketsystem durchzulaufen um mir mein X-tausendstes Login anzuschaffen, welches ich beim zweiten zu meldenden Fehler ohnehin wieder vergessen habe. Besonders toll wenn irgend so eine "Leuchte" die tolle Idee hatte irgendwelche Passwort-Mindestanforderungen zu definieren (Groß- und Kleinschreibung, mindestens ein Sonderzeichen, ...), So bin ich dazu übergegangen, dass ich Fehler, die mir nicht so wichtig sind, bzw. für die ich einen Workaround habe, einfach in die Mailingliste des Projekts poste. Wenn der Projektleiter ein Ticket will, soll er eines anlegen.
VDR endlich richtig netzwerkfähig machen, so dass er von sich aus eine Multimediaclient-Server Umgebung wird. So richtig mit zentraler Verwaltung der Ressourcen wie DVB-Empfänger, Timer, Aufnahmen auf verschiedenen Rechnern... zentral an allen Fernsehern nutzbar.
Das wäre ein Traum!
Ich wollte mich zwar eigentlich hier raushalten, weil ich ungern über "ungelegte Eier" rede. Aber bevor das hier weiter eskaliert mache ich jetzt mal die Aussage, daß in Version 2.1 die ersten Hauptpunkte, mit denen ich mich beschäftigen möchte, der Einbau der Unterstützung für positionierbare Antennen und eine Vernetzung einzelner VDRs sein werden. Die Vernetzung wird dabei so ablaufen, daß VDRs im gleichen Netzwerk sich einfach und ohne Zutun des Benutzers "finden" (sofern sie das zulassen). Es wird keinen "client/server" oder "master" geben, sonder nur gleichberechtigte "peers". Im ersten Schritt sollen Timer der anderen Peers angezeigt und verwaltet werden können. Wie es dann weitergeht werde ich sehen...
Klaus
Hi Klaus,
das klingt super...ich freue mich schon
Ich finde die Idee mit den gleichberechtigten peers auch besser als einen Master oder ein Clent/Server Konstrukt.
Falk
Hi!
Ich würde mir eine Archive-HDD Funktion wünschen, wie sie in extrecmenu
implementiert ist. Das ist momentan hauptsächlich durch ein Script verwirklicht.
Der Aufnahmeordner wird auf die Archivplatte verschoben, auf der ein File
"hdd.vdr" mit einer Kennung existiert. Im Videoverzeichnis bleibt der Aufnahme-
ordner bestehen, bis auf die eigentlichen Videodateien. Zusätzlich wird hdd.vdr
dort reinkopiert, welches die Aufnahme als Archiv markiert. Wenn nun diese
Aufnahme abgespielt werden soll, wird man aufgefordert, die Platte mit der ID
xxxx anzuschliessen. Danach werden die Videodateien gesymlinkt, und das
Playback läuft. Danach werden die Symlinks einfach wieder entfernt.
Alles anzeigenHi!
Ich würde mir eine Archive-HDD Funktion wünschen, wie sie in extrecmenu
implementiert ist. Das ist momentan hauptsächlich durch ein Script verwirklicht.
Der Aufnahmeordner wird auf die Archivplatte verschoben, auf der ein File
"hdd.vdr" mit einer Kennung existiert. Im Videoverzeichnis bleibt der Aufnahme-
ordner bestehen, bis auf die eigentlichen Videodateien. Zusätzlich wird hdd.vdr
dort reinkopiert, welches die Aufnahme als Archiv markiert. Wenn nun diese
Aufnahme abgespielt werden soll, wird man aufgefordert, die Platte mit der ID
xxxx anzuschliessen. Danach werden die Videodateien gesymlinkt, und das
Playback läuft. Danach werden die Symlinks einfach wieder entfernt.
Ich denke so was ist sicher besser in einem FUSE aufgehoben als im VDR.
Streng genommen ist das eigentlich auch mit einem Skript und AutoFS(siehe PROGRAM TYPE MAPS) machbar.
Ich bin der festen Überzeugung, dass es nicht sinnvoll ist, etwas was ein anderes Tool/Programm für dich tun kann, nochmal in ein weiteres Tool/Programm zu implementieren.
Ich denke das ist doch die Unix/Linux-Philosophie, oder?
Gerald
Das Problem mit fuse ist der Feedback, dann bräuchte der VDR ne allgm. API mit dessen Hilfe fuse mit ihm reden könnte. Weil beim Versuch die Aufnahme abzurufen muss ja evtl. nen Dialog kommen der zum anschliessen der HDD auffordert und der VDR muss solange warten.
Wobei dem VDR ne allgm. API dafür zu geben evtl. auch nicht so verkehrt wäre. Man könnte dann ja auch andere Dinge damit abbilden (z.B. die Aufnahmen eines andeen VDR virtuel abbilden).
cu
Das Problem mit fuse ist der Feedback, dann bräuchte der VDR ne allgm. API mit dessen Hilfe fuse mit ihm reden könnte. Weil beim Versuch die Aufnahme abzurufen muss ja evtl. nen Dialog kommen der zum anschliessen der HDD auffordert und der VDR muss solange warten.
Nein, ein solches API muss es nicht geben, ich denke es reicht auch so was, oder eine entsprechende Erweiterung von restful/dbus2vdr.
Wobei du ja jetzt schon einen einfache Message von außen anzeigen lassen kannst. Ich denke das ist mit einem kleinen Python-Skript und AutoFS schnell gemacht.
Bei yaVDR reicht auch ein einfacher Dialog der vor dem VDR-Fenster aufpoppt.
Gerald
Warum so kompliziert? Ist doch eigentlich eine recht simple Funktion.
Das Verschieben auf die Archiv-HDD kann ja weiterhin über die reccmds
gemacht werden. Der VDR müsste nur eine vorhandene hdd.vdr auslesen,
den Benutzer zum Anschliessen der HDD auffordern.
Und der Code existiert ja schon in extrecmenu.
Moin!
dbus2vdr kann den Nutzer schon fragen:
https://github.com/flensrocker…r/blob/master/README#L188
Lars.
Dann nimm doch das extrecmenu oder was spricht dagegen? Ist ja nicht der einzige Mehrwert des Plugins.
Nein, ein solches API muss es nicht geben, ich denke es reicht auch so was
Der macht das VDR OSD aber zu IIRC sollter der VDR auch Plugin OSD über vorhandenes OSD anzeigen können, aber osdserver kann das nicht. Ferner darf der VDR nicht versuchen diese "fehlerhafte" Aufnahme abzuspielen (da hat yaVDR mit dem Fenster drüber auch das Problem).
Ferner klappt die Durchschnittsgrössenberechnung auch nicht ohne Schnittstelle dafür.
Ich denke ganz ohne Hilfe von Klaus geht das nicht (jedenfalls nicht sauber implementiert). Wobei, bei der epg Schnittstelle hats ja auch toll geklappt, also habe ich hier auch erstmal Hoffnung
cu
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
