Beiträge von Alex

Hi,

a new version of the Mailbox plugin is available at
<http://sites.inka.de/~seca/vdr/>

Download link:
<http://sites.inka.de/~seca/vdr…oad/vdr-mailbox-0.5.0.tgz>

Changes since version 0.4.0:


2007-10-21: Version 0.5.0


- Added support for the new i18n system of vdr >= 1.5.7


- Check the used charset with cCharSetConv::SystemCharacterTable() when
  using vdr >= 1.5.3


- Added French language texts
  (thanks to Patrice Staudt)


- Added call to cStatus::MsgOsdTextItem to make the message body visible
  with graphlcd/graphtft.


- Added call cStatus::MsgOsdTextItem() whenn scolling up/down in
  mail-view.


- Added workaround for imap-servers not reporting attribute "charset=.."
  in "Content-Type:" lines. If charset is missing ISO-8859-1 is used.

Viel Spass,

Alex

Hi Toxic-Tonic und Thorsten

Zitat

Original von Toxic-Tonic

Debug aktivieren kann ich machen, aber ich bekomme bei HTML-Mails auch nix angezeigt!

Nett von Dir, dass Du das Plugin einmal mit aktivierten Debugs neu übersetzen und ausprobieren würdest.

Hier findest Du Die Sourcen einer Version des Plugins, bei dem ich ein paar Debug-Ausgaben aktviert habe. Diese basieren auf der Version 0.4.0 des Plugins - ich habe lediglich ein paar Compiler-Warnungen beseitigt und einige Debug-Ausgaben (landen im syslog) aktiviert, d.h. das Verhalten sollte identisch mit der Release sein. Insofern erwarte ich mit diesen Sourcen noch keine Besserung des Verhaltens, sondern hoffe lediglich auf Hinweise zum Aufspüren des Problems. Für den Einsatz im Alltagsbetrieb ist diese Version natürlich wegen der Logs nicht geeignet.

Was mich jetzt interessieren würde, ist ein grosszügiger Ausschnitt aus dem syslog, wenn eine (nicht lesbare) HTML-Mail geöffnet wird. Den Ausschnitt aus dem Log kannst Du mir gerne auch per E-Mail schicken an 'alex AT seca DOT inka DOT de'.

HTH, Alex

Hi Torsten

Zitat

Original von wtor
habe bei mir skinenigma so konfiguriert, das bei neuer Mail vom mailbox Plugin das Mailsymbol angezeigt werden soll. Das funktioniert aber nie. Ist neue Mail da, dann sehe ich das wenn ich das Hauptmenu aufrufe am Menueintrag "Postfach (1 neue)" oder zuvor durch die OSD Nachricht. Aber bei Ok (kurze Sendungsinfo) wird das Mailsymbol nie angezeigt.

Kann es sein, dass Du in der MailAccount-Konfiguration unter dem Punkt "Zyklische Abfrage" zwar "- Hauptmenüeintrag" aktiviert hast, "- Interne Schnittstelle" jedoch nicht? Genau diese, also die interne Schnittstelle wird von SkinEnigma (und anderen) zur Darstellung des Mail-Symbols verwendet.

Zitat

Habe jetzt mal ein wenig debuggt. Im Service() interface in AxPluginMailBox.cpp wird myHasNewMail zurückgegeben. Ich sehe aber nigends, das diese Varible bei neuer Mail mit true gefüllt wird.

myHasNewMail kommt in der Datei genau drei mal vor:

(1) Im Konstruktor
(2) in Service() wird lesend zugegriffen
(3) in setMainMenuAppendix() wird schreibend zugegriffen

Und der Wert, auf den die Variable in (3) gesetzt wird, wird in AxMailChecker::Action() nur ermittelt, wenn oben genannter Konfigurationsschalter aktiviert ist.

Zitat

Deshalb habe ich testweise einfach mal die Zeile ersetzt:

Code

-        *fHasNewMail = myHasNewMail;
+        *fHasNewMail = !myMainMenuEntryAppendix.empty();

Damit gehts dann! Ist das evtl. ein bekanntes Problem? Ich habe aber nichts dazu gefunden.

Nein, das ist kein bekanntes Problem und daher hast Du auch nichts dazu gefunden

bye, Alex

PS: Bin ab sofort für eine Woche offline.

Hi yannick699

Zitat

Original von yannick699
Hallo

hab schon wieder ein problem
hab unter dem admin plugin mailbox installiert also auf 11 gesetzt
hab neu gestartet,es wird in plugins aufgeführt
finde aber jetzt die config nicht um die ienstellungen für mein pop3 konto zu übernehmen,muss ich noch irgendwas installieren?

In den Einstellungen des Plugins (auf oberster Ebene der Einstellungen des Plugins, also nicht im Untermenü "Allg. Einstellungen") kannst Du die vom Plugin zu verwendenden Mail-Accounts verwalten, also auch anlegen (Taste "grün").

