Hi *,
seit einiger Zeit habe ich bei allen öffentlch-rechtlichen Sendern, und nur bei denen, doppelte EPG-Einträge.
Einer davon wird durch EPGD aktualsiert, der andere enthält nur die Infos, die im Standard-EPG vorhanden sind.
Wie kann denn sowas passieren?
Thx und ciao.
Michael.
Am Server xine-lib-1.2.9-147.1, am Client xine-lib-1.2.9-149.4.
Hi *,
ich habe nach längerer Zeit mal wieder mit xineliboutput und vdr-sxfe herumgespielt.
Leider bekomme ich nur ein schwarzes Bild am Client und am Server folgende Fehlermeldungen:
vdr[17328]: [17374] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
vdr[17328]: [17374] [xine..put] cXinelibServer: Too many TCP buffer overflows, dropping client
vdr[17328]: [17374] [xine..put] cXinelibServer::Play Write/Queue error (TCP/PIPE)
vdr[17328]: [17374] [xine..put] Closing connection 0
Die Tips bzgl. der Settings in config_xineliboutput (am Client und am Server) habe ich soweit befolgt, hat aber nix geholfen.
Die xineliboutput hat die Version 2.1.0, das Plugin läuft unter vdr 2.4.1.
Hat Jemand ne Idee, was ich noch machen könnte?
Thx.
Ciao.
Michael.
Danke, auch wenn ich's nicht brauche 
Danke für die ausführliche Beschreibung.
Allerdings hört sich das für mich bei meinem Anwendungszweck eher wie ein Rückschritt gegenüber graphtftng an.
Naja, ich werd bei Gelegenheit mal ein wenig damit herumtesten.
Danke!
epg2vdr braucht allerdings tatsächlich einen Patch, wenn man graphtftng nutzt, sonst gibt es Fehler beim Übersetzen.
osd2web habe ich irgendwie verpennt - kann das graphtftng ersetzen und auch gut lesbar auf einem kleinen Gehäuse-TFT Programminfos darstellen? Und das unabhängig vom eigentlichen OSD-Skin?
Hi *,
nachdem vdr-2.4.1 raus ist, habe ich mal wieder versucht herauszufinden, bei welchen Plugins das Plugin selbst oder der VDR noch gepatcht werden muss/sollte, um übersetzt werden zu können, bzw. um danach ihre volle Funktionalität zu haben. Gibt es da eine Übersicht irgendwo? Klar kann man das iterativ selbst herausfinden, aber das ist schon recht mühsam.
Sicher weiß ich, dass GraphTFTNG und EPG2VDR (bei Benutzung von GraphTFTNG) einen Patch für den VDR brauchen. Aber auch da bin ich nicht sicher, ob es da mittlerweile einen neuen Patch gibt. Der, den ich hier habe, ist schon etwas angegraut und matcht auch nicht mehr 100%.
Darüber hinaus wäre es interessant zu wissen, ob die VDR-Patches aus der grauen Vorzeit noch Sinn machen, als da wären:
- vasarajanauloja
- binaryskip
- menusel
- menuselection
- resumereset
...
Ciao.
Michael.
Finally - habs gebacken bekommen.
Und hier meine Vorgehensweise, falls nochmals Jemand in die verlegenheit kommt - Verbesserungsvorschläge sind jederzeit willkommen:
Das Budget-Modul lässt sich allerdings nach wie vor nicht übersetzen - das brauche ich aber auch nicht.
Ne, der make rpm fliegt immer noch raus, diesmal beim Linker:
Ah doch - der make rpm Abbruch hat doch auch was mit dem Patch zu tun.
Da ist er wegen eines Fehlers beim DVB_SAA716X_BUDGET raus geflogen:
Und siehe da, wenn ich das Modul nicht bauen lasse, klappen sowohl der "make -j6 modules" als auch der "make rpm".
Ok, also:
Bis dahin hat alles offenbar geklappt. Beim Patch kamen auch keine Abweisungen.
"make menuconfig" habe ich mir gespart, weil ja beim "make localyesconfig" die Fragen zur saa716X schon kamen.
Beim "make -j6 modules" hats ihn dann allerdings mit etlichen Errors zerlegt:
Das Include-File ist allerdings da:
find . -name tda827x.h
./include/config/media/tuner/tda827x.h
./drivers/media/tuners/tda827x.h
Auch ein kompletter "make rpm" klappt leider nicht:
Das hat allerdings vermutlich eher was mit openSUSE als mit deinen Patches zu tun.
Trotzdem bin ich an der Stelle mit meinem Latein am Ende 8-<
Ciao.
Michael.
Alles klar, macht Sinn.
Dann werde ich mal den Weg nehmen, den du so schön beschrieben hast.
Thx again!
Display MoreKoennte man so sagen, exakt 95 Patches...
Bitte immer nur komplette Kernel-Sourcen verwenden. Die gibt es ganz sicher auch von SuSE.
Die letzte Anfrage, den Treiber fuer Suse zu bauen, kam von kls, siehe hier.
Gruss,
S:oren
Danke für deinen Tip.
Ich hatte allerdings irgendwie immer noch gehofft, man könnte das Ganze außerhalb des Distro-Source-Tree so bauen wie vorher.
Da wurde das dann als weak-update Modul installiert und wurde genutzt, selbst wenn ein neuer Kernel derselben Hauptversion installiert worden war.
Man musste also nicht bei jedem kleinen Update wieder zu patchen und übersetzen anfangen.
Ciao.
Michael.
Ich versuch mal, ob ich da weiter komme.
Danke nochmals!
[...]
Du musst halt mal schauen, ob der Inhalt Deines src.rpm zu einem aktuellen Patch passt.
[...]
Das ist dann so ca. der Punkt, wo ich aussteige 8-<
Ich hab zu wenig Ahnung, um a) beurteilen zu können, ob das zusammenpasst und b) was ich tun müsste, wenn es denn doch passen würde.
Ich kann ja schlecht den Patch, der gegen einen ganzen Kerneltree laufen würde, gegen das bisschen Sourcecode werfen, das in den src.rpms drin war. Die waren nur ca. 250 KB groß.
Danke aber trotzdem für deine Antworten!
Ciao.
Michael.
Die vorherige Methode, dass man ein Modul außerhalb des Kerneltrees übersetzt, existiert dann nicht mehr?
Das war ja bei den vorherigen src.rpms das Schöne. Man hat das src.rpm installiert, hat einen rpmbuild gemacht und konnte dann ein fertiges rpm mit dem Modul installieren.
Danke dir!
Ich hab hier ne openSUSE.
Auf der 42.3 lief alles, bzw. mit deren 4.4er Kernel läuft auch noch alles.
Mit der 15.1 und deren 4.12er Kernel bekomme ich die src.rpms nicht mehr übersetzt, was mit dem 4.4er Kernel der 42.3 noch ohne Probleme geklappt hat.
Ich habe - meine ich - alles hier aus dem Forum schon gelesen, wenn auch vermutlich nicht abschließend verstanden 8-<
Der Link, den du da genannt hast, verweist auf komplette Kerneltrees - für mich wäre dann der 4.12er davon richtig, gehe ich davon aus.
Den hatte ich auch schon runter geladen, aber danach fehlt mir der nächste Step.
Du schreibst, ich müsste "diesen Patch mit einem Kernel-Source Deiner Wahl verheiraten." - aber das heruntergeladene Paket ist doch schon ein kompletter Kerneltree!?!? Irgendwie steh ich da auf dem Schlauch 8-(
Hi *,
nachdem ich mir jetzt einen Wolf gelesen habe, aber immer noch keine definitive Aussage gefunden habe, frage ich mal direkt:
Was ist denn die aktuell funktionierende Vorgehensweise, wenn man für ein neues System mit Linux 4.x oder 5.x den Treiber für die TT S2-6400 benötigt?
Wo bekommt man den her und wie baut man ihn am einfachsten?
Danke euch.
Ciao.
Michael.
Display Morekein Problem so hatte ich es auch nicht aufgefasst wollte nur das Ziel verstehen.
Das könnte man machen aber nicht mit nur einer Tabellen Liste, es gibt eine Gruppe die immer gedropt wird und eine andre nur auf wunsch.
Dann noch eine Gruppe von Tabellen mit User Eintellungen die noch seltener gedropt werden sollen und dann noch eine mit vermutlich überschneidender Menge an Tabellen welche man vermutlich vorher sichern möchte.
Finde es für mich so recht einfach zu pflegen.
Ok 
nein hab ich eigentlich nicht vor, welchen Vorteil hätte das beim verwenden?
War nur so ne Idee, wollte dir nicht zu nahe treten.
Beim Verwenden ist es nicht von Vorteil, aber evtl. beim Pflegen des Codes und beim Lesen durch Dritte.
Ciao.
Michael.
