Die Aufnahmefehler wurden aber bei mir durch den Quirk verursacht.
Ohne diesen, habe ich kaum noch Aufnahmefehler, und keine bei gleichzeitiger Nutzung eines anderen Senders auf dem aufnehmenden Transponder.
Aber sehr interessant, Deine Analyse...
Beiträge von heifisch
-
-
Ich denke auch, Transparent.
Klar ist es etwas aufwendiger, wenn man beide Logos ("Light" und "Dark") vorhalten muss, weil der VDR-Skin die "Light" und das Live-Theme die "Dark" benötigen damit es gut ausschaut. Stellt man in Live ein dunkleres Theme ein, würden "Light"-Logos auch gehen.
-
Von "bwdif" in FFmpeg inzwischen auch eine Cuda-Version, eventuell ist das hier also auch einen Versuch wert.
So, ffmpeg 6.1 ist raus und bwdif_cuda mit an Bord.
Codevdr ~ # ffmpeg -filters -hide_banner | grep Deinterlace TS. bwdif V->V Deinterlace the input image. T.. bwdif_cuda V->V Deinterlace CUDA frames TS. yadif V->V Deinterlace the input image. T.. yadif_cuda V->V Deinterlace CUDA framesIch habe mich mal an einem Patch versucht um Bwdif statt Yadif zu verwenden, siehe Anhang.
Ich weiß zwar nicht, ob ich es richtig gemacht habe, der VDR läuft damit aber schon mal.
Code
Alles anzeigenDec 2 21:10:10 vdr vdr: ***************codec: Video Open using video codec ID 0x0002 (mpeg2video) Dec 2 21:10:10 vdr vdr: codec: decoder found Dec 2 21:10:10 vdr vdr: codec: video 'Nvidia CUVID MPEG2VIDEO decoder' Dec 2 21:10:10 vdr vdr: pesdemux: pes start code id 0xbd Dec 2 21:10:10 vdr vdr: pesdemux: new codec 000000 -> 0x15003 Dec 2 21:10:10 vdr vdr: codec: using audio codec ID 0x15003 (ac3) Dec 2 21:10:10 vdr vdr: Codec open 0 Dec 2 21:10:10 vdr vdr: Initializing cuvid hwaccel thread ID:2985 Dec 2 21:10:10 vdr vdr: schon passiert Dec 2 21:10:10 vdr vdr: codec: audio 'ATSC A/52A (AC-3)' Dec 2 21:10:10 vdr vdr: codec/audio: Chanlayout 3 format change fltp 48000Hz *2 channels PCM AC-3 E-AC-3 pass-through Dec 2 21:10:10 vdr vdr: codec/audio: resample fltp 48000Hz *2 -> s16 48000Hz *2 Dec 2 21:10:10 vdr vdr: video: ready --:--:--.--- 0ms/frame 1753ms Dec 2 21:10:10 vdr vdr: Cuvid_get_format: codec 2 fmts: Dec 2 21:10:10 vdr vdr: 0x00000075 cuda Dec 2 21:10:10 vdr vdr: 0x00000017 nv12 Dec 2 21:10:10 vdr vdr: Cuvid_get_format: codec 2 fmts: Dec 2 21:10:10 vdr vdr: 0x00000075 cuda Dec 2 21:10:10 vdr vdr: video profile -99 codec id 2 Dec 2 21:10:10 vdr vdr: video: create decoder 16bit?=0 720x576 old 720 576 Dec 2 21:10:10 vdr vdr: video: slow down video, duping frame 37 Dec 2 21:10:10 vdr vdr: deint = Bwdif Dec 2 21:10:10 vdr vdr: GetFormat Init ok 720x576 Dec 2 21:10:11 vdr vdr: Init BWDIF okLeider gibt es zum Zittern des Bildes keine Verbesserung gegenüber Yadif.
jojo61 Kannst Du Dir den Patch mal ansehen, nicht dass das Deinterlacing immer noch mit Yadif läuft.
Danke.
-
Hallo,
ich habe hier eine Aufnahme, deren Timer von TvScraper angelegt wurde.
Diese habe ich manuell beendet, in dem ich den Timer gelöscht habe, nachdem der Film zu Ende war.
Nun habe ich die Fehler-Anzeige "Abweichung der Aufzeichnungslänge..." bei dieser Aufnahme.
Sollte diese Anzeige nicht nach dem Schneiden verschwinden?
Was muss ich tun, damit der Fehler nicht mehr angezeigt wird?
Gruß und Danke
Heiko
-
Das ist ja aber schon der erste Unterordner, der "Dateisystem-Ansicht" heißt. Oder wo kommt das bei euch her ? Ich habe den nicht.
Das ist bei mir auf der Platte kein Unterordner.
Im Filesystem ist das /video bei mir.
-
Mir ist auch noch ein Problem mit der 3.3.1 aufgefallen:
Aufnahmen in der obersten Ebene des Aufnahmeverzeichnisses werden nicht mehr angezeigt. Es muss zumindest eine Ebene Unterverzeichnis geben, damit man die Aufnahme durch aufklappen sehen kann.
Ich weiß nicht, ob ich es richtig verstanden habe, aber bei mir, mit tntnet3.0, sind direkt unter Dateisystem-Ansicht, Aufnahmen sichtbar:
-
Im git ist ein update. Damit sollte auch tntnet 3 gehen
Vielen Dank!
Bei mir funktioniert es jetzt auch wieder.
-
Code
InstallTrigger sollte nicht mehr verwendet werden und wird in Zukunft entfernt werden. constants.js:50:14Das irritiert mich, das kommt nicht von live.
Kann sein, stand schon da bevor ich den Ordner aufgeklappt habe.
-
Irgendwas im syslog, was den String "get_recordings" enthält?
Oder etwas mit "tntnet"?
Beide Strings gibt es nicht im syslog.
Ich habe mal --log=TRACE bei live eingestellt aber da kommt auch nicht mehr.
Das Einzige was im Zusammenhang mit live kommt ist Folgendes:
CodeNov 19 19:30:58 vdr vdr: [3979] live: DH: ------ RecordingsTree::RecordingsTree() --------, required time: 1,07090 Nov 19 19:30:58 vdr vdr: [3979] live: VDR-Live-Recordings-Tree-Open-Nodes = fldr_7CCB6B15,fldr_80A7D7B8 -
Kannst Du mal mit Firefox testen?
Den Debugger von Firefox einschalten (F12), und schauen, ob es Fehlermeldungen gibt?
CodeInstallTrigger sollte nicht mehr verwendet werden und wird in Zukunft entfernt werden. constants.js:50:14 Uncaught (in promise) TypeError: obj is undefined recordings.html:241:9 RecordingsSt_int http://192.168.139.150:8008/recordings.html?flat=false&filter=:241 RecordingsSt_a http://192.168.139.150:8008/js/live/createHtml.js:309 rec_string_d_a http://192.168.139.150:8008/js/live/createHtml.js:316 Toggle http://192.168.139.150:8008/js/live/treeview.js:60 onclick http://192.168.139.150:8008/recordings.html?flat=false&filter=:1 -
Lösche doch bitte mal den Browser Cache.
Bzw. Seite mit strg+F5 neu laden.
Browser Cache hatte ich schon prophylaktisch gelöscht und Browser neu gestartet.
Hat aber nicht geholfen.
Nachtrag: hier tntnet3.0
-
Ich bekomme leider mit der aktuellen git-Version keine Aufnahmen unter Aufnahmen angezeigt, auch bei den Serien und Sammlungen.
Unter Aufnahmen (flach) sind die Aufnahmen sichtbar.
-
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.
-
Was mir noch aufgefallen ist, in "Was läuft" könnte zwischen dem Datum und der Uhrzeit noch ein Leerzeichen rein.
-
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
) -
Nur das Suchfeld leeren oder das komplette Formular resetten?
Jetzt muss man 3 Aktionen durchführen:
1. Cursor mit der Maus in das Suchfeld setzen,
2. Suchstring entfernen, mit Backspace oder was auch immer,
3. Enter drücken für ein reload,
Ich weiß, ich bin sehr faul.
Würde gerne nur mit der Maus auf eine Knopf drücken für diese Aktionen...
-
Erst mal vielen Dank für die Weiterentwicklung!
Ich hätte auch einen kleinen Verbesserungsvorschlag.
Ich wünsche mir einen Reset-Knopf für die Volltext-Suche in den Aufnahmen.
Der soll das Suchfeld leeren und ein Reload ausführen.
Vielleicht ist das ja ohne großen Aufwand machbar.
Gruß
Heiko
-
Hallo Cumpy Rules.
Wie wäre die beste Vorgehensweise zu prüfen ob meine Octopus Net die Ursache für die Umschaltprobleme sind.
Die Aufnahme-Problem im Titel kamen von der Aktivierung von quirk: 0x08...
Gruß und Danke.
-
Ich habe nun mal meine betagte GSS.box mit aktueller satip-axa und Minisatip8 angeschlossen und konnte das Problem beim Umschalten damit nicht reproduzieren.
Also ist wahrscheinlich die Ursache der Umschaltprobleme die Octopus Net.
Nun ist die Frage, kann es ein Hardware Problem sein?
Bei einem Software-Problem, wäre der Fehler möglicherweise nicht über alle Firmware-Versionen aufgetreten und es wäre möglicherweise noch bei jemand anderen aufgetreten, oder?
Hat jemand noch eine Idee?
Edit:
Ein anderes Netzteil habe ich probiert, bringt keine Besserung.
-
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.
