Share your experience!
Problem
Wenn ich die Gerätschaften einschalte (BRAVIA muss sich im Deep Sleep befinden!), findet meist eine automatische Umschaltung des Eingangs auf den HDMI3/ARC statt. Die daran angeschlossene Cinebar 52 THX fungiert aber lediglich als ARC-Audio-Ausgabe-Gerät, nicht aber als Eingang.
Ich habe mir jetzt mal die Zeit genommen und die CEC-Kommunikation (aus Sicht des TVs) zwischen den Geräten geloggt und analysiert. Das System bestehend aus BRAVIA, Apple TV 4K und Teufel Cinebar 52 THX wird dabei über die Fernbedienung vom Apple TV 4K eingeschalten.
Konfiguration/Verkabelung
__________________ ____________
| BRAVIA HDMI1 |_ | |
| X9005F HDMI2 |________| AppleTV 4K |
| HDMI3/ARC |____ |____________|
| HDMI4 |_ | ____________
|__________________| |___| Teufel |
| Cinebar 52 |
|____________|
Ich muss die Cinebar über ARC betreiben, da der darin integrierte HDMI-Switch lediglich die Version 1.4 unterstützt und somit kein 2160p60/HDR für den Apple TV 4K, welchen ich daher am HDMI-Switch vom BRAVIA betreibe.
CEC-Kommunikation
(1)
Apple TV 4K versucht recht schnell nach dem Einschalten, sich zur aktiven Quelle (Active Source) zu machen:
02-09 13:49:46.648 1640 1640 I HdmiCecController: [R]:<Active Source> src: 4, dst: 15, params: 20 00
02-09 13:49:46.650 1640 1640 I HdmiCecController: [R]:<Active Source> src: 4, dst: 15, params: 20 00
Der Apple TV hat als Wiedergabegerät die Adresse 4, die Teufel Cinebar 52 THX als Audio System die Adresse 5 und der BRAVIA selber die Adresse 0. 15 ist die Broadcast Adresse (0xF), sprich Kommandos mit dst: 15 gehen an alle Geräte.
(2)
Erst in weiterer Folge geben die am BRAVIA angeschlossenen Geräte ihre physikalische Adresse bekannt (HDMI2=0x2000, HDMI3=0x3000):
02-09 13:49:48.098 1640 1640 I HdmiCecController: [R]:<Report Physical Address> src: 4, dst: 15, params: 20 00 04
02-09 13:49:48.099 1640 1640 I HdmiCecLocalDeviceTv: Ignored while tv is transient to or in standby: <Report Physical Address> src: 4, dst: 15, params: 20 00 04
02-09 13:49:48.233 1640 1640 I HdmiCecController: [R]:<Report Physical Address> src: 5, dst: 15, params: 30 00 05
02-09 13:49:48.239 1640 1640 I HdmiCecLocalDeviceTv: Ignored while tv is transient to or in standby: <Report Physical Address> src: 5, dst: 15, params: 30 00 05
Wie es scheint, ist der BRAVIA zu diesem Zeitpunkt einfach noch nicht bereit, die CEC-Kommandos von den angeschlossenen Geräte zu verarbeiten. Deshalb verpuffen wohl auch die Bemühungen seitens des Apple TV 4K, sich zur aktiven Quelle zu machen, siehe (1).
(3)
Der Apple TV 4K hat wohl gemerkt, dass er nicht zur aktiven Quelle gemacht wurde und fragt diese erstmal ab:
02-09 13:49:48.297 1640 1640 I HdmiCecController: [R]:<Request Active Source> src: 4, dst: 15
(4)
Darauf antwortet nun die Cinebar 52 THX und sieht sich als aktive Quelle:
02-09 13:49:48.418 1640 1640 I HdmiCecController: [R]:<Active Source> src: 5, dst: 15, params: 30 00
Warum auch immer das so ist. Schließlich hängt an den HDMI-Eingängen der Cinebar 52 THX nichts. Das ist IMHO ein Fehlverhalten der Cinebar.
(5)
In weiterer Folge schaltet der BRAVIA dann tatsächlich auf die Cinebar 52 THX am HDMI3/ARC um. Das Log kann ich diesbezüglich aber nicht ganz entschlüsseln:
02-09 13:49:58.041 3173 3173 I com.sony.dtv.braviasyncservice.BraviaSyncService: MSG_NOTIFY_ACTIVE_SOURCE_CHANGED logicalAddress:82
02-09 13:49:58.049 3131 3150 D TIS_ExternalTis: onChange: device:Hardware: physical_address: 0x3000 port_id: 3 inputId:com.sony.dtv.tvinput.external/.ExternalTvInputService/HW4
02-09 13:49:58.057 3131 3150 I TIS_ExternalTis: onChanged: input change request from connected HDMI device. Change input
Logische Adresse 82? Die ist mir gänzlich unbekannt und taucht im Log sonst auch nirgends auf.
Es kommt auch zu dem Problem, wenn man anstatt des Apple TV 4K nur den BRAVIA (samt Teufel via CEC) einschaltet. Das Log sieht dann ähnlich aus, außer, dass sich der Apple TV 4K nicht versucht, sich zur aktiven Quelle (Active Source) zu machen. Schließlich ist er ja "aus". Das hindert ihn aber nicht daran (weil der Apple TV 4K in Wirklichkeit ein "Always-on" Gerät ist), die aktive Quelle abzufragen (siehe ab (3)), was den BRAVIA dazu verleitet, die Quelle auf die Cinebar 52 THX zu wechseln, nachdem sich diese als aktive Quelle ausweist.
IMHO handelt es sich bei dem Problem um eine CEC Inkompatibilität zwischen den Geräten. Erst versucht sich wohl der Apple TV zu früh zur aktiven Quelle zu machen. In weiterer Folge fragt er dann die aktive Quelle ab, woraufhin sich die Cinebar fälschlicherweise meldet und der BRAVIA selbige dazu ernennt.
Im Pro-Modus des BRAVIA kann man Eingänge komplett aus dem Verkehr ziehen, in diesem Fall also den HDMI3. ARC funktioniert weiterhin, der Eingang kann aber nicht mehr zur Quelle werden. Wäre schön, wenn man das auch im "normalen Modus" machen könnte.
Interessante Ausführung.
Wenn sich die Cinebar 52 THX fälschlicherweise als aktive Quelle meldet, liegt dann nicht auch hier der Fehler?
Mein Sony A1 hat noch nie automatisch auf den HDMI3 / ARC umgeschaltet, an dem ein SONY AV-Receiver STR-DH540 angeschlossen ist.
Ja. So ganz sauber ist das Verhalten für mich auch nicht. Die Cinebar geht halt prinzipiell davon aus, dass sie der HDMI-Hub ist, wo alle Eingabe-Geräte dran hängen. Im ARC Fall mit HDMI-Hub im BRAVIA (auf Grund von HDMI2.0 Unterstützung) ist das aber nicht der Fall.
Das Problem könnte in allen 3 involvierten Geräten gelöst werden:
Apple TV 4K:
Der Apple TV 4K müsste nach fehlgeschlagenem <Active Source> kein <Request Active Source> machen. Das bringt ihm IMHO gar nichts.
Teufel Cinebar 52 THX:
Die Cinebar müsste sich bei einem <Request Active Source> nicht als <Active Source> melden, bzw. dürfte sie streng genommen auch nicht, wenn an den Eingängen vom darin integrierten HDMI-Switch gar nichts hängt.
Sony BRAVIA:
Wenn der BRAVIA die eingehenden Kommandos schneller nach Standby verarbeiten würde, würde der Apple TV 4K zur aktiven Quelle und selbige nicht abfragen, was dann zu keiner Umschaltung auf die Cinebar am HDMI3 führen würde.
Du hast doch den XF9005 (?) mit alten SoC (ATV2), würde ja bedeuten das mit dem neuen die Probleme (z.b. beim XG9505) nicht sein dürften oder ? Oder ist das Startverhalten aus dem Standby ein genereles Android Problem ?
Teufel schonmal deswegen angeschrieben ? Ggf. könnten die das bei sich mal Testen oder eine angepasste Firmware bereit stellen.
MFG
MajinWalkman
@MajinWalkman schrieb:
Du hast doch den XF9005 mit alten SoC (ATV2)
Richtig.
würde ja bedeuten das mit dem neuen die Probleme (z.b. beim XG9505) nicht sein dürften oder ?
Verstehe nicht, wie du zu diesem Schluss kommst. Weil der neue SoC schneller ist? Ich denke, das liegt eher an der Reihenfolge, in der Dinge nach Standby abgearbeitet werden.
Ja auch weil schneller und aber auch weil der Kernel viel aktueller ist. Evt. ist es auch ein "Treiberbug" im 3.10er.
P.S. jetzt hast du schneller geantwortet als ich vorher noch ergänzt habe, schau mal nochmal vorher ;D.
MFG
MajinWalkman
@MajinWalkman schrieb:Teufel schonmal deswegen angeschrieben ? Ggf. könnten die das bei sich mal Testen oder eine angepasste Firmware bereit stellen.
Ja. Aber wie bei CEC üblich macht da keiner Eingeständnisse. Da zeigen alle nur mit dem Finger auf andere. Ich habe ihnen jetzt noch diesen Link hier geschickt. Damit dürfte das dann auch erledigt sein.
Naznačite sviđanje na Facebooku
Pretplatite se na YouTubeu