Beiträge von FireFly

Zitat von vdr_rossi

Ja, es gab Abstürze bei mir.

Schneide und verschiebe meist gleich danach, hätte vor längerer Zeit mal einen Beitrag zu dem crash verfasst.

Es ging jetzt aber nicht um einen Absturz (Segfault) sondern um einen Deadlock, d.h. das Menü und der ganze VDR reagieren nicht mehr auf Eingaben.

Deinen Post hatte ich die Tage gefunden, der war vermutlich der Grund für den Fix, der mit 2.6.2 rein kam aber sporadisch einen Deadlock erzeugt hat. Mit dem neuen Fix müssten jetzt aber beide Probleme behoben sein.

Ich hatte es auch einmal beim Verschieben auf eine andere Partition, aber ansonsten nur manchmal beim Schneiden. Zusätzlich muss ja das Menü offen sein und auch dann tritt es nur sporadisch auf.

kamel5: Kannst Du den Patch auch mal installieren? Du konntest ja den Deadlock zuverlässiger reproduzieren als ich

Zitat von bernie63

Kann mir jemand erklären, für welchen Stream-Type die @17 in der channels.conf steht?

aus remux.c:

case 0x11: // ISO/IEC 14496-3 Audio with LATM transport syntax

Ich denke, das ist deren Umstellung auf den AAC-LC Codec.

neues Release v1.1.1

• unvollständiges Scrollen in der Kanalanzeige korrigiert, wenn das REC-Symbol angezeigt wird

Oh, ich dachte mehrfaches Locking wäre innerhalb eines Threads erlaubt.

Grund für den Fix war lt. GIT: Fixed a possible crash if an editing process is canceled while the edited recording is being replayed

Wo das dann gecrashed ist weiß ich aber auch nicht.

Zitat

Kraftsonde ist auch nicht erforderlich.

Ich habe mal das recording.c von vanilla 2.6.1 und 2.6.3 verglichen:

