Warum so kompliziert? Ist doch eigentlich eine recht simple Funktion.
Und der Code existiert ja schon in extrecmenu.
Wir würden das aber gerne loswerden.
Gerald
Warum so kompliziert? Ist doch eigentlich eine recht simple Funktion.
Und der Code existiert ja schon in extrecmenu.
Wir würden das aber gerne loswerden.
Gerald
Dann nimm doch das extrecmenu oder was spricht dagegen? Ist ja nicht der einzige Mehrwert des Plugins.
extrecmenu scheint schon seit längerem nicht mehr gepflegt zu werden.
Und das Aufzeichnungsmenu ist ja eine Grundfunktion des VDR.
Und Grundfunktionen will ich nicht unbedingt ersetzen.
Die Archivfunktion ist für mich der einzige Grund.
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.
Dir fehlt einfach die Phantasie. Eine mögliche Implementierung ist es die Recording-Dirs dieser Aufnahmen mit der Info-Datei und den Symlinks zu den .ts-files im Video-Verzeichnis zu behalten. Die Symlinks zeigen aber auf ein Verzeichnis, dass von AutoFS gemanagt wird. Jetzt brauchst du nur noch den Dialog, der anhand des Filenamens die richtige HDD anfordert und AutoFS mountet sie. Es gibt dann gar keine falsche Aufnahmen. Es gibt eine ganz normale Aufnahme die etwas lange braucht bis sie reagiert. das würde eben nicht nur mit dem VDR funktionieren, sondern mit jedem File-Zugriff auf die .ts-Datei.
Gerald
Nicht anhand des Filenamens. hdd.vdr ist eine normale Textdatei mit
einer ID als Inhalt. Ich hab die Platten nummeriert (0001, 0002....).
Mit autofs würde man aber eine Abhängigkeit schaffen, die nicht
unbedingt nötig ist. Da fänd ich mount besser.
Aber anscheinend nutzt sonst keiner Archiv-HDDs.
dbus2vdr kann den Nutzer schon fragen:
Sorry Lars, wie konnte ich daran zweifeln.
Gerald
Nicht anhand des Filenamens. hdd.vdr ist eine normale Textdatei mit
einer ID.
Ich benutze es nicht, aber ich kenne es. Ich bin wegen eines VDR-Patches an dem Extrecmenu-Code vorbeigekommen.
Ich weiß also wie es geht, finde es aber nicht gut.
Nur der VDR mit dem Extrecmenu-Plugin kommt so an die Dateien ran. Mit meine Lösung klappt das mit jedem Programm.
Mit autofs würde man aber eine Abhängigkeit schaffen, die nicht
unbedingt nötig ist.
Klingt albern. So bist du von extrecmenu abhängig.
Gerald
Dir fehlt einfach die Phantasie.
Ne klappt schon
Aber ich habe da generell nen anderen Ansatz für "was wäre schön" Wobei wir uns darin schon einig sind das die Hauptfunkionalität ausserhalb des VDR sein sollte.
Das Problem was ich sehe ist das es der VDR evtl. nicht mag wenn der Zugriffsversuch einen extrem langen Hänger produziert. Da fände ich es schon sauberer wenn der VDR da eingebunden ist (und dem User auch direkt Feedback gibt). Muss ja nicht viel an Code sein.
Aber anscheinend nutzt sonst keiner Archiv-HDDs.
Doch, ich nutze das auch.
cu
Ja, momentan bin ich abhängig davon. Da ich erst 3 Platten
voll habe, wäre es nicht sehr aufwändig, noch was an dem
Konzept zu ändern. Es soll nur bedienerfreundlich bleiben.
Aber es wäre erforderlich, dass der VDR es vorher mit einem
Dialog abfängt. Und wenn die Symlinks bestehen bleiben sollen,
wäre es eigentlich egal, ob autofs oder mount verwendet wird.
Es fehlt halt noch die Möglichkeit, eine Aufnahme wieder
zurückzuspielen. Aber diese Funktion hat extrecmenu auch nicht.
Und die Platte muss ja auch vorbereitet werden, d. h. formatieren,
und eine ID vergeben.
Ich will meinen VDR nicht allzusehr patchen, oder seine Grund-
funktionen ersetzen. Der MainMenuHooks Patch muss wohl bleiben.
Schon alleine wegen epgsearch, was wohl die meisten verwenden.
Behaupte ich mal.
Es fehlt halt noch die Möglichkeit, eine Aufnahme wieder
zurückzuspielen. Aber diese Funktion hat extrecmenu auch nicht.
Ginge schon mit einem Recording Kommando. Aber genau wie beim Auslagern der Aufnahme auf die Archiv HDD fehlt hier ne Möglichkeit das diese Kopierscripte mit dem Nutzer in Dialog treten (das müsste sein um es wirklich sauber umzusetzen).
cu
Moin!
Ich will mir auch mal was wünschen:
Unterstützung für mehrere OSD-Provider, die parallel betrieben werden können, denen getrennte Eingabegeräte zugewiesen sind.
D.h. mit zwei unterschiedlichen Fernbedienungen/Input-Devices werden zwei verschiedene OSD-Provider bedient, die dann jeweils "irgendwohin" ausgeben, Anwendungsfall OSD und GraphTFT.
Die "andere" Fernbedienung sind dann z.B. Knöpfe am Gehäuse, die dann explizit das Display am Gehäuse steuern und nicht das vdr-OSD.
Keine Ahnung, ob das jetzt so rüberkommt, wie ich mir das denke...
Lars.
Alles anzeigenMoin!
Ich will mir auch mal was wünschen:
Unterstützung für mehrere OSD-Provider, die parallel betrieben werden können, denen getrennte Eingabegeräte zugewiesen sind.
D.h. mit zwei unterschiedlichen Fernbedienungen/Input-Devices werden zwei verschiedene OSD-Provider bedient, die dann jeweils "irgendwohin" ausgeben, Anwendungsfall OSD und GraphTFT.
Die "andere" Fernbedienung sind dann z.B. Knöpfe am Gehäuse, die dann explizit das Display am Gehäuse steuern und nicht das vdr-OSD.
Keine Ahnung, ob das jetzt so rüberkommt, wie ich mir das denke...
Lars.
Das wünsch ich mir auch. Mit Graphtft ist der Vdr aktuell kaum bedienbar wenn man sich durch die einstellungen klickt. Habe deshalb bei mir Graphtft gepatched damit nur die Sendungs Infos gezeigt werden. Jetzt wird wenigstens nicht mehr das Osd ausgebremst.
Mfg Thomas
..und das ganze natürlich ohne nervige Zusatzpatches
Generell wünsche ich mir
- Übernahme wesentlicher Bestandteile ext-Patch
- flexiblere Behandlung der Menü Struktur
- optisch noch flexiblere Möglichkeiten (Auge isst mit, muss ja nicht gleich XBMC Konkurrenz machen)
Wo ist da der Fortschritt , wenn ich in jeder VDR-Kiste mindestens 2 Karten + Ci, volle Hardware , etc. verbauen muss, anstatt
einmal (bzw. 2 Karten) alles in einen Server ?
Vom Konfigurationsaufwand mal abgesehen.
Wenn ich im Schlafzimmer-VDR eine Aufnahme anschauen moechte , welche
der Wohnzimmer-VDR aufgenommen hat , dann muss ich den ja erst hochfahren, sollte er
ausgeschaltet sein. Bei Timern ja genauso.
Also ich komme jetzt nicht drauf , wo da der Nutzen sein soll.
Wahrscheinlich bin ich nur beschraenkt.
Ich dachte der Vorteil von VDR waere halt , dass man bei epgsearch irgendein Begriff eingibt und
irgendwann auf die Platte schaut , was drauf ist. Sowas mache ich aber doch lieber ueber eine Weboberflaeche , anstatt
von VDR ueber VDR.
Wenn es verschiedene Personen sind , welche ihren eigenen VDR haben. Ich wuesste jetzt nicht was Anderen bzw. mich
angeht was Andere fuer Timer setzen. Ist ja wie bei "Facebook"
OK , ist ein Hobbyprojekt , da haette ich auch keine Lust und Zeit Sachen zu programmieren , welche ich selber nicht brauche.
Btw. Programmierer sind wie Politiker.
Waehrend die einen immer nur "neue" Gesetze erlassen , koennen die Anderen ihre nicht Finger ruhighalten und muessen neue Features einbauen.
Das eine erzeugt ein Moloch an Gesetzen und das andere ist Bloatware.
Vielleicht VDR einfach so lassen wie er ist und sich auf das Wesentliche beschraenken.
Es spricht aber bei der Variante mit den gleichberechtigten Peers nichts dagegen, wenn du einen als "Server" ausstattest und ihn im Dauerbetrieb laufen läßt. Du musst dann halt nur deine Aufnahmen auf diesem VDR programmieren, was lt. Klaus ja auch gehen wird. Da dieser VDR dann immer läuft, kannst du von anderen auch immer auf dessen Aufnahmen zugreifen.
Dies ist aber nur EIN Anwendungsfall von vielen.Wenn es denn tatsächlich so wird, dass alle VDR's, die sich finden gleichberechtigt sind und gegenseitig ihre Resourcen nutzen können, kann sich jeder seine VDR's so einrichten und ausstatten, wie es für SEINEN Anwendungsfall am Besten ist.
Falk
ist halt ein altersack, er kann sich mit dem modernen kram nur schwer anfreunden.
Es spricht aber bei der Variante mit den gleichberechtigten Peers nichts dagegen, wenn du einen als "Server" ausstattest und ihn im Dauerbetrieb laufen läßt.
Sehe ich auch so. Nur weil die Peers gleichberechtigt sind heißt das ja nicht, dass man sie auch so nutzen muss.
Ich finde die Idee auf jedem Fall interessant. Timer fernzuprogrammieren ist da schon ein sehr guter Anfang. Richtig interessant wird das dann, wenn Tuner vom "Server-Peer" an die "Client-Peers" "geshared" werden können.
Zitatist halt ein altersack, er kann sich mit dem modernen kram nur schwer anfreunden.
Also wenn du hotzenplotz mein reales Alter an meinem "Nick" ausmachst ,
dann muss ich bei dir die Groß-Kleinschreibweise zu deiner Zahl im Nick mit einbeziehen.
Warte mal..1. Klasse faengt man damit an und da ist man so ~6 Jahre alt.
Hmm, da kommt es mit hotzenplotz5 ja wirklich hin.
Laesst ja hoffen , dass du den einen Satz ab Sommer richtig hinbekommst.
Aber keine Angst, den Kasperl , den gibt es in Wirklichkeit garnicht.
(ja ich weiss , dass ich gerade genao so einen stuss verzapft habe wie er ;))
ZitatEs spricht aber bei der Variante mit den gleichberechtigten Peers nichts dagegen, wenn du einen als "Server" ausstattest und ihn im Dauerbetrieb laufen läßt.
Du musst dann halt nur deine Aufnahmen auf diesem VDR programmieren, was lt. Klaus ja auch gehen wird. Da dieser VDR dann immer läuft, kannst du von anderen auch immer auf dessen Aufnahmen zugreifen.
Das macht man zur Zeit doch schon mit dem Plugin "remotetimer" und was du hier beschreibst , ist das Client-/Server Prinzip.
Nur leuchtet es mir nicht ein , warum ich vollwertige und gleichberechtigte Geraete hinstelle , nur damit mal jener oder jener den Server spielen darf.
Wenn jeder VDR seine Aufnahme selber speichert , dann darf ich mir ja auch merken , wo was liegt.
ZitatDies ist aber nur EIN Anwendungsfall von vielen.Wenn es denn tatsächlich so wird, dass alle VDR's, die sich finden gleichberechtigt sind und gegenseitig ihre Resourcen nutzen können,
kann sich jeder seine VDR's so einrichten und ausstatten, wie es für SEINEN Anwendungsfall am Besten ist.
Nein , in der Praxis hast du doch keine Wahl mehr bei wechselnden Servern.
Alle Geraete muessen im Idealfall "komplett" ausgeruestet , vollverdrahtet (Signalleitung) und sowohl als Client und Server konfiguriert/bestueckt werden.
Da du nie weisst , welches Geraet nun den Serverpart uebernimmt , muss zB jeder VDR ein eigenes shutdownscript haben , etc. um nur mal
ein kleines Puzzleteilchen zu nennen. Von Schreib- und Leserechten mal ganz abgesehen.
Das wird noch ein Spass (Sehe schon die VDRler , welche auf root wechseln , weil
sie ihre gegenseitigen Aufnahmen nicht oeffnen koennen obwohl selber User(vdr) , nur unterschiedliche UserIDs etc. .)
ZitatSehe ich auch so. Nur weil die Peers gleichberechtigt sind heißt das ja nicht, dass man sie auch so nutzen muss.
Ja , deswegen hat Microsoft die Internetverbindungsfreigabe( so war doch der Name oder) auch wieder ausgebaut, weil
nun eh ueberwiegend Router eingesetzt werden.
Der Gedanke kam mir sofort in den Sinn als ich "timer sharing" gelesen habe. Nichts fuer ungut..
ZitatSehe ich auch so. Nur weil die Peers gleichberechtigt sind heißt das ja nicht, dass man sie auch so nutzen muss.
Zitatch finde die Idee auf jedem Fall interessant. Timer fernzuprogrammieren ist da schon ein sehr guter Anfang.
Hallo...live ,vdradmin , remotetimer...
Wie sieht das denn bei dir in der Praxis aus ?
Sitzt du an Peer 1 und schaltest erstmal Peer 2 an um dort den Timer zu setzen ?
Wenn deine Frau ankommt und dich erstmal fragen muss, welche Geraete denn nun angeschaltet werden muessen
um im Wohnzimmer Aufname-X anzuschauen.
ZitatRichtig interessant wird das dann, wenn Tuner vom "Server-Peer" an die "Client-Peers" "geshared" werden können.
Klar , "Server-Peers-/Client-Peers Loesung" hoert sich dann doch besser an als
"Client-/Server Loesung" . lol
Wenn der selbe Code verwendet werden kann mit den Peers aber der Server durch welchen Mechanismus auch immer die Aufgaben immer übernimmt, dann sehe ich da keinen Unterschied, ausser das es flexibler ist. Und ein Wohnzimmer VDR + Schlafzimmer VDR + Kinderzimmer VDR kommt hier doch nicht so selten vor. Wenn ein Timerkonflikt da ist, und die Timer sich dann auf andere Rechner im Netz bewegen und die Aufnahme später wieder den Weg zurück findet, klingt das für mich schon recht nett. Auf jedenfall sinnvoller als ganze Codeteile neu zu schreiben nur weil man weiss das da Code ist den man in bestimmten Szenarien nie benutzt. Was fehlt denn den Client/Server Fetischisten für eine richtige Client/Serverlösung mit dem VDR ? Was ist an "auch möglich, aber nicht nur" so schlecht ?
Wie gesagt ich verstehe nicht was "Client/Server" bedeuten soll. Den Firlefanz den MythTV da macht alles akademisch aufzuteilen und damit den 90% Use Case dermassen zu verkomplizieren ?
Wenn man einen reinen Client will, dann kann man ja z.b. VOMP nehmen und dort mein VDPAU Ausgabeplugin einbauen.
Ansonsten ist sehr viel von Client + Server gleich. also ist die Idee VDR auf Peer to Peer auszubauen nicht verkehrt.
Was braucht man:
Im Großen und Ganzen gibt es für die meisten Sachen schon sehr gute Ansätze.
Ein großes Problem ist SVDRP, was immer wieder für Probleme und Ärger sorgt, wenn dies mehrere
Sessions und nicht Blockierend unterstützen würde, wäre schon viel geholfen.
Auch eine Zentrale Verwaltung würde allen helfen, im Moment muß man bei jedem Plugin zb. den Server
konfigurieren.
Edit: Zugriff aufs Setup hinzugefügt.
Johns
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!