satip plugin am EXIP 418 (gelöst)

jojo61 · December 31, 2023 at 12:21 PM

Hallo

ich habe einen neuen EXIP 418 bekommen und jetzt gibt es Probleme mit dem satip-plugin. Beim start des vdr wird zwar auf das eingestellte Programm getuned, aber es wird keine Pidliste geschickt. wenn der VDR dann beginnt die epgs zu aktualisieren dann klappt das senden der Pidliste für diesen Kanal einwandfrei. Nur auf dem ersten Kanal werden weiterhin keine geschickt.

Auch wenn ich blind umschalte wird neu getuned aber weiterhin keine Pidliste geschickt. Nach mehrfachem Umschalten klappt es dann auf einmal. Und dann geht es bis zum nächsten neustart immer gut. Der SAT Receiver wird bei einem vdr neustart auch immer neu gestartet.

D.h. die erste Verbindung zum Sat Receiver nach einen neustart klappt nicht. So ein verhalten ist natürlich bei timergesteuerten Aufnahmen tötlich

heifisch · December 31, 2023 at 12:43 PM

Quote from jojo61

D.h. die erste Verbindung zum Sat Receiver nach einen neustart klappt nicht. So ein verhalten ist natürlich bei timergesteuerten Aufnahmen tötlich

Ist auf der Box die Original-Firmware?

Das kommt mir bekannt vor von satip-axe auf meiner GSS.box DSI 400:

https://github.com/perexg/satip-axe/issues/182

Ich hatte das Problem auch, konnte es aber nicht lösen.

Bin dann zurück auf die Original-Firmware bzw. später zur Octopus Net.

jojo61 · December 31, 2023 at 12:55 PM

Soweit ich weiss gibt es für die Kathrein nur Original Firmware und die ist drauf (1.1.2).

Übrigens Signal ist da, ( es wird ja auch getuned) es fehlen nur die PIDS. Und wenn ich den Trace des satip Plugins einschalte dann sieht man auch das keine gesendet werden.

Also irgend etwas hindert das Plugin daran die Pids zu senden. Da muss ich wohl mal das Plugin debuggen

rell · December 31, 2023 at 1:07 PM

Ich habe auch den EXIP 418, konnte aber noch nie Probleme feststellen, dass Aufnahmen ausgefallen sind. Das aber nie genau beobachtet und bin jetzt auf vtuner umgestiegen.

jojo61 · December 31, 2023 at 1:15 PM

rell läuft dein EXIP 418 durch oder bootet der mit dem vdr ?

rell · December 31, 2023 at 1:25 PM

Der läuft durch. Daran hängt der Server mit 4 Devices und aktuell 2 Clients mit jeweils 2 Tuner. Alles läuft ständig.

jojo61 · December 31, 2023 at 1:32 PM

Ahh ok dann hast du das Problem auch nicht. Tritt nur nach dem boot des EXIP 418 beim ersten Tuner setup auf. Wenn es mal geht dann geht es

rüsseltier · December 31, 2023 at 1:40 PM

Quote from jojo61

rell läuft dein EXIP 418 durch oder bootet der mit dem vdr ?

Interessehalber: wie handled man sowas? WOL beim Bootup des VDR? Aber dann muss man ja wohl ein sleep einbauen, oder?

Joe_D · December 31, 2023 at 1:46 PM

Quote from jojo61

Tritt nur nach dem boot des EXIP 418 beim ersten Tuner setup auf

Wäre es eine Möglichkeit nach dem Start vom VDR mit svdrpsend chan auf einen anderen Kanal zu wechseln?

jojo61 · December 31, 2023 at 4:00 PM

Quote from rüsseltier

Interessehalber: wie handled man sowas? WOL beim Bootup des VDR? Aber dann muss man ja wohl ein sleep einbauen, oder?

Ich starte den Odroid per WOL. Das macht die Alexa. Dann schaltet der Odroid ein Relay um den Sat Server zu starten. Und wartet bis dann ein Ping durchgeht.

Quote from Joe_D

Wäre es eine Möglichkeit nach dem Start vom VDR mit svdrpsend chan auf einen anderen Kanal zu wechseln?

Ja das geht. Aber leider funktioniert es nicht immer beim ersten mal, manchmal muss ich 4-5 mal umschalten bis dann ein Bild kommt und die PIDS gesendet werden. Mit dem vtunerc habe ich es noch nicht getestet weil der im chroot nicht läuft.

