Philips - Kanal nicht verfügbar Problem!

[Npq]

Vorschlag zur Güte:

Code: Alles auswählen

Index: Makefile
===================================================================
RCS file: /cvs/tuxbox/driver/dvb/drivers/media/dvb/avia/Makefile,v
retrieving revision 1.72
diff -c -r1.72 Makefile
*** Makefile	12 Sep 2003 03:01:51 -0000	1.72
--- Makefile	16 Nov 2003 18:58:08 -0000
***************
*** 16,21 ****
--- 16,25 ----
  EXTRA_CFLAGS	+= -DDEBUG
  endif
  
+ ifeq ($(EXPERIMENTAL), 1)
+ EXTRA_CFLAGS	+= -DEXPERIMENTAL
+ endif
+ 
  ifeq ($(STANDALONE), 1)
  obj-m		+= $(AVIA_AV_MODS) $(AVIA_GT_MODS)
  EXTRA_CFLAGS	+= -DSTANDALONE
Index: avia_gt_dmx.c
===================================================================
RCS file: /cvs/tuxbox/driver/dvb/drivers/media/dvb/avia/avia_gt_dmx.c,v
retrieving revision 1.193
diff -c -r1.193 avia_gt_dmx.c
*** avia_gt_dmx.c	14 Nov 2003 18:15:37 -0000	1.193
--- avia_gt_dmx.c	16 Nov 2003 18:58:11 -0000
***************
*** 2009,2018 ****
  	case 0x0014:
   		ucode_info.caps = (AVIA_GT_UCODE_CAP_ECD |
   			AVIA_GT_UCODE_CAP_PES |
! //
! // this one is pretty experimental yet, beware!
! // 			AVIA_GT_UCODE_CAP_SEC |
! //
   			AVIA_GT_UCODE_CAP_TS);
  		ucode_info.qid_offset = 1;
  		ucode_info.queue_mode_pes = 3;
--- 2009,2017 ----
  	case 0x0014:
   		ucode_info.caps = (AVIA_GT_UCODE_CAP_ECD |
   			AVIA_GT_UCODE_CAP_PES |
! #ifdef EXPERIMENTAL
!  			AVIA_GT_UCODE_CAP_SEC |
! #endif
   			AVIA_GT_UCODE_CAP_TS);
  		ucode_info.qid_offset = 1;
  		ucode_info.queue_mode_pes = 3;

Dann braucht man nicht ständig beim "cvs up/commit" aufpassen und zumindest ich nehme eh' ein angepaßtes "build.sh" im driver-Verzeichnis, so daß das Makefile.am im CDK ungeändert bleiben kann und dann eben "nicht-experimentelle"-Treiber erzeugt.

Npq

[kerlimann]

finde die idee gut, werde aber einen teufel tun, und das makefile anfassen <g>. ich denke mal, dann darf ich sofort die koffer packen

da ist eigentlich obi gefragt, wenn das mit ihm OK ist, waere das super!

[Sepp776]

Hätte noch ne andere Idee: Kann man nicht aus der internen ucode.bin eine neue basteln mit Versionsnummer 0x1234 oder so? Dann könnte man für die 0014er das SEC drin lassen und wer Probleme hat nimmt die 1234 (die ja ansonsten die selbe ist).

Vorteil: Bei jedem fertigen Image oder Yadd kann man mit reinkopieren/löschen der ucode.bin das SEC ein bzw ausschalten (hat aber ansonsten die gute 0014er ucode.bin). Und jeder kann für sich selbst überprüfen ob die Probleme mit dem SEC zusammen hängen

(c) Probleme gibt es doch da nicht mehr oder?

[obi]

@sepp und kerlimann:
tut mir einen gefallen... und lasst die finger von den treibern. danke. woran denkt ihr eigentlich wenn ihr argumente ignoriert?

wir fangen jetzt auch nicht an, irgendwelche ucode versionsnummern zu patchen um mal so aus spass die leute zu verwirren. sowas unnoetiges. und wie klar waere das dem user gegenueber, wenn sein ucode aus dem dateisystem andere funktionen benutzt als der identische ucode aus dem treiber?

leute, es gibt MODULPARAMETER. wir haben das recht sie zu verwenden.

wenn ich schreibe, dass treiber patches bitte ueber mich laufen sollen, dann sage ich das nicht nur einfach so aus spass, sondern ich denke mir dabei auch was. nicht jeder hat sofort den ueberblick und deshalb sollen fragen gestellt werden.

eure versuche in allen ehren, aber CVS HEAD ist INSTABIL. es ist EXPERIMENTELL. wenn ihr denkt dass es release tauglich waere und nurnoch kleinigkeiten fehlen, dann macht einen zweig dafuer im CVS.

