Posts by kamel5

Hallo,

neue Version 1.2.10:

- Update remotetimers.h

- Simplify cRecMenuSearchTimerEdit::GetSearchTimer

- Fixed cRecMenuItemSelectDirectory::DrawValue

- Some rework

Link dazu im ersten Post.

Gruß

kamel5

Hallo,

neue Version 1.2.9:

- Correct plugin options in README and CommandLineHelp

- Change locking in cTVGuideSearchTimer::cTVGuideSearchTimer

- Fixed a dayOfWeek error in RecMenuSearchTimerEdit

Link dazu im ersten Post.

Gruß

kamel5

Hallo,

marco wrote:

eine Segfault Meldung bekommen.

Ja, das hatte ich auch schon mal. Da ich mich mit dem Teil des Plugins bisher noch nicht beschäftigt habe, kann ich dazu auch im Moment keine Aussage treffen, wenn da jemand eine Idee hat...

Da hier auch kein Neukompilieren des Plugins geholfen hat, habe ich das im Moment bei mir mit einem Downgrade von graphicsmagick auf Version 1.3.30 gelöst.

Bei Fedora dazu einfach ein "dnf downgrade graphicsmagick*" machen und dann natürlich das nächste Update unterdrücken. Dann läuft es wieder.

Da ich bei Fedora schon mehrfach Probleme bei einem ersten Upgrade eines Programmes auf eine neue Version hatte, warte ich jetzt erst einmal ab, was beim nächsten Upgrade von graphicsmagick passiert, bevor ich da Zeit investiere.

Ein Umstellen auf imagemagick kann natürlich auch helfen.

Grüsse

kamel5

Ich stand vor kurzem vor der gleichen Frage und bin dann auch bei gitlab hängen geblieben.

Ja, das ist schon recht umfangreich, es lässt sich aber komfortabel über die Web-Oberfläche bedienen und konfigurieren.

Außerdem ist es Opensource und es gibt Pakete für verschiedene Linux-Distributionen. Es läuft sogar auf einem Raspi, wenn man sonst nichts weiteres mit ihm macht.

Hallo,

ich habe mal das Repo auf https://projects.vdr-developer.org aktualisiert.

Grüsse

kamel5

Hallo,

ich habe mal das Repo auf https://projects.vdr-developer.org aktualisiert.

Grüsse

kamel5

Hallo,

ich habe mal eine Version 2.0.3 mit ein paar Bereinigungen gemacht.

Grüsse

kamel5

carel wrote:

Option “--logodir=<LOGODIR> “ funktioniert nicht.

Das dürfte schon lange nicht mehr funktioniert haben, vielleicht auch noch nie.

Laut Code gibt es diese Optionen:

--epgimages

--iconpath

--logopath

In der Hilfe steht es allerdings falsch, ich werde das da mal mit anpassen.

Grüsse

kamel5

OK, schau ich mir an.

Grüsse

kamel5

Hallo,

neue Version 1.2.8:

- Some refactoring

- Update i18n

- Add almost all search timer options to cRecMenuSearchTimerEdit,

only one is missing: "Use content descriptor"

(Create and modify of channelgroups and blacklists isn't possible,

because the epgsearch service interface doesn't support that,

should be done in epgsearch)

Link dazu im ersten Post.

Gruß

kamel5

.

nobanzai wrote:

Ich kann ja schlecht den Patch, der gegen einen ganzen Kerneltree laufen würde, gegen das bisschen Sourcecode werfen

Das ist eigentlich kein Problem, da der Patch hauptsächlich neue Dateien hinzufügt, Wenn Du Dein src.rpm auspackst, hast Du ja auch die saa* Dateien.

Wenn Du z.B. in einem leeren Ordner das

patch -p1 < saa716x-4.12.diff

eingibst, macht er dann sowas: Das Beispiel ist für einen Kernel 5.1

Alle Meldungen bestätigst Du einfach mit Enter.

Hier siehst Du 1. welche Dateien er zu ändern versucht: +++ b/drivers/media/pci/Makefile und nicht findet. Die muss man sich dann separat nochmal anschauen.

Und 2. legt er den Treiber komplett an unter drivers/media/pci/saa716x/.

Und diese Dateien kannst Du doch einfach mit dem Inhalt Deines rpm vergleichen.

Außerdem sollte es doch auch Fehlermeldungen beim Bauen des rpm geben, die sagen doch manchmal auch schon was aus.

nobanzai wrote:

