extrecmenu Verhalten nach changeset vom 3.5.2013

Quote from helau

- Bei jedem weiteren Aufruf des Aufnahmemenus landet er in dem Verzeichnis, in welchem er beim letzten Verlassen des Aufnahmemenues war.

Das wäre meines Erachtens die schlechteste aller möglichen Lösungen ;-).

Klaus

Quote from helau

Stelle Dir einfach mal den anderen Fall vor:
Du hast eine Sendung zuende gesehen, gehst dann ins Aufnahmemenu und landest im Verzeichnis dieser Aufnahme(es koennte ja auch die einzige Aufnahme sein). Soweit so gut. Dann schaue ich nach was ich sonst so an Aufnahmen habe, gehe in andere Verzeichnisse und wieder raus aus dem menu.
Irgendwann will ich dann eine andere Aufnahme sehen, gehe ins Menu und wo lande ich ? Im Menu der Aufnahme die ich schon laengst gesehen habe und wo es nicht mal weitere Filme gibt.
Erklaere das mal Deiner Frau

Das kommt bei mir öfters vor. Wenn ich ein Film für später aussuche, starte ich den Film kurz und beende ihn wieder. Wenn nun alle zum Film sitzen kann man sofort die markierte Aufnahme starten, ohne sie in der Verzeichnisflut wieder zu suchen.

Also ich bin für "Springe zur letzten Aufnahme". (bzw. als Option)

Gruß
Steevee

Quote from Steevee

Wenn nun alle zum Film sitzen kann man sofort die markierte Aufnahme starten, ohne sie in der Verzeichnisflut wieder zu suchen.

Warum dann nicht einfach Play drücken? Der VDR merkt sich ja mittlerweile die zuletzt abgespielte Aufnahme sogar über den Shutdown hinweg...

Quote from kls

Das wäre meines Erachtens die schlechteste aller möglichen Lösungen ;-).
Klaus

Warum ? Wenn ich meinen Editor oeffne moechte ich auch die Dateien offen haben, welche ich beim letzten Verlassen offen hatte, und nicht irgendeine Datei die ich irgendwann mal abgespeichert hatte ...
Und es macht meines Erachtens ueberhaupt keinen Sinn, in einem Verzeichnis zu landen, wo bereits alle Aufnahmen angeschaut wurden.
Aber so wie es im VDR derzeit ist, passts fuer Recht

Quote from helau

Wenn ich meinen Editor oeffne moechte ich auch die Dateien offen haben, welche ich beim letzten Verlassen offen hatte

Ich will eigentlich immer mit einem leeren Editor starten, aber das hat nichts mit meinem vdr-Verhalten zu tun.

Mit "Back" zurück zur aktuellen Aufnahme finde ich ok, muss ich mir nur merken.
Wenn ich über das Menü in die Aufnahmen gehe, erwarte ich auch, dass ich "ganz vorne" bin.

Was die Vorbereitungen für den Fernsehabend betrifft, da wünsche ich mir eine playlist-Möglichkeit (Serien der Woche für den Sonntag Abend fertig machen). Hab aber noch nicht gesucht, ob's da schon ein Plugin o.ä. gibt. War bisher nicht so wichtig...

Lars.

Hi,

Quote from Ramirez

Nach dem Update ist da nun folgender Code:

Code

if(mysetup.GoLastReplayed && mysetup.ReturnToRec && myReplayControl::LastReplayed())
	Open();
  mysetup.ReturnToRec = false;

Damit ist eigentlich auch klar, dass man GoLastReplayed of true setzen kann, so viel man will. Nach dem ersten Aufruf ist ReturnToRec false und die Zeile mit dem Open wird nie aufgerufen.

Ich habe mal testweise dort den alten Code eingebaut und siehe da, alles funktioniert wieder. Was für Auswirkungen an anderen Stellen dadurch sind, kann ich natürlich nicht sagen. Ich weiß ja nicht, warum diese Änderung überhaupt reinkam.
Ich kann nur sagen, dass danach dieses, für mich wichtige, Feature wieder geht.

Sorry, da hatte ich einen kleinen Vertipper. Im aktuellen GIT ist das nun behoben.

@all
Ich würde gerne demnächst eine neue Version veröffentlichen.
Es geistert aber noch ein "Absturz beim Verschieben mit dem Skin nOpacity" herum. Leider habe ich bis jetzt noch keinen Backtrace bekommen.
Wenn das also noch immer der Fall ist, dann mir bitte *jetzt* einen Backtrace schicken, dann versuche ich das noch in die nächste Version einzubauen.

Gruß
Andreas

Werd ich mal machen heute abend. Bei mir geht weder verschieben, noch umbenennen im Moment. Also es funktioniert schon, nur schmiert der VDR ab.

Oje, ich hatte es befürchtet und daher schon extra von meinem Use Case gesprochen. Wollte keine Grundsatzdiskussion lostreten. Jeder hat halt andere Gewohnheiten.

