Du könntest auch mal z.B. auf Windows mit dvbviewer Testversion testen.
Denn es könnte ja nicht nur am satip-plugin liegen, sondern auch am Octopus.
[Octopus NET Pro und Sat>IP] Fehler beim Umschalten (Tele 5 SD --> kabel eins SD)
-
-
Guck mal in log.h
Je nach dem was du sehen willst, musst du die Werte addieren.
Ja, habe ich schon gesehen.
Da kommt nur teilweise sehr viel, bei dem ich nicht sehe, dass es nützlich wäre.
Du könntest auch mal z.B. auf Windows mit dvbviewer Testversion testen.
Denn es könnte ja nicht nur am satip-plugin liegen, sondern auch am Octopus.
Habe leider keinen Windows-Rechner. Hier läuft ausschließlich Gentoo-Linux.
Aber da gibt es sicher auch etwas vergleichbares.
Ich habe mich mal mit ffplay auf einen bestehenden Stream drauf geschaltet, aber das hat noch nichts gebracht.
-
Was hast du bei CSeq: 21 gesehen und gehört?
Kannst du Netzwerk-Fehler ausschliessen? Passiert das auch, wenn der Client direkt an der Octopus hängt?
-
Habe leider keinen Windows-Rechner. Hier läuft ausschließlich Gentoo-Linux.
Übersicht der SAT>IP ClientsIn dieser Übersicht möchten wir Nutzern von SAT>IP Servern eine Liste von möglichen SAT>IP tauglichen Clients aufzeigen.www.digital-devices.eu -
Was hast du bei CSeq: 21 gesehen und gehört?
Mit der Umschaltung bei Cseq: 21 tritt der Fehler auf.
Danach erkennt ffmpeg die Auflösung des Stream fälschlicherweise 480x576 und VDR hängt mit Bildfehler und Einfrieren des Bildes und den Clear-Meldungen. Man sieht das in der satip_log5.txt.
Das CSeq: 21 habe ich dann verwendet um im Debug-Log der Octonet den Bereich zu finden in dem die fehlerhafte Umschaltung stattfindet.
Aber gesehen bzw. verstanden, was da schief läuft, habe ich nicht.
Kannst du Netzwerk-Fehler ausschliessen? Passiert das auch, wenn der Client direkt an der Octopus hängt?
Ja, Netzwerkfehler würde ich ausschließen.
Der VDR hängt direkt am Switch der Octonet und ich konnte den Fehler genauso, mit einem frischen 10m Patchkabel, direkt angeschlossen an der Octonet, reproduzieren.
-
Was hast du bei CSeq: 21 gesehen und gehört?
Ich meinte nicht deine Erkenntnisse, sondern was du auf dem Bildschirm gesehen hast und mit den Ohren als Ton gehört hast
-
Das satip plugin hat den richtigen Transponder getuned und die richtigen PIDs gesetzt, VDR hat dann den richtigen Audio und Video Codec gemeldet, schief gehts erst nach
Nov 9 16:37:13 vdr vdr: ***************codec: Video Open using video codec ID 0x0002 (mpeg2video)
Nov 9 16:37:13 vdr vdr: codec: decoder found
Nov 9 16:37:13 vdr vdr: codec: video 'Nvidia CUVID MPEG2VIDEO decoder'
-
Der Quirk 0x08 (eSatipQuirkTearAndPlay) löst beim Tuning ein Disconnect() aus, deshalb die Fehler in den Aufnahmen.
Ich habe jetzt mal nach dem tuning.Set(eTuningTimeoutMs); ein sleep eingebaut.
Damit konnte ich bisher keine Hänger und auch keine Bildfehler beim Umschalten mehr feststellen.
Diff
Alles anzeigendiff --git a/tuner.c b/tuner.c index b5af331..19d3a1e 100644 --- a/tuner.c +++ b/tuner.c @@ -100,54 +100,55 @@ cSatipTuner::~cSatipTuner() void cSatipTuner::Action(void) { debug1("%s Entering [device %d]", __PRETTY_FUNCTION__, deviceIdM); bool lastIdleStatus = false; cTimeMs idleCheck(eIdleCheckTimeoutMs); cTimeMs tuning(eTuningTimeoutMs); reConnectM.Set(eConnectTimeoutMs); // Do the thread loop while (Running()) { UpdateCurrentState(); switch (currentStateM) { case tsIdle: debug4("%s: tsIdle [device %d]", __PRETTY_FUNCTION__, deviceIdM); break; case tsRelease: debug4("%s: tsRelease [device %d]", __PRETTY_FUNCTION__, deviceIdM); Disconnect(); RequestState(tsIdle, smInternal); break; case tsSet: debug4("%s: tsSet [device %d]", __PRETTY_FUNCTION__, deviceIdM); if (currentServerM.IsQuirk(cSatipServer::eSatipQuirkTearAndPlay)) Disconnect(); if (Connect()) { tuning.Set(eTuningTimeoutMs); + sleepM.Wait(eSleepTimeoutMs); // Test HF RequestState(tsTuned, smInternal); UpdatePids(true); } else Disconnect(); break; case tsTuned: debug4("%s: tsTuned [device %d]", __PRETTY_FUNCTION__, deviceIdM); deviceM->SetChannelTuned(); reConnectM.Set(eConnectTimeoutMs); idleCheck.Set(eIdleCheckTimeoutMs); lastIdleStatus = false; // Read reception statistics via DESCRIBE and RTCP if (hasLockM || ReadReceptionStatus()) { // Quirk for devices without valid reception data if (currentServerM.IsQuirk(cSatipServer::eSatipQuirkForceLock)) { hasLockM = true; signalStrengthDBmM = eDefaultSignalStrengthDBm; signalStrengthM = eDefaultSignalStrength; signalQualityM = eDefaultSignalQuality; } if (hasLockM) RequestState(tsLocked, smInternal); } else if (tuning.TimedOut()) { error("Tuning timeout - retuning [device %d]", deviceIdM); RequestState(tsSet, smInternal);Was meint jemand dazu, der Ahnung hat? (Ich habe ja eigentlich keine
) -
Das warten wird eigentlich in tsTuned erledigt. Deine Änderung hält ja die ganze Statemaschine an.
Interessant wäre mal nachzuforschen, ob ein neues Tunen hasLockM auf false setzt.
Codeif (hasLockM || ReadReceptionStatus()) { -
Interessant wäre mal nachzuforschen, ob ein neues Tunen hasLockM auf false setzt.
So vielleicht?
Diff
Alles anzeigendiff --git a/tuner.c b/tuner.c index b5af331..76aba43 100644 --- a/tuner.c +++ b/tuner.c @@ -98,71 +98,73 @@ cSatipTuner::~cSatipTuner() rtpM.Close(); } void cSatipTuner::Action(void) { debug1("%s Entering [device %d]", __PRETTY_FUNCTION__, deviceIdM); bool lastIdleStatus = false; cTimeMs idleCheck(eIdleCheckTimeoutMs); cTimeMs tuning(eTuningTimeoutMs); reConnectM.Set(eConnectTimeoutMs); // Do the thread loop while (Running()) { UpdateCurrentState(); switch (currentStateM) { case tsIdle: debug4("%s: tsIdle [device %d]", __PRETTY_FUNCTION__, deviceIdM); break; case tsRelease: debug4("%s: tsRelease [device %d]", __PRETTY_FUNCTION__, deviceIdM); Disconnect(); RequestState(tsIdle, smInternal); break; case tsSet: debug4("%s: tsSet [device %d]", __PRETTY_FUNCTION__, deviceIdM); if (currentServerM.IsQuirk(cSatipServer::eSatipQuirkTearAndPlay)) Disconnect(); if (Connect()) { tuning.Set(eTuningTimeoutMs); RequestState(tsTuned, smInternal); +// sleepM.Wait(eSleepTimeoutMs); // Test HF UpdatePids(true); } else Disconnect(); break; case tsTuned: debug4("%s: tsTuned [device %d]", __PRETTY_FUNCTION__, deviceIdM); deviceM->SetChannelTuned(); reConnectM.Set(eConnectTimeoutMs); idleCheck.Set(eIdleCheckTimeoutMs); lastIdleStatus = false; + debug1("%s: hasLockM %B [device %d]", __PRETTY_FUNCTION__, hasLockM, deviceIdM); // Read reception statistics via DESCRIBE and RTCP if (hasLockM || ReadReceptionStatus()) { // Quirk for devices without valid reception data if (currentServerM.IsQuirk(cSatipServer::eSatipQuirkForceLock)) { hasLockM = true; signalStrengthDBmM = eDefaultSignalStrengthDBm; signalStrengthM = eDefaultSignalStrength; signalQualityM = eDefaultSignalQuality; } if (hasLockM) RequestState(tsLocked, smInternal); } else if (tuning.TimedOut()) { error("Tuning timeout - retuning [device %d]", deviceIdM); RequestState(tsSet, smInternal); } break; case tsLocked: debug4("%s: tsLocked [device %d]", __PRETTY_FUNCTION__, deviceIdM); if (!UpdatePids()) { error("Pid update failed - retuning [device %d]", deviceIdM); RequestState(tsSet, smInternal); break; } if (!KeepAlive()) { error("Keep-alive failed - retuning [device %d]", deviceIdM); RequestState(tsSet, smInternal); break; } if (reConnectM.TimedOut()) {hasLockM ist fast immer 1 siehe Anhang.
-
heifisch
Hat den Titel des Themas von „[Octopus NET Pro und Sat>IP] Aufnahmefehler bei gleichzeitiger Nutzung eines anderen Senders auf dem aufnehmenden Transponder“ zu „[Octopus NET Pro und Sat>IP] Fehler beim Umschalten (Tele 5 SD --> kabel eins SD)“ geändert. -
So wie es bis jetzt ausschaut, hast du auf diesem einen Transponder Probleme mit Signalstärker und/oder -qualität. Je nachdem, welche Tuner-Hardware sich daran versucht, hast du Erfolg oder auch nicht.
Du könntest - mit deinem dirty Patch, der dir erfolgreiches Tunen ermöglicht - mal bei Werte mit dem Femon Plugin vergleichen.
Zweite Frage wäre, ob du nach erfolgreichem Tunen vermehrt Bildfehler beobachtest.
-
Empfangsprobleme lassen sich aus satip/vtuner-Logs kaum erkennen. Was rauszulesen ist, ist die Signalstärke von 120/121 bei 12480 und 115/116 bei 12545. Vielleicht gibt es hier ein Muster?
Das Modul dvb-core hat den Schalter dvb_demux_tscheck, den vielleicht mal auf 1 setzen? -
So wie es bis jetzt ausschaut, hast du auf diesem einen Transponder Probleme mit Signalstärker und/oder -qualität. Je nachdem, welche Tuner-Hardware sich daran versucht, hast du Erfolg oder auch nicht.
Du könntest - mit deinem dirty Patch, der dir erfolgreiches Tunen ermöglicht - mal bei Werte mit dem Femon Plugin vergleichen.
Zweite Frage wäre, ob du nach erfolgreichem Tunen vermehrt Bildfehler beobachtest.
Die Signalstärke und Qualität ist in Ordnung.
Ich habe die Umschaltprobleme auch, wenn ich den Pegel anhebe.
Die Anlage (1m Kathrein-Schüssel mit Kathrein LNB) ist mit einem Sat-Messgerät alpsat AS06-STC eingemessen und die Werte decken sich mit den Anzeigen in der Octopus Net.
Die femon Werte sehen allerdings völlig anders aus.
Der Mitarbeiter von Digital Devices hat mir gesagt, ich soll mit der Signalstärke möglichst nicht höher als 65 dBµV gehen.
Also habe ich die runtergeregelt. Ohne Dämpfer hatte ich >80 dBµV und damit auch die Probleme gehabt.
Zur 2. Frage, bei erfolgreichem Tunen gibt es absolut keine Bildfehler.
Für mich (als Halbwissender) sieht es nicht danach aus, dass die Ursache das Signal ist, was bei der Octopus Net ankommt.
Gefühlsmässig würde ich sagen, der Stream wird gestartet bevor ein "sauberes" lock stattgefunden hat.
Deswegen hilft der Patch das Problem zu kaschieren.
Ich hatte gehofft man könnte in den logs so etwas erkennen.
-
Empfangsprobleme lassen sich aus satip/vtuner-Logs kaum erkennen. Was rauszulesen ist, ist die Signalstärke von 120/121 bei 12480 und 115/116 bei 12545. Vielleicht gibt es hier ein Muster?
Das Modul dvb-core hat den Schalter dvb_demux_tscheck, den vielleicht mal auf 1 setzen?Danke erstmal fürs drüber schauen.
Wie ich eins höher schon schrieb, gehe ich nicht von Empfangsproblemen aus.
Die Signalstärken sollten passen, sind in dem Bereich, wie es mir der DD-Mitarbeiter genannt hat.
Das dvb_demux_tscheck haut bei jedem Umschalten eine Menge raus:
Code
Alles anzeigenJan 20 10:18:09 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x200 expected 0x1 got 0x2 Jan 20 10:18:09 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x12 expected 0x3 got 0x0 Jan 20 10:18:09 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x0 expected 0x2 got 0x1 Jan 20 10:18:09 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1ff expected 0x1 got 0x4 Jan 20 10:18:10 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x10 expected 0xa got 0x0 Jan 20 10:18:10 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x12 expected 0xb got 0x5 Jan 20 10:18:10 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0xff expected 0x1 got 0x4 Jan 20 10:18:10 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x103 expected 0x1 got 0x5 Jan 20 10:18:10 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x100 expected 0x1 got 0xe Jan 20 10:18:10 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x60 expected 0xa got 0xb Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x203 expected 0x1 got 0xd Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1ff expected 0x1 got 0x4 Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x200 expected 0x1 got 0x2 Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x12 expected 0x1 got 0x3 Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x0 expected 0x1 got 0x5 Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x61 expected 0x1 got 0xd Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x60 expected 0x1 got 0xd Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x10 expected 0x1 got 0x3 Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x62 expected 0x1 got 0xe Jan 20 10:21:51 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x63 expected 0x1 got 0xf Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x203 expected 0x1 got 0xb Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x200 expected 0x1 got 0x0 Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x0 expected 0x1 got 0x9 Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x12 expected 0x1 got 0xe Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x1ff expected 0x1 got 0xa Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x10 expected 0x1 got 0xd Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x62 expected 0x1 got 0x2 Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x63 expected 0x1 got 0x3 Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x11 expected 0x1 got 0x2 Jan 20 10:25:29 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x64 expected 0x1 got 0x4 Jan 20 10:25:50 vdr kernel: dvb_dmx_swfilter_packet: 5 callbacks suppressed Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x3ff expected 0x1 got 0xd Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x3ff expected 0x4 got 0xc Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x400 expected 0x1 got 0xd Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x0 expected 0xb got 0xc Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x12 expected 0xe got 0xb Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x400 expected 0xe got 0x8 Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x3ff expected 0x9 got 0xa Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x12 expected 0x0 got 0x5 Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x0 expected 0xd got 0xc Jan 20 10:25:50 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x63 expected 0x4 got 0x9 Jan 20 10:27:10 vdr kernel: dvb_dmx_swfilter_packet: 14 callbacks suppressed Jan 20 10:27:10 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x4ff expected 0x1 got 0x3 Jan 20 10:27:10 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x500 expected 0x1 got 0x6 Jan 20 10:27:10 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x64 expected 0x5 got 0xd Jan 20 10:27:11 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x10 expected 0xc got 0xe Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x13f3 expected 0x1 got 0xa Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x13ed expected 0x1 got 0x2 Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x13f2 expected 0x1 got 0x3 Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x13f1 expected 0x0 got 0x1 Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x13ee expected 0x1 got 0xf Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x13ef expected 0x1 got 0xf Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x12 expected 0x1 got 0xf Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x0 expected 0x2 got 0xb Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x11 expected 0x0 got 0xc Jan 20 10:27:32 vdr kernel: dvb_demux: dvb_dmx_swfilter_packet: TS packet counter mismatch. PID=0x14 expected 0x4 got 0x8 Jan 20 10:27:45 vdr kernel: dvb_dmx_swfilter_packet: 14 callbacks suppressedWenn das unnormal ist, könnte ich das noch mal mit dem anderen Sat>IP Server der GSS.box vergleichen.
Für mich (als Halbwissender) sieht es nicht danach aus, dass die Ursache das Signal ist, was bei der Octopus Net ankommt.
Gefühlsmässig würde ich sagen, der Stream wird gestartet bevor ein "sauberes" lock stattgefunden hat.
Deswegen hilft der Patch des satip-Plugins das Problem zu kaschieren.
Ich hatte gehofft man könnte in den vtuner/satip logs so etwas erkennen.
Ich weiß allerdings nicht, auf was ich da schauen müsste.
-
64 dBµV sind völlig i.O. (47..77 passen), wenn du zusätzlich keine Bildfehler beobachtest, dann liegt es auch nicht daran.
-
haut bei jedem Umschalten eine Menge raus: [...]
Wenn das unnormal ist, könnte ich das noch mal mit dem anderen Sat>IP Server der GSS.box vergleichen.Nö, ist nicht unnormal. Bei mir ist das schon auch so, aber nach dem Umschalten ist "Ruhe", d.h. da bekomme ich dann keinen einzigen Fehler mehr...
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!