stattdessen wird hier wie im kindergarten ein und dieselbe aenderung immer wieder gemacht. wieso? weil keiner von euch beiden in der lage ist, nachzufragen oder wenigstens die gruende zu lesen, die ich hier genannt habe.

@Zwen:
was sind denn die restlichen treiber bugs?

[DieMade]

leute, es gibt MODULPARAMETER. wir haben das recht sie zu verwenden.

Seit gerade eben sogar einen weiteren

[Sepp776]

Lieber obi,
ich habe 1. versucht vor dem ersten Einchecken nachzufragen ob das ok ist, 2. nichts mehrmals eingecheckt und 3. versucht eine andere Möglichkeit zu finden nachdem die erste offenbar nicht der richtige Weg war.
Wüsste nicht was es an diesem Vorgehen auszusetzen gäbe *kopfschüttel*.

Schönen Tach,
Sepp.

[DieMade]

Sepp776:

ich habe mich heute morgen kurz mit obi über den module-parameter unterhalten, bekam noch eine Hilfe, wo und wie das einzubauen sei (im prinzip schon inkl. komplettem source ) und nach 30 minuten war das im cvs.

Miteinander reden (im IRC, nicht per Forum) ist oftmals sehr hilfreich (zumindest hilfreicher als solche Diskussionen und "commit-wars").

Nur mal so als Denkanstoß

[Rudi Ratlos 4711]

Und was kann man als Ergebnis festhalten ? Wie läufts am Besten ?

RR4711

[Zwen]

was sind denn die restlichen treiber bugs?

Diese Kernel-Oopses beim umschalten/playback-starten während bzw. kurz nach dem streamen ( zB. hier beschrieben http://www.tuxbox-cvs.sourceforge.net/f ... hp?t=26146 )

Möchte auch nochmal klar stellen, dass

Ich sehe halt nicht, das es jemanden gibt (der Lust hat | der dazu in der Lage ist) dieses Problem in naher Zukunft zu lösen. Wie bei anderen Treiber-Problemen halt auch...

nicht als Vorwurf gemeint war, schliesslich liegt es auch an jedem einzelnen selbst, diesen Zustand zu Verbessern (mich eingeschlossen, ich persönlich schiebs auf mangelnde Zeit ;-) )

Zwen

[petgun]

...und nach 30 minuten war das im cvs....

diemade 03/11/17 09:22:22

Modified: dvb/drivers/media/dvb/avia avia_gt_dmx.c
Log:
added module-paramter hw_sections (default=1 - enabled)

..und in welche Datei schreibe ich jetzt 'hw_sections=1/0' oder wie geht das ?

cu,
peter

[Zwen]

..und in welche Datei schreibe ich jetzt 'hw_sections=1/0' oder wie geht das ?

Dort , wo das Module avia_gt geladen wird. (init1/init2/rcS).
IMHO wäre es sinnvoll, so wie bei den BH-Mode Treibern damals auch, das über ein trigger file in /var zu lösen, also
wenn /var/.no_hw_sections existiert, dann lade das module mit hw_sections=1 sonst ohne...
Über ein frontend in neutrino, dass dieses File dann anlegt, könnte man sich auch noch gedanken machen...

Zwen

[petgun]

..und in welche Datei schreibe ich jetzt 'hw_sections=1/0' oder wie geht das ?

Dort , wo das Module avia_gt geladen wird. (init1/init2/rcS).
IMHO wäre es sinnvoll, so wie bei den BH-Mode Treibern damals auch, das über ein trigger file in /var zu lösen, also
wenn /var/.no_hw_sections existiert, dann lade das module mit hw_sections=1 sonst ohne...
Über ein frontend in neutrino, dass dieses File dann anlegt, könnte man sich auch noch gedanken machen...

Zwen

Danke fuer die sehr schnelle Antwort

cu,
peter

[kerlimann]

IMHO wäre es sinnvoll, so wie bei den BH-Mode Treibern damals auch

nicht damals, das ist ja noch drin (fuer rel api1). waere recht unproblematisch das einzubauen fuer hw-sections.

aber ehrlich gesagt kann ich mich mit diesen ganzen semaphores nicht so richtig anfreunden. koennte man das nicht aus der neutrino.conf lesen? irgendwie beim start mit grep die neutrino.conf nach hwsections durchwuehlen.
finde ich irgendwie aufgeraeumter, wenn man nicht etlichen configstuff hat.

//nachtrag: jetzt haette ich enigma / lcars fast vergessen. also wegen mir eine "driver.conf" vielleicht?