rüsseltier · December 31, 2023 at 4:06 PM

Quote from jojo61

Ich starte den Odroid per WOL. Das macht die Alexa. Dann schaltet der Odroid ein Relay um den Sat Server zu starten. Und wartet bis dann ein Ping durchgeht.

Ah, OK. Über ein Relais ist dann doch etwas aufwendiger als ich annahm.

Eigentlich schade, dass es da bei SAT-IP keine werkseitigen Stromsparmöglichkeiten zu geben scheint.

Also, im Sinne von WOL-fähig und "fahr dich runter wenn x Minuten keine Stream-Aktivität".

jojo61 · January 2, 2024 at 10:35 AM

Ich habe den Fehler gefunden. Es ist ein Fehler im Satip Plugin. Wenn der Server die StreamID 0 verwendet dann schickt er keine Pidliste.

Ich habe das im satip plugin gepatcht und nun geht es auch direkt nach einem reboot des EXIP 418.

Hier ist der dazugehörige patch:

Diff

diff --git a/tuner.c b/tuner.c
index be7b392..d7c7b27 100644
--- a/tuner.c
+++ b/tuner.c
@@ -500,7 +500,7 @@ bool cSatipTuner::UpdatePids(bool forceP)
   debug16("%s (%d) tunerState=%s [device %d]", __PRETTY_FUNCTION__, forceP, TunerStateString(currentStateM), deviceIdM);
   cMutexLock MutexLock(&mutexM);
   if (((forceP && pidsM.Size()) || (pidUpdateCacheM.TimedOut() && (addPidsM.Size() || delPidsM.Size()))) &&
-      !isempty(*streamAddrM) && (streamIdM > 0)) {
+      !isempty(*streamAddrM) && (streamIdM >= 0)) {
      cString uri = cString::sprintf("%sstream=%d", *GetBaseUrl(*streamAddrM, streamPortM), streamIdM);
      bool useci = (SatipConfig.GetCIExtension() && currentServerM.HasCI());
      bool usedummy = currentServerM.IsQuirk(cSatipServer::eSatipQuirkPlayPids);
@@ -600,7 +600,7 @@ bool cSatipTuner::ReadReceptionStatus(bool forceP)
      statusUpdateM.Set(eStatusUpdateTimeoutMs);
      forceP = true;
      }
