2.0 erreicht - wie geht es jetzt weiter?

  • 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


    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

  • 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


    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

  • 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


    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

  • 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


    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


  • 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.


  • 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

    VDR:
    Hardware: Thermaltake DH102, Zotac ION ITX-F-E, 2Gig Ram, TechnoTrend
    dual DVB-S2 6400, TechnoTrend Connect CT-3650,


    Software: EasyVDR 1.0

  • ..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. :D
    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

  • 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.

  • Zitat

    ist 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. :P
    (ja ich weiss , dass ich gerade genao so einen stuss verzapft habe wie er ;))


    Zitat

    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.


    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.


    Zitat

    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.


    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 :D (Sehe schon die VDRler , welche auf root wechseln , weil
    sie ihre gegenseitigen Aufnahmen nicht oeffnen koennen obwohl selber User(vdr) , nur unterschiedliche UserIDs etc. .)


    Zitat

    Sehe 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.. :D


    Zitat

    Sehe ich auch so. Nur weil die Peers gleichberechtigt sind heißt das ja nicht, dass man sie auch so nutzen muss.


    Zitat

    ch 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.


    Zitat

    Richtig 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 ?

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • 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:

    • Zugriffsregeln, hier klafft im Moment eine sehr große Lücke und jedes Plugin macht hier etwas eigenes.
    • EPG Austausch, siehe epgsync Plugin.
    • Kanallisten Austausch, ich kenne nichts fertiges, mache immer vdr stop und scp.
      Wobei lokale Kanallisten gar nicht so verkehrt sind, aber hier soll sich ja auch etwas tun (Favoritenverwaltung).
    • Zugriff auf LiveTV, macht streamdev sehr gut
    • Zugriff auf Aufnahmen, mit NFS usw. nicht besonders einfach, wird in streamdev gerade eingebaut
    • Timer, macht remotetimer oder live.
    • OSD Ich weiß nicht ob man dies umbedingt braucht, aber remote OSD Plugin ist nicht schlecht.
    • Zugriff aufs Setup (dafür braucht man meist das obige OSD)


    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

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    Einmal editiert, zuletzt von johns ()

Jetzt mitmachen!

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