[gefunden]vdr-2.6.5 komisch

    Hallo,


    ich mache folgendes:

    Code
    git clone --branch stable/2.6 git://git.tvdr.de/vdr.git
mv vdr vdr-2.6.5
cd vdr-2.6.5
cp Make.config.template Make.config # hier angepasst: VIDEODIR     = /video265
make  -j 5 LCLBLD=1  ONEDIR=1
cp *.conf /video265/
./vdr  -D 2   -Pskincurses

    das Ergebnis:

    Code
     can't switch to live channel 1 S19.2E-1-1089-12003 (RTL Television)

    ich steh auf dem Schlauch...


    VG

    Zitat von highrgb

    ./vdr -D 2 -Pskincurses

    Fehlt da nicht noch ein Ausgabe-Plugin wie z.B. SoftHDDevice?

    Zitat von MegaV0lt

    Fehlt da nicht noch ein Ausgabe-Plugin wie z.B. SoftHDDevice?

    Das passiert auch mit streamdev...


    hier 2.6.5


    hier 2.6.4

    kein "can't switch'....

  • highrgb

    Hat den Titel des Themas von „vdr-2.6.5 komisch“ zu „[gefunden]vdr-2.6.5 komisch“ geändert.

    Du hast kein Output Device, darum kannst du den Live Kanal beim Start nicht umschalten und es kommt eine Fehlermeldung.

    Neu in 2.6.5 ist, dass das geprüft wird.

    Kein Problem oder Bug, sondern ein neues Feature.

    Siehe hier.

    Einmal editiert, zuletzt von kfb77 ()

    Leider kann ich jetzt aber auch im osd2web-Plugin nicht mehr den laufenden Kanal sehen (EPG Info) und auch das zyklische Schalten durch die Kanäle für einen EPG Scan "extern" geht nicht mehr. Das ist natürlich für meinen Headless Server Mist/Schade (Regression)...

    > Leider kann ich jetzt aber auch im osd2web-Plugin nicht mehr den laufenden Kanal sehen (EPG Info)

    Was ist der laufende Kanal bei einem Server ohne primary device?

    Bei einem Client mit primary device ist der laufende Kanal der Kanal, der gerade vom primary device wiedergegeben wird.

    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

    Wenn man den laufenden Kanal nur als den ansieht, der auf einem Ausgabedevice zu sehen ist, hast du natürlich recht. Für mich ist aber das auch ein laufender Kanal, auf dem z.B. Das EPG eingelesen wird. Mit der jetzigen Mimik kann ich hier aber nicht mehr hin und her schalten. Und auch das osd2web Plugin ist ja eigentlich ein Ausgabedevice (etwas weiter ausgelegt). Es dient ja dazu den headless Server bedienbar zu halten und das EPG anzuzeigen. Ist jetzt auch nicht mehr möglich. Gut, das braucht man vielleicht alles nicht. Aber gefiel mir bisher ganz gut. Das Wegfallen dieser Möglichkeiten jetzt als "Feature" verkaufen zu wollen, halte ich aber dennoch für etwas gewagt...

    Wenn das nicht gewollt ist, dann müsste aber ein anderer Fix für das ursprüngliche Problem gefunden werden.

    Code
    2023-12-30: Version 2.6.5

