Posts by Alex

    Hi Hollywood,


    wenn ich es richtig sehe, compilierst Du das Mailbox-Plugin (0.7.1?) mit gcc-6.2 gegen vdr-2.3.2, richtig?


    Aus Zeitmangel habe ich mich noch nicht mit vdr-2.3.x beschäftigt und auf meinen Gentoo-Installationen ist noch gcc-4.9 aktiv.


    Habe trotzdem mal auf die Schnelle ein Ubuntu 16.10 mit gcc-6.2 einer VM installiert, die Sourcen von VDR und dem vdr-mailbox-0.7.1 ausgepackt, den oben angesprochenen Patch eingespielt und ein paar Änderungen vorgenommen. Compilieren konnte ich das Plugin nach den Änderungen, ausführen (d.h. testen) konnte ich es in der VM allerdings nicht.


    Würdest Du bitte mal beigefügten Patch auf ein frisch ausgepacktes vdr-mailbox-0.7.1 anwenden und testen? Der obige Patch ist in meiner Datei auch enthalten, sollte/muss also nicht auch noch angewandt werden.


    HTH, Alex

    Guten Morgen,


    könnte die Meldung, die magicamun (und ich auch) bekommt...


    Code
    1. Apr 23 06:35:41 tutanchamun epghttpd: SQL-Error in 'execute(stmt_execute)' - Unknown prepared statement handler (0) given to mysqld_stmt_execute (1243) 'Unknown prepared statement handler (0) given to mysqld_stmt_execute' [select action, active, autotimerid, autotimername, aux, channelid, childlock, day, directory, doneid, endtime, eventid, expression, file, id, info, lifetime, namingmode, priority, retrys, source, starttime, state, tccmailcnt, type, vdruuid, vps, weekdays from timers where state not in ('D', 'E'. '-') and eventid = ? and channelid = ?]


    ... mit folgender Meldung, die ich beim Start des epghttpd bekomme, zusammen hängen?


    Code
    1. Apr 23 08:28:20 seca epghttpd[364]: Calling mysql_init(364)
    2. Apr 23 08:28:20 seca epghttpd[364]: SQL client character now 'utf8'
    3. Apr 23 08:28:20 seca epghttpd[364]: SQL-Error in 'prepare(stmt_prepare)' - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '. '-') and eventid = ? and channelid = ?' at line 1 (1064) 'You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '. '-') and eventid = ? and channelid = ?' at line 1' [select action, active, autotimerid, autotimername, aux, channelid, childlock, day, directory, doneid, endtime, eventid, expression, file, id, info, lifetime, namingmode, priority, retrys, source, starttime, state, tccmailcnt, type, vdruuid, vps, weekdays from timers where state not in ('D', 'E'. '-') and eventid = ? and channelid = ?]
    4. Apr 23 08:28:20 seca epghttpd[364]: Calling mysql_init(364)


    Git-Stand von heute früh, make, make install, restart habe ich ausgeführt.


    bye, Alex

    So, nen neue Version ist im git:


    2016-04-14: version 1.0.13 (rechner)
    [...]
    - changed: name from searchtimer is always visible
    - added: searchtimerlist: name or expression will shown and has now icons

    Wow, das ging ja schnell, ich bin begeistert - vielen Dank, für die schnelle Umsetzung!


    Lediglich in der Timer-Liste könnte in der rechten Spalte bei durch Suchtimer erzeugten Timern auf dem Button "Suchtimer bearbeiten" auch der Name angezeigt werden (falls vorhanden), ansonsten eben der Suchausdruck wie bisher.


    Nochmals vielen Dank.
    bye, Alex

    Hallo zusammen,


    zunächst einmal möchte ich allen beteiligten Entwicklern ein großes Lob und vielen Dank aussprechen: Was Ihr da mit der Kombination epgd/epghttp/epg2vdr-plugin/scraper2vdr-plugin/etc. entwickelt ist wirklich toll!


    Epgd nutze ich schon länger, den http-Branch habe ich erst vor einigen Wochen installiert und steige nun schrittweise von epgsearch/live mit meinen Suchtimern um.


    Zwei Anregungen möchte ich hier notieren:


    Anregung 1: Ich würde mir wünschen, dass Suchtimer generell ein Feld "Name" (oder "Beschreibung") haben würden, welches für die Auswertung/Suche selbst keine Funktion besitzt, jedoch in der Tabelle mit den Suchtimern als zusätzliche Spalte (erste Spalte, noch vor dem eigentlichen Suchausdruck) angezeigt wird. In der Tabelle mit den erstellten Timern könnte die Beschriftung des Buttons ganz rechts ebenfalls diesen Namen darstellen (anstatt des Suchausdrucks).


    Ggf. könnte man das Eintragen eines Namens für einen Suchtimer für den Benutzer auch optional machen und dann in der Suchtimerübersicht und der Timerübersicht den Namen nur dann darstellen, falls dieser eingetragen wurde und ansonsten eben den Suchausdruck.


    In folgenden beiden Szenarien hielte ich diese Namen für nützlich:


    Szenario 1: Ich nehme z.B. eine Serie auf, die ich auch archivieren möchte. Nun wird die Serie auf zwei Sendern A und B ausgestrahlt, wobei A die neuen Episoden früher, aber mit Werbeunterbrechungen ausstrahlt, B strahlt die neuen Episoden später, dafür in besserer Qualität / ohne Werbeunterbrechungen aus. Also würde ich die Aufnahmen von A zeitnah ansehen, dieselben Episoden jedoch später noch einmal von B aufnehmen lassen, diese dann schneiden und archivieren.


    Also würde ich zwei Suchtimer anlegen, welche dieselben Suchausdrücke hätten, jedoch Timer1 auf Sender A und Timer2 auf Sender B eingeschränkt würden.


    In der Suchtimer-Übersicht würde ich nun zwei Einträge (Zeilen) mit denselben Suchausdrücken sehen und könnte nicht unterscheiden, welcher nun für die neuen/schlechten Aufnahmen ist und welcher für die guten, zu archivierenden Aufnamen. Daher würde ich gerne unterschiedliche Namen für die Suchtimer vergeben (e.g. "FooBar (neu)", "FooBar (gut)")


    Frage am Rande: Funktioniert das Aufnehmen derselben Episode über verschiedene Suchtimer überhaupt, wenn ich die einzelnen Suchtimer mit "Wiederholungen vermeiden" konfiguriere, d.h. wirkt das "Wiederholungen vermeiden" Suchtimer-spezifisch oder global?


    Szenario 2: Ich habe einige Suchtimer, die im Suchausdruck mit Regular-Expressions arbeiten. Da diese durchaus einige Sonderzeichen (div. Klammern, Punkt, \, etc.) enthalten (können), sind diese in der Suchtimer-Übersicht in der linken Spalte "Suchausdruck" nicht immer auf einen Blick zu entziffern. Auch hier wäre eine zusätzliche (erste) Spalte mit dem Namen/Beschreibung des Suchtimers hilfreich.


    Epgsearch/Live haben ein solches Namens/Beschreibungs-Feld leider auch nicht (oder ich habe es bisher immer übersehen), habe es aber schon immer vermisst und hielte es daher für eine sinnvolle Ergänzung von epgd/epghttpd.


    Vielleicht könnte man hierfür das neue Feld "Name" bei reinen Suchtimern für alle Timer-Typen verwenden?


    Anregung 2: "channel"-Objekt in der recording.py verfügbar machen.
    Für die Erzeugung der Aufnahme-Pfade verwende ich hauptsächlich den User-Mode, in welchem ich wiederum gerne anhand des Kanals, für den der Timer erstellt wird, die Pfade festlegen würde. Daher wäre es hilfreich, wenn in recording.py auch ein "channel"-Objekt mit ein paar Informationen über den Kanal (Kurz-/Lang-Name, Provider, etc.) verfügbar wäre. Vielleicht wäre es sogar denkbar, ein weiteres Objekt "searchtimer" zugreifbar zu machen, mit dem sich einige Informationen über den eigentlichen Suchtimer abfragen liessen?


    Liebe Entwickler, bitte seht meine Ausführungen nicht als Gemeckere, sondern lediglich um vorsichtige Anregungen zur weiteren Verbesserung an. Natürlich habe ich keinerlei Erwartungshaltung bzgl. der Umsetzung der Anregungen, wollte aber meine Vorschläge dennoch einmal äussern...


    Viele Grüße,
    Alex

    Hi Louis


    Ich bin gespannt, wie sich die Erweiterung auf den verschiedenen Systemen verhält. Insbesondere Animationen ... schon ein bisschen schicker ;) Aber auch die Ausgabe an sich ist insbesondere bei aufwändigeren Skins merkbar flüssiger.


    Jo...ich hoffe auf reges Feedback, viel Spass beim Testen!


    Ich habe dieser Tage auf meinem Schlafzimmer-VDR (reiner Streaming-Client, ASUS Eee Box PC EB1012, Atom N330, ION erste Generation, Nvidia-Treiber 340.96) Dein softhddevice-openglosd installiert und hatte ein echtes WOW-Erlebnis: Die Bedienung des OSDs und insbesondere das Scrollen durch lange Listen geht nun spürbar schneller und flüssiger. Zuvor dauerte es ziemlich lange und flackerte zwischendurch immer mal wieder, wenn ich durch eine längere (ca. 300) Liste von Aufnamen seitenweise (Taste 'rechts') ans Ende gesprungen bin - jetzt flackert es nicht mehr und scrollt/springt sehr schnell :-)


    Installiert ist hier die aktuellste skindesigner-Version mit blackhole-Skin.


    Auch der Wohnzimmer-VDR (ebenfalls reiner Streaming-Client, Asus P8H77-M, Intel i3-2120T, Asus GT610-SL-2GD3-L, Nvidia-Treiber 358.16) profitiert deutlich spürbar vom beschleunigten OSD - hier mit Shady-Skin.


    Vielen Dank also, für die tolle Entwicklung (von openglosd, skindesigner, blackhole) und und vielen Dank auch an Tomas für die Shady-Skins.
    Alex

    Hi Tomas, Louis und Hollywood,


    entschuldigt bitte, die Verwirrung bzgl. der Mailbox-Plugin-Versionen 0.7.0 / 0.7.1: Offensichtlich hatte ich damals versäumt, die Download-Seite der Homepage zu akualisieren - habe ich nachgeholt.


    bye, Alex

    Hallo


    ...Und das mit dem Mailbox-Plugin hast du auch richtig verstanden. Der Nachrichtenbereich bleibt bei mir schwarz. ...


    Ich kann ebenfalls bestätigen, dass bei mir der Nachrichteninhalt zumindest mit den beiden Shady-Skins, sowie mit metrixhd und blackhole, mit skindesigner und allen skins heute früh per git akutalisiert, einwandfrei angezeigt wird.


    bye, Alex

    Hallo Zusammen,


    ich möchte mich hier mal anhängen, da ich bei mir ähnliches Verhalten beobachte: Sobald ich einen Timer anlege / lösche, blockiert epg2vdr den vdr dermaßen, dass ich erst nach ca. 1,5 Minuten erneut Timer anlegen/löschen kann.


    Wenn ich beispielsweise über das Live-Plugin vom epgsearch zuviel angelegte Timer löschen möchte, ist es lästig, nach dem Löschen eines Timers erst einmal 1,5 Minuten warten zu müssen, bis ich den nächsten Timer löschen kann. Auch wenn ich Timer über einen Client-VDR mit remotetimers-Plugin lösche, blockiert der Server derart lange, dass der Client die svdrp-Verbindung abbricht. Dieses Verhalten (oder zumindest ein ähnliches) wurde vom User machtnix schon im September hier beschrieben.


    Auszug aus dem Log:


    Um 15:27:54 habe ich einen Timer gelöscht: "Timer changed, updating", danach ist der VDR "blockiert" und legt erst einmal für 1,5 Minuten bis 15:29:26 eine Pause ein, in der ich nicht erkennen kann, was vdr da macht. Danach folgen in schneller Folge viele Meldungen "Updatie timer for event XXXX" (wohl für jeden Timer eine), nach deren Ausgabe der VDR wieder bereit ist, Timer-Änderungen entgegen zu nehmen.


    Zum diesem Zeitpunkt waren übrigens 120 Timer vorhanden. Der vdr, epgd und mysql laufen auf demselben Rechner: Intel DH87RL, i5-4570S, 32 GB RAM und Datenbank und die VDR-Konfigurationsdateien liegen auf einer 2 TB WD black, die Video-Dateien auf weiteren 4 TB WD red-> ich hoffe nicht, dass diese Hardware auch als zu schwachbrüstig für epg2vdr/epgd/mysql angesehen wird ;-)


    Wenn ich mit weiteren Logs helfen kann, das Problem zu suchen/beseitigen, werde ich diese gerne liefern.


    bye, Alex

    Hi Alex,


    soweit korrekt...die verfügbaren MenuCategories sind in der skins.h definiert. Ich kenne dein Plugin ja kaum, aber du rufst ja z.B, auch cDisplayMenu::SetText(const char *Text, bool FixedFont); auf, da solltest du dann mcText setzen.


    Vielen Dank, für die Antwort.


    Dann baue ich das mal wie folgt ein:
    - In den OsdMenus zur Konfiguration des Plugins setze ich: mcPluginSetup
    - In den übrigen OsdMenus mit listenähnlicher Darstellung setze ich: mcPlugin
    - In den OsdMenus, die Text bildschirmfüllend anzeigen (Mail-Ansicht und Log-Ausgabe), setze ich: mcText


    Korrekt?


    Dürfen OsdMenus, die unterhalb der Einstellungen liegen, jedoch keine Einstellungen ändern, auch andere Kategorien setzen? Es gibt nämlich ein OsdMenu, das die aktuelle Tastenbelegung in Listenform anzeigt: Dies kann sowohl von den 'normalen' Bildschirmen (also absteigend aus dem VDR Hauptmenü), wie auch aus den Einstellungen des Plugins (also absteigend aus dem Einstellungen-Menü) angezeigt werden und hier würde ich wiederum mcPlugin setzen. Weiterhin gibt es auch unterhalb der Plugin-Einstellungen ein OsdMenu, welches bildschirmfüllend Text ausgibt, sich also für mcText anbietet.


    bye, Alex

    Hallo Louis,


    Quote

    Das mailbox Plugin setzt leider so gar keine MenuCategories... [...] Das beste wäre es, man würde das Plugin mal an die Gegebenheiten in einem aktuellen VDR anpassen...


    wärest Du so nett und würdest mir kurz sagen, was ich im Plugin "an die Gegebenheiten in einem aktuellen VDR" anpassen bzw. was das Plugin so an MenuCategories setzen muss/soll?


    Reicht es, in allen Setup-Seiten des Plugins im Konstruktor SetMenuCategory(mcPluginSetup) und in den 'normalen' Seiten SetMenuCategory(mcPlugin) aufzurufen? Wenn's nur das wäre, kann ich das gerne machen. Größere Umbauarbeiten möchte ich an dem Plugin aber nicht (mehr) durchführen...


    Welche Auswirkungen haben diese Aufrufe denn?


    bye, Alex

    Hallo nochmal,


    nachdem mir meine Gentoo-Installationen gestern Abend auch den gcc-4.8 angeboten haben, habe ich diesen auf meinem Entwicklungsrechner installiert und etwas damit herumprobiert: Tatsächlich startet damit das Plugin auch bei mir nicht mehr, d.h. ich habe eigenen "Leidensdruck", die Sache wieder zum Laufen zu bekommen :-)


    mini73: Danke, für den Link. Das Plugin versucht aber nicht, die zu den OsdMenu/MenuHelpKeys (Templates) gehörigen cpp-Files separat zu übersetzen, sondern die Header-Files includieren die cpp-Files, d.h. die Implementierung der Methoden ist dadurch im Header zu finden.


    Der Fehler war eher, dass ich den Inhalt der cpp-Files nochmal gegen doppeltes Includieren per #defines 'geschützt' habe. Warum allerdings die Compiler sich unterschiedlich verhalten (bzw. auch die -O-Flags hierauf einen Einfluß haben), verstehe ich spontan nicht bzw. habe jetzt nicht die Zeit und Muße, mich da hineinzudenken.


    Ich habe jetzt aus den beiden betreffenden .cpp-Files (im include-Verzeichnis) die #ifdef...#define...#endif-Konstruktion entfernt und damit kein Problem mehr beim Start von vdr. Dadurch kann ich nun auch im Plugin-Makefile das "-O2" entfernen und das Plugin mit den zentral konfigurierten Flags (-O3) compilieren und starten. Getestet unter Gentoo mit vdr-2.0.5 und gcc-4.7 und vdr-2.1.6 mit gcc-4.7 und 4.8 (jeweils 64-Bit).


    Ich schaue mir jetzt noch mal die Sache mit den MenuCategories an und stelle dann wohl ein Päckchen zum Test bereit.


    bye, Alex

    Quote

    Eine template-Klasse muss immer komplett im Header sein.


    IIRC werden doch die beiden .cpp-Dateien im include-Verzeichnis in die jeweiligen Header-Dateien includiert (d.h. zum Beispiel: OsdMenu.h includiert OsdMenu.cpp und MenuHelpKeys.h includiert MenuHelpKeys.cpp), sollten also eigentlich beim "Verarbeiten" des Headers vorhanden sein.


    OK, ich gebe ja zu, dass mglw. .cpp an dieser Stelle unglücklich gewählt ist und vielleicht .inl treffender gewesen wäre...


    Warum das allerdings mit gcc-4.8 Probleme macht, weiss ich nicht und kann mich auf die Schnelle auch nicht darum kümmern (habe noch 4.7 auf dem Arbeitsrechner und keine Zeit...)


    bye, Alex