@petgun:
es ging darum, was zwen meinte. und zwar, das ueber das menue von neutrino dieser parameter gesetzt werden kann - aehnlich dem bh driver bei api1.

[petgun]

..aber ehrlich gesagt kann ich mich mit diesen ganzen semaphores nicht so richtig anfreunden. koennte man das nicht aus der neutrino.conf lesen? irgendwie beim start mit grep die neutrino.conf nach hwsections durchwuehlen.
finde ich irgendwie aufgeraeumter, wenn man nicht etlichen configstuff hat.

//nachtrag: jetzt haette ich enigma / lcars fast vergessen. also wegen mir eine "driver.conf" vielleicht?

eben in HOWTO gelesen:

Nix entfernen. avia_gt.o kennt jetzt den Parameter hw_sections=0

Also:
- avia_gt.o austauschen
- entweder in /etc/init.d/rcS oder /etc/modules.conf den Parameter eintragen.

Beim Laden meldet das Modul, ob HW-Sections (de)aktiviert sind.

..kannst Du Dich denn damit nicht anfreunden ?

cu,
peter

[Npq]

Ehrlichgesagt bin ich eher der Meinung, daß eine Userspace-Anwendung nichts über die verwendeten Treiber und ihre Funktion wissen sollte.

Alles andere gibt nur Chaos wenn in 3 Monaten die Treiber diesen Parameter mal nicht mehr nutzen und User dann verwirrt ist "wozu ist dieser Schalter XY denn, der macht bei mir gar nichts".

Npq

[kerlimann]

>Ehrlichgesagt bin ich eher der Meinung, daß eine Userspace-Anwendung
>nichts über die verwendeten Treiber und ihre Funktion wissen sollte.
das ist aber anscheinend derweil wegen der verschiedenen boxen nicht anders moeglich, bzw. wegen der verschiedenen ucodes.

>Alles andere gibt nur Chaos wenn in 3 Monaten die Treiber diesen Parameter
>mal nicht mehr nutzen
also komm, dann fliegt das flag halt raus.

>und User dann verwirrt ist "wozu ist dieser Schalter
>XY denn, der macht bei mir gar nichts".
iss doch bei bh das selbe, oder?

aber ich sehe es schon.. die diskussion fuehrt wieder eh zu nix, schade. der branch derweil ist so saustable, naja, vielleicht sollte man den erstmal taggen?
und zwar ohne den flag, also hw_sections erstmal wechlassen. ala HEAD_1_1_0

koennte ich mal probieren, wenn nix dagegen spricht! immerhin findet sich ja niemand, der ohne(!) hw_sections nachteile hat.

[Npq]

Nicht gleich sauer werden

Ich meine nur man sollte nicht anfangen, Dinge an Stellen einzubauen, die dort nicht hingehören.

Wenn User seine ucodes hochladen kann, dann kann er auch eine leere ".swsection"-Datei irgendwo hinbefördern. Und den Rest erledigt dann das Initscript.

Aber naja, ich seh ja ein, daß das für die, die kein Netz haben, dann schwierig wird.

Also, ein Kompromiß wäre vielleicht ein "Expert"-Plugin. Dann wäre das zumindest auf Programmebene getrennt und man könnte es zudem noch für alle GUIs verwenden.

Npq

[kerlimann]

oh noe, ne? <g>
>Nicht gleich sauer werden
mach ich doch garnicht.

>Wenn User seine ucodes hochladen kann, dann kann er auch eine leere
>".swsection"-Datei irgendwo hinbefördern. Und den Rest erledigt dann das
>Initscript.
der user weiss in dem moment garnicht, wozu das gut ist.

>Aber naja, ich seh ja ein, daß das für die, die kein Netz haben, dann
>schwierig wird.
ebend das ist auch ein thema. dein prinzip wuerde nur bei einer neuinstallation greifen. und wie wir alle hier taeglich lesen, bekommen die meisten user das "fertig hingestellt" (eGay usw..)

>Also, ein Kompromiß wäre vielleicht ein "Expert"-Plugin. Dann wäre das
>zumindest auf Programmebene getrennt und man könnte es zudem noch
>für alle GUIs verwenden.
hmm..

[Regloh]

nur mal ein kurzes feedback:
mit deaktivierter hardware section filtering läuft meine box erstmalig stabil mit der internen ucode. kanalsuche ist möglich und darüber hinaus ist der scharze bildschirm beim umschalten zu 99% nicht mehr vorhanden.
alles getestet auf zwei sagem kabel 2x und einer kabel sagem 1x.
Regloh