# diff -y vdr-2.6.1/recording.c vdr-2.6.3/recording.c
....
void cRecordingsHandler::Action(void)                           void cRecordingsHandler::Action(void)
{                                                               {
  while (Running()) {                                             while (Running()) {
        bool Sleep = false;                                             bool Sleep = false;
        {                                                               {
          LOCK_RECORDINGS_WRITE;                              <
          Recordings->SetExplicitModify();                    <
          cMutexLock MutexLock(&mutex);                                   cMutexLock MutexLock(&mutex);
          if (cRecordingsHandlerEntry *r = operations.First()             if (cRecordingsHandlerEntry *r = operations.First()
             if (!r->Active(Recordings)) {                    |              if (!r->Active()) {
                error |= r->Error();                                            error |= r->Error();
                r->Cleanup(Recordings);                       |                 r->Cleanup();
                operations.Del(r);                                              operations.Del(r);
                }                                                               }
             else                                                            else
                Sleep = true;                                                   Sleep = true;
...

Da war ja vorher in cRecordingsHandler::Action() ein LOCK_RECORDINGS_WRITE vor dem &mutex drin !!

Das war zwar für das SetExplicitModify(), hat aber außerdem das Setzen der Mutexe in der falschen Reihenfolge verhindert!

Morgen werde ich das mal ausprobieren in der Hoffnung, dass es keine Nebenwirkungen hat ...

kamel5: Danke für Deine Rückmeldung.

Fairerweise muss ich natürlich zugeben, dass mein VDR auch gepatched ist auch wenn ich denke, dass das alles vergleichsweise harmlose Patches sind die nicht in das Locking eingreifen wie z.B. der menu-selection-Patch.

Weil Du "Verschieben" genannt hast: da fällt mir ein, dass ich es auch schon einmal hatte beim Verschieben einer Aufnahme auf die zweite phys. Platte.

Ich hatte jetzt schon mehrfach den Fall, dass VDR hängen blieb. Debuggen konnte ich das zweimal, als ich eine Wiedergabe starten wollte und in diesem Moment offenbar ein Schnittprozess fertig wurde.

Es hat offenbar etwas mit dem LOCK_RECORDINGS_WRITE und dem mutex im cRecordingshandler zu tun, mir ist aber nicht klar, wo welche Locks zuvor angefordert werden. Es scheint aber mit dem Patch http://git.tvdr.de/?p=vdr.git;…a62c38bea4712272623779b5e von VDR 2.6.2 zusammen zu hängen, da damit das LOCK_RECORDINGS_WRITE in cRecordingsHandlerEntry::Active() reingekommen ist.

Vielleicht kann jemand mehr aus den Backtraces lesen?

Ich habe eben bemerkt, dass ich mit der neuen Version 2.0.0 einen Absturz hatte, die OctopusNet war seit heute Vormittag via IP nicht mehr erreichbar und an der Front haben die beiden kleinen weißen LEDs geblinkt.

Ein Reset hat sie nun wieder zum Leben erweckt, aber ein ungutes Gefühl bleibt .... Die Logs zeigen nur Meldungen nach dem Reset an

Zitat von The Master

Ich fange mit "mc_to_pro" nicht wirklich was an.

Es hieß doch in der Ankündigung:

Zitat

Anfang des Jahres 2023 folgt dann ebenfalls das Update für alle Octopus NET MC Modelle.

Also ist das wohl für eine andere Octopus Net Modellreihe

Nachdem ich jetzt auch das Update eingespielt habe kann ich das auch weiter untersuchen. Die Lüfterdrehzahl gibts als JSON mit

> curl "http://octopus-ip/system/fanspeed"
{"speed": 1800}

und die Temperatur (leider nicht mehr als JSON-Objekt sondern als einfache Liste) mit

> curl "http://octopus-ip/log/Temperatur.log"
1,30,-2
28
27
27
27
27
26
...

Dabei stehen offenbar in der ersten Zeile (in Anlehnung an meinen vorigen Post) "NumSensors, Interval, Fanstate"

und dann die Temperaturen in chronologischer Reihenfolge, d.h. der aktuellste Wert ist der letzte in der Liste.

Die aktuelle Temperatur bekommt man also z.B. auf der bash mit

> curl -s "http://octopus-ip/log/Temperatur.log"|tail -1
24

Das Auslesen der aktuellen Tuner-Empfangswerte bleibt dem Leser als Übungsaufgabe überlassen

Was sagt denn smartctl?

Zitat von 447377

Wie sollte sonst die aktuelle Temperatur der Octopus Net vom VDR ausgelesen werden?

Bei der 1.1.x geht das mit wget "http://octopusnet/monitor.lua"

Da kommt dann ein JSON Objekt zurück, das als letzten Wert in SensorData die aktuelle Temperatur enthält:

"NumSensors":"1",
"Interval":"30",
"FanState":"-2",
"FanSpeed":"1700",
"SensorData": [
["34","34","34","34","33","33","33","33","32","32","32","33","33","34","34","34","34","34","34"
.......
"24","24","24","24","24","24","24","24","24","24","24","24","24","24","24","24","24","24","24"]
]
}

Bei 2.0.0 (habe ich noch nicht installiert) müsste es doch etwas ähnliches geben, wenn das Webinterface die Grafik selbst aktualisiert. Rauszufinden ist das über die Source-Ansicht der Seite im Browser.

Zitat von The Master

Also eintragen kann man es in der GUI nicht.

Dann bleibe ich wohl noch etwas länger bei der 1.1.7 ...

Zitat von The Master

Auch "/monitor.lua" funktioniert mit Version 2.0 nicht mehr.

Dann heißt es jetzt vermutlich anders, in den Systemeinstellungen gibt es ja lt. Screenshots noch die Temperatur (wenn sie etwas vernünftiges anzeigt)

DNS/Netzwerk kann man doch jetzt über das Webinterface einstellen und die Temperatur sollte auch via HTTP abzufragen sein, wenn man die gleichen GET-Requests stellt wie das Webinterface (geht zumindest bei der 1.1.7 mit "http://octopus/monitor.lua", die 2.0 habe ich noch nicht ausprobiert)

Sowas hatte ich vor einigen Jahren mal mit yaUSBir, da wird das USB-Device irrtümlich nach einiger Zeit deaktiviert IIRC.

Ich weiß aber nicht mehr ob es mit einem neueren Kernel (d.h. im USB-Subsystem) gefixed wurde oder ob ich im yaUSBir/LIRCD etwas anpassen musste.

Zitat von MegaV0lt

Bei meinen versuchen den VDR zu patchen lief danach nichts mehr...

Bei mir schon Hat gerade wieder 3% eliminiert

Mission completed Dann kann ich mein Repo ja wieder löschen (mach ich aber nicht)