Keine Lautstärke Regelbar über AVS

[Homar]

hi folks,

seit kurzem ist keine Lautstärkenregelung über avs mehr möglich, nur noch über über ost.


Wollte mal fragen, ob es bei jemandem noch so ist, oder ob es ein lokales Problem bei mir ist.

[sox]

bei mir das gleiche - schon ein paar wochen...

[obi]

ihr habt nicht zufaellig seit kurzem ein optisches kabel?
und habt ihr mal geschaut ob es der treiber oder neutrino ist?
ich moechte garnicht wissen, wie lang es her ist, dass am avs treiber was geaendert wurde.

[Homar]

Frühlein, habe di frage...
...schiraube an mei dibox, machen bssst kein Tonn

Waruum ???

zuviel und zuschnelle cleanups könnte der schuldige sein *schielNachGoodguy*

[zexma]

Waruum ???
zuviel und zuschnelle cleanups könnte der schuldige sein *schielNachGoodguy*

http://tuxbox-cvs.sourceforge.net/forum ... highlight=

Ausserdem läuft seit dem snapshot vom 19.09 das
tuxcal-Reminder-script nicht mehr (da hat irgendwer "grep" ge-"cleanup"-ed)
Quote:
/var/tuxbox/config/tuxcal/reminder: 199: grep: not found
/var/tuxbox/config/tuxcal/reminder: 201: grep: not found

@thegoodguy: ich habe den Eindruck, das haed seit den "Aufräumaktionen" einiges an Stabilität verloren hat...

[Terminator]

Also mit dem Image vom 17.9. geht das einwandfrei.

Aber anderes Problem: Gibt's einen Grund, warum im AVS-Modus der SPDIF-Mute nicht funktioniert? Bei OST geht's einwandfrei, allerdings entsprechen dort 95% Balken = 10% Lautstärke und 90% = 0%, sprich, die Regelung ist (nur bei Sagem?!) unbrauchbar!

[thegoodguy]

AVS und OST sind verschiedene Baustellen an denen die Lautstaerke modifiziert werden kann. Am AudioVideoSwitch ist halt ein Mute fuer SPDIF nicht moeglich.
Die Lautstaerkeskala wurde fuer AVS logarithmisch und fuer OST linear implementiert (vgl. map_volume in controld.cpp). Warum? Keine Ahnung - das war schon im aelteren Code so drin.

[Homar]

@Zexma: das sollte kein Vorwurf sein von mir; ist schon toll, das es jemand macht.

Nur sollte derjenige der Änderungen an der CVS vornimmt, auch selber seine Änderungen überprüfen, bevor es eincheckt.

Wenn jeder dev alle seine Änderungen nur teilweise eincheckt wird es nie eine Vernünftig funktionierende Head-Image geben.
Ganz schnell bekommt man dann gegenseitige Wechselwirkungen.
Niemand kann dann nachvollziehen, wo der eigentliche Wurm steckt.
Noch bevor mann sein Vorhaben komplettiert fängt man an zu bugfixen.

Das aktuelle Problem mit Cable-Bruteforce zeigt die Problematik genau auf.
zwei-drei dev es haben gleichzeitig code im Zapit geändert, während ein anderer die Zapit-Sourcen gecleaneuped hat.
Fast zeitgleich wurden die Treiber mit Linux-TV gesynct.

Die Werte in cables.xml dürften für BF gar nicht so sein, weil es nicht mehr zu den Treibern passt.
Die Modulation (QAM_AUTO) kann kein Kabel-Frontend. Folglich kann auch kein Sender im BF-Mode gefunden werden.
Dieser Fehler war bloss nicht sichtbar, weil irgendwann mal so ein Mixed-Mode beim Scan implementiert wurde von mir:
Wird eine Sat-Quelle im Kabel eingespeisst, hat es eine falsche NIT. In den Zapit-Sourcen wurde dieses korrekt festgestellt und der TP wurde in die Liste der zu scannenden TP es trotzdem aufgenommen. Ursprünglich
musste man eine Flag setzten, das es ein Satfeed ist (satfeed="true").
Bei einem der Cleanups wurde ein wichtiger Teil dieses Mixed-Mode-Scans aus frontend.cpp und scan.cpp entfernt (@TheGoodguy müsstest dich noch an eine PM von mir erinnern). Mein Fehler... hätte ich besser kommentieren müssen.
Seitdem gibbet kein Cable-Bruteforce mehr.

...egal: Software-Auto_QAM und Scan-Speedup ist fertig, manueller Suchlauf ist auch bald durch

gruitzi

...meine Meinung

[zexma]

@Zexma: das sollte kein Vorwurf sein von mir; ist schon toll, das es jemand macht.

Nee, wollte ich Dir auch nicht unterstellen und sollte auch kein Vorwurf an thegoodguy sein. Ich wollte es nur nochmal nach oben holen.
Just for info eben