Posts by berndm

    Hmm, es wurde jedenfalls keine Wiedergabe gestartet (es war niemand zu Hause). Kann es sein, dass das Plugin oder vdr eine laufende Aufnahme auch als Wiedergabe interpretiert?
    Hier mal der entsprechende syslog-Auszug:

    Hallo zusammen,
    das Plugin läuft bei mir sehr gut. Schön, dass jetzt auch die Anrufliste aktuell ist :)
    Eine Sache ist mir aber noch aufgefallen: Seit kurzem habe ich ab und zu Sofortaufnahmen in der Aufnahmeliste, die ich mir nicht erklären konnte. Ich hab's zunächst meiner besseren Hälfte in die Schuhe geschoben :)
    Jetzt habe ich aber festgstellt, dass das Fritzbox-Plugin "Schuld" ist. Wenn nämlich eine Aufnahme läuft und ein Anruf kommt, drückt das Plugin auf die virtuelle Pause-Taste, woduch (zusätzlich zur aktuellen Aufnahme) noch eine Live-Aufnahme gestartet wird. Ist das jetzt ein Bug oder ein Feature? Ich dachte, pausiert wird nur bei einer laufenden Wiedergabe?
    Oder ist das mit "Fehler bei pausierter Aufnahme u. Pause bei Anruf beheben" von der ToDo-Liste auf der Homepage gemeint?
    Danke und Gruß
    Bernd

    Hallihallo,

    Quote

    Original von jowi24


    War hier auch nur eine Testmessung. Keine Ahnung wie das genau im Hintergrund abläuft. Es scheint aber so zu sein, dass ein manueller Abruf der Liste über das Webfrontend ein Update auslöst.


    Wenn also jemand eine Lösung dafür hat, bzw. den Unterschied zwischen dem Abruf via Plugin und dem Abruf als Mensch sieht... her mit dem Patch ;-)


    Ich habe mir mal den "FRITZ!Box Monitor" von AVM installiert. Der kann z.B. auch die Anrufliste der FRITZ!Box auslesen. Ein Lauschangriff zeigt, dass das Tool zum Aktualisieren der Anrufliste tatsächlich zwei Anfragen sendet, nämlich zunächst

    Code
    1. GET /cgi-bin/webcm?getpage=../html/de/menus/menu2.html&var:lang=de&var:pagename=foncalls&var:menu=fon

    und anschließend

    Code
    1. GET /cgi-bin/webcm?getpage=../html/de/FRITZ!Box_Anrufliste.csv


    Die erste Anfrage dient wohl tatsächlich nur der Aktualisierung der csv-datei auf der FRITZ!Box.
    Vielleicht kannst du das ja ähnlich realisieren ...
    Gruß
    Bernd

    Hallo faulmeier,
    Ich habe den Effekt, dass bei Benutzung des Plugins meine CPU-Last von 3% auf 35% steigt - liegt wohl an der Polling-Schleife. Kannst du da vielleicht 'ne Pause einbauen?


    Und noch was anderes: Das integrierte CDDA-Plugin ist ja ganz schön, hat aber keine CDDB-Unterstützung im Gegensatz zu dem schon länger existierenden cdda-Plugin. Gibt es einen bestimmten Grund, warum du das bereits existierende nicht nutzt? Oder andersherum: Planst du evtl. CDDB ebenfalls zu integrieren oder das cdda-Plugin mediamanager-fähig zu machen? Wäre 'ne tolle Sache ...


    Besten Dank für's Plugin!
    Gruß
    Bernd

    ciax
    Die Meldung mit dem locale hatte ich auch.
    Nach einem

    Code
    1. dpkg-reconfigure locales

    und Auswahl von "de_DE@euro ISO-8859-15", welches ich in der runvdr mit "LANG=de_DE@euro" ja auch auswähle, funtioniert es.
    Komisch, irgendwann muss das mal verloren gegangen sein. Bin mir jedenfalls sicher, dass ich das schon mal richtig konfiguriert hatte ...
    Gruß
    Bernd

    Hi,
    erstmal danke für das nützliche Plugin!
    Ich hatte bei mir das Problem, dass der vdr beim Laden des Telefonbuchs abstürzte, sobald Sonderzeichen (Umlaute etc.) im letzteren enthalten waren. Habe die Ursache aber bereits gefunden:
    In convertEntities muss es statt

    Code
    1. unsigned int pos = s.find(Entities[i][0]);

    heißen:

    Code
    1. std::string::size_type pos = s.find(Entities[i][0]);

    Sonst crasht es nämlich auf 64-Bit-Systemen.
    Wenn ich das richtig sehe, wird auch nur das erste von mehrere gleichen Sonderzeichen ersetzt, oder?
    Gruß
    Bernd

    Quote

    Original von nordlicht
    Das Schöne am RecCommands-Menü ist ja, dass man aus dem Aufzeichnungsmenü und aus meinem Plugin das Menü nicht erst aufrufen muss, um dann Befehle auszuführen. Wenn z.B. der erste Eintrag im RecCommands-Menü eine Befehl zum Starten von Noad ist, geht man auf die entsprechende Aufzeichnung und drückt '1'. Man kann natürlich auch 'Rot' + '1' drücken, ist aber nicht nötig.


    Achso, das wusste ich nicht. Das ist natürlcih praktisch.
    Dennoch fände ich es schön, wenn "Löschen" wieder direkt auf Gelb käme (bevor es nackig bleibt).
    Gruß
    Bernd

    Quote

    Original von nordlicht
    Aber dadurch, dass die Zifferntasten die Befehle auch aufrufen können, würde sich die Bedienung zu jetzt auch vereinfachen.


    Hmmm, zum Löschen muss ich doch im Moment folgendes drücken:
    Gelb + Gelb + OK
    Nach deiner Änderung:
    Rot + 3 + OK
    Sieht für mich eher komplizierter aus. Aber ich will ja nicht meckern ;)
    Was soll denn stattdessen auf Gelb?
    Gruß
    Bernd

    Hallo Nordlicht,
    wenn ich das richtig verstehe, wird die gelbe Taste dann ja wieder frei und kann wie im Orginal-VDR mit "Löschen" belegt werden, oder? D.h. "Löschen" müsste gar nicht mehr ins Kontextmenü. Das fände ich gut, da das Löschen die von mir am häufigsten verwendete Funktion aus dem Kontextmenü ist.
    Ansonsten: weiter so :].
    Bernd

    Quote

    Original von wolfgang61
    ich habe vorläufig kaum Zeit dafür, leider. Ich glaube, Lars geht es ähnlich.


    Klar, kenne ich, sollte ja auch kein Vorwurf sein :)


    Quote

    - machst Du noch eine deutsche Übersetzung des neuen Strings? ("Jump interval (FF/FREW)")


    Stimmt, hatte ich ganz vergessen. Kann ich heute Abend noch nachschieben.


    Quote

    - wieviel RAM braucht das zusätzlich? 5000*100000 Bytes? Evtl sollte das per Make.config vordefinierbar sein und dann ein Default, der auch auf Rechnern mit wenig RAM geht:


    Ne ne, es werden maximal 100.000 "FrameInfos" (á 16 Byte) in 5000er-Blöchen reserviert, d.h. maximal 1,6MB, falls ein MP3 wirklich mal 100.000 Frames hat.
    Alternativ hätte ich auch das "Vor-Scannen" der MP3s vom MP3-Plugin übernehmen können, um die maximale Frame-Anzahl zu bestimmen, aber das war mir zu aufwändig :)


    Quote

    #ifndef FRAME_INFO_VECTOR_MAX_SIZE
    #define FRAME_INFO_VECTOR_MAX_SIZE blabla
    #endif


    Kann ich noch einbauen.


    Quote

    - Du schreibst "bei MP3" - im Patch sehe ich diese Einschränkung nicht. Was ist mit WAV, FLAC?


    OK, die Änderung betrifft alles was mit mgMP3Decoder bzw. libmad decodiert wird, hab's aber nur mit MP3s getestet. mgOggDecoder und mgSndfileDecoder habe ich nicht geändert - ich glaube, da funktioniert es schon, oder?


    Quote

    - ich weiss jetzt nicht so genau, wie das in anderen Plugins aussieht,
    und man will ja konform sein, aber könnte man evtl mit kFastFwd weiter springen als mit kRight?


    Ich hab's wie beim MP3-Plugin gemacht. (Oder war's MP3-ng?)


    Gruß
    Bernd

    Hallo Lars und Freundeskreis der Muggle-Nutzer!
    Hier tut sich ja nicht mehr so richtig viel, oder habe ich eine neue Muggle-Version verpasst? Jedenfalls habe ich mich mal drangesetzt und einen Patch für das (Zurück-)Spulen bei MP3s geschrieben. Damit können dann auch die FastForward/FastReverse-Tasten der Fernbedienung zum Spulen verwendet werden. Das "Sprungintervall" ist außerdem im Setup-Menü einstellbar.
    Gruß
    Bernd


    EDIT: Neuer Patch weiter unten ...

    Quote

    Original von Urig
    Irgendwelche Gegenvorschläge, woran man die unterschiedlichen Makefile-Situationen festmachen könnte?


    Im Moment tendiere ich eher dazu, das wir ein rechtzeitig definiertes PLUGIN= im Makefile vorschreiben, um das zu umgehen.


    Hallo Udo,
    ich habe schon wieder vergessen, was diese -fPIC-Option genau macht, aber was wäre denn schlimm daran, wenn der vdr selbst auch mit -fPIC kompiliert wird, also so wie früher? Macht sich das in der Performance bemerkbar?


    Könnte man alternativ die CXXFLAGS nicht direkt im Makefile beim Ziel "plugins" manipulieren? D.h., es wird beispielsweise eine Variable "CXXFLAGSPLUGIN" in Make.config hinzugefügt, und beim Ziel "plugins" so etwas wie CXXFLAGS=$(CXXFLAGSPLUGIN). Evtl. muss CXXFLAGS anschließend wieder zurückgesetzt werden.
    Ich habe aber nicht wirklich Ahnung von Makefiles.


    Gruß
    Bernd

    Quote

    - Added "-fPIC" to the compiler options in Make.config.template when compiling
    plugins (thanks to Udo Richter). If you use your own Make.config file, you may
    want to add these lines there, too.


    Das funktioniert noch nicht so optimal. Das servicedemo-Plugin beispielsweise, welches ja beim vdr dabei ist, bekommt die -fPIC-Option nicht mit, da es kein "PLUGIN=xxx" definiert und folglich das Kompilieren fehlschlägt (zumindest mit amd64). Da es nicht wirklich installiert wird, ist das zwar nicht weiter schlimm, stört aber doch.
    Beim image-Plugin wird "PLUGIN=image" übrigens zu spät definiert und in den Unterverzeichnissen gar nicht. Beim games-Plugin ebenfalls.
    Gruß
    Bernd

    Olé, olé!


    nordlicht
    Ich habe mich jetzt mal ein paar Stunden mit dem gdb rumgeschlagen, bevor ich gemerkt habe, dass es auch den etwas komfortableren cgdb gibt. Aber so richtig schön ist das trotzdem nicht, wenn man kein X installiert hat.
    Aber wenigstens habe ich den Fehler beim Umbennen gefunden :]
    Die Funktion ExchangeChars macht evtl. (und nur bei VFAT=1) ein realloc auf den übergebenen String, d.h. der ürsprüngliche Zeiger wird evtl. ungültig (siehe auch Kommentar in recordings.h). Das wird in myMenuRenameRecording::ProcessKey nicht beachtet.


    Mit dem angehängten Patch sollte das Umbenennen funktionieren. Es gibt aber, glaube ich, noch weitere kritische Stellen, z.B. beim Verschieben.


    Gruß
    Bernd

    Hallo nordlicht,
    benutze auch seit kurzem dein Plugin - gefällt mir sehr gut :)


    Quote

    Original von nordlicht
    @foobar
    An dem Theater mit dem VFAT bleibe ich dran. Ich hoffe, das wird keine "neverending story" ?(

    Das Problem tritt bei mir auch auf, ist aber nicht zu 100% reproduzierbar. Die Aufnahmen werden bei mir auf der Platte anscheinend korrekt umbenannt, das anschließende Verhalten des vdr variiert aber, entweder
    - direkter Absturz (keine Reaktion mehr, Watchdog schlägt an)
    - der Titel der Aufnahme (im OSD) zeigt Müll an und variiert beim Scrollen
    - Titel im OSD zwar korrekt, aber seltsam eingeordnet (zwischen den Verzeichnissen)


    Da scheint's irgendwas im Speicher zu zerhauen ...


    Mal funktioniert das Umbenennen aber auch 5-mal hintereinander.
    Benutze kein NFS o.ä., alles lokal auf XFS.


    Gruß
    Bernd