[ANNOUNCE] VDR developer version 1.7.25

  • jau, dann ist es nicht zwingend an pute gekoppelt und auch andere Plugins können in Ruhe ihre Daten reinschieben.


    Keine dumme Idee per svdrpsend - und/oder eine äquivalente Funktion die ein Plugin aufrufen kann (in meinem Laien-C gesprochen)


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/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.1/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
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Das hatte mein Script früher so gemacht, leider dauert dann das EPG einlesen so ca. 45 Min. und das finde ich, ist mir zu lange...


    45 Minuten für das EPG einges Kanals? Da läuft irgendwas gewaltig schief. Schiebst du die da einzeln per svdrpsend rein?


    cu

  • Moin!


    An die EPG-Mischer (zu denen ich mich auch zählen würde, auch wenn ich es momentan noch nicht tue):
    Der Hauptgrund zum Mischen sind doch meistens "nur" bessere Beschreibungen und Episodentitel, oder?
    Was helfen würde, wäre eine feinere Steuerung, was der vdr an einem Event überschreiben darf. Sprich, wenn man mal den Titel, Untertitel und Beschreibung aktualisiert hat, dann soll der vdr nur noch den Rest wie Startzeit usw. aktualisieren.


    Wäre das so richtig beobachtet?


    @C-3PO
    Hast du mal ein EPG-Update mit dbus2vdr probiert? Es hätte zumindest den Vorteil, das SVDRP nicht die ganze Zeit blockiert wäre. Ob es schneller ist, würde mich auch mal interessieren.


    Lars.

  • An die EPG-Mischer (zu denen ich mich auch zählen würde, auch wenn ich es momentan noch nicht tue):
    Der Hauptgrund zum Mischen sind doch meistens "nur" bessere Beschreibungen und Episodentitel, oder?


    Ja, ich denke schon. Ich finde es gut das Sender EPG nutzen zu können (reagiert oft schneller auf Programmänderungen) und es einfach um Episodentitel und Flags (country, year, category *) ) ergänzen zu können.


    Läuft hier, wie schon erwähnt, seit Jahren wunderbar. Und es ist wirklich schade das das einfach mal so nebenbei weggewischt wird.


    Der nächste Schrit wäre dann das das externe EPG nicht nur das Sender EPG ergänst sondern auch fehlende Events auffüllt, so das man immer EPG hätte egal ob Sender EPG oder externes ausfallen. Das kann xmltv2vdr nicht, und wird es jetzt vermutlich auch niemals mehr können.


    Was helfen würde, wäre eine feinere Steuerung, was der vdr an einem Event überschreiben darf. Sprich, wenn man mal den Titel, Untertitel und Beschreibung aktualisiert hat, dann soll der vdr nur noch den Rest wie Startzeit usw. aktualisieren.


    Das wäre natürlich noch besser.


    cu


    *) Auf diese Weise funktioniert z.B. die epgsearch Ansicht "Zeige mir alle Science-Fiction Filme der nächsten 24h" ohne das man sich EPG mässig komplett von nem externen Anbieter abhängig macht.

  • Sorry, der Patch von vorhin war leider nicht ganz richtig.
    Hier nochmal:


    Klaus

  • Und es ist wirklich schade das das einfach mal so nebenbei weggewischt wird.


    Eines darfst Du nie dabei vergessen, der VDR wird nicht nur für Euch 3 EPG "Frickler" geschrieben und nichts ist so stetig wie die Veränderung. Wenn nicht noch revolutionäre Änderungen einließen, bin ich mir sicher Ihr werdet einen Weg finden Euch damit zu arrangieren :)


    Aber Dein Gejammer verstehe ich trotzdem nicht, Du bist Doch mit VDR 1.6.0 gar nicht betroffen von der Veränderung ...


    Regards
    fnu

    HowTo: APT pinning

  • Zitat

    ... und es einfach um Episodentitel und Flags (country, year, category *) ) ergänzen zu können.
    Auf diese Weise funktioniert z.B. die epgsearch Ansicht "Zeige mir alle Science-Fiction Filme der nächsten 24h" ohne das man sich EPG mässig komplett von nem externen Anbieter abhängig macht

    Whow - das ist ein geniales Viehtscher.
    Sowas würde ich mir im Standard-VDR wünschen, insbesondere auch die Suchmöglichkeit.


    Bei meiner Stipvisite zur (vermeintlichen) Konkurrenz habe ich gesehen, dass dort das EPG z.B. nach HD-Sendungen durchsucht werden kann.
    Das ist beispielsweise auch etwas, was ich vermisse und mir sehnlichst wünsche.


    Wäre doch genial, wenn man sich z.B. alle Spielfilme in HD auflisten lassen könnte - quer über alle Sender :)
    (zumindest solange HD eher die Ausnahme ist)


    Zitat

    Eines darfst Du nie dabei vergessen, der VDR wird nicht nur für Euch 3 EPG "Frickler" geschrieben


    Hm, also das finde ich jetzt schon derb!
    Nur weil jemand den Mund aufmacht, ist er doch kein Frickler?!?


    ... und (anders-)denkende abzuwatschen halte ich auch nicht für besonders kreativ. Derlei Kommentare bringen niemand weiter.


    Es gibt sicher viele, die sich einfach ärgern, den Mund halten und irgendwann den VDR entsorgen und was anderes verwenden. Damit ist niemand geholfen.
    Ich wäre dankbar für Kritik - denn nur so kann man sich weiter entwickeln.


    Gruß Gero

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!


  • Eines darfst Du nie dabei vergessen, der VDR wird nicht nur für Euch 3 EPG "Frickler" geschrieben und nichts ist so stetig wie die Veränderung. Wenn nicht noch revolutionäre Änderungen einließen, bin ich mir sicher Ihr werdet einen Weg finden Euch damit zu arrangieren :)


    Es betrifft nicht nur 3 Frickler. Es Betrifft z.B. alle Nutzer des xmltv2vdr Plugins, und eine Nutzergruppe eines Plugins als Frickler zu bezeichnen nur weil du ein anderes Plugin zum EPG Import nimmst finde ich schon etwas seltsam ;)


    Aber OK, ich nutze als Skin Skinenigma, und wenn irgendwann wegen einer Änderung die andere Skins nicht mehr gehen (und die Nutzer dann dumm rumjammern) ist es mir doch egal, sollen die "Frickler" sich das halt hinfummeln. mir doch egal, mich betrifft es ja nicht ;)


    BTW: Die Änderung im VDR zurückzunemhen scheint wirklich nicht schwer solange sich das generelle TableID=0 Verhalten nicht ändert. Das Problem ist halt das Plugin nicht darauf aufbauen können wenn ein VDR Patch benötigt wird. Restfulapi hat ja aktuell das selbe Problem.


    Aber Dein Gejammer verstehe ich trotzdem nicht, Du bist Doch mit VDR 1.6.0 gar nicht betroffen von der Veränderung ...


    Natürlich bin ich das. Erstmal verhindert die Änderung das sich die Plugins weiterentwickeln *) (das war die letzte Möglichkeit das VDR EPG etwas moderner zu nutzen, das ist ein allgm. Rückschritt). Und zweiten möchte ich nicht auf den 1.7er Umstellen wenn es für mich einen Rückschritt in der Funktion darstellt. Und hiermit ist es eine Baustelle mehr die zu lösen ist ehe ich umstellen kann (d.h. ich werde noch einige Zeit länger den 1.6er nutzen).


    cu


    *) Es sein denn man macht es wie yaVDR und baut einen (zum Rest der Welt inkompatiblen) Patch ein um da was am VDR EPG zu ändern ;)
    Also gerade aus der yaVDR Ecke hätte ich da etwas mehr Verständnis für diese Problematik erwartet ;)

  • Wo steht eigentlich, dass xmltv2vdr ein Problem mit dem neuen Feature hat?


    Nehmen wir mal 7 Tage Sender EPG für RTL an. xmltv2vdr ergänst die Subtitle für 1 Tag und setzt dort natürlich die TableID auf "0". D.h. es kommen keine Updates mehr vom Sender EPG rein. Am nächsten Tag ergänst xmltv2vdr wieder 1 Tag mit Subtitle, und wieder und wieder. Irgendwann gibts es nur noch nen Rest mit TableID=0 und vom Sender kommt während der ganzen Zeit nix mehr.
    Ist das EPG leegelaufen wird wieder das Sender EPG aufgefüllt und am nächsten Tag werden die Subtitle wieder ergänst und das Spiel geht von neuen los.


    D.h. irgendwie bastelt sich das schon hin, mit Phasen ganz ohne EPG und Phasen mit Sender EPG ohne Ergänzung. Und immer ein 7 Tage EPG was kontinuierlich abnimmt und wenn es leer ist wieder auf 7 Tage aufgefüllt wird. Und das ist nicht wirklich praktikabel das so zu nutzen.


    cu

  • Als "Erfinder des Frickelns" (infosatepg als Plugin mit Mischfunktion, xmltv2vdr-plugin mit Mischfunktion) sehe ich in der Änderung für die "EPG-Superuser" mit Ihren sensationell flinken Hühnerimports (aka PUTE) eine Verbesserung ;) Wenn der externe EPG-Provider ausfällt, dann wird automatisch SenderEPG nachgeschoben, mit noEPG-Patch fallen dann Sendungen aus und Nutzer solcher Skripte und Plugins haben sich dann in der Vergangenheit im Forum wegen fehlender Sendungen ausgeheult...


    Auf der anderen Seite, wenn nur die TableID des ersten Events angeschaut wird bedeutet das ja nicht das man nicht mehr mischen könnte. Es bedeutet nur das während solche Events aktiv sind kein neues SenderEPG hinzukommt. Aus meiner Erfahrung werden aber nicht 100% der Events angefasst, sondern meistens nur Serien... es besteht also noch Hoffnung für "uns" Frickler...


    Gruß


    Joe_D


    P.S.: Der Typ in der Maillingliste war übrigens ich, ich wollte eine Option E0/E1 in der channels.conf mit der man Sender-EPG Ein-/Ausschalten konnte für den jeweiligen Sender (als Ersatz für den noEPG-Patch). Wurde natürlich abgelehnt ;)


  • Das remote Plugin hat damit nix zu tun. Bei dem rcu gehts ja um die Steuerung mit nem selbstbau IR Empfänger.
    So wie es aussieht wurde einfach der rcu Teil (den vermutlich eh nur noch sehr wenige Nutzen) in ein Plugin ausgelagert. Diese Änderung sollte also nur sehr wenige Betreffen.


    Ich glaube ich brauche da noch mal ein wenig Nachhilfe. Bisher war ich immer davon ausgegangen das bei Verwendung des remote Plugins auch die Option --rcu gesetzt werden muss. Hab ich das nun richtig verstanden, dass das beides nichts miteinander zu tun hat? Kannst Du mir das ein wenig ausführlicher erläutern?
    Ich benutze das ja nicht selber, sondern mache das nur in der MLD "bequem" konfigurierbar.


    Claus

    MLD 5.5 mit vdr 2.6 - 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.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

    Einmal editiert, zuletzt von clausmuus ()

  • Und zweiten möchte ich nicht auf den 1.7er Umstellen wenn es für mich einen Rückschritt in der Funktion darstellt.


    Nun, das hast Du seither auch nicht, warum auch immer, man könnte den Eindruck gewinnen, das kommt Dir gerade recht ... ;)


    Also gerade aus der yaVDR Ecke hätte ich da etwas mehr Verständnis für diese Problematik erwartet


    Wie Du weiter oben lesen kannst ist das Gegenteil der Fall, wir begrüssen das eher.


    Als "Erfinder des Frickelns"


    Also bitte nicht persönlich nehmen, war ausdrücklich in "" und diente dazu ein Bild zu verdeutlichen ... :engel1


    es besteht also noch Hoffnung für "uns" Frickler...


    So denke ich auch, :motz2 , viel Rauch um ...


    Regards
    fnu

    HowTo: APT pinning

  • Ich glaube ich brauche da noch mal ein wenig Nachhilfe. Bisher war ich immer davon ausgegangen das bei Verwendung des remote Plugins auch die Option --rcu gesetzt werden muss. Hab ich das nun richtig verstanden, dass das beides nichts miteinander zu tun hat? Kannst Du mir das ein wenig ausführlicher erläutern?


    Jup, das hat nix miteinander zu tun.


    Es gibt (gab bissher) im VDR drei Fernbedienungsobjekte.


    1. rcu - ist für die spezielle Hardware (dem sagt man über --rcu wo es seine Hardware findet, wenn leer wird es einfach abgeschaltet (garnicht erst erstellt))
    2. lirc - ist für die lirc Anbindung (dem sagt man über --lirc wo es sein lirc socked findet, wenn leer wird es einfach abgeschaltet (garnicht erst erstellt))
    3. keyb - ist für die Tastatur als Fernbedienung und als Tastatur in Eingabefeldern (das kann man per --no-kbd komplett abschalten, die Quelle der Tastendrücke ist immer die aktive VDR Konsole)


    Über Plugins kann man noch weitere dazuwerfen. z.B. über das lircrc, das remote und das control Plugin (und weitere, die Outputplugin bringen ja meist auch welche mit).
    Alle diese Fernbedienungsobjekte holen ihre Tastendrücke aus ihrer jeweiligen Quelle und übergeben sie dem VDR.


    Jetzt ist einfach das rcu Obekt (und damit der Kommandozeilenparameter dafür) aus dem VDR verschwunden und kann bei Bedarf über das Plugin geladen werden.


    Wobei das wirklich nur diese spezielle Hardware betrifft.


    cu

  • Hi Keine_Ahnung,


    Danke für die Erklärung. Da war ich die letzten Jahre ja ein wenig auf dem Holzweg,...


    @All,
    innerhalb der nächsten 15 Minuten dürfte der VDR-1.7.25 für die MLD zu haben sein (auch auf den Live CD Images). Der Compile-Server ist schon kräftig am schwitzen :D


    Claus

    MLD 5.5 mit vdr 2.6 - 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.5 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.5 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT

  • kls


    ich habe wohl doch noch ein Problem mit der aktuellen Version festgestellt.
    Da hier bisher keiner weiter darüber berichtet hat, kann ich mir vorstellen, das es mit meinem device-bonding zu tun haben könnte.


    Folgendes Verhalten tritt auf:
    - Start des VDR -> ständiges Umschalten auf den aktuellen Kanal mit kurzem schwarzen Bild (ohne Bedien-Aktivitäten)
    - manchmal keine Reaktion auf Fernbedienung -> Neustart.


    Dazu folgende Log-Ausgaben:


    hier ein Beispiel mit Neustart:

    Code
    Mar  4 16:16:28 home-05 vdr: [19224] switching to channel 1
    Mar  4 16:16:49 home-05 vdr: [19224] switching to channel 1
    Mar  4 16:17:10 home-05 vdr: [19224] switching to channel 1
    Mar  4 16:17:31 home-05 vdr: [19224] switching to channel 1
    Mar  4 16:17:53 home-05 vdr: [19224] switching to channel 1
    Mar  4 16:18:15 home-05 vdr: [19224] switching to channel 1
    Mar  4 16:18:36 home-05 vdr: [19224] switching to channel 1
    Mar  4 16:20:05 home-05 vdr: [19224] PANIC: watchdog timer expired - exiting!
    Mar  4 16:20:05 home-05 vdr: [19247] KBD remote control thread ended (pid=19224,
     tid=19247)


    Jedesmal wenn das "switching to channel 1" auftritt wird das Bild kurz schwarz.


    Das Problem trat mit VDR1.7.24 nicht auf.


    Getestet habe ich mit VDR+remote+dvbhddevice
    Eine zufällig gerade anstehende Aufnahme hat gezeigt, das dieses Problem im Zeitraum der Aufnahme nicht auftritt.


    Gruß
    Karl


    PS: Gerade noch einen Neustart gehabt - siehe Nachtrag im ersten Log.

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Einmal editiert, zuletzt von kamel5 ()

  • Dieses "Vergessen" könnte ich mir höchstens bei einem unkontrollierten Absturz erklären, wenn seit dem letzten PUTE die EPG-Daten noch nicht auf die Platte geschrieben wurden (was alle 10 Minuten passiert).
    Wenn VDR normal beendet wird, dann werden die EPG-Daten auf alle Fälle geschrieben.


    Kannst du eine reproduzierbare Vorgehensweise angeben, bei der das nicht wie erwartet funktioniert?


    Klaus


    Nun, reproduzieren kann ich es so:


    Ich schreibe mein ext-EPG mit PUTE in den VDR, dann passt das alles. nun kommt es immer wieder vor, dass das ext-EPG von DVB-EPG überschrieben wird.


    Seltsamerweise ist das aber nicht bei allen Sendern so. Auffallen tut mir das am häufigsten bei "Sky Cinema".


    Den noEPG-Patch verwende ich nicht, da ich falls mal das ext-EPG ausfällt, ich dann wenigstens noch das normale EPG habe.


    Die EPG Settings sehen so aus:



    Das Problem scheinen alle vdr-1.7.x Versionen zu haben, bei vdr-1.6.x war das noch nicht so.

Jetzt mitmachen!

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