Für eine Erklärung der möglichen Einstellungen: Siehe README (z.B. hier)

HTH, Alex

BTW: Ein Subject "mailbox plugin geht nicht!!!" finde ich dafür, dass Du anscheinend die Einstellungen nicht gefunden hast, ... hmmm... zumindest unpassend.

Hi Martux

Zitat

Original von Martux
Hallo!
Ich habe noch ein Problem mit der Mailbox bei c't-vdr6:
Ich kann den POP3 account einrichten und testen. Meine Emails kann ich 1x lesen, aber danach habe ich keinen Zugriff mehr, d.h. der VDR reagiert nicht.
Die Syntax des accounts ist richtig (geschweifte Klammern usw.).
Ich habe auch schon das Plugin entfernt und neu installiert, gleiches Ergebnis.
Wenn ich nach der Einstellung des accounts das Plugin übers OSD neu konfigurieren möchte, friert der vdr auch ein.
Hat jmd. einen Tipp für mich?
Was mich wundert ist, dass ich ja aufs Postfach 1x zugreifen kann und danach nicht mehr. Ich gehe also davon aus, dass die Einstellungen prinzipiell richtig sind.
Gibt es u.U. Probleme mit dem Router? Ich weiss nicht weiter.

Vielen Dank,
Martux

Alles anzeigen

Kannst Du bitte mal die "Debug"-Option beim Mail-Account aktivieren (das ist der unterste Eintrag in den Einstellungen des Accounts) und dann eine erfolgreiche und eine fehlerhafte Abfrage des Mail-Accounts durchführen und anschliessend mindestens die Zeilen zwischen den ">>>.." und "<<<..." aus dem syslog ausschneiden und entweder hier posten oder mir per E-Mail schicken. Bei der gescheiterten Abfrage sind auch ein paar Zeilen mehr interessant.

Ausserdem würden mich folgende Angaben interessieren:
* Welchen Watchdog-Timeout (Parameter -w) übergibst Du dem VDR beim Start?
* Wie ist der Parameter "Verbindungstimeout" in den allgemeinen Einstellungen des Mailbox-Plugins eingestellt?
* Wie lautet die Zeile "Mailbox = " in Deiner Datei .../pfad-zu-VDR-Einstellungen/plugins/mailbox/accounts.conf?
* Was ist Dein E-Mail-Provider? Handelt es sich vielleicht um einen Provider/Account, der nur alle n Minuten eine Abfrage zulässt?

Mglw. können wir Dein Problem mit diesen Informationen weiter eingrenzen.

bye, Alex

Hi Andreas

Zitat

Original von amair
Stimmt, das habe ich übersehen. Werde ich demnächst einbauen.
Ich denke, es müßte passen, wenn man zusätzlich noch einen Fixed-Font im Setup definieren kann. Sollte in diesem Bereich kein FixedFont verlangt werden, dann könnte man pFontDetailsText verwenden.
Einwände?

Das hört sich prima an. Ich denke auch, dass pFontDetailsText für Proportionalschrift die passende Einstellung ist, da bei cSkinEnigmaDisplayMenu::SetText() ja auch ein kompletter Bildschirm mit Text vollgeschrieben wird. Insofern sollte ein weiterer Font für FixedFont reichen.

Vielen Dank und viele Grüße,
Alex

Hi Andreas,

ich habe gerade auch auf die aktuellen cvs-Version Deines Skins upgedatet und probiere gerade verschiedene Fonts aus: Das sieht schon sehr schick aus.

Dabei ist mir aufgefallen, dass diejenigen OSDs, die mit DisplayMenu()->SetText() einen kompletten Bildschirminhalt mit Text füllen, mit den VDR Standard-Fonts ausgegeben werden. Das Mailbox-Plugin verwendet zum Beispiel diese Methoden zur Darstellung der Mails.

Kann es sein, dass folgende Methoden (bzw. nur die untere) in enigma.c die neuen Fonts noch nicht berücksichtigen:

void cSkinEnigmaDisplayMenu::SetText(const char *Text, bool FixedFont)
{
#ifndef DISABLE_ANIMATED_TEXT
  if (!fLocked) TE_LOCK;
#endif
  // draw text
  textScroller.Set(osd, xBodyLeft + Gap, yBodyTop + Gap,
                   GetTextAreaWidth(),
                   yBodyBottom - Gap - yBodyTop - Gap, Text,
                   GetTextAreaFont(FixedFont),
                   Theme.Color(clrMenuTxtFg), Theme.Color(clrBackground));
  SetScrollbar();
#ifndef DISABLE_ANIMATED_TEXT
  if (!fLocked) TE_UNLOCK;
#endif
}


...


const cFont *cSkinEnigmaDisplayMenu::GetTextAreaFont(bool FixedFont) const
{
  // text area font
  return cFont::GetFont(FixedFont ? fontFix : fontOsd);
}

Ich habe mal probehalber die return-Anweisung in GetTextAreaFont() so geändert, dass "pFontDetailsText" zurückgegeben wird und das hat tatsächlich sichtbare Auswirkungen.