-  if (forceP && !isempty(*streamAddrM) && (streamIdM > 0)) {
+  if (forceP && !isempty(*streamAddrM) && (streamIdM >= 0)) {
      cString uri = cString::sprintf("%sstream=%d", *GetBaseUrl(*streamAddrM, streamPortM), streamIdM);
      if (rtspM.Describe(*uri))
         return true;

Display More

wirbel · January 2, 2024 at 12:34 PM

Sieht korrekt aus, in der Spec ist sogar ein Beispiel mit streamID 0.

M-Reimer · January 2, 2024 at 5:14 PM

Sehe gerade das jojo61 ein Issue dazu angelegt hat: https://github.com/rofafor/vdr-plugin-satip/issues/85

Ich hatte in der Vergangenheit auch schon mindestens einmal Patches gesammelt, einen PR erstellt und damit bisschen versucht dazu beizutragen das nicht alles irgendwo rumliegt.

ABER: Für mich sieht es doch etwas so aus als würde das Plugin von rofafor nicht mehr wirklich gepflegt.

Ich frage mich schon länger ob man mittlerweile vielleicht https://github.com/wirbel-at-vdr-portal/vdr-plugin-satip als "aktuelles Repo" ansehen sollte. Der letzte Commit im Repo von rofafor ist zwei Jahre her und eigentlich auch nur ein Mergen von Patches die aus der Community kommen.

Ist halt die Frage ob wirbel Lust hat bisschen einen Blick auf das Plugin zu halten. Dann könnte man ja, um die Form zu wahren, bei rofafor via Issue nachfragen wie der "Pflege-Stand" ist bevor man Verlinkungen auf das neue Repo ändert.

wirbel · January 2, 2024 at 6:44 PM

Ich werde meinen fork aktuell halten und auch diese sinnvolle Änderung von jojo dort einpflegen.

Aber dann müsste man mal beide Zweige vergleichen, commit für commit. Ich habe nur aufgegeben upstream bei rofafor Änderungen vorzuschlagen, weil die dann dort Monate lang unbearbeitet herum liegen. z.B. sind einige Patche aus der Community nicht drin bis jetzt, was das device Handling betrifft.

Zabrimus · January 2, 2024 at 8:00 PM

Quote from M-Reimer

ABER: Für mich sieht es doch etwas so aus als würde das Plugin von rofafor nicht mehr wirklich gepflegt.

Ich frage mich schon länger ob man mittlerweile vielleicht https://github.com/wirbel-at-vdr-portal/vdr-plugin-satip als "aktuelles Repo" ansehen sollte.

Quote from wirbel

Ich werde meinen fork aktuell halten und auch diese sinnvolle Änderung von jojo dort einpflegen.

Mir stellt sich gerade die Frage, ob ich das Repository in VDR*ELEC ändern sollte. Zumindest für die letzten 2 Commits in rofarors Repository habe ich auf die Schnelle ohne weitere gründliche Überprüfungen keine Entsprechnung im Repository von wirbel gefunden. Es betrifft Fixes, die FireFly hier im Forum bereitgestellt hatte.

wirbel · January 2, 2024 at 8:21 PM

Mein fork divergiert nach all der Zeit, nach der es upstream schon länger wenig Willen zu Änderungen gab.

Mein Focus lag auf der Anwendung innerhalb des Kanalscanners w_scan_cpp, aber das widerspricht ja nicht der generellen Anwendung.

Die Änderungen von FireFly ergaben Null Vorteil in w_scan_cpp, wohl aber der Anwendung als plugin. Und - die Änderungen waren zu groß, um sie eben mal einzupflegen.

wirbel · January 2, 2024 at 8:25 PM

btw: die Änderungen von jojo könnten erklären, warum ab && zu der erste channel Lock in w_scan_cpp keine Daten liefert..

jojo61 · January 6, 2024 at 10:53 AM

Ich hatte gestern mal auf das plugin von wirbel umgestellt weil ich mit dem von rofafor immer wieder Probleme mit dem Sctionfilter hatte (wobei ich nicht weiss was ein Sectionfilter ist :-). Allerdings treten die mit dem plugin von wirbel auch auf.

Dann wollte ich gestern meine HD+ Karte verlängern und da kamen dann die EMMs nicht durch. Wobei das nicht unbedingt am satip plugin liegen muss.

Ich denke das derzeit das plugin von wirbel wohl die bessere Wahl ist. Zumindest ist es beser gepflegt. wirbel schau halt mal nach den fehlenden Commits die zabrimus oben angesprochen hat (wenn du Lust hast).

jojo61 · January 6, 2024 at 11:55 AM

Hier nun die Probleme mit dem Sectionfilter:

Code

Jan 06 11:53:43 Orion vdr[4279]: [4285] SATIP-ERROR: failed to send section data (595 bytes) [device=0]
Jan 06 11:53:43 Orion vdr[4279]: [4285] SATIP-ERROR: failed to send section data (627 bytes) [device=0]
Jan 06 11:53:43 Orion vdr[4279]: [4285] SATIP-ERROR: failed to send section data (410 bytes) [device=0]
Jan 06 11:53:43 Orion vdr[4279]: [4285] SATIP-ERROR: failed to send section data (972 bytes) [device=0]
Jan 06 11:53:43 Orion vdr[4279]: [4285] SATIP-ERROR: failed to send section data (702 bytes) [device=0]
Jan 06 11:53:43 Orion vdr[4279]: [4285] SATIP-ERROR: failed to send section data (3006 bytes) [device=0]
Jan 06 11:53:43 Orion vdr[4279]: [4285] SATIP-ERROR: failed to send section data (386 bytes) [device=0]
Jan 06 11:53:43 Orion vdr[4279]: [4285] SATIP-ERROR: failed to send section data (627 bytes) [device=0]
Jan 06 11:53:43 Orion vdr[4279]: [4285] SATIP-ERROR: failed to send section data (627 bytes) [device=0]

Und das geht dann endlos weiter.

satip plugin am EXIP 418 (gelöst)

jojo61 January 2, 2024 at 12:41 PM

Participate now!

Users Viewing This Thread

jojo61 January 2, 2024 at 12:41 PM

Participate now!

Users Viewing This Thread

jojo61 January 2, 2024 at 12:41 PM