- Fixed broken video data streams on systems without output device when switching live
  channel to a different transponder while recording (reported by Markus Ehrnsperger).

    Man müsste:

    - Eindeutig definieren, welches Device den Kanal ändern soll

    - Prüfen, ob dieses Device den Kanal ändern kann, ohne laufende Aufnahmen zu unterbrechen.

    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

    Wundert mich das der VDR eine Aufnahe deshalb abgebrochen hat.


    War es nicht mal so das eine "Live-Ansicht" immer niedriger priorisiert ist wie eine Aufnahme? Worst-Case, also wenn alle Tuner durch Aufnahmen beansprucht werden, erwarte ich bei einem "Nicht Headless VDR" einen schwarzen Bildschirm und im Idealfall eine Fehlermeldung.

    Ist denn mir dem dummy-device-Plugin das Verhalten wie gewünscht?

    (Irgend einen Zweck muss das Ding ja haben :) )

    Gruss
    SHF


    Momentan sind ja die octopuss Tuner ohne dummy device immer ausgeschaltet, außer bei Aufnahme oder epg scan. Wenn das dummy device benutzt wird vermute ich mal, daß dann immer ein tuner mitläuft. Hab ich aber nicht ausprobiert.

    Zitat von kls

    MarkusE Der Patch stammt von dir ;-). Soll ich ihn wieder entfernen?

    Die Fehlermeldung ist von mir, siehe RE: Server ohne Ausgabeplugin, Kanal ändern führt zu "ERROR: video data stream broken" .


    Der Fehler führt reproduzierbar zu kaputten Aufnahmen, siehe RE: Server ohne Ausgabeplugin, Kanal ändern führt zu "ERROR: video data stream broken" .


    Also, wir brauchen eine Korrektur dieses Fehlers. Ich hoffe, da sind sich alle einig (?).


    Die Korrektur kann aber auch gerne anders aussehen. Wie geschrieben, man müsste:

    - Definieren, welches Device den Kanal ändern soll

    - Prüfen, ob dieses Device den Kanal ändern kann, ohne laufende Aufnahmen kaputzumachen. Und nur dann den Kanal ändern.


    ~ 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

    Zitat von MarkusE

    Die Fehlermeldung ist von mir, siehe RE: Server ohne Ausgabeplugin, Kanal ändern führt zu "ERROR: video data stream broken" .

    Sorry, steht ja auch so in der HISTORY (*reported* by Markus Ehrnsperger). Mea culpa.


    Ich mache die Änderung dann erstmal rückgängig, vielleicht findest du oder jemand anderes ja eine bessere Lösung.

    Zitat von kls

    Ich mache die Änderung dann erstmal rückgängig.

    Ich erlaube Umschalten des Kanals im reinen Server Betrieb in vollem Bewusstsein, dass das zu kaputten Aufnahmen führen kann?

    Kann ich jetzt nicht nachvollziehen. Aber klar, Deine Entscheidung. Ich baue den Patch dann bei mir halt wieder ein.

    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 Na gut, dann bleibt sie halt drin - allen werde ich es eh nicht recht machen können ;-).

    Und du hast schon Recht, kaputte Aufnahmen zu vermeiden hat Vorrang.

    Da ein "headless" Betrieb für mich keine Prorität hat, werde ich in der Richtung selber nicht weiter debuggen. Wenn also jemand mit headless System einen besseren Vorschlag hat, bitte melden.

    Zitat von M-Reimer

    Wundert mich das der VDR eine Aufnahe deshalb abgebrochen hat.


    War es nicht mal so das eine "Live-Ansicht" immer niedriger priorisiert ist wie eine Aufnahme? Worst-Case, also wenn alle Tuner durch Aufnahmen beansprucht werden, erwarte ich bei einem "Nicht Headless VDR" einen schwarzen Bildschirm und im Idealfall eine Fehlermeldung.

    Gibts denn hierzu noch eine Aussage, warum das nicht funktioniert, wenn kein Ausgabedevice vorhanden ist. Werden denn diese "Priorisierungen" nur auf der Ausgabeseite durchgeführt?

    ich hab übrigens in mein epgscan-Script folgendes eingebaut. Damit wird verhindert, daß Aufnahmen gestört werden.


    Code
    echo  "Shell-Skript fuer EPG wird ausgeführt -- "$(date)
secs="$(${SVDRPSEND} NEXT rel | egrep "^250" | cut -d' ' -f3)"
if [ "$(echo ${secs}|sed s/[0-9].*//g)" = "-" ]; then
  echo "VDR nimmt auf."
  exit 0
elif [ "$(echo ${secs}|sed -e "s/[^0-9].*//g")" -lt "900" ]; then
  echo "VDR nimmt innerhalb der nächsten viertel Stunde auf."
  exit 0
fi

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden