Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - maf

1
Daran liegt's leider (oder zum Glück) nicht: Die EPG-Daten sind vorhanden. Ich kann sie unter "Programm" problemlos abrufen.

2
Das Problem ist leider weiterhin ungelöst  :-[

Und mittlerweile kann ich noch ein zweites Phänomen beobachten: Manchmal ist nach dem Start aus dem "weichen Suspend" die Liste der Aufnahmen völlig durcheinander: Beim Aufruf von "Aufzeichnungen" fehlen manche Ordner, andere werden unter falschem Namen oder doppelt angezeigt. Das Aufnahmeverzeichnis ist über NFS eingebunden, auf dem Server ist alles in Ordnung.

Ich vermute, irgendetwas läuft beim Aufbau des OSD schief.

3
Allgemein [ General ] / Fehler beim Ansprechen des fernen Timers
« on: June 20, 2019, 11:39:54 »
Hatte bei mir ähnliche Probleme und bin deshalb wieder weg vom Remote-Timer'n.

Im Plugin svdrpservice steckt ein Fehler, der zu Kommunikationsproblemen zwischen Client und Server führt, die sich in allen Plugins bemerkbar machen können, die svdrpservice benutzen, z.B. remotetimers. Ich habe einen Patch für svdrpservice vorgeschlagen.


4
Hallo,

überlicherweise werden ja nach dem Kanalwechsel oder nach Ok (o. dgl) mit der Fernbedienung für gewisse Zeit Informationen zur aktuellen und zur nächsten Sendung eingeblendet. Bei meinem MLD 5.3 Client aber klappt das nicht immer. Bei manchen Sendern wird in der Oberfläche "Klassischer VDR" lediglich ein graues Feld mit Datum und Uhrzeit angezeigt. Oder auch nur die nächste, nicht aber die aktuelle Sendung. In den Oberflächen "LCARS" und "ST:TNG-Konsolen" tritt das Problem nicht auf.

Die Programmdaten werden mit dem Plugin epgsync vom Server geholt. Unter //Programm// sind im OSD alle Informationen verfügbar. Unter System > VDR Setup > Plugins -> epgsync habe ich den Wert für "Jetzt" und "Nächste" zuerst Nein auf Ja gesetzt. Das hat aber nicht geholfen.

An welcher Schraube sollte ich drehen?

Gruß, maf

5
Danke für den Hinweis. Ich habe festgestellt, dass auch im Paket libcec1 eine Datei /usr/bin/cec-client enthalten ist, ohne dass ein Konflikt mit cec-utils eingetragen wäre. Installiert habe ich cec-utils und nun funktioniert der Start aus dem Suspend. Vielleicht eine Abhängigkeit von oder Empfehlung für cec-utils in suspend eintragen?

6
Hallo,
benötige hier für libcec-daemon ebenfalls libcec3.
Da

Die Binärpakete sind weiterhin vorhanden, libcec3 könntest Du z.B. mit
Code: [Select]
apt-get install libcec3installieren.

7
Wen es die in der 5.4 nicht mehr gibt, dann werden die da nicht mehr benötigt.

Die Git-Archive für Pakete, die in MLD 5.4 nicht mehr enthalten sind, werden rückstandslos gelöscht? Also sind z.B. die "Bauanleitungen" für libcec3 und libcec4 nirgendwo mehr verfügbar?

8
Was bedeutet es denn, dass in MLD 5.3 Pakete libcec3 und libcec4 verfügbar sind, aber nicht im aktuellen MLD Git? Habt ihr die Pakete im Git gelöscht, weil sie in MLD 5.4 nicht mehr benötigt werden? Und falls ja, finde ich die noch irgendwo anders?

9
Ich habe mir das Skript /sbin/suspend.soft angeguckt, von dem ich vermute, dass es beim Suspend ausgeführt wird (zumindest, wenn die Methode suspend.soft wie bei mir ausgewählt ist).

Das Skript benutzt /usr/bin/cec-client, um dem Fernseher Kommandos zum Aus- und später wieder zum Einschalten zu schicken. Dieses Programm existiert auf meinem Rechner allerdings nicht. Erstaunlich, dass der Fernseher trotzdem ausgeschaltet wird. Vielleicht eine Serviceleistung der HDMI-Verbindung?

Unter MLD 5.0.0 auf meinem alten Client gibt es das Programm /usr/bin/cec-client. Es gehört zum Paket libcec2. Dieses Paket gibt es jedoch in MLD 5.3 nicht mehr. Stattdessen ist libcec4 installiert, das aber keine Datei /usr/bin/cec-client enthält. Außerdem existieren noch Pakete libcec1 und libcec3, die aber nicht installiert sind. Und im aktuellen Git-Archiv von MLD finde ich nur libcec1 und libcec2. Verwirrend...

In welchem Paket von MLD 5.3 befindet sich /usr/bin/cec-client?

10
Hallo,

ich habe unter MLD 5.3 auf einem Raspberry Pi das Paket suspend installiert. Nun kann ich mit der Fernbedienung den Client in den Ruhezustand versetzen, d.h. das Programm vdr vorübergehend beenden. Der angeschlossene Fernseher, ein Samsung UE55H6270, wird dabei ausgeschaltet.

Ich kann den Client, d.h. vdr, auch mit der Fernbedienung wieder reaktivieren. Nur leider wird dabei der Fernseher nicht wieder eingeschaltet. Den muss ich mit seiner eigenen Fernbedienung einschalten.

Mit MLD 5.0.0 habe ich das Problem nicht, der Fernseher schaltet sich "von alleine" wieder ein. Was sollte ich unter MLD 5.3 tun?

Gruß, maf

11
Ansonsten schreib doch mal dein Patch hier rein, oder schick uns den zu. Dann schauen wir es uns an.

Ich habe meinen Patch in einem eigenen Thread zur Diskussion gestellt.

12
Entwicklung [ Development ] / Patch für Plugin svdrpservice
« on: June 19, 2019, 12:28:12 »
Vor einem guten Jahr habe ich über Probleme im OSD bei der Kommunikation zwischen Client und Server berichtet. Zum Beispiel ließ sich ein Timer auf dem Server nicht (de)aktivieren. Damals ging es noch um MLD 5.0. Doch nach dem Wechsel zu MLD 5.3 musste ich feststellen, das die Probleme weiterhin bestehen.

Zunächst dachte ich, es läge am Plugin remotetimers. Mittlerweile weiß ich, dass das Plugin svdrpservice den Fehler verursacht. Damit betrifft er viele Plugins auf dem Client, die mit dem Server kommunizieren, und dürfte auch für MLD 5.4 interessant sein, in dem wegen des Wechsels zu VDR 2.4.0 das Plugin remotetimers nicht mehr benötigt wird.

Ursache der Kommunikationsprobleme ist, dass der Server recht zügig die SVDRP-Verbindung beendet, wenn der Client sich nicht mehr meldet, und dem Client eine entsprechende Nachricht schickt. Der Client ignoriert jedoch den Timeout und hält fälscherweise die Nachricht des Servers (bzw. deren Reply Code) für die Antwort auf seine nächste Anfrage, ohne diese überhaupt abgeschickt zu haben.

Mit folgendem Patch server-timeout.patch habe ich das Problem für mich gelöst:
Code: [Select]
--- a/connection.c
+++ b/connection.c
@@ -192,7 +192,7 @@
        if (!Cmd)
                return false;

-       if (Reconnect && !file.IsOpen())
+       if (Reconnect && (!file.IsOpen() || ReceivedTimeout()))
                Open();
        if (!file.IsOpen()) {
                esyslog("svdrpservice: unable to send command to %s. Socket is closed", serverIp);
@@ -240,6 +240,18 @@
        return 0;
 }

+bool cSvdrpConnection::ReceivedTimeout() {
+       if (file.Ready() && ReadLine(0)) {
+               long int code = ::strtol(buffer, NULL, 10);
+               if (code != 221) {
+                        esyslog("svdrpservice: unexpected message from %s: '%s'", serverIp, buffer);
+               }
+               file.Close();
+               return true;
+       }
+       return false;
+}
+
 bool cSvdrpConnection::ReadLine(int TimeoutMs) {
        if (!file.IsOpen())
                return false;
--- a/connection.h
+++ b/connection.h
@@ -26,6 +26,7 @@
                bool            shared;

                int             Connect();
+               bool            ReceivedTimeout();
                bool            ReadLine(int TimeoutMs);
        public:
                cSvdrpConnection(const char *ServerIp, unsigned short ServerPort, bool Shared);

Ich würde mich freuen, wenn das MLD Team den Patch testen und im Erfolgsfall eine neue Version des Plugins für MLD 5.3 (und MLD 5.4) bereitstellen könnte

13
Wenn Du die Sourcen des Plugins mit eincheckst, dann müssen da drin bereits alle Patches angewendet sein. Wenn Du trotzdem Patches dazu packst, dann dient das lediglich der Dokumentation.
Normalerweise checken wir die Sourcen nicht mit ein. Das wird nur bei einigen wenigen Plugins gemacht, bei denen die Sourcen nicht zuverlässig verfügbar sind, oder nicht unter einer festen URL abrufbar sind.

Verstanden. Dann habe ich bei vdr-plugin-svdrpservice einfach nur "Pech gehabt", ein Plugin mit eingecheckten Sourcen zu erwischen.

14
Ich habe nun doch Docker auf einem Raspberry Pi 3 unter Raspbian Stretch benutzt, um eine Enwicklungsumgebung für MLD 5.3 aufzubauen. Dazu benutze ich drei Dateien. Mit raspbian-jessie.Dockerfile wird ein Image für Jessie erstellt:
Code: [Select]
FROM arm32v7/debian:jessie
MAINTAINER MLD Team <team@minidvblinux.de>

ARG DEBIAN_FRONTEND=noninteractive

# Add Raspbian repositories
RUN apt-get update \
 && apt-get install -y wget \
 && wget -O - -q https://archive.raspbian.org/raspbian.public.key | apt-key add - \
 && echo 'deb http://raspbian.raspberrypi.org/raspbian/ jessie main' \
    > /etc/apt/sources.list.d/raspbian.list \
 && wget -O - -q https://archive.raspberrypi.org/debian/raspberrypi.gpg.key | apt-key add - \
 && echo 'deb http://archive.raspberrypi.org/debian/ jessie main ui' \
    >> /etc/apt/sources.list.d/raspbian.list

# Update and upgrade
RUN apt-get update \
 && apt-get dist-upgrade -y

Mit mld53-rpi.Dockerfile wird basierend auf dem Image mit Jessie ein Image für eine Entwicklungsumgebung für MLD 5.3 erstellt:
Code: [Select]
FROM maf/raspbian:jessie
MAINTAINER MLD Team <team@minidvblinux.de>

ARG DEBIAN_FRONTEND=noninteractive

# Update und benötigte Pakete installieren
RUN apt-get update \
 && apt-get dist-upgrade -y \
 && apt-get install -y \
    make git-core software-properties-common locales locales-all g++

# MLD Pakete holen und auf Version 5.3 umstellen
COPY Makefile.adjust /tmp/Makefile.adjust
RUN git clone http://minidvblinux.de/git-5/MLD.git MLD \
 && cd MLD \
 && echo ".SILENT:\nCLASS = stable" > Makefile.config \
 && git checkout 5.3 \
 && cat /tmp/Makefile.adjust >> Makefile.git \
 && rm /tmp/Makefile.adjust \
 && make checkout_base \
 && make adjust_version_all

# Abhängigkeiten der MLD Pakete installieren
RUN cd MLD \
 && apt-get install -y $(make deps)

# Platz freigeben
RUN apt-get autoremove -y \
 && apt-get autoclean -y

In das Image für MLD 5.3 geht noch die Datei Makefile.adjust ein:
Code: [Select]

# Version aller Module an Version von MLD anpassen
adjust_version_all:
        ls | while read package; do \
                if [ -e "$$package/.git" ]; then \
                        echo -e "$(color_green)$$package$(color_reset)"; \
                        $(MAKE) adjust_version name=$$package; \
                fi; \
        done

# Version eines Moduls an Version von MLD anpassen
adjust_version:
        if [ -e "$(name)/.git" ]; then \
                git -C $(name) rm --force --cached --ignore-unmatch .gitignore; \
                git -C $(name) checkout --force $$(git -C $(name) rev-list -n 1 --first-parent --before=$$(git log -1 --format='%at') master) &>/dev/null; \
        else \
                echo -e "$(color_red)unknown package $(name)$(color_reset)"; \
        fi
Die beiden Ziele in diesem Makefile werden an Makefile.git angefügt. Mit
Code: [Select]
make checkout_all; make adjust_version_all bzw.
Code: [Select]
make checkout name=PACKAGENAME; make adjust_version name=PACKAGENAME können dann alle oder ein einzelnes Paket auf den Versionsstand von MLD 5.3 zurückgesetzt werden. Dazu wird das letzte Commit eines Pakets vor dem aktuellen Commit von MLD ausgecheckt.

15
Danke für Deine Hinweise.

Die Regel in Makefile.plugin sieht eigentlich vielversprechend aus:
Code: [Select]
src/$(pluginname)-%:
        if [ -n "$(src_url)" ]; then \
                $(MAKE) -f ../Makefile.getfile file=src/$(name).tgz version=$(version) url='$(src_url)'; \
        else \
                $(MAKE) -f ../Makefile.getfile file=src/$(name).tgz version=$(version) rule='$(src_rule)'; \
        fi
        rm -rf $@ $@-src
        mkdir -p $@-src
        tar xf src/$(name).tgz -C $@-src
        mv $@-src/* $@
        rm -r $@-src
        ln -fns $(@F) src/$(pluginname)
        $(MAKE) patch src_path=$@ src_name=_$(pluginname)_
Aber das Verzeichnis src/$(pluginname)-% wird bereits im Zuge von 'make checkout' angelegt, die Regel deshalb nie angewandt.

Ich habe es deshalb mit
Code: [Select]
make patch src_path=$PWD/src/PACKAGENAME-PACKAGEVERSIONversucht. Das funktioniert zwar, sieht aber nicht wie die "richtige" Lösung aus.

Ich suche also immer noch nach allgemeingültigen Vorgehensweise: Wie kann man dafür sorgen, dass ein Patch, den man nach dem 'make checkout' in das Verzeichnis src kopiert, beim Erstellen des Pakets angewandt wird?