Den Vorschlag das Verhalten nicht mehr deterministisch, sondern von der Anzahl der Aufrufe abhängig zu machen, finde ich allerdings wirklich nicht gut. Das versteht dann wohl keiner mehr.

Mir gefällt es so wie in extrecmenu und damit ein Danke an amair.

Ich finde das übrigens konsistent, weil im VDR man auch beim Kanalmenü nicht oben sondern beim gerade aktuellen Kanal anfängt. Damit sollte das Aufnahmemenü bei der gerade aktuellen Aufnahme anfangen. Just meine Meinung

Quote from Ramirez

Ich finde das übrigens konsistent, weil im VDR man auch beim Kanalmenü nicht oben sondern beim gerade aktuellen Kanal anfängt. Damit sollte das Aufnahmemenü bei der gerade aktuellen Aufnahme anfangen. Just meine Meinung

Da kann man doch prima diskutieren
Beim Kanalmenu kommst Du auf den aktuellen Kanal - prima.
Wenn Du eine Aufnahme anschaust und dabei ins Aufnahmemenu gehst dann waere das Verzeichnis der gerade angesehenen Aufnahme auch ok.
Aber was ist wenn Du gerade live TV schaust und ins Aufnahmemenu gehst. Ist dann die aktuelle Aufnahme die zuletzt angesehene, oder die zuletzt aufgenommene, oder die naechste nach der zuletzt fertig angesehenen oder ist es das Verzeichnis welches Du zuletzt im Menu angesehen hast ? Daher ists schon gut wenn man im Zweifelsfall im Root-Video verzeichnis landet, so wie das VDR jetzt macht

Hier mal ein Backtrace beim Umbenennen oder Verschieben einer Aufnahme:

warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/bin/vdr -u root -g /tmp -c /etc/vdr -v /video0 -E /var/cache/vdr/epg'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f9298ac0e21 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007f9298ac0e21 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f9299323450 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00007f928d01c3b5 in cNopacityRecordingMenuItem::CreateText (this=0xf8d3400) at menuitem.c:1124
#3  0x00007f928cfdf0df in cNopacityDisplayMenu::SetItemRecording (this=0xe4dc830, Recording=0x7f927c18bc60, Index=6, Current=true, Selectable=<optimized out>, Level=<optimized out>, Total=0, New=0) at displaymenu.c:513
#4  0x00007f9285efc87f in myMenuRecordingsItem::SetMenuItem (this=0xf573d10, displaymenu=0xe4dc830, index=6, current=true, selectable=true) at mymenurecordings.c:497
#5  0x00000000004ce349 in Display (this=0xf9a0fe0) at osdbase.c:256
#6  cOsdMenu::Display (this=0xf9a0fe0) at osdbase.c:217
#7  0x00000000004cee20 in cOsdMenu::CloseSubMenu (this=0xf9a0fe0, ReDisplay=true) at osdbase.c:513
#8  0x00007f9285f04add in myMenuRecordings::ProcessKey (this=0xf9a0fe0, Key=kOk) at mymenurecordings.c:1368
#9  0x00000000004cee67 in cOsdMenu::ProcessKey (this=0xf980e40, Key=kOk) at osdbase.c:521
#10 0x00007f9285f04add in myMenuRecordings::ProcessKey (this=0xf980e40, Key=kOk) at mymenurecordings.c:1368
#11 0x00000000004cee67 in cOsdMenu::ProcessKey (this=0x63f1080, Key=kOk) at osdbase.c:521
#12 0x00000000004c3694 in cMenuMain::ProcessKey (this=0x63f1080, Key=kOk) at menu.c:3919
#13 0x0000000000477602 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1217

Weiss jetzt nicht, ob das Problem in extrecmenu zu suchen ist oder in skinnopacity.

Wie lautet der Pfad der Aufnahme und wie soll sie umbenannt werden?
Sind da "komische" Zeichen bei?

Lars.

/video0/Musik/Lemmy/2011-09-27.22.12.25-0.rec/

Nix besonderes und das passiert bei allen Aufnahmen.

Ich vermute mal, der Pointer auf das Recording-Objekt ist an der Stelle nicht mehr gültig.
Vermutlich wäre es besser, sich im Konstruktor von cNopacityRecordingMenuItem eine Kopie des Objekts anzulegen.

Leider hat cRecording mit Absicht keinen Copy-Konstruktor, deshalb würde ich an der Stelle wohl einfach ein neues cRecording-Objekt mit dem FileName des übergebenen erstellen.

Lars.

Damit bekomm ich das:

warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/bin/vdr -u root -g /tmp -c /etc/vdr -v /video0 -E /var/cache/vdr/epg'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fa36e7e0e21 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007fa36e7e0e21 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fa36e7e0b36 in strdup () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00000000004e05ef in cRecording::cRecording (this=0x7fa3354bd490, FileName=0x6c726165502f7365 <Address 0x6c726165502f7365 out of bounds>) at recording.c:811
#3  0x00007fa362d38b82 in cNopacityRecordingMenuItem::cNopacityRecordingMenuItem (this=0x7fa3354bd2f0, osd=<optimized out>, imgCache=<optimized out>, Recording=<optimized out>, sel=<optimized out>, isFolder=false, Level=0, Total=0,
    New=0, vidWin=0x7fa351c03d88) at menuitem.c:1097
