[ANNOUNCE] VDR developer version 2.3.7

  • Gruß MegaX


  • Hi Klaus,


    auch diesmal wieder vielen Dank für die neue Version.

    Gruß MegaX


  • Erst mal vielen Dank an Klaus für die neue Version


    Leider auch ein Problem mit streamdev:


    Code
    1. connectionVTP.c:44:2: error: ‘cSchedulesLock’ does not name a type
    2. cSchedulesLock *m_SchedulesLock;
    3. ^
    4. connectionVTP.c: In destructor ‘cLSTEHandler::~cLSTEHandler()’:
    5. connectionVTP.c:213:9: error: ‘m_SchedulesLock’ was not declared in this scope
    6. delete m_SchedulesLock;
    7. ^


    vdr-User-# 755 to_h264 chk_r

  • Ich vermute mal, daß m_SchedulesLock nirgendwo wirklich verwendet wird. Daher einfach mal komplett löschen.


    Und bei der Gelegenheit auch gleich noch schauen, ob es irgendwo ein Member vom Typ (cSchedules *) gibt, über das sich das Plugin einen längerfristigen Pointer auf die Schedules merkt. Das ist seit dem strikten Locking nicht mehr zulässig. Man muß sich den Pointer immer neu holen, wenn man ihn braucht.


    Klaus

  • Bei so schönen Wetter sitzt man auf dem Motorrad und veröffentlicht keine neue VDR Version ... ;D


    Vielen Dank für Deine Mühen und die neue Version.


    Gruß
    FRank

    HowTo: APT pinning

  • Leider auch ein Problem mit streamdev

    GuckstDU hier.

  • EDIT: Der Crash tritt nur auf, wenn ich osd2web aktiviert habe. Ich poste das daher im entsprechenden Thread nochmal.
    EDIT2: Für's Protokoll: war ein osd2web-Problem und ist dort gefixt.




    Habe hier einen Segfault beim Tunen auf Sparhandy TV.

    Code
    1. Sparhandy TV;BetaDigital:12460:HC34M2S0:S19.2E:27500:3071=2:3072=deu@3:0:0:659:133:5:0



    Mit 2.3.6 tritt das nicht auf, wobei ich auch die Plugins teilweise zwischen 2.3.6 und 2.3.7 geupdated habe.


    Christian

  • Ich hätte da mal einen Wunsch für eine Erweiterung des VDR. Aktuell unterstützt der VDR ja nur ein aktives OSD-Menü. Für graphtft musste man deswegen den VDR immer patchen. Jetzt wäre es schön, wenn man z.B. auch für das neue osd2web Plugin im Zuge der Weiterentwicklung vielleicht auch mal die API aufbohren könnte. Es gibt doch einige Personen, die dem alten Verhalten von graphtft nachtrauern ;D

    VDR 2.4.0 Kodi 17.4-Krypton
    OpenSUSE Leap 42.3, Kernel 4.16.9, Thermaltake DH102, ASHRock Q2900M, CineS2 V6.5.
    Plugins:
    radio v1.1.0-6-g468280f , externalplayer 0.3.3, trayopenng 1.0.2, fritzbox 1.5.3, cdplayer 1.2.4, femon v2.3.0-GIT-6112484, menuorg 0.5.2, extrecmenu v1.2.5-git, streamdev-server v0.6.1-git, extrecmenu v1.2.4, cecremote 1.4.2, osd2web 0.2.33, softhddevice v0.7.0-GIT282c346

  • Hi,


    wenn man das noch ein wenig flexibler gestalten möchte, wünsche ich mir schon sein langem die Möglichkeit mehrere OSDs haben zu können. Es wäre also schön wenn solche Plugins wie das graphtft, osd2web oder restfulapi ein OSD öffnen können, dass auf dem Haupt Ausgabedevice nicht angezeigt wird. Das OSD des Ausgabedevices sollte von den Plugins nicht gestört werden.


    Claus

    MLD 5.1 mit vdr 2.2 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM -
    WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.1 mit vdr 2.2 - Banana Pi - softhddevice
    MLD 5.0 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT
    MLD 2.0 mit vdr 1.6 - SMT-7020s - 80GB HDD

  • Es wäre also schön wenn solche Plugins wie das graphtft, osd2web oder restfulapi ein OSD öffnen können, dass auf dem Haupt Ausgabedevice nicht angezeigt wird.


    Genau das geht aber doch, zumindest mit osd2web.


    Das OSD des Ausgabedevices sollte von den Plugins nicht gestört werden.


    Und genau das geht eben nicht, zu einer Zeit nur ein OSD, aber warum willst du den VDR von zwei Stellen konkurrierend bedienen?


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.0/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.0/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.0 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD Red WD30EFRX 3TB in SW Raid5

  • Weshalb gibt es dann einen osd2web Patch für den VDR?

    Gruß
    Frodo

  • Weil das wie immer schlecht dokumentiert ist, es wird gefühlt seit 2.3.4 oder 5 kein Patch mehr im vdr benötigt. Jörg sollte den dringend aus dem Source nehmen wenn noch nicht geschehen

    CKone: yavdr-ansible/18.04 LTS/2.4.0/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.0/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.0 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD Red WD30EFRX 3TB in SW Raid5

  • Und genau das geht eben nicht, zu einer Zeit nur ein OSD, aber warum willst du den VDR von zwei Stellen konkurrierend bedienen?


    Je nach Plugin hat das verschiedene Gründe:
    - restfulapi: Das setze ich im Webinterfave ein, um einen VDR über den Browser zu konfigurieren. Und das würde ich gerne machen, ohne auf dem Hauptausgabe Device ein OSD zu öffnen, also z.B. während meine Frau TV schaut.
    - osd2web: Genau wie restfulapi
    - graphtft: um z.B. Timer programmieren zu können, ohne das das OSD auf dem TV auf geht.
    - xineliboutput: Um mehrere vollwertige Clients mit nur einem VDR nutzen zu können
    - MPV-VDR-Streamdev-Client: Um beliebig viele Clients (auf beliebigen Plattformen) mit vollwertigem VDR OSD nutzen zu können
    - ...


    Claus

    MLD 5.1 mit vdr 2.2 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM -
    WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.1 mit vdr 2.2 - Banana Pi - softhddevice
    MLD 5.0 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT
    MLD 2.0 mit vdr 1.6 - SMT-7020s - 80GB HDD

  • Also mehrere OSDs gleichzeitig, die unabhängig voneinander bedient werden können, das geht schon mal überhaupt nicht! Das Chaos, das dadurch enstehen kann, möchte ich mir nicht antun.


    Zu einer Zeit genau *ein* OSD ist sicherlich die einfachste und sauberste Lösung.


    Sollte es gleichzeitig mehrere OSDs geben, so müssten diese vollkommen synchron laufen. Das heißt, jede über die FB ausgelöste Aktion müsste gleichzeitig auf allen OSDs dargestellt werden. Das scheitert aber allein schon daran, daß jedes OSD eine andere Zahl von Menüzeilen haben kann. Der Aufwand, hierfür eine einfache Lösung zu finden, erscheint mir unverhältnismäßig hoch.


    Klaus

  • Nun, dass nur Einer eine Eingabe zur selben Zeit machen kann, sehe ich ein und das macht ja auch Sinn, aber weshalb sollt denn die Ausgabe nicht auf mehreren "Geräten" gleichzeitig erfolgen können?


    Man könnte doch sicherlich dafür sorgen, dass wenn von "Gerät 1" ein Eingabe Event kommt, dann die Eingabe für x Millisekunden die Eingabe für alle Andern gesperrt ist, oder?

  • Das Hauptproblem sind die unterschiedlichen Zeilenzahlen der Menüs. Wenn sichergestellt werden könnte, daß alle OSDs immer die selbe Zahl an Menüzeilen haben, dann wäre es vielleicht denkbar.


    Klaus

  • Das legt jede Skin für sich individuell fest:

    Code
    1. class cSkinDisplayMenu : public cSkinDisplay {
    2. ...
    3. virtual int MaxItems(void) = 0;
    4. ///< Returns the maximum number of items the menu can display.


    Hängt z.B. ab von der Größe des OSDs und des verwendeten Fonts.


    Klaus

  • Das heißt, jede über die FB ausgelöste Aktion müsste gleichzeitig auf allen OSDs dargestellt werden.


    Ja, ansonsten wird das auch für den Bediener schnell unübersichtlich 8)

    Zitat

    Das scheitert aber allein schon daran, daß jedes OSD eine andere Zahl von Menüzeilen haben kann.


    Das Problem ist doch im Prinzip einfach lösbar. Jedes Skin/OSD kümmert sich selber um das Zeichnen der Menüs incl Scrolling. Der VDR braucht dann nur Hoch/Runter und ggf noch Anfang/Ende des Menüs zu liefern. So ist doch sichergestellt, dass immer eindeutig eine Menüzeile ausgewählt ist. Allenfalls für ein Page-Up/Down müsste man halt die kleinste darstellbare Zeilenzahl der aktiven OSDs als Offset für alle OSDs verwenden.

    VDR 2.4.0 Kodi 17.4-Krypton
    OpenSUSE Leap 42.3, Kernel 4.16.9, Thermaltake DH102, ASHRock Q2900M, CineS2 V6.5.
    Plugins:
    radio v1.1.0-6-g468280f , externalplayer 0.3.3, trayopenng 1.0.2, fritzbox 1.5.3, cdplayer 1.2.4, femon v2.3.0-GIT-6112484, menuorg 0.5.2, extrecmenu v1.2.5-git, streamdev-server v0.6.1-git, extrecmenu v1.2.4, cecremote 1.4.2, osd2web 0.2.33, softhddevice v0.7.0-GIT282c346