Posts by kamel5

  • TVGuide und VDR-2.4.0+

    Neue Version 1.3.12 im git:

    - Fix Update SearchResults after deleting a recording in cRecMenuRecordingSearchResults
    - Check if event->EndTime() is greater than nextEvent->StartTime() (overlap)
    - Change NULL to nullptr
    - Minimum number of search letters in cRecMenuRecordingSearch() changed from 4 to 3
    - Delete obsolete function cTvGuideOsd::DetailedEPG()
    - Comment unused variable timerIsActive
    - Elimitate deprecated function Recordings->DelByName()
    - Add "tvguide: " to some logs

    Grüße
    kamel5

  • ExtrecmenuNG zeigt die Aufnahmelänge in Sekunden an!?

    Quote from kls

    Das heißt, der Client "sieht" gar nicht das Video-Verzeichnis des Servers?

    Das wäre zwar ein Grund, so klang es aber eigentlich nicht, den er bekommt die Aufzeichnung ja angezeigt, nur mit dem falsche Wert.

    Vielleicht liegt es aber auch daran, wie er den Server am Client eingebunden hat, möglicherweise wird da die index-Datei nicht zeitnah aktualisiert.

    Quote from kls

    Vielleicht liefert die markierte Zeile einzufügen brauchbare Infos.

    Das müsste dann wayne mal probieren, oder jemand, der so eine Konfiguration in Betrieb hat.

    Für extrecmenung sehe ich das Problem erst einmal als erledigt an.

    Grüße
    kamel5

  • ExtrecmenuNG zeigt die Aufnahmelänge in Sekunden an!?

    Quote from kls

    Recording->LengthInSeconds() ruft cRecording::NumFrames() auf, was wiederum cIndexFile::GetLength() aufruft.

    Man sieht ja hier, das NumFrames() scheinbar auch "-1" sein kann:

    int cRecording::LengthInSeconds(void) const
    {
    int nf = NumFrames();
    if (nf >= 0)
    return int(nf / FramesPerSecond());
    return -1;
    }
    was dann zu der bisher falschen Anzeige in extrecmenu geführt hat.

    In cIndexFile::GetLength() wird ja geprüft, ob es ein index-File gibt, wenn nicht, wird da auch eine "-1" zurückgegeben. Ich weiß jetzt nicht wie das in einer Client/Server-Konfiguration funktioniert, da gibt es ja das index-File nur auf dem Server.

    Grüße
    kamel5

  • ExtrecmenuNG zeigt die Aufnahmelänge in Sekunden an!?

    Quote from kls

    Die Frage ist dann wohl, warum das keine gültigen Daten liefert, denn ansonsten hätte ja Recording->LengthInSeconds() schon einen richtigen Wert geliefert.

    Recording->LengthInSeconds() kann scheinbar auch negativ sein. In cRecording::Title() wird dann "int Minutes = max(0, (LengthInSeconds() + 30) / 60);" zur Anzeige benutzt, das dann zu der "0" führt. In extrecmenu war das bisher nicht so, deshalb der andere Wert. Ich habe es jetzt genau so wie in cRecording::Title() geändert, dadurch wird jetzt auch eine "0" angezeigt. Die Frage ist nun, wo dieser Wert <"0" herkommt.

    Ich kann das hier leider nicht nachstellen, da ich so eine Konfiguration nicht habe.

    Grüße
    kamel5

  • ExtrecmenuNG zeigt die Aufnahmelänge in Sekunden an!?

    Quote from SHofmann

    und dazu (noch) keine Funktionen des Menüs vom Core-VDR benutzt. ;)

    So einfach ist das nicht:). Es werden zur Bestimmung der Länge schon Funktionen des Core-VDR benutzt. Ich habe gerade mal geschaut, der Core-VDR benutzt dazu nur "Recording->LengthInSeconds()", das wird dann zur "0", wenn ein negatives Ergebnis liefert wird. Extrecmenu versucht dam noch anders an die Länge über die index-Datei und "FramesPerSecond()" zu kommen, was in dem Fall keine gültigen Daten liefert und zu der komischen Anzeige führt. Ich könnte dann z.B. auch einfach eine "0" anzeigen lassen, dann passt es zumindest zum Core-VDR.

    Grüße
    kamel5

  • VDR version 2.7.9 freigegeben

    Ich habe beim Versuch, eine Aufzeichnung zu löschen, die gerade geschnitten wird, im Log folgenden "invalid lock sequence report" bemerkt:

    Feb 12 12:55:58 vdr[26434]: [26434] confirm: Aufzeichnung löschen? 
    Feb 12 12:55:58 vdr[26434]: [26434] warning: Aufzeichnung löschen? 
    Feb 12 12:55:59 vdr[26434]: [26434] confirmed 
    Feb 12 12:55:59 vdr[26434]: [26434] confirm: Aufzeichnung wird bearbeitet - trotzdem löschen? 
    Feb 12 12:55:59 vdr[26434]: [26434] warning: Aufzeichnung wird bearbeitet - trotzdem löschen? 
    Feb 12 12:55:59 vdr[26434]: [26434] --- begin invalid lock sequence report 
    Feb 12 12:55:59 vdr[26434]: [26434] TID    T  C  R  DR S                 ST 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  U  -  -  -  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  U  -  -  -  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  W  -  -  -  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  *  -  -  W  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  *  -  -  U  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  U  -  -  -  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  W  -  -  -  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  *  -  -  W  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  *  -  -  U  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  U  -  -  -  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  W  -  -  -  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  *  -  -  W  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  *  -  -  U  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  U  -  -  -  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  W  -  -  -  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  *  -  -  W  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  *  -  -  U  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26438  -  U  -  -  -  -  -  -  -  -  U 
    Feb 12 12:55:59 vdr[26434]: [26434] 26434  -  -  R  -  -  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26434  R  -  *  -  -  -  -  -  -  -  L 
    Feb 12 12:55:59 vdr[26434]: [26434] 26434 invalid lock sequence: 1 Timers 
    Feb 12 12:55:59 vdr[26434]: [26434] full backtrace: 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cStateLock::Lock(cStateKey&, bool, int) at thread.c:737 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cListBase::Lock(cStateKey&, bool, int) const at tools.c:2188 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cTimers::GetTimersRead(cStateKey&, int) at timers.c:1297 (discriminator 1) 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cTimers_Lock::cTimers_Lock(bool) at timers.h:269 (discriminator 10) 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cSkinLCARSDisplayMenu::Flush() at skinlcars.c:1767 (discriminator 2) 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cSkins::Message(eMessageType, char const*, int) at skins.c:308 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cInterface::Confirm(char const*, int, bool) at interface.c:62 (discriminato
    r 1) 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cMenuRecordings::Delete() at menu.c:3375 (discriminator 4) 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cMenuRecordings::ProcessKey(eKeys) at menu.c:3546 (discriminator 6) 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cOsdMenu::ProcessKey(eKeys) at osdbase.c:572 (discriminator 1) 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr cMenuMain::ProcessKey(eKeys) at menu.c:4809 (discriminator 1) 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr main at vdr.c:1421 (discriminator 2) 
    Feb 12 12:55:59 vdr[26434]: [26434] /lib64/libc.so.6 at ??:? 
    Feb 12 12:55:59 vdr[26434]: [26434] /lib64/libc.so.6 __libc_start_main calling __libc_start_main_alias_2 at :? 
    Feb 12 12:55:59 vdr[26434]: [26434] /usr/local/bin1/vdr _start at ??:? 
    Feb 12 12:55:59 vdr[26434]: [26434] --- end invalid lock sequence report

    Der tritt auf, wenn man in der Flush()-Funktion von einem Skin, hier beispielhaft in "cSkinLCARSDisplayMenu::Flush()" ein "LOCK_TIMERS_READ" einbaut. Ich hatte das bisher so verstanden, das keine LOCK's vom Core-VDR gehalten werden, wenn die Funktion "Flush()" aufgerufen wird.

    Anbei der aktuell von mir genutzte Patch, der das verhindert.

    kls , vielleicht magst Du Dir das mal ansehen.

    Grüße
    kamel5

  • ExtRecMenu und VDR-2.4.0+

    Hallo,

    es gibt eine neue Version 2.0.15:

    - Adaptation to VDR 2.7.8 (Undelete)
    - Add ALTERNATE_CUT_MARK
    - Removed play/rewind keys for deleted recordings
    - Retention time of deleted recordings shown in recording-info title
    - Update the information when the recording is updated
    - Extended recording info and revised order of displayed items
    - Update Setup-Menü
    - Some refactorings
    - Update Language files
    - Update Makefile
    - Add .gitignore
    - Update "class cPluginExtrecmenung"
    - Delete obsolete function "myMenuRecordings::SetPath()"
    - Update function "myMenuRecordings::Set"

    Vielen Dank an SHofmann für das Bereitstellen der meisten Änderungen und das anschließende Testen.

    Grüße
    kamel5

  • VDR >= 2.7.8 und Undelete

    Quote from kls

    Für mich klingt das fast so, als würde das ständig passieren.

    Ja, das passiert schon häufiger. Auch oft wenn ich was teste, oder eine Aufzeichnung über das Netzwerk in den falschen Ordner verschoben habe. Dann ist es einfacher, diese verschobene zu löschen, die alte wiederherzustellen und erneut an die richtige Stelle zu verschieben.

    Außerdem habe ich mich daran gewöhnt:).

    Und ja, es gibt sicher viele Möglichkeiten, wie man das anstellen könnte. Das mit "keymacros.conf" hat zum Beispiel das Problem, das ich keine Taste auf der Fernbedienung mehr frei habe, die ich dafür benutzen könnte.

    Insgesamt habe ich viel im Aufzeichnungsmenü gepacht, z.B. die gesamte Bedienung umgestellt wie im extrecmenu-Plugin (die Diskussion dazu gab es ja früher mal) , da kommt es darauf jetzt auch nicht mehr an.;)

    Grüße
    kamel5

  • VDR >= 2.7.8 und Undelete

    Hallo,

    die Diskussion im anderen Thread hat doch eine menge unterschiedlicher Meinungen zur Position des Knopfes "Gelöschte Aufz." offenbart.;)
    Für meine Situation nützlich (zum Teil bis zu 5 Unterverzeichnisse) finde ich keine andere Position, als die im Aufzeichnungsmenü selbst. Jedesmal zurück aus dem x. Unterverzeichnis ins Hauptmenü oder auch Einstellungsmenü wäre doch sehr lästig.
    Ich habe deshalb den bisherigen Undelete-Patch, der ja jetzt funktional im Core-VDR gelandet ist, soweit vereinfacht, das nur noch das Bedienverhalten entsprechend dem ursprünglichen Patch angepasst wird.
    Zusätzlich gibt es jetzt im Menü Einstellungen->OSD ganz unten im Bereich "gelöschte Aufzeichnungen" die Möglichkeit, die Position für "gelöschte Aufz." anzupassen. Es stehen hier als Default wie bisher das Aufzeichnungsmenü mit dem bekannten Verhalten, sowie zusätzlich das Einstellungsmenü (wie beim Core-VDR) und das Hauptmenü (wie von FireFly vorgeschlagen), zur Verfügung. Damit kann es sich jeder so einstellen, wie gewünscht.
    Den Vorschlag, die "Befehle" auf die gelbe Taste zu legen, habe ich erst einmal nicht übernommen, das hat ja grundsätzlich nichts mit "Undelete" zu tun. Bei Bedarf, kann ich das aber noch übernehmen.

    Grüße
    kamel5

  • VDR version 2.7.8 freigegeben

    Quote from clausmuus

    Ich fände es viel besser wenn die wiederherstellen Funktion im "Aufnahmen" Menü untergebracht würde

    Ja, dieser Teil von meinem Patch ist leider nicht mit übernommen worden. Ich bin gerade dabei einen entsprechenden Patch, der die Bedienung, wie im Undelete-Patch, wiederherstellt, vorzubereiten. Bei mir funktioniert das schon soweit.:) Mein Ziel ist, diesen Patch bis ca. nächste Woche zu veröffentlichen.

    Grüße
    kamel5