Die vorherige Methode, dass man ein Modul außerhalb des Kerneltrees übersetzt, existiert dann nicht mehr?

Das kann man so nicht sagen. Es gibt eigentlich keinen Grund warum das nicht mehr gehen sollte.

Du musst halt mal schauen, ob der Inhalt Deines src.rpm zu einem aktuellen Patch passt.

Kernel 4.4 ist ja auch schon eine Weile her und wenn ich mich richtig erinnere, sind seit dem geringfügige Anpassungen am Treiber gemacht worden.

Zu openSUSE selbst kann ich leider nichts sagen.

Aus dem genannten Git kannst Du sowohl einen kompletten Kernel, wie auch einen Patch für einen bestimmten Kernel laden.

Wenn Du z.B. einen Patch für 4.12 brauchst, musst Du das so machen:

wget -O saa716x-4.12.diff https://github.com/s-moch/linux-saa716x/compare/v4.12...saa716x-4.12.diff

Wenn Du einen kompletten Kernel lädst und übersetzt, bekommst Du einen kompletten Vanilla-Kernel mir saa726x-Support.

Wenn Du allerdings den Patch nimmst und den zu Deinen passenden Kernel-Sourcen dazu tust, brauchst Du nur die paar zusätzlichen Module übersetzen und zu den vorhandenen Modulen dazu kopieren, was wesentlich schneller geht.

Hallo,

na ja, da gibt es keine definitive Aussage. Das hängt ganz davon ab welche Distribution Du verwendest.

Den Treiberpatch bekommst Du hier:

https://github.com/s-moch/linux-saa716x

Und dann musst Du diesen Patch mit einem Kernel-Source Deiner Wahl verheiraten.

Für verschiedene Distris gibt es auch Anleitungen hier im Forum.

Gruß

kamel5

Hallo,

das Ganze ist doch etwas merkwürdig.

Ich habe jetzt mal mit dem aktuellen SOURCE-rpm von Fedora einen kompletten Kernel mit allen Patches von Fedora gebaut.

Damit wird auch der TT6400-Treiber wieder geladen:

Das bedeutet wohl, das das ausgelieferte Kernel-Binary-RPM von Fedora doch noch etwas anders macht als das SOURCE-RPM widerspiegelt, zumindest mit meiner Hardware.

Ich werde wohl erst einmal den Kernel in größeren Abständen selbst kompilieren und hoffen, das sich das irgend wann mal von selbst erledigt, denn ich wüsste jetzt nicht, was ich da noch tun könnte.

Grüsse

kamel5

Hallo marco ,

Du nutzt die TT6400 Mit Fedora Kernel 5.1 ohne Probleme?

Bei mir kommt da eine Fehlermeldung, siehe ersten Post.

Was nutzt Du für eine Hardware-Basis?

Gruss

kamel5

S:oren wrote:

Vielleicht findet sich ja noch eine einfache Erklaerung. Ansonsten ist leider 'git bisect' angesagt...

Zum Glück hat sich gezeigt, das es kein git bisect auf den Vanilla-Kernel braucht.

Damit sieht es so aus:

Fedora hat für seine Distro noch zusätzlich 36 Patche eingespielt.

Ich werde mal versuchen herauszufinden, welcher von denen diese Auswirkungen hat.

Das wird aber etwas länger dauern, da meine dafür benutzte Hardware doch etwas braucht, um einen vollständigen Kernel zu kompilieren.

Grüsse

kamel5

Hallo,

sonst niemand diese Kombination im Einsatz?

marco : Du benutzt doch auch Fedora, bist Du schon bei Kernel 5.1?

Ich werde jetzt erst einmal einen Vanilla-Kernel installieren und sehen ob es damit geht, vielleicht liegt es ja an Fedora-spezifischen Sachen.

Gruß

kamel5

S:oren wrote:

Steht in /proc/iomem etwas dazu?

Der Eintrag fehlt.

Anbei mal das cat /proc/iomem von 5.0 und 5.1

Grüsse

kamel5

S:oren wrote:

Hier klappt schon das allererste Mappen des PCIe-Speichers nicht. Da wird noch nichts Karten-spezifisches gemacht.

Kann das an zu alter Hardware liegen?

Ich nutze z.Z. noch ein AM3+ Board aus ca. 2011. Ich habe zwar schon lange mal an ein Hardware-Upgrade gedacht, aber so richtig nötig war das bisher nicht.

S:oren wrote:

Laeuft bei mir mit 5.1.6.

Was nutzt Du da für eine Hardware-Basis?

Gruß

kamel5