Server ohne Ausgabeplugin, Kanal ändern führt zu "ERROR: video data stream broken"

  • Hi,


    Zum Reproduzieren:

    • VDR 2.6.4, keine Patches, keine Plugins (insbesondere keine Ausgabeplugins)
    • Ein Empfänger (oder -D 0 beim Start). Darf nicht FF sein, also kein Ausgabedevice.

    Einen Timer anlegen, z.B. auf ARD (kann man vorher machen, also bevor man den VDR ohne Ausgabedevice startet).

    VDR neu starten (jetzt ohne Ausgabeplugin).

    "svdrpsend chan 2" eingeben (2 ist ZDF, also anderer Transponder als der Timer).

    -> "ERROR: video data stream broken".


    Aus dem syslog (unvollständig!):


    kls , kannst Du Dir das bitte mal ansehen?


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Einmal editiert, zuletzt von MarkusE () aus folgendem Grund: VDR Version korrigiert

  • Hi,


    Der Fehler kann so, wie in meinem Post 1 beschrieben, reproduziert werden.

    Das heisst aber nicht, dass der Fehler in anderen Situationen nicht auftritt.

    z.B. habe ich den Fehler auch, wenn ich 2 DVB Empfänger verwende.


    Andere Situationen wie z.B. ältere VDR Versionen, FF Karten, VDR Patches, VDR Plugins, ... habe ich nicht getestet. D.h. mir ist nicht bekannt, ob der Fehler da auch auftritt.


    kls , an diesem commit liegt es nicht. Der impact ist doch nur relevant, um zu entscheiden, welches DVB Device gewählt wird. In der Testbeschreibung steht doch, dass es nur 1 DVB Device gibt.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • MarkusE Sorry, war einfach mein erster Gedanke, da sich in der Ecke was geändert hatte. Aber du hast natürlich Recht, bei nur einem Device spielt das keine Rolle.


    Probier bitte mal das hier:

  • Danke, Klaus!


    Damit konnte ich den Fehler nicht mehr reproduzieren.

    Könntest Du in den (jetzt 2) isyslog Meldungen noch das Device mit ausgeben? Also:

    Code
    isyslog("can't switch device %d to live channel %d %s (%s)", DeviceNumber() + 1, Channel->Number(), *Channel->GetChannelID().ToString(), Channel->Name());
     return false;
         }
     isyslog("switching device %d to channel %d %s (%s)", DeviceNumber() + 1, Channel->Number(), *Channel->GetChannelID().ToString(), Channel->Name());


    @All: Wenn ihr einen Server ohne Ausgabedevice habt (also auch ohne dummydevice), betrifft Euch der Fehler vermutlich. Zum Test:

    1. Timer anlegen, Aufnahme starten (z.B. sat1)
    2. Kanal umschalten (auf einen anderen Transponder, z.B. tele5). Das geht z.B. mit dem live plugin, oder mit svdrp.

    Wenn ihr im Log einen "ERROR: video data stream broken" bekommt, seid ihr betroffen. Sonst nicht.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Hallo kls,


    Ich denke, es liegt an device.c, Zeile 883:

    Code
    cDevice *Device = (LiveView && IsPrimaryDevice()) ? GetDevice(Channel, LIVEPRIORITY, true) : this;

    Device wird hier ohne weitere Prüfung = this gesetzt, und dann umgeschaltet.

    Der Grund ist die Implementierung von IsPrimaryDevice():

    Code
      bool IsPrimaryDevice(void) const { return this == primaryDevice && HasDecoder(); }

    da HasDecoder() false ist, kommt hier false zurück.


    Wie würde man das denn am besten lösen?


    Code
    cDevice *Device = (LiveView && (this == primaryDevice)) ? GetDevice(Channel, LIVEPRIORITY, true) : this;


    müsste funktionieren (ungetestet).


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Die Abfrage kam vor gut zehn Jahren dazu:


    Klaus Schmidinger's git trees - vdr.git/blobdiff - device.h


    und in der HISTORY steht dazu:

    Code
    - cDevice::IsPrimaryDevice() now also checks whether the primary device actually has
     a decoder and returns false otherwise. This should improve device allocation on
     systems that are only used as a receiver and don't actually display anything.

    Leider steht kein Name dabei, von wem das vorgeschlagen wurde. Aber ich denke mal nicht, dass ich es selber war, denn ich habe keine headless VDRs. Sollte ich das wieder rausnehmen?

  • > Sollte ich das wieder rausnehmen?

    Schwer zu sagen. Das jetzige Verhalten (IsPrimaryDevice() gibt false zurück, obwohl es das primary device ist) ist überraschend und führt zu Fehlern. Von daher: ja.

    Andererseits wäre es halt eine inkompatible Änderung, könnte also auch negative Nebeneffekte haben (oder auch nicht ...).


    Optimal wären wohl 2 Methoden:

    - IsPrimaryDevice()

    - IsPrimaryDeviceAndCanPlay()


    Und dann müsste man an jeder Stelle die IsPrimaryDevice() verwendet prüfen welche der 2 Methoden die richtige ist.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • MarkusE Es gibt ja schon HasDecoder(), was ...AndCanPlay() entspricht. Wenn du also "...&& HasDecoder()" aus IsPrimaryDevice() rausnehmen und stattdessen and den notwendigen Stellen zu den IsPrimaryDevice()-Aufrufen hinzufügen willst, würde ich einen entsprechenden Patch akzeptieren. Man könnte auch IsPrimaryDevice(bool CanPlay = false) machen und es an den Stellen, wo es nötig ist, mit 'true' aufrufen und den Parameter entsprechend auswerten.

  • davie2000,


    Ich habe:

    - Den Fehler gefunden

    - Die Ursache analysiert

    - Lösungen vorgeschlagen


    Klaus schlägt nun vor, dass ich noch weitere Stellen im vdr analysiere und einen Patch baue, und bekommt dafür Dein Lob.


    Irgendwie de-motivierend. :(

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Hi,


    Anbei ein Patch für vdr 2.6.5, aber ungetestet. Bitte testen. Ich werde natürlich auch testen, wenn ich wieder an meinen live vdr komme.

    Zum Test:

    - Wer ein Ausgabeplugin oder FF Karte hat, braucht nicht zu testen. Da sollte sich nichts ändern.

    - Ohne Ausgabeplugin, bei reinem Server: es sollte nun möglich sein, Kanäle zu ändern ohne laufende Aufnahmen zu gefährden. Test z.B. wie im 1. Post beschrieben.


    Außerdem: Code review, ob ich IsPrimaryDevice() korrekt aufrufe (also ob IsPrimaryDevice(true) oder IsPrimaryDevice(false) korrekt ist).


    ~Markus

  • MarkusE:

    Das Lob an Klaus kam, für die sehr gute kurzfristige Analyse und den doch - wie ICH finde - sehr guten und vor allem sauberen Lösungsvorschlag.

    Und ob man jetzt an den betroffenen Stellen den neuen Methodennamen reinpackt oder den zweiten Methodenaufruf sollte ziemlich der gleiche Aufwand sein.

    Prinzipiell sollten sich aber Plugin-Entwickler keine Gedanken machen müssen, ob der VDR ein Ausgabeplugin hat oder nicht - aber das ist sicher eine größere (andere) Baustelle.


    Ich wollte dir mit meinem "Daumen hoch an Klaus" auf keinen Fall ans Bein pinkeln oder deine Leistung schmälern, zumal ich dich als sehr aktiven und hilfsbereiten Entwickler hier im Forum verstehe. Und demotivieren wollte ich dich schon gar nicht - dafür entschuldige ich mich!

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

    Einmal editiert, zuletzt von davie2000 ()

  • MarkusE Danke für den Patch.

    Da es doch deutlich mehr Stellen mit 'true' als mit 'false' gibt habe ich, um die Zahl der geänderten Stellen möglichst klein zu halten, den Parameter defaultmäßig auf 'true' gesetzt und in 'CheckDecoder' umbenannt, was dann bei der Abfrage m.E. besser mit 'HasDecoder()' harmoniert. Man sieht damit auch schön, dass es nur zwei Stellen sind, an denen sich für headless-Systeme was ändert.

    Bitte schaut mal, ob beiliegende Version auch OK wäre.

  • Hi Klaus,


    dein Patch sieht gut aus. :) . Ich denke, dass ich in den nächsten Tagen auch noch testen kann.


    ~Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Probier's bitte mal aus. Ich kann das selber nicht, da ich VNSI nicht nutze.

    Wäre schön wenn das jemand anders übernehmen könnte. Meine HTPC-Kiste ist auf einem Softwarestand von bestimmt vor zwei Jahren. Ich müsste da erstmal komplett durchaktualisieren und ich schaue aktuell eigentlich tatsächlich mehr auf dem Raspberry im Schlafzimmer. Dort komplett ohne VNSI-Anbindung.


    Ich hab gestern nur mal kurz versucht im Sourcecode nachzuvollziehen was da passiert. VNSI öffnet die Devices mit der gleichen Prio wie VDR selbst für "Live-Ansicht". Keine Ahnung wer da "gewinnt" wenn nun nur zwei Tuner da sind und von außen zwei Clients verschiedene Transponder haben wollen. Wer "würde dann zurückstehen"? Und wenn dann doch irgendwer einen z.B. über Cron gesteuerten Channel-Scan anwirft wäre ja irgendwo Mist wenn der einem Client das Live-Bild "klaut".


    Vermutlich kann man einen gleichwertigen Test auch durchführen wenn man ein Setup mit streamdev zum Testen nimmt.

  • Wäre schön wenn das jemand anders übernehmen könnte. Meine HTPC-Kiste ist auf einem Softwarestand von bestimmt vor zwei Jahren. Ich müsste da erstmal komplett durchaktualisieren und ich schaue aktuell eigentlich tatsächlich mehr auf dem Raspberry im Schlafzimmer. Dort komplett ohne VNSI-Anbindung.


    Ich hab gestern nur mal kurz versucht im Sourcecode nachzuvollziehen was da passiert. VNSI öffnet die Devices mit der gleichen Prio wie VDR selbst für "Live-Ansicht". Keine Ahnung wer da "gewinnt" wenn nun nur zwei Tuner da sind und von außen zwei Clients verschiedene Transponder haben wollen. Wer "würde dann zurückstehen"? Und wenn dann doch irgendwer einen z.B. über Cron gesteuerten Channel-Scan anwirft wäre ja irgendwo Mist wenn der einem Client das Live-Bild "klaut".


    Vermutlich kann man einen gleichwertigen Test auch durchführen wenn man ein Setup mit streamdev zum Testen nimmt.

    svdrp ändert Kanäle mit prio von live-view.

    Ich meine, du kannst bei VNSI die Prio einstellen.

    Du kannst das aber auch mit dem sw Stand von vor 2 Jahren testen, mit dem Patch hier verhält sich vdr so wie ein alter vdr. Es wird nur verhindert, dass Aufnahmen kaputtgehen.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

Jetzt mitmachen!

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