[Umfrage] Favoritenliste oder Vernetzung?

  • So besonders wichtig sind mir momentan beide Themen nicht, das wichtigste ist mir, das die Zuverlässigkeit nicht leidet.
    Denn was nützten einem die ganzen tollen Funktionen, wenn man es dauernd Abstürze und so gibt.
    Meinen aktuellen Produktiv-VDR hab ich schon seit Jahren und ich kann an einer Hand abzählen wie viele Aufnahmen fehlgeschlagen sind und bei keiner war der VDR schuld. In dem Sinne weiter so :respekt !



    Ich hab mal für Vernetzung gestimmt.
    Bis vor garnicht langer Zeit hatte ich das zwar für völlig überflüssig gehalten, aber bei den ganzen NAS, Tablets, Smart-TV und SAT-IP Geräten, fängt es langsam an Sinn zu machen.
    Aufnahme und Wiedergabe trennen und mit einem zentralen Aufnahmegerät (zB. so einer SAT-IP-BOX, wenn man denn dort einen VDR drauf bekommt), mehrere nur temporal laufende VDRs bei den Ausgabegeräten bedienen.



    Eine Favoritenliste vermisse ich nicht.
    Die Kanalgruppen sind echt genial, wenn man die mal einigermassen sinnvoll erstellt hat, hat man alles voll im Griff. Viel besser als bei allen anderen Receivern, die ich kenne.
    Was schön wäre, wäre wenn man die Kanalgruppen auch aus dem OSD heraus erstellen und verwalten kann. Ich denke dann würden das auch mehr Leute nutzen. (Sofern das schon geht habe ich das auch nach 10Jahren VDR noch nicht raus gefunden wie :whistling: .)


    Wenn so eine Favoritenliste Sinn machen soll, dann sollte man damit auch Alternativ-Kanäle bei unterschiedlichen Empfangsarten abdecken. Das wäre dann ein echter Mehrwert.
    Da werden dann zB. nach einer Priorität erst die SAT- und wenn die Belegt sind, die DVB-T-Kanäle verwendet. Wobei das sicher nicht so trivial zu lösen sein wird....
    Sonst bräuchte man ja nur die Gruppe "Favoriten" in der channels.conf definieren und alle anderen Kanäle im Favoriten-Modus unterdrücken.
    Oder man macht gleich mehrere vom Benutzer definierbare Filter für die channels.conf, dann kann man nach Kanalgruppe, Satellitenposition oder was weiss ich noch filtern.



    Auch wenn das jetzt nicht unbedingt auf Begeisterung stösst, wie wäre es als erstes mal ein reinen Patch-Release zu machen?
    Also mal die gebräuchlichsten Patches (zB. Jumpplay fällt mir da spontan ein) rauszusuchen und so vorbereiten, dass Klaus sie aufnehmen mag. Also aufs nötigste entkernen, dafür sorgen, dass man die Funktion auch sicher deaktivieren kann usw. .
    Ich denke mal das wird vielen Paketerstellern und Selberkomilierern das Leben erleichtern und diese elenden, fehleranfälligen Monsterpatches eindämmen.
    Ich weiss, das das schon mal diskutiert worden und irgendwie im Sande verlaufen ist. Damals war bei HD noch Grossbaustelle, aber jetzt wäre eigentlich eine gute Gelegenheit.

    Gruss
    SHF


  • Hmm, falls wirklich Vernetzung als nächstes kommt, dann ist ja mein Hobbyprojekt irgendwann obsolet ;(


    kls
    Falls Vernetzung wirklich kommt, dann ist hoffentlich das vompserver plugin und der client, einen Blick wert für die Inspiration.
    Wenn gewünscht, kann ich auch schreiben, welche Designfehler, gemacht wurden, die ich bisjetzt bereue bzw. was wichtig ist bei der implementation.
    Die Umschaltzeiten sind ganz gut für das vomp Protokolll.


    Dann sollte ich meine Arbeit an einem vlc plugin für vomp einstellen?


    Marten

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

  • Dann sollte ich meine Arbeit an einem vlc plugin für vomp einstellen?

    Bitte nicht!
    VOMP ist bisher der einzige Standard, der die meisten Funktionen des VDR an verschiedenen Clients abbildet und einfach einzurichten ist.....
    Genau wegen der Erfahrungen, was man alles falsch machen kann, solltest Du bitte, bitte weitermachen...


    Gruß Marcus

    VDR: DD 5.5 mit 4 Tunern , Intel 847 mit nvidia Kepler 630 , 4GB RAM , 1x 1TB , yavdr 0.5 X10 Fernbedienung von Pollin zu Steuerung, Diverse XBMC (openelec + Windows) im Haus als Clients

  • ... zumal es ja jetzt erstmal primär um "VDR zu VDR Kommunikation" geht. Ob und wie man dann später eventuell z.B. mit VLC einen von einem VDR freigegebenen Tuner zum Live-TV-Schauen nutzen kann, wird sich dann erst noch zeigen. Wahrscheinlich wird da dann zumindest auf VLC-Seite ein Plugin fällig.

  • Bitte nicht!
    VOMP ist bisher der einzige Standard, der die meisten Funktionen des VDR an verschiedenen Clients abbildet und einfach einzurichten ist.....
    Genau wegen der Erfahrungen, was man alles falsch machen kann, solltest Du bitte, bitte weitermachen...


    Gruß Marcus

    VOMP ist nicht der einzige Standard, es existiert auch noch XVDR welches mittlerweile sogar eine libxvdr für z.B. einen VDR als Client.


    Gruß Ralph

  • Ich habe für Vernetzung abgestimmt, aber kls kannst du bitte kurz erklären was du mit Favoritenliste meinst?
    Ich sehe da ehrlich gesagt kein großen Bedarf. Die Channels.conf kann man doch anpassen wie man möchte und man kann sich doch eine Gruppe ":Favoriten" am Anfang der Datei setzen und dann packt man dort seine Kanäle hinterher.
    Vielleicht denk ich auch nur zu einfach :)
    Evtl. wäre es wünschenswert wenn man ein Kanal 2x in der channels.conf haben kann (ich glaube derzeit wird ein zweiter Eintrag beim Laden gelöscht) dann könnte man den Eintrag einmal unter der Favoritengruppe haben und einmal in der normalen Sortierung, aber das ist ja sicherlich nur eine Bedingung entfernen damit der 2. Eintrag nicht mehr beim laden gelöscht wird und keine große Änderung am core vdr.


    Grüße
    Martin


  • Ich sehe da ehrlich gesagt kein großen Bedarf. Die Channels.conf kann man doch anpassen wie man möchte und man kann sich doch eine Gruppe ":Favoriten" am Anfang der Datei setzen und dann packt man dort seine Kanäle hinterher.


    Ist schon deshalb keine Option, weil nicht via OSD änderbar. Mag ja sein, dass es einige toll finden die Kanalliste im Texteditor bearbeiten zu können, aber ich mache sowas einfach lieber mit der Fernbedienung am TV.

  • kls Danke für den Thread
    @Mreimer: so verschieden sind die Geschmäcker :)
    Ich handhabe das lieber in der Datei, bevor ich mit der Fernbedienung einen Kanal verschiebe. Da mach ich mir auch den Aufwand bei Fernsehern (jetzt mal ohne externen Receiver) die Kanalliste über Debug/Admin/Service -Schnittstelle zu kopieren, auf dem Rechner bearbeiten und dann zurückspielen. Mit der Fernbedienung nein Danke.
    Aber gut jedem das seine :)


    Grüße
    Martin

  • Hi,


    Ich handhabe das lieber in der Datei, bevor ich mit der Fernbedienung einen Kanal verschiebe. Da mach ich mir auch den Aufwand bei Fernsehern (jetzt mal ohne externen Receiver) die Kanalliste über Debug/Admin/Service -Schnittstelle zu kopieren, auf dem Rechner bearbeiten und dann zurückspielen. Mit der Fernbedienung nein Danke.


    tztz, Du arbeitest mit der channels.conf und kennst die besten Features (:@[Kanalnummer]) dieser nicht ;) .
    So ist die regüläre channels.conf schon fast die Favoritenliste.


    Auch ich kann das Rumgewürge an den sogenannten "Smart-TV's" mit der Fernbedienung nicht ab, zumal das Samsung-Gerät meiner Schwiegereltern ein Mischen von DVB-C und analogem TV in der Favoritenliste nicht zulässt. Des Weiteren kann man ja auch hier die Liste auf einen USB-Stick runterladen und dann am Rechner bearbeiten, was wiederum nur mit grottigen Windows Programmen geht und ich keinen nativen Windows-Rechner mehr habe. So gesehen ist der VDR hier schon Jahre voraus gegenüber den sogenannten "Smart-TV's".


    Grüße,
    j.

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 8GB RAM | 120GB SSD System + 3TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P553 | SEDU + 96 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

  • tztz, Du arbeitest mit der channels.conf und kennst die besten Features (:@[Kanalnummer]) dieser nicht ;) .
    So ist die regüläre channels.conf schon fast die Favoritenliste.


    Genau das ist ja mein Reden, deswegen habe ich ja nicht verstanden was mit Favoritenliste gemeint ist, sprich doch ich keine die besten Features der channels.conf, siehe dazu auch das Plugin in meiner Signatur ;)


    Grüße
    Martin

  • Hätte da mal eine Frage bzgl Bouquets, bin grad dabei dieses zu verwirklichen (tv+radio bouquet) handling und gui ist schon fertig. Die Bouquetlisten enthalten nur die channelid, quasi als link zum eigentlichen kanal + wie gewohnt Seperatoren, Damit sollten eigentlich keine wünsche offen bleiben. Alles wunderbar. Da das ganze als Plugin laufen soll und die normale chanels.conf nicht angefasst wird stehe ich nun wieder mal vor dem Problem mit den Switchmethoden ( DisplayChannel), dem CurrentChannel in der device.h und den Kanalnummern, da diese sich auf die Channels.conf beziehen.


    Ohne Patch wird es wohl nicht gehen. Nun wollte ich mal fragen ob du da einen Tip hättest wie man dies am besten lösen könnte.


    Schön wäre es ja wenn alle Kanalbezogenen Methoden mit der channelid arbeiten würden, anstatt mit der Kanalnr. und auch der "CurrentChannel" als channelid gesetzt werden würde.
    Dann wäre es möglich die Kanalnr. über die channelid zubekommen, je nach dem was man gerade nutzt ( pur channels.conf, bouquet tv oder radio ... ).

  • Hätte da mal eine Frage bzgl Bouquets, bin grad dabei dieses zu verwirklichen (tv+radio bouquet) handling und gui ist schon fertig. Die Bouquetlisten enthalten nur die channelid, quasi als link zum eigentlichen kanal + wie gewohnt Seperatoren, Damit sollten eigentlich keine wünsche offen bleiben. Alles wunderbar. Da das ganze als Plugin laufen soll und die normale chanels.conf nicht angefasst wird stehe ich nun wieder mal vor dem Problem mit den Switchmethoden ( DisplayChannel), dem CurrentChannel in der device.h und den Kanalnummern, da diese sich auf die Channels.conf beziehen.


    Ohne Patch wird es wohl nicht gehen. Nun wollte ich mal fragen ob du da einen Tip hättest wie man dies am besten lösen könnte.


    Schön wäre es ja wenn alle Kanalbezogenen Methoden mit der channelid arbeiten würden, anstatt mit der Kanalnr. und auch der "CurrentChannel" als channelid gesetzt werden würde.
    Dann wäre es möglich die Kanalnr. über die channelid zubekommen, je nach dem was man gerade nutzt ( pur channels.conf, bouquet tv oder radio ... ).


    Ich werde mir über all diese Dinge Gedanken machen, wenn ich daran gehe, Favoritenlisten in VDR einzubauen. Im Moment kann und will ich dazu nichts sagen, da ich mich zur Zeit mit dem Thema drehbare Antennen beschäftige.


    @all: Ich schaue ja normalerweise mehrmals täglich hier im VDR-Portal rein, aber bei dem momentanen Traffik ist leider an ein vernünftiges Arbeiten nicht mehr zu denken. Ich versuche, mich auf mein momentanes Thema zu konzentrieren, doch wenn ich dann doch (neugierigerweise ;) mal wieder ins Portal reinschaue, dann gibt's gleich wieder etliche Postings, die mich wieder irgendwie im Hinterkopf beschäftigen (teilweise auch ärgern) und damit aus dem Konzept bringen.
    Ich habe mich daher nach reiflicher Überlegung dazu entschlossen, eine "Auszeit" vom VDR-Portal zu nehmen, und mich erst wieder zu melden, wenn ich mein momentanes Thema abgeschlossen habe. Ich weiß noch nicht, ob ich es durchhalte, aber der Wille ist da. Sonst komme ich hier nämlich nicht weiter...
    Falls es Bug-Reports zur 2.0.1 gibt, postet diese bitte auf der VDR-Mailingliste oder schickt sie an vdr-bugs@tvdr.de.


    Bis dann
    Klaus

  • The favorites / flexible channel lists are a basic feature in modern receivers and therefore my vote goes for it. Also, the number of households with multiple VDRs seems to be a rather minority in the VDR community (IMO) or then things are just rather different in Germany. Anyway, I'd suggest to add multiple channel lists with certain namespaces at least in the UI and finally implement a LCN support for them.

    +1


    ich teile diesbzgl. rofaror's meinung! hier im forum krebsen eher die 'freaks+devs+distro-maintainer" herum. ja, Klaus/KLS auch .. reine anwenderfragen kommen eher selten ... :o|


    ein server/client-setup ( neuerdings "peer-setup" - schon fast ein "autonomes system" ) ist doch eher ein spezialbereich (hausinstallationen) und stellt sich auch in den diversen diskussionen hier im forum als ziemlich komplex heraus (grundsätzlich ist das meiste als "basis" bereits bzgl. netzwerk schon als "open-src" mit vdr abgedeckt).


    es ist immer wieder der "reizende" vergleich mit den 0815-receivern hier im forum zu lesen. ja, es gibt noch leute, die vdr als einzel-reicever einsetzen ..


    deshalb (vorab) aus meiner 'kleinen' perspektive für "The favorites / flexible channel lists" !!


    ciax


    ps: sorry rofaror for being impolite answering in german .. just agreeing.

    Lascala LC17 - tribute to viking ;o) + atric IR / SoC ASUS J3455M-E / OctopusNet S4 / yavdr-(testing) vdr / output: graphTFT-fe via 6.4" TFT & DVB-S/S2 via FullHD / NVidia GT1030 passiv

  • Hätte da mal eine Frage bzgl Bouquets, bin grad dabei dieses zu verwirklichen (tv+radio bouquet) handling und gui ist schon fertig. Die Bouquetlisten enthalten nur die channelid, quasi als link zum eigentlichen kanal + wie gewohnt Seperatoren, Damit sollten eigentlich keine wünsche offen bleiben. Alles wunderbar. Da das ganze als Plugin laufen soll und die normale chanels.conf nicht angefasst wird stehe ich nun wieder mal vor dem Problem mit den Switchmethoden ( DisplayChannel), dem CurrentChannel in der device.h und den Kanalnummern, da diese sich auf die Channels.conf beziehen.


    Ohne Patch wird es wohl nicht gehen. Nun wollte ich mal fragen ob du da einen Tip hättest wie man dies am besten lösen könnte.


    Schön wäre es ja wenn alle Kanalbezogenen Methoden mit der channelid arbeiten würden, anstatt mit der Kanalnr. und auch der "CurrentChannel" als channelid gesetzt werden würde.
    Dann wäre es möglich die Kanalnr. über die channelid zubekommen, je nach dem was man gerade nutzt ( pur channels.conf, bouquet tv oder radio ... ).


    Nimm Dir doch die Kanalnummer mit in dein Plugin. Müsste doch gehen, oder? Channel->Number() in channels.h?

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Mit was arbeitest du mit dem Index aus Channels? Oder welche ID meinst du? Wenn du mit dem Index arbeitest dann so rein aus dem Bauch heraus, da ich ähnliches in meinen Plugin mache

    Code
    cChannel *channel = Channels.Get( CHANNELINDEX );
    cDevice::PrimaryDevice()->SwitchChannel(channel, true);


    Grüße
    Martin

  • Moin!


    Für meinen Geschmack sollte man in einem Plugin eigentlich immer mit der Channel-ID arbeiten. Index und Nummer eines Kanals ändern sich, wenn man die Kanäle umsortiert oder neue dazukommen oder man in einer Gruppe die Startnummer ändert usw.
    Die Channel-ID bekommt man mit cChannel::GetChannelID().


    Lars.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!