Das ging ja schnell!
Ist perfekt so fuer mich, sogar die Einstellung war automatisch richtig (vorher 'ja', jetzt 'in breiten Menues').
Vielen Dank,
S:oren
Beiträge von S:oren
-
-
Bin jetzt mal zum Testen der neuen Skin-Version gekommen. Vielen Dank.
Display scroll bar also if content is not scrollable
Das gefaellt mir sehr gut fuer breite Menues, fuer schmale (insbesondere das Hauptmenue) aber eher nicht so. Koennte es Sinn ergeben, das getrennt einstellbar zu machen? Ansonsten kann ich mir das auch so zurecht patchen, wie ich es brauche.
Gruss,
S:oren
-
Das wird wohl notwendig sein.
Nicht laut Doku von TT.
Keine Ahnung haben, aber die einfachsten Sachen von vornherein ausschliessen. Prima Strategie.
Was soll's, warum ich auch immer wieder versuche zu helfen. Bewunderung an Leute wie kamel5 , die die Geduld immer noch aufbringen...
Gruss,
S:oren
-
leider sacht mit Bonding überhaupt nix.
vdr/INSTALL:
CodeIf DVB-S devices need to be connected to the same satellite cable, but no "Satellite Channel Routing" is available, they can be set to be "bonded" in the Setup/LNB menu. Bonded devices can only be tuned to the same polarization and frequency band, which reduces the number of potentially receivable channels.Vielleicht kann das jemand besser erklaeren, der es auch nutzt. Von oben:
Ich habe z.B. ein Problem beim Bonding...
Gruss,
S:oren
-
Hrmpf, frontend 1/0 ist der zweite Tuner der Karte, der ist nicht angeschlossen (und war es auch noch nie).
Warum wird der denn jetzt seit Neuestem angemault - da kann ja garkein Signal kommen.
Offiziell ist es wohl so, dass der zweite Tuner das Signal vom ersten uebernehmen soll, wenn kein zweites Kabel angeschlossen ist. Den Modus habe ich nie benutzt. War eher ein Stoerfaktor, weil ohne zweites (funktionierendes) Kabel doch manchmal Empfang war. Natuerlich nur, wenn Hi/Lo-Band und Polarisation zufaellig stimmten. Was man per Bonding einstellen muss, sollte man den Single-Kabel-Modus nutzen wollen.
Jetzt nicht direkt eine Antwort auf das aktuelle Problem, aber vielleicht waere Bonding einfacher als verschobene Devices. Keine Garantie, dass der Single-Kabel-Modus wirklich zuverlaessig ist.
Gruss,
S:oren
-
kann ich die SAT-Tuner deaktivieren (zugunsten Kanäle via von streamdev-client) und die Ausgabe trotzdem via dvbhddevice (S2-6400) machen?
Klar, das dvbhddevice-Plugin hat sogar eine Option --outputonly, damit die ungenutzten Tuner nicht 'im Weg' sind.
Gruss,
S:oren
-
Diese Funktionalität, einen definierten Entwicklungszustand sicher und mit wenig Aufwand (wieder)herstellen zu können, ist für mich eigentlich einer der Hauptgründe so ein System wie Git überhaupt zu verwenden.
Aber nicht fuer eine riesige Community wie bei Linux. Wieviele alte kaputte Zwischenstaende will man denn oeffentlich aufheben? Warum? Wer soll sich da durchfinden? Der Entwicklungsprozess ist in den Mailing-List-Archiven dokumentiert.
Das Prinzip der Git-Entwicklung ist gerade, in unabhaengigen Development-/Topic-Branches Fixes und Features zu entwickeln, Patches solange zu verbessern, umzusortieren und anzupassen, bis alle Reviewer zufrieden sind. Rebase ist das Hauptwerkzeug bei der Entwicklung, das ist der groesste Vorteil von Git gegenueber alten Versionskontrollsystemen wie cvs/svn/hg. Und man kann sich lokal beliebig viele Branches von welchen-Zwischstaenden-auch-immer hinlegen, sogar aus verschieden remote-Repos zusammen im selben lokalen git. Natuerlich hat Git auch sonst noch viele weitere Vorteile fuer grosse Projekte: Pull statt Push fuer Master-Repositories mit (implizitem) Review und der Moeglichkeit von Merge-Commits mit Zusatzinformationen, Bisect zum Debugging und anderes mehr.
Der einzelne Entwickler wird vermutlich seine Zwischenversionen privat aufheben, die Oeffentlichkeit ist sicher fuer eine Muellabfuhr dankbar. Wenn man das System nicht verstanden hat, muss man sich nicht unbedingt zuerst ueber Leute aufregen, die mehr Erfahrung und vielleicht auch Durchblick haben.
Gruss,
S:oren
-
Keine Ahnung was die da machen, ...
Was sie immer machen, rebasen. Immutable Trees gibt es nur unter ganz besonderen Umstaenden in Development-Repos.
-
Da sowohl Du, als auch das Wiki die Karten als identisch bezeichnet haben
Hab ich eben nicht. Meine Formulierung war
anscheinend baugleich
was eben (vermutlich) gleiche Hardware, aber andere IDs bedeutet.
Und wenn der "SAA716x TT-budget driver" nur an die PCI-ID 13c2:3010 bindet, das funktioniert (nur der zugehoerige Frontend-Treiber laesst sich nicht uebersetzen), warum sollte es mit der gleichen ID beim TBS-Treiber nicht gehen?
Aber meine Hilfe ist ja anscheinend sowieso nicht gefragt, andere glauben wieder mal, es besser zu wissen.
Gruss,
S:oren
<EOT>
-
Ich habe die "tbs-linux-drivers_v170330.zip" herunter geladen. Sie trägt das Datum des Downloads. Die Dateien im Archiv sind aber viel älter, teilweise von 2011.
Nun ja, das heruntergeladene Archiv hat immer das Datum des Downloads. Treiber-Dateien werden nie _alle_ fuer ein neues Release ueberarbeitet.
Und ich habe auch eine tbs-open-linux-drivers_v20221231.zip heruntergeladen, da sind teilweise Dateien mit Datum vom Februar drin, also offenbar nochmal neuer als das Datum im Archivnamen suggeriert.
Aber wenn Du lieber ueber Zeitstempel diskutieren und eben keinen neuen Thread eroeffnen willst, ich muss meine Hilfe nicht irgendjemandem aufdraengen.
Da die Karte TBS6922 anscheinend baugleich zur S2-4100 ist, sollten die Treiber von TBS auch fuer die S2-4100 funktionieren (jedenfalls steht das so im Treibercode von TBS).
Vorher aber bitte die Subsystem-ID vergleichen, ob es sich wirklich um eine TBS6922 handelt.
Wenn die nicht übereinstimmt, wird die Karte nie erkannt werden.
Schoen dass Du mir unterstellst, ich wuesste nicht, wovon ich rede. Ich habe im Code von TBS jedenfalls das gefunden (Ausschnitt):
Codestatic struct pci_device_id saa716x_budget_pci_table[] = { MAKE_ENTRY(TURBOSIGHT_TBS6922, TBS6922, SAA7160, &saa716x_tbs6922_config), MAKE_ENTRY(TECHNOTREND, TT4100, SAA7160, &saa716x_tbs6922_config), { } };Der Treiber bindet explizit mit der selben Config fuer TBS6922 und fuer TT4100. Also wird die S2-4100 auch mit ihrer eigenen ID erkannt.
Danke fuer nichts,
S:oren
-
habe ich gemacht, funktioniert auch nicht. Zu alt.
Zu alt kann ich mir nicht vorstellen, was ich heruntergeladen hatte war ~4 Wochen alt.
Mach am besten ein neues Thema auf.
-
Das ist doch alles genau das, was ich oben geschrieben habe. Mein saa716x-Treiber unterstuetzt die S2-4100 nicht, was nicht an der SAA7160-Bridge liegt, sondern an der nicht vorhandenen Unterstuetzung fuer die verwendeten Frontends in Mainline. Egal wie lange Du verschiedene Kernel ausprobierst, in der jetzigen Form wird mein saa716x-Treiber nicht mit Deiner S2-4100 funktionieren -> Zeitverschwendung.
Von Technotrend (wer auch immer heutzutage unter diesem Namen auftritt) gibt es diesen Fork des saa716x-Treibers ("SAA716x TT-budget driver") mit dem closed-source-Frontend-Modul tt_s2_4100_drv. Weil es keine oeffentlichen Sourcen dazu gibt, kann man dieses Modul nicht fuer neuere Kernel oder andere Prozessorarchitekturen kompilieren. Und dann kann man vielleicht einen Basistreiber fuer die SAA7160-PCIe-Bridge laden, einen DVB-Datenstrom wird man ohne Frontend-Treiber nicht aus der S2-4100 herausbekommen. Ich empfehle: Finger weg! (Oder halt bei alten Kerneln bleiben, fuer die es diese Binaermodule gibt.)
Da die Karte TBS6922 anscheinend baugleich zur S2-4100 ist, sollten die Treiber von TBS auch fuer die S2-4100 funktionieren (jedenfalls steht das so im Treibercode von TBS). Ich kenne mich mit den TBS-Treibern nicht naeher aus und will keinen Support dafuer leisten. Aber dort gibt es auf den ersten Blick auch Sourcecode fuer Tuner und Demod der Karte (tas2101, av201x). Also die TBS-Treiber fuer die S2-4100 zu verwenden sieht mir nach der vielversprechendsten Loesung aus, wenn man neuere Kernel verwenden will. Versuch macht 'kluch'.
Mehr kann ich hier auch nicht helfen. Und nun bitte nicht weiter diesen Thread mit S2-4100-Diskussionen zumuellen. Das hat nichts mit dem Bauen meines saa716x-Treibers unter 22.04 zu tun.
Gruss,
S:oren
-
Kernel 4.4 (weiter unten im Thread) ist ja auch schon recht alt, und es ist der Mist mit dem closed-source-Modul. Ich wuerde moeglichst die Finger davon lassen...
-
Das Problem ist dabei nicht die SAA7160-Bridge, sondern das closed-source Frontend-Modul.
Soweit, so schlecht. Aber:
Anscheinend unterstuetzt der Treiber fuer die TBS6922 auch die (baugleiche?) S2-4100. Von TBS scheint es auch passende Frontend-Treiber (tas2101, av201x) zu geben. Also vielleicht mal damit probieren...
Gruss,
S:oren
PS: Sorry, ist ja alles off-topic hier...
-
Der saa716x-Treiber, um den es hier geht, hat keinen Support fuer eine S2-4100.
Anscheinend hat ein "Konstantin Dimitrov" einen "SAA716x TT-budget driver" fuer so eine Karte gebaut. Das ist aber ein ganz anderer Treiber.
Gruss,
S:oren
-
es fehlt ein Modul "tt_s2_4100_drv"
So ein Modul ist kein (und war nie) Bestandteil des saa716x-Treibers.
Gruss,
S:oren
-
Wenn dir der Name nicht zusagt, mach bei Zeiten einen Gegenvorschlag.
Ich habe alles geschrieben, was ich dazu zu sagen habe.
Eine einmalige, winzige Anpassung der Plugins halte ich dafür für vertretbar.
Bin mal gespannt, was die ganzen Distris dazu sagen, wenn ihr Quellcode der Plugins nicht mehr kompiliert. Ich habe da eine Vermutung: Kaputt, kann weg.
Mir ging es immer um die User, die nicht alles selber bauen, sondern alles komplett fertig und funktionsfaehig zentral bekommen wollen. Wenn man alles noch funktionsfaehige wegwerfen und von vorne anfangen will, von mir aus.
Die einzige Chance, die ich sehe ist, das auf dem kleinen Dienstweg durch zu kriegen.
Private APIs hingegen sind Teil des Treibers, für deren Inhalt ist primär Maintainer vom Treiber zuständig
.Der Du dann bist!?
Komplett ohne Ironie: Viel Glueck, Spass, und vor allem Erfolg damit.
Gruss,
S:oren
-
Woher nimmst du das, dass die FF-Treiber nicht zurück kommen? Hat Hans doch explizit geschrieben.
Richtig, er hat explizit geschrieben "av7110 stays in staging for now", was man in dem Pull-Request auch direkt sehen kann.
-
Der Vorschlag wird 99% deiner Forderung erfüllen, sollte er angenommen werden.
Ueberhaupt nicht. Wenn das DVB-API nicht mehr Userspace-API ist, sondern ein privater Header, dann ist das Unfug. Es waere auf jeden Fall auch eine Anpassung der Output-Plugins noetig, die ganze Idee einer einheitlichen und standardisierten Treiberschnittstelle (DVB-API) ist damit tot.
Warum man nun unbedingt dafuer streiten will, ohne Not, kann ich nicht nachvollziehen.
Aber auch egal, da ja nun die tatsaechliche Absicht ans Licht gekommen ist, den av7110 heimlich zu entfernen ("I have not really been involved in the move of av7110 to staging,..."). Man unterschreibt also Patches, die anscheinend untergeschoben sind. Grossartige Arbeitsweise. Und die FF-Treiber kommen, nach jetzigem Stand, eben nicht wieder zurueck. Was daran "Great news" sind, kann ich auch nicht nachvollziehen.
Aber wie schon mehrfach hier geschrieben, mir auch recht, ich bin dann 'raus...
Gruss,
S:oren
-
Du schätzt den Aufwand für die Umstellung DVB > V4L also bedeutend grösser / invasiver ein als VB1 > VB2?
Mindestens 20fach, vermutlich deutlich mehr. Haengt ja auch ein neues Ausgabeplugin dran. Die Versprechungen von V4L2, dass alles kompatibel ist, scheinen ja nicht so recht zu stimmen, bei der grossen Anzahl verschiedener softhddevices. Das selbe nochmal fuer die enigma2-Leute, da kenne ich mich aber nicht aus.
Wesentlich mehr Leute werden es aber nicht werden, so realistisch muss man sein.
Vielleicht reicht ja _eine_ Frage wie bei Budget-Karten. Ob es nur reicht, wenn sie von einem grossen Distributor kommt, keine Ahnung.
Ansonsten: Wer es noch nicht gemerkt hat, ich mache das alles nicht fuer mich. Wer von den Treibern profitieren will, kann ja wohl mindestens mal sein Interesse aeussern. Und nicht immer nur: "Ich wuerde ja gerne, kann aber nicht programmieren...", darum geht es nicht.
Anscheinend haben die Entscheidungsträger bei linux-media nicht wirklich Ahnung, was DVB angeht.
Fuer Mauro trifft das meines Erachtens voll und ganz zu. Hans gibt sich ja zumindest Muehe, vielleicht kommt man mit ihm bei linux-media wieder zu einer Arbeitsweise, wie sie in allen anderen Kernel-Subsystemen ueblich ist. Wieviel er jetzt und in Zukunft hier zu sagen hat, kann ich nicht einschaetzen. Dass er sich jetzt auch um DVB kuemmert, ist fuer mich jedenfalls ein sehr gutes Zeichen. Vielleicht arbeitet er ja mit der Community, statt gegen sie. Ich habe jedenfalls nichts gesehen, was dagegen spricht.
Gruss,
S:oren