#4  0x00007fa362cff12c in cNopacityDisplayMenu::SetItemRecording (this=0x7fa351c03c20, Recording=0x716cf30, Index=9, Current=true, Selectable=true, Level=0, Total=0, New=0) at displaymenu.c:502
#5  0x00007fa35bc1c87f in myMenuRecordingsItem::SetMenuItem (this=0x7fa33593b0c0, displaymenu=0x7fa351c03c20, index=9, current=true, selectable=true) at mymenurecordings.c:497
#6  0x00000000004ce349 in Display (this=0x7fa335903830) at osdbase.c:256
#7  cOsdMenu::Display (this=0x7fa335903830) at osdbase.c:217
#8  0x00000000004cee20 in cOsdMenu::CloseSubMenu (this=0x7fa335903830, ReDisplay=true) at osdbase.c:513
#9  0x00007fa35bc24add in myMenuRecordings::ProcessKey (this=0x7fa335903830, Key=kOk) at mymenurecordings.c:1368
#10 0x00000000004cee67 in cOsdMenu::ProcessKey (this=0x7fa351c03ef0, Key=kOk) at osdbase.c:521
#11 0x00000000004c3694 in cMenuMain::ProcessKey (this=0x7fa351c03ef0, Key=kOk) at menu.c:3919
#12 0x0000000000477602 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1217

Verweist das Recording-Objekt eventuell noch auf das alte vor dem Umbenennen/Verschieben?

Aha, interessant - das Recording-Objekt scheint einen Dateinamen im Nirwana zu haben...
Kannst du den coredump in gdb laden und in den Frame #3 springen, um dort ein paar Werte von Recording auszugeben?

Lars.

Wenn Du mir sagt, wie ich das mache?

Eventuell hängt das Problem auch mit dem Update auf 2.1.2 zusammen? Da hatte sich ja einiges geändert mit den Aufnahmen.

Die 2.1er-Reihe kenne ich noch nicht, aber so schlimm sollten die Änderungen hoffentlich nicht sein.

$ gdb /usr/bin/vdr --core="/pfad/zum/coredump"
(gdb) frame 3
(gdb) print Recording->fileName

Wobei das nicht funktionieren muss, ich weiß nicht, inwieweit gdb Zugriff auf private Member hat.
Und dann noch mal in Frame 4 gucken, da scheint der Pointer auf Recording noch in Ordnung zu sein.

Lars.

Scheint schon vorher kaputt. Nehme eben an, wegen umbenennen/verschieben, da sich er Pfad geändert hat?

(gdb) frame 3
#3  0x00007fa362d38b82 in cNopacityRecordingMenuItem::cNopacityRecordingMenuItem (this=0x7fa3354bd2f0, osd=<optimized out>, imgCache=<optimized out>, Recording=<optimized out>, sel=<optimized out>, isFolder=false, Level=0, Total=0,
    New=0, vidWin=0x7fa351c03d88) at menuitem.c:1097
1097        this->Recording = new cRecording(Recording->FileName());
(gdb) print Recording->fileName
value has been optimized out
(gdb) frame 4
#4  0x00007fa362cff12c in cNopacityDisplayMenu::SetItemRecording (this=0x7fa351c03c20, Recording=0x716cf30, Index=9, Current=true, Selectable=true, Level=0, Total=0, New=0) at displaymenu.c:502
502             cNopacityMenuItem *item = new cNopacityRecordingMenuItem(osd, imgCache, Recording, Selectable, isFolder, Level, Total, New, &videoWindowRect);
(gdb) print Recording->fileName
$1 = 0x6c726165502f7365 <Address 0x6c726165502f7365 out of bounds>
(gdb) frame 5
#5  0x00007fa35bc1c87f in myMenuRecordingsItem::SetMenuItem (this=0x7fa33593b0c0, displaymenu=0x7fa351c03c20, index=9, current=true, selectable=true) at mymenurecordings.c:497
497       if (!(mysetup.SetRecordingCat && displaymenu->SetItemRecording(recording,index,current,selectable,level,totalentries,newentries)))
(gdb) print recording->fileName
$2 = 0x6c726165502f7365 <Address 0x6c726165502f7365 out of bounds>
(gdb)

Sollte extrecmenu nicht ab 2.1.2 die VDR internen Verschieben/Umbenennen-Funktionen nutzen? Eventuel müsste da amair nochmal Hand anlegen.

Ja, da scheint noch was im Argen zu sein, da fällt mir jetzt auch nicht so schnell eine Lösung ein.
Vielleicht ist das Recording-Objekt schon in extrecmenu "kaputt", dann muss da evtl. mit einer Kopie gearbeitet werden.
Da hab ich jetzt aber keinen Überblick.

Lars.

Na ok, danke erstmal. Vielleicht findet ja amair was.