Ich bin nur nicht sicher, ob pFontDetailsText an dieser Stelle den korrekten Font bezeichnet. Selbst wenn pFontDetailsText hier für die proportionale Schrift noch plausibel sein mag, so fehlt doch noch die Berücksichtigung des Parameters "bool FixedFont".

bye, Alex

Hi Marc

Zitat

Original von zulu
ich habe hier jetzt mit reelchannelscan-0.4.1 probiert. Damit öffnen sich die Menüs bei mir auch nicht mehr. Mit deinem Patch funktionieren sie dann wieder.

Prima

Zitat

Den Patch, auf den Zzam verweist, habe ich auch probiert und der hilft ebenfalls.

Japp, der korrigiert IMHO das Verhalten des reelchannelplugins - wie ich es in meiner Mail (die ich wohl gleichzeitig wie Zzam geschrieben habe) beschrieben habe.

Zitat

Original von zulu
IMHO ist dein Patch eine sinnvolle Änderung der MainMenuHooks. Hast du schon Kontakt zu einem der Autoren der MainMenuHooks aufgenommen?

Zu meiner Schande muss ich gestehen, dass ich nicht einmal weiss, wer der/die Autoren des MainMenuHooks-Patches sind - also nein.

bye, Alex

Hallo FireFly / viking

Zitat

Original von FireFly
- es von einem Plugin in VDR-Setup geändert (evtl. nur im Main Thread möglich? siehe Post von triple955)

Zitat

Original von viking
Ich denke mal das größte problem dürfte sein ob die VDR-Setup einstellung (ohne VDR patch) im plugin geändert werden kann (stichwort main thread).

Nur zur Klarstellung: Ich möchte nicht mit Gewissheit behaupten, dass es nur aus dem Haupthread von VDR möglich ist, die OSD-Einstellung vom VDR-Setup zu ändern.

Als ich damals probehalber den Analyse-Teil von avards in mein SwitchOSDPos-Plugin gebastelt habe, war ich mir einfach nicht sicher, welche Auswirkungen es haben kann, wenn ich von einem Thread aus diese VDR-Einstellungen verändere. Ausserdem konnte ich nicht überblicken, welche Konsequenzen es auf VDR oder andere Plugins hat, wenn die OSD-Einstellungen geändert würden, wenn gerade ein OSD offen ist. Und da ich mir weiterhin nicht sicher war, ob ich cOsd::IsOpen() in einem Thread (eben dem Bildanalyse-Thread) aufrufen darf, habe ich mich eben für die defensivste Variante entschieden und die Abfrage, ob ein OSD offen ist und ggf. die Änderung der OSD-Position in MainThreadHook() gelegt.

Als Pseudocode sah mein MainThreadHook dann ungefähr so aus:

void MyPlugin::MainThreadHook()
{
  if (aktuelle Einstellungen != AnalyseThread.getOSDPos() && !cOsd::isOpen())
  {
    setze Setup.OSDxxx
    gebe WSS-Signal aus.
  }
}

Also wie gesagt: Da ich einfach nicht alle Auswirkungen überblicken konnte, habe ich mich für die aus meiner Sicht und nach meinem Kenntnisstand für eine defensive Variante entschieden. Mit etwas mehr Überblick über die Auswirkungen mag man zu einer anderen Beurteilung kommen.

Das nur zur Information.

bye, Alex

Zitat

Original von zulu
Hi Alex,

welche Version des reelchannelscan nutzt du denn? Bei mir läuft 0.3.3 ohne das es Problem gibt.

Es handelt sich um Version vdr-reelchannelscan-0.4.1.

Entgegen der Dokumentation in PLUGINS.html ("The function shall return true for any service id string it handles, and false otherwise.") liefert diese Methode stets true, behauptet also alle Services zu unterstützen.

