Die gleichen Aussetzer lassen sich im log ganz klar erkennen. Habe gefragt weil keiner mehr ein log gepostet hat.
Kurze Aussetzer bei Widergabe von einer internen HDD
-
-
Logs sind ja schon zig Mal gepostet worden.
Weiters Posten würde also nur Sinn machen, wenn jemand andere Einträge im Log findet. -
Soo es liegen nun Treiber auf dem Unstable Feed die das Problem laut den internen Tests nun beheben.
Stable folgt dann in ca. einer Woche...
cya
-
Wow, super! Und woran hat es gelegen?
-
Am Treiber
-
Also ich hatte eben leider wieder einen Aussetzer im Timeshift
Hab natürlich nicht mitgeloggt -
Wenn die Box noch läuft kannst Du auch einfach mal "dmesg" eingeben... dann bekommst Du die Treiber Ausgaben rückwirkend... je nachdem wie viel da schon war kann es sein, dass man noch etwas sieht.
Es kann aber auch sein, dass du einfach ein anderes Problem hast, was nichts mit dem zu tun hat, was da nun behoben wurde...
Nimmst du auf Netzwerk auf? Oder Festplatte?
Schau wie gesagt mal ob im dmesg was steht.. allerdings müsstest du dann ungefähr die Uhrzeit wissen.. und dann die sekunden abziehen von denen im dmesg log...
cu
-
Also hab den besagten Fehler gefunden über dmesg
Danke für den Tipp
[10898.571268] pts_error_isr: 53 callbacks suppressed
[10898.571283] VIDEO0: pts error PTS 0x75b38a87, STC 0x75b3e714, type 0Ich zeichne Timeshift auf eine interne Samsung SSD Evo 840 auf
PS: Rund um den Fehler sind nur CEC Meldungen
PPS: Ok er ist zwei mal vorhanden
Greetz Gerry
-
Das normale dmesg kann sogar Datum und Uhrzeit ausgeben.
Könnte man nicht ein paar Busybox Befehle durch die GNU Pendants ersetzen? Platz dazu gibt es ja.Gesendet von iPhone mit Tapatalk
-
Gerry6n: hmm hast Du geschaut, ob der Fehler an der selben Stelle nochmal kommt wenn du zurück springst?
Weil da sieht einfach die Aufnahme kaputt aus.
Das ist nicht der alte Fehler.. also der, der gefixt wurde.
Das kann nun einfach alles sein.. kaputte Aufnahmen.. kaputt gesendete Daten vom Sender...
cu
-
Mhh leider wurde schon umgeschaltet und das Timeshift nicht gespeichert. Werde die Tage mal testen wenn ich wieder mehr Zeit habe. Evtl liegts ja an der SSD? Werde mal testweise ne normale HDD reinschieben.
Halte euch auf dem Laufenden
-
Sorry hatte Glück im Unglück,
das File pts_livebuffer.1 ist noch auf der SSD. Leider taucht hier der Fehler nicht mehr auf
-
Ja schwierig dann...
Ich werde nun mal etwas Feedback abwarten.
Aber die, die intern den Fix getestet hatten, hatten alle keine Fehler mehr.
Naja beobachte es mal...
Aber das was du da im Log hattest ist definitiv nicht der Fehler, der hier die ganze Zeit in den Logfiles sichtbar war.
Eventuell ist das auch einfach ein Bug im Timeshift ... oder PTS.
Wüsste zwar gerade nicht was das sein könnte..
Allerdings hatte ich in den letzten Tage hier sehr oft Timeshift laufen über längeren Zeitraum... und keine Fehler in der Richtung.
cu
-
kannst das file ja notfalls mit TS doctor testen.. einfach um alles auszuschließen. oder wo hochladen ?
-
Hatte gestern beim Abspielen von der QNAP wieder einen Bildhänger
[58226.593389] pts_error_isr: 113 callbacks suppressed
[58226.593421] VIDEO0: pts error PTS 0x24ab51ef, STC 0x24abac9c, type 0Also kann es ja nicht an der internen SSD liegen wenn es von der NAS auch auftritt.
Werde mal sehen ob ich ein richtiges LOG davon erstellen kann.
Beide TS-Files sind laut TS-Doctor fehlerfrei
Braucht ihr ein enigma log oder ein serielles davon?
PS: würde ja acuh mal den alten Imagestand testen, dann funktioniert aber mein FBC-Tuner wahrscheinlich nicht
Greetz Gerry
-
Aktuell scheinst du aber der einzige zu sein, der da noch Probleme hat. Oder aber es schreibt niemand etwas.
Als Erklärung der Meldung... diese Meldung sagt nur aus, dass die SystemTimeClock .. also die Audio/Video Decoder Zeit von der "PresentationTimeStamp" eines Bildes was demnächst angezeigt werden soll.. bzw.. welches gerade an der Reihe wäre zu weit abweicht.. in diesem Fall übernehmen dann beide Decoder die zeit aus der PTS .. sprich die STC wird neu gesetzt. Woran das bei Dir nun liegt weiss ich nicht.
Netzwerk sehe ich allerdings als noch deutlich fehleranfälliger an, als eine lokale Festplatte.
Betrifft es denn bei Dir eventuell nun immer die selben Sender?
Also keine Ahnung.. wenn es immer die selben Sender / Sendungen wären, und es irgendwie halbwegs nachstellbar wäre könnte man da suchen.. aber wenn das alle X Tage einmal auftritt, dann wird es extrem schwierig.
In diesem Fall war die Abweichung übrigens ungefähr 260ms.
Das kann man recht einfach ausrechnen, indem man die angegebene STC von der PTS abzieht... und dann durch 90000 teilt.. aber beachten, dass das Hex Werte sind.
Der ursprüngliche Fehler ist das auf jedenfall nicht.... beim ursprünglichen Fehler dieses Threads kam immer eine falsche PTS die den Wert 0xFFFFFFFF hatte... und damit dann total falsch war..
Ach nochwas.. in deinem Fall da war die STC schon weiter, als die eigentliche PTS. Sprich das Bild kam zu spät. Was durchaus ein Problem des Datentransports gewesen sein kann.
Sprich die Daten kamen einfach zu spät im Decoder an.
cu
-
Mhh seltsam,
es waren zwei verschiedene Sender RTLII beim ersten mal und RTL beim zweiten. Die TS-Files sind laut TS-Doctor fehlerfrei. Also kann ec schlecht daher kommen
Werde nochmal sie Netzwerk-Setting checken, wobei im ersten Fall ja die interen SSD gleiches Problem hatte, wenn auch der Zeit Unterschied nicht so Groß war.
Greetz gerry
-
Wie schauts mittlerweile aus, haben die betroffenen mit dem neuen Fix noch Aussetzer?
-
Es gibt ein Fix?
Rex
-
Sowohl im Unstable als auch im Stable Feed ist der Fix derweil enthalten.
Und ich bekomme da eigentlich nur positive Rückmeldungen. Auch Leute die viele Aussetzer hatte, haben nun keine mehr.
Der Rest, der nun übrig bleibt wird dann wohl etwas anderes sein.. sprich Netzwerk Probleme.. defekte Aufnahmen .. whatever.
Aber das Problem um welches es in diesem Thread ging, ist behoben.
cu