Posts by FireFly

Ok, ich werde es mit -Wshadow probieren und versuchen das nochmal nachzustellen

Nach reiflicher Überlegung ... verstehe ich immer noch nicht was da passiert ist.

Beim Schneiden auf der zweiten SSD lief diese voll, so dass das Schneiden abgebrochen wurde. Dann hing der VDR mit offenem Recording Display bis ich ihn beendet habe.

(gdb) bt  
#0  0x00007f16a78d3463 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f16a78cb1d1 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x0000000000540f19 in cMutex::Lock (this=0x61bde0 <RecordingsHandler+96>) at thread.c:224
#3  0x000000000054167f in cMutexLock::Lock (this=0x7ffd415bd200, Mutex=<optimized out>) at thread.c:409
#4  0x00000000005063cf in cRecordingsHandler::Finished (this=0x61bd80 <RecordingsHandler>, Error=@0x7ffd415bd320: false) at recording.c:2119
#5  0x0000000000480895 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1525

(gdb) bt
#0  0x00007f16a78d3463 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f16a78cb1d1 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x0000000000540f19 in cMutex::Lock (this=0x61bc00 <cControl::mutex>) at thread.c:224
#3  0x000000000054167f in cMutexLock::Lock (this=0x7f160247cc50, Mutex=<optimized out>) at thread.c:409
#4  0x00000000005009e7 in cControl::Shutdown () at player.c:110
#5  0x000000000049944d in cCutter::Active (this=0x7f1654005110) at cutter.c:714
                             calls Stop();
#6  0x000000000050bf8d in cRecordingsHandlerEntry::Active (this=this@entry=0x11858c0, Recordings=Recordings@entry=0x61bf80 <cRecordings::recordings>) at recording.c:1938
#7  0x000000000050c2dc in cRecordingsHandler::Action (this=0x61bd80 <RecordingsHandler>) at recording.c:2035
                            LOCK_RECORDINGS_WRITE in recording.c:2035
#8  0x0000000000541395 in cThread::StartThread (Thread=0x61bd80 <RecordingsHandler>) at thread.c:293
#9  0x00007f16a78c86ea in start_thread () from /lib64/libpthread.so.0
#10 0x00007f16a6139a6f in clone () from /lib64/libc.so.6

Ich sehe aber in den beiden Backtraces keine zweite Mutex, die zu einem Deadlock führen könnte.

Kann es sein, dass der Compiler da die Mutexe verwechselt weil sowohl das statische cMutex cControl::mutex in cControl::Shutdown() als auch private cMutex mutex in cRecordingsHandler::Finished() nur als &mutex angesprochen werden?

kls : Kannst Du Dir das bitte mal ansehen?

Ich sag's nur ungern, aber ich habe wieder einen Deadlock, diesmal in RecordingsHandler::Finished()

Details später ...

Quote from 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

Quote from 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.

Quote

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

Quote from The Master

Ich fange mit "mc_to_pro" nicht wirklich was an.

Es hieß doch in der Ankündigung:

Quote

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?

Quote from 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.

Quote from The Master

Also eintragen kann man es in der GUI nicht.

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

Quote from 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)