Natürlich liegt der eigentliche Fehler im reelchannelscan-Plugin und ist eigentlich auch leicht zu beheben. Man müsste nur das "return true;" durch ein "return false;" ersetzen und ein "return true;" direkt darüber als letzte Anweisung innerhalb der schliessenden Klammer vom if einfügen.
(BTW: Der Name des Services "install" entspricht ebenfalls nicht der in PLUGINS.html geforderten Konvention ("

Allerdings ist der Bigpatch bzw. der MainMenuHook-Teil davon IMHO einfach allgemein anfällig gegen Plugins, die fälschlicherweise true liefern und öffnet in diesem Fall überhaupt keine Menüs für Schedule/Channels/Timers/Recordings mehr, da eben nicht geprüft wird, ob der Service-Aufrufl tatsächlich einen Zeiger auf eine Menü-Instanz geliefert hat.

Durch meinen Patch wird zumindest in diesem Fehlerfall, eine Meldung ins Log geschrieben (mit dem Namen des Plugins, das diese Situation verursacht hat) und ein VDR-eigenes Menü erzeugt. Ich halte das immer noch für besser als stillschweigend überhaupt keine Menüs mehr anzuzeigen.

bye, Alex

Sorry, Doppelpost.

Hi FireFly

Zitat

Original von FireFly
Bingo! Es guckt ja doch jemand in den Quelltext

Mindestens zwei

Zitat

Original von FireFly
die OSD-Größe von der Bildgröße (Zoom) abhängig zu machen war der Hauptgrund für mich das Avards in ein Plugin zu packen. Ich wollte aber erst mal diese Version rausbringen um zu sehen, ob's da "im Feld" vielleicht noch Probleme gibt.

Zugegebenermassen habe ich Dein Plugin nicht ausgeführt sondern Sonntag nur kurz in die Sourcen gesehen, bin aber überzeugt, dass die Sache so funktionieren kann (s.u.).

Zitat

Seit Sonntag Abend habe ich auch schon eine lauffähige Version mit variabler Menügröße und dem SkinElchi zusammen.

Ich dachte das jeweilige Skin-Plugin kann bei Avards die (maximale) OSD-Größe abfragen. Ist Avards nicht aktiv, dann werden die Standardwerte Setup.OSDLeft, Setup.OSDTop, Setup.OSDWidth und Setup.OSDHeight zurückgegeben. Ist Avards aktiv und wird gezoomt, dann werden angepasste Werte übergeben. Setup.OSDLeft und Setup.OSDWidth sollen immer unverändert weitergegeben werden (Breite bleibt unverändert), Setup.OSDTop und Setup.OSDHeight werden an den jeweiligen Zoomfaktor angepaßt.

Alternativ könnte das Plugin doch auch direkt die Einstellungen von VDR (also Setup.OSDxxx) manipulieren. Natürlich nur im Haupthread (also z.B. in MainThreadHook()) und nur dann, wenn gerade kein OSD offen ist.

Dies hätte auch den Vorteil, dass die Skins überhaupt keine Anpassungen bräuchten und direkt die korrekten (von Deinem Plugin festgelegten) Koordinaten verwenden würden.

Zitat

Im Moment verschiebe ich das OSD (mangels besserer Ideen) um (576 - nActiveLines)/2 nach unten und kürze es um (576 - nActiveLines) und habe damit schon ganz gute Ergebnisse erreicht, bin aber für Verbesserungsvorschläge offen ....

Eine komplett automatischen Bestimmung der OSD-Ausmaße stelle ich mir in folgendem Fall problematisch vor: Ist das aktuelle Bildformat 4:3 (oder 16:9 anamorph), so würde das OSD die grössten Ausmasse annehmen. Dann kann es aber vorkommen, das es mit einigen Skins auf 2MB-DVB-Karten Probleme gibt.

Würdest Du andererseits die OSD-Grösse stets um einen gewissen Prozentsatz unter dem Maximum halten, dann würde das OSD nicht die maximal mögliche Grösse bei Letterboxed -Ausstrahlungen annehmen. Im Letterboxed-Fall würde als Bild-Bereich ja eine geringere Höhe als bei 4:3 ermittelt werden und der Fernseher würde zoomen. Das OSD würde noch kleiner werden, da es dann noch um den Prozentsatz reduziert werden würde - und das, obwohl die Karte mehr darstellen könnte.

Zitat

Vermeiden möchte ich zu viele Einstellungen im Setup, also z.B. jeden der vier Werte für jeden Modus einstellbar machen - das wird zu unübersichtlich und (für den Enduser) nicht mehr administrierbar.

Grins, ganz genau: Ich habe vor längerer Zeit ein Plugin SwitchOSDPos geschrieben, um *händisch* per Fernsteuerung zwischen verschiedenen Einstellungen für die OSDPosition (Presets) umschalten zu können. (Der zweite Grund für dieses Plugin war, dass ich damit leicht den Zeilenumbruch im Mailbox-Plugin mit verschiedenen OSD-Grössen testen konnte.) Später habe ich das Plugin mit einer SVDRP-Schnittstelle versehen, um die Ergebnisse von dvb-aspect an das Plugin schicken zu können.
Noch später (ungefähr avards-0.4) habe ich dann mal versuchweise den Analyse-Part von dvb-aspect in einen Thread in dieses Plugin eingebaut - also ganz ähnlich, wie Du es gemacht hast. Die Ergebnisse der Bildanalyse wurden dann verwendet, um verschiedene Presets umzuschalten, die in diesem Hack exakt so heissen mussten, wie dvb-aspect sie liefert.

Die Integration des Analyseteils von dvb-aspect war nur schnell zusammen gehackt und da ich damals keine weitere Zeit hatte, die Sache Endusertauglich zu machen, ist es bei einem privaten (aber seitdem funktionierenden) proof-of-concept geblieben.

Aber wie Du geschrieben hast: Die ganzen Presets (OSD-Left/Top/Width/Height) für die verschiedenen Bildformate (4.3, 16.9, 16:9L, >16.9) passend zu erstellen ist eine Heidenarbeit und dem Enduser fast nicht zuzumuten.

Insofern danke ich Dir schon jetzt für deine Arbeit an einem sauberen Plugin für diese avards-Thematik.

bye, Alex

Hallo Marc,

zunächst einmal möchte ich mich herzlich für die ganze Arbeit bedanken, die Du in den Extensions Patch investierst. Insbesondere dass Du die Patches einzeln ausschaltbar machst, finde ich super.

Zum Problem: Ich wollte gerade meine Kanalliste aufräumen und damit es wirklich was zu tun gibt, habe ich vorher das reelchannelscan-Plugin installiert. Danach gingen die Hauptmenüeinträge Schedule/Channels/Timers/Recordings nicht mehr.

Der eigentliche Verursacher war wohl das reelchannelscan-Plugin, da dieses für alle Aufrufe von cPlugin::service() true zurück liefert, also 'behauptet', es würde den Service-Aufruf unterstützen - ein Menü wird jedoch nicht geliefert.

Tatsächlich könnte der MainMenuHooks-Patch ein klein wenig defensiver ans Werk gehen.

Hier exemplarisch der Fall für ein Menü:

case osSchedule:
        if (!cPluginManager::CallFirstService("MainMenuHooksPatch-v1.0::osSchedule", &menu))
           menu = new cMenuSchedule;
        else
           state = osContinue;
        break;

Falls der cPluginManager ein Plugin findet, welches von sich behauptet, es würde den Service-Aufruf unterstützen, so wird 'state' auf 'osContinue' gesetzt, auch wenn überhaupt kein Menü (in 'menu') geliefert wurde.

Ich würde folgende Änderung vorschlagen:

case osSchedule:
        {
          cPlugin *p = cPluginManager::CallFirstService("MainMenuHooksPatch-v1.0::osSchedule", &menu);
          if (p && !menu)
              isyslog("MainMenuHook::osSchedule: plugin %s claims to support service but didn't return menu", p->Name());


          if (!menu)
            menu = new cMenuSchedule;
        }
        break;

Damit wird, falls ein Plugin meldet, dass es den Service-Aufruf unterstützt und kein Menü zurück liefert, der Name des Plugins zur weiteren Diagnose ausgegeben und zumindest ein VDR-native-Menü erzeugt.

Angehängt habe ich mal einen Patch gegen vdr-1.4.7-Extensions-Patch-28, in dem ich an allen Stellen diese Änderung durchgeführt habe.

Da ich den Patch nur rel. kurz getestet habe, wäre es sinnvoll, wenn sich mehrere Leute die Sache mal ansehen, bevor die Marc die Änderung übernimmt.

HTH, Alex

Hi Ronny

Zitat

Original von ronnykornexl
Ignoriert mich einfach, der Erfolg hällt es ebenso

Sorry, war keine Absicht.

Zitat

Keiner bei 1&1?

Hatte auch mal, eine andere Version von VDR drüber gebügelt, bleibt das gleiche.

Danach:

Code

mailbox: WARN  MailBox: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN

Geht die Last hoch.

MFG Ronny

Alles anzeigen

Die üblichen Fragen:
- Wie lautet der exakte Mailbox-String (aus der accounts.conf)?
- Aktiviere den /debug-Schalter für den Mail-Account und schicke mir das komplette Log (mindestens ab ">>>>" bis zum Ende des VDR) - bevorzugt per E-Mail, die Adresse hast Du ja.

bye, Alex

Hallo Toxic-Tonic,

freut mich, dass sich aus dem Kreis derjenigen, die für LinVDR Updates compilieren können, nun jemand für das Problem interessiert -> Willkommen

Zitat

Original von Toxic-Tonic
OK, dann also hier! Ich bin mir nicht sicher, aber da bei mir das Mailbox-Plugin läuft (GMX) glaube ich nicht das es ein generelles Problem ist!

Verwendest Du ssl zum Zugriff auf GMX?

Zitat

Außer Google-Mail besteht auf bestimmten ssl-Funktionen, aber dann hätte wenigstens Web.de laufen müssen!

Nun, web.de über pop3 ohne ssl funktioniert (bei mir) grundsätzlich, führt aber zu dem Problem, dass web.de nicht beliebig viele Abfragen hintereinander zulässt.

Zitat

Jetzt mal eine blöde Frage am Rande, der Rechner hat aber freien Zugang zum INet? Firewall dazwischen? Richtiges Gateway eingetragen? Kannst du den gmail-server anpingen?

Die Fragen an Nighthawk777 kann ich natürlich nicht beantworten.

Aber es deutet m.E. vieles darauf hin (was ich auch in diesem Thread und im Mahlzeit-3.2-Thread (hier und hier) begründet habe), dass die c-client Bibliothek für LinVDR ohne ssl-Unterstützung gebaut wurde und damit keine Mail-Accounts über ssl erreichbar sind.

Zum Test habe ich meinen lokalen Mail-Server ("seca.local") inzwischen ebenfalls mit pop3-ssl und imap-ssl konfiguriert und getestet. Zusätzlich habe ich in meiner accounts.conf noch Einträge für gmail (pop3-ssl), web.de (pop3-ssl, imap-ssl, pop3 und imap).

Siehe hier die relevanten Teile meiner accounts.conf:

Zitat

[Account]
AccountName = Alex (alex@seca[imap-ssl])
MailBox = {seca.local/imap/ssl/notls/novalidate-cert}
[Account]
AccountName = Alex (alex@seca[pop3-ssl])
MailBox = {seca.local/pop3/ssl/notls/novalidate-cert}
[Account]
AccountName = GMail [pop3-ssl]
MailBox = {pop.gmail.com/pop3/ssl/notls/novalidate-cert}
[Account]
AccountName = web.de [pop3-ssl]
MailBox = {imap.web.de/imap/ssl/notls}
[Account]
AccountName = web.de [imap-ssl]
MailBox = {imap.web.de/imap/ssl/notls}
[Account]
AccountName = web.de [pop3]
MailBox = {imap.web.de/imap/notls}
[Account]
AccountName = web.de [imap]
MailBox = {imap.web.de/imap/notls}

Alles anzeigen

(Dies ist natürlich keine vollständige accounts.conf, sondern lediglich die hier relevanten Zeilen).

Diese Accounts.conf habe ich sowohl auf meinem Entwicklungsrechner (ein Gentoo-System) und auf einem Test-Rechner mit Mahlzeit-ISO 3.2 getestet.. Für die Tests haben beide die Default-Route ins Internet gesetzt und können die jeweiligen Mail-Server anpingen.

Auf meinem Entwicklungsrechner bekomme ich Zugang zu allen Accounts. Auf dem LinVDR-Rechner bekommen nur die beiden unteren Accounts ohne ssl Zugriff. Die ersten fünf ssl-Accounts führen zu der Fehlermeldung "invalid remote specification".

Entferne ich auf meinem Entwicklungsrechner die von Gentoo gelieferte c-client Bibliothek und baue mir diese ohne ssl-Unterstützung selbst, so erhalte ich exakt das gleiche verhalten, wie auf dem LinVDR-System. Es sieht also so aus, als würde c-client die ssl-Optionen nicht verstehen ("invalid remote specification") wenn c-client ohne ssl-Unterstützung gebaut wurde.

IMHO bestätigt dies meine oben geäusserte Vermutung bestätigt, dass die c-client bei LinVDR / Mahlzeit ohne SSL-Unterstütung erzeugt wurde und daher die Verwendung von SSL im Mailbox-Plugin nicht möglich ist.

Hinweis: Beim Erzeugen der c-client wird eine Datei "linkage.c" im Verzeichnis der Header erzeugt, welche von einem Anwendungsprogramm (also z.B. dem Mailbox-Plugin) in ein Source-File includiert werden muss. Diese Datei linkage.c wird beim Übersetzen der c-client erzeugt und enthält build-konfigurationsabhängige Funktionsaufrufe. Daher muss nach jeder Erzeugung der c-client das Mailbox-Plugin zwingend neu compiliert werden.

Ich konnte beobachten, dass in der linkage.c ganz unten eine Zeile
Zitat:
ssl_onceonlyinit ();
vorhanden ist, wenn die c-client mit SSL-Support übersetzt wurde und diese Zeile fehlt, wenn die c-client ohne SSL-Support erzeugt wurde. (Natürlich weiss ich nicht 100%ig, ob dies als Beweis ausreichend ist.)

Könntest Du die Datei linkage.c von Deinem Entwicklungsrechner bitte mal hier posten?

bye, Alex

Hallo zusammen

Zitat

Original von Mase
Ich würde gerne noch 2 Wünsche äussern:

Da möchte ich mich einem Wunsch anschliessen, einen erfüllen und einen neuen äussern

Zitat

Würde es nicht besser aussehen, wenn der Aufnahme-Indikator ne andere Farbe hätte? Z. B. roter Hintergrund mit weisser Schrift.

Ich fände es auch besser, wenn der Aufnahme-Indikator etwas kontrastreicher dargestellt würde.

Zitat

Wie wäre es mit einem Email-Indikator, der mit dem mailbox-Plugin kommuniziert?
Für Skinelchi gab es da einen Patch.

Der beigefügte Patch (gegen den cvs-Stand von vor zwei Stunden) erlaubt es, bei vorhandenem Mailbox-Plugin das Mail-Icon immer (grau/gelb) oder nur bei Vorhandensein einer neuen Mail (gelb) darzustellen. Die Darstellung des Mail-Icons muss im Setup aktiviert werden.

Disclaimer: Sehr intensiv habe ich den Patch noch nicht getestet. Bei einer kurzen Funktionsprüfung konnte ich jedoch keine Probleme feststellen.

Andreas: Ich habe lediglich meinen älteren Patch, den ich für den Elchi-Skin gemacht habe, an Dein Plugin angepasst. Falls Dir die Source-Formatierung, die Position im Setup-Menü oder sonstiges nicht gefällt, kannst Du es ja gerne an Deine Gepflogenheiten anpassen. So viele Zeilen sind's ja nicht.

Neuer Wunsch: Ich fände es nützlich, wenn in der Wiedergabe-Info (zumindest in der ausführlichen Darstellung mit dem Fortschrittsbalken/Schnittmarken) auch ein Bereich für das Recording- und das Mail-Icon vorhanden wäre - mglw. in der untersten Zeile, rechts von der Uhrzeit.

bye, Alex

Nochmal hallo tarandor

Zitat

Original von tarandor
Habt ihr eigentlich das installiert:
http://vdr-online.org/lib-ssl-0.9.8.tar.bz2
???

Siehe hier:
http://www.vdr-online.org/

Alles anzeigen

Inzwischen habe ich mal nachgesehen und festgestellt, dass beim Mahlzeit 3.2 die ssl-libs bereits vorhanden sind. Trotzdem habe ich das von Dir angegebene Paket herunter geladen und in einem separaten Verzeichnis ausgepackt und die Dateien verglichen: die enthaltenen Dateien sind identisch.

Ausserdem habe ich gerade folgendes getan:

Auf meinem Entwicklungsrechner (gentoo) habe ich gerade die Gegenprobe gemacht und c-client und das Mailbox-Plugin mehrmals händisch übersetzt:

Zunächst habe ich die c-client zunächst mit SSL-Support erzeugt (und natürlich danach das Mailbox-Plugin neu compiliert) mit dem Ergebnis, dass ich auf alle Test-Accounts zugreifen konnte.

Danach habe ich die c-client ohne SSL-Suppport erzeugt und dies führte zu dem Ergebnis, dass ich auf genau diesen gmail-Account, der eben ssl benötigt, nicht mehr zugreifen konnte und die Fehlermeldung "invalid remote specification" erschien.

Ich würde sagen, dass dies meine oben beschriebene Vermutung bestätigt, dass die c-client bei LinVDR / Mahlzeit ohne SSL-Unterstütung erzeugt wurde und daher die Verwendung von SSL im Mailbox-Plugin nicht möglich ist.

Hinweis: Beim Erzeugen der c-client wird eine Datei "linkage.c" im Verzeichnis der Header erzeugt (ja, der Build-Vorgang der c-client ist... hmm, etwas ungewöhnlich), welche von einem Anwendungsprogramm (also z.B. dem Mailbox-Plugin) in ein Source-File includiert werden muss, und zwar in einen Block der am Anfang der Applikation ausgeführt werden muss. Diese Datei linkage.c wird beim Übersetzen der c-client erzeugt und enthält build-konfigurationsabhängige Funktionsaufrufe. Daher muss nach jeder Erzeugung der c-client das Mailbox-Plugin zwingend neu compiliert werden.

Hinweis: Ich konnte beobachten, dass in der linkage.c ganz unten eine Zeile

Zitat

ssl_onceonlyinit ();

vorhanden ist, wenn die c-client mit SSL-Support übersetzt wurde und diese Zeile fehlt, wenn die c-client ohne SSL-Support erzeugt wurde. Natürlich weiss ich nicht 100%ig, ob dies als Beweis ausreichend ist.

Tarandor:

- Könntest Du mal nachsehen, ob diese Zeile in Deiner linkage.c (muss im selben Verzeichnis wie die anderen c-client Header liegen) vorhanden ist?

- Wäre es Dir möglich, die c-client mit SSL-Support und das Mailbox-Plugin neu zu übersetzen und mir die Binaries zum Test zur Verfügung zu stellen?

bye, Alex

Hi Tarandor

Zitat

Original von tarandor
Habt ihr eigentlich das installiert:
http://vdr-online.org/lib-ssl-0.9.8.tar.bz2
???

Siehe hier:
http://www.vdr-online.org/

Gruß
Tarandor

Alles anzeigen

Nein, habe ich zugegebenermassen nicht probiert und kanns auch jetzt nicht gleich testen (hab gerade Besuch).

Aber wenn ich darüber nachdenke, so glaube ich nicht, dass allein das Einspielen der libssl etwas bringt. Grund: Die Sourcen der c-client-Bibliothek werden durch den Parameter, der beim Aufruf von make mitgegeben wird, bestimmte Teile übersetzen und bestimmte Teile nicht (bedingte Compilierung). Wenn nun also c-client ohne ssl-Unterstützung compiliert wurde, dann kennt c-client die ssl-Unterstützung und die damit aktivierten Parameter ("/ssl", etc. ) nicht.

Natürlich kann ich mich auch täuschen, da es eine Weile zurück liegt, dass ich in die Sourcen von c-client hinein gesehen habe, aber ich kann mich nicht erinnern in diesen Sourcen Stellen gesehen zu haben, an denen die ssl-Library dynamisch zur Laufzeit geladen wird.

Später am Abend werde ich es aber - um mich Rückzuversichern - noch ausprobieren.

bye, Alex

Hi Frankman

zufällig bin ich auf Dein Posting hier gestossen.

Zitat

Original von Frankman
Geht leider immer noch nicht, darum schubs ichs noch mal nach oben...

Ich erhalte immer folgenden log:

Die Meldung kommt mir bekannt vor, siehe hier und hier.

Zitat

Meine Einstelllungen sind:

Ich bin wohl zu doof für dieses Plugin!

Glaube ich nicht Genau diese Einstellungen funktionieren bei mir so einwandfrei - allerdings verwende ich kein LinVDR.

Wie in den beiden oben verlinkten Threads nachzulesen, hatten/haben andere LinVDR-User das gleiche Problem beim Zugriff auf Mail-Accounts über SSL.

Probehalber habe ich mir diese Woche auf einem alten Spielrechner ein LinVDR Mahlzeit 3.2 mit streamdev-client und DXR3 eingerichtet.

(BTW: Schon beeindruckend, einen funktionsfähigen VDR innerhalb von ein paar Minuten einzurichen. Grossen Respekt an alle Beteiligten.)

Wie ich feststellen konnte, funktioniert die gleiche Konfigurationsdatei, die auf meinen anderen PCs einwandfrei Zugriff auf das Google-Mail-Konto über SSL erhält, auf dem LinVDR-Rechner nicht. Es erscheint genau die oben sichtbare Fehlermeldung.

Ich würde vermuten, dass die vom Mailbox-Plugin verwendete c-client-Bibliothek in der LinVDR-Version nicht mit SSL-Unterstützung erzeugt wurde. Leider ist mir (derzeit) keine c-client-Funktion bekannt, mit der ich abfragen könnte, ob c-client SSL-Support eincompiliert hat. Ich habe aber in den c-client-Sourcen gesehen, dass bei fehlendem SSL-Support die damit zusammenhängenden Optionen (z.B. "/ssl") als ungültig abgewiesen werden ("invalid remote specification").

Da ich die Zuständigkeiten / Arbeitsteilung im LinVDR-Umfeld von Mahlzeit / Toxic-Tonic / Tarandor / u.v.A. nicht so genau kenne, weiss ich nicht, an wen ich mich nun genau wenden sollte.

Interessieren würde mich z.B. folgendes: Ist sichergestellt, dass c-client mit SSL-Unterstützung compiliert wurde? Welcher Parameter wurde an make beim Erzeugen der c-client übergeben?

Bei der c-client ist es wichtig, dass der korrekte Parameter an make übergeben wird. Natürlich muss zu diesem Zeitpunkt SLL (incl. Header) und mglw. libcrypt vorhanden sein. Nachdem c-client neu erzeugt wurde, muss auch das Mailbox-Plugin neu übersetzt werden.

Es wäre also nett, wenn sich einer der LinVDR-Erzeuger dieses Problem mal ansehen würde. Ich habe selbst keine Entwicklungsumgebung für LinVDR und bin in der Debian/LinVDR-Welt auch nicht Zuhause. Als Tester für fertige Compilate würde ich mich allerdings zur Verfügung stellen.

bye, Alex

Zitat

Original von vejoun
Hallo,

Die Paktete sind richtig und gehören zusammen:
libc-client-dev/etch uptodate 7:2002edebian1-13.1
libc-client2002edebian/etch uptodate 7:2002edebian1-13.1

Hallo vejoun,

vielen Dank, für die Klarstellung.

Zitat

Original von binduli
...
Und bekomme beim Abholen immer diese Einträge im Log

Code

...
Mar  7 20:32:50 localhost vdr: [2695] mailbox: CLLBK MailBox: mm_flags: MsgNum: 2

Hmm, leider ist in diesem Log nicht zu sehen, was danach passiert.

Ich sehe aber, dass sich in dem Postfach 212 Nachrichten befinden und das Plugin versucht, die Nachrichten von Anfang an (also ab Nr. 1, Größe: 443427) abzurufen.

Soeben habe ich mal mit denselben Einstellungen auf meinen web.de-Account zugegriffen und die Log-Ausgabe sieht ganz ähnlich aus, führt aber nicht zu Problemen. Allerdings habe ich momentan auch nur vier kleine Nachrichten in dem Postfach

Könntest Du mal probehalber im Mailbox-Plugin in den allgemeinen Einstellungen eine absteigende Sortierreihenfolge wählen und maximal 5 oder 10 Mails abholen lassen und mir das dabei entstehende Log komplett zuschicken?

Uli, ich würde vorschlagen, dass wir die weitere Analyse der Log-Files lieber per E-Mail durchführen, damit wir diesen Thread nicht mit langen Logs überfluten. Bitte schicke mir die Logs also per normaler E-Mail an alex @ seca PUNKT inka PUNKT de.

bye, Alex