Hmm kannst Du das Verhalten mal etwas genauer erklären? Was passiert wann, und wie äußert es sich.
Ist das auch direkt nach dem Neustart so.. oder erst nach langer Laufzeit.. usw...
Ich kann das so gerade gar nicht einordnen und nachvollziehen. Und es gab auch keinerlei andere Meldungen außer von Dir.
cu
Du kannst direkt nach dem booten im telnet mal "dmesg" eingeben. Oder auf der "seriellen" shell. Oder wenn du ein mini usb auf USB kabel hast auch dieser shell schauen. Aber die dmesg Lösung reicht auch.
cu
Hmm das ist komisch.
Ich schaue mir das nochmal genauer an. Kannst du mal in dem Bootlog schauen, welcher Treiberstand da verwendet wird?
Da sollte es eine Meldung geben ähnlich sowas: Amlogic S922x DVB driver init version 20210324r0-11-g3df71
Also bei dem alten Stand. Dann schaue ich nochmal genauer.
cu
Also ich würde ja sagen, du machst mal ein Backup der Software auf der Box mit der alten Firmware....das kann man über den recovery loader problemlos machen... und dann ggf. auch später wieder auf die box flashen.
Und dann aktualisierst du diese Box ebenfalls mal. Wenn das Problem dann trotzdem bei der Box nicht auftritt, dann kann es nur an der Box selber liegen. Eventuell die BT Antennen nicht richtig angesteckt.. oder an anderer Stelle verklebt. Oder ein HW Defekt. An der Soft selber gab es in Sachen BT eigentlich keine Änderungen. Also ich habe zumindest gerade nichts weltbewegendes gefunden.
cu
Oder waren bei den beiden One keine BT Fernbedienungen dabei?
Ist mir gar nicht bekannt, ob die auch ohne verkauft werden. Ist eventuell Händler Sache.
cu
Wurde denn an einer der beiden Boxen mal eine der BT RCUs verwendet, die dabei waren? Weil sobald eine Bluetooth RCU gepaired ist und in der Nähe ist, wacht die Box über IR nicht mehr auf!
Nur als kurze Info. Ich habe das ganze mal an den technischen Support vom SRF weitergeleitet. Bzw. meine Erkenntnisse mitgeteilt.
Ich könnte da nun irgendwelche Workarounds bauen, die aber auf kosten längerer Umschaltzeiten und Synchronisierungszeiten bei allen (nicht nur den SRF) Sendern führen würde.
Von daher möchte ich erstmal abwarten, ob der SRF das ganze nicht bei der Muxxer Konfiguration recht einfach beheben kann. Eine kurze Antwort habe ich auch schon erhalten... der SRF prüft das ganze.
Wenn sich rausstellt, dass der SRF nichts tun kann / möchte werde ich weiter nach einer anderen Lösung suchen.
cya
EInfach in der Tuner Konfiguriation den zweiten Satelliten hinzufügen mit einem zweiten LNB.. also LNB 2 und die selben SCRs nehmen wie beim anderen Satelliten. Ein weiteres Kabel ist nicht nötig. Die LNB Nummer wird dann automatisch in dem Unicable Kommando integriert.
cu
msxler: das scheint kein Fehler in einem neuen Image gewesen zu sein. Ich habe eben ein altes geflasht vom september letzten Jahres. Und da ist das verhalten exakt identisch.
Ich vermute da hat SRF was geändert. Ich schau es mir aber an.
Devilcards.de was soll ich mir solchen Fehlermeldungen anfangen. Fehler die nicht ordentlich beschrieben sind, und auch nicht ordentlich reproduzierbar sind, sind immer schwer zu greifen.
Mach einen ordentlichen Thread auf... erkläre was kaputt ist, und wie man es nachstellen kann. Ggf. auch welche Plugins und streams man braucht. Sonst ist sowas nicht zu fixen.
cu
There are now updates on the unstable feed which should fix this Problem.
Please report.
cya
Der erste Parameter wäre der devicename also wenn man in der actionmap "<device name="dreambox advanced remote control (native)"> .... oder sowas verwendet..
Hmm das senden des break sollte in dem Fall eigentlich egal sein, weil beim nächsten Tastendruck eigentlich wieder ein make kommt, was die "state machine" da wieder zurücksetzt.
Hmm das ist im core schwierig zu handlen... weil dann müsste der code sich ja merken, ob eine make/long action die vorher lief einen passenden handler hatte.. und der handler mit einem valid return code beendet wurde...
Aber dein keyPressed ist ein funktionierender Workaround. Dieser funktioniert weil dann innerhalb des Handlers für das long ja ein neuer Tastendruck simuliert wird. Dieser simulierte Tastendruck überschreibt dann den vorherigen "make" code. Und ein long oder break wird immer nur ausgeführt, wenn der vorherige Tastendruck von der selben Taste kam und ein make war. Das sollte theoretisch keine Nebenwirkungen haben.
Naja b steht für break.. also das ist ein break code, der schon im Treiber generiert wird.
Break kommt bei jedem loslassen der Taste... immer.
Wenn du also Folge eines "long" keypress einen neuen screen öffnest.. oder als folge eines "make" codes... dann ist danach ein neuer Screen offen.. deshalb geht dann halt der "break" code verloren.
Aber solange ein Screen offen ist wird immer das break kommen. Ich wüsste auch nicht wie man das verhindern will.. weil das halt total verschiedene keycodes sind die da aus dem Treiber / kernel eventdevice kommen.
cu
Okay. There are some i2c transfer errors. I think the box is broken. You should either try to exchange them through the dealer, or you can try to let repair them via dream support.
Without Bootlog its not easy to say anything.
But when you tried latest firmware from dreamboxupdate.com and the DVB-C is not detected... then i think its a hardware defect or no genuine box.
cu
from enigma import eAlsaOutput
alsa = eAlsaOutput.getInstance()
alsa.close()
Das geht aber nur, wenn gerade kein Sender läuft.. oder eine Wiedergabe. Sprich der aktuelle service muss beendet werden vorher.
Wenn man einen service startet wird automatisch dann alsa auch wieder von e2 gestartet...
cu
Ich mache hier mal auf Wunsch von Gutemine zu. Das führt zu nichts.
I'll close here at Gutemine's request. This leads to nothing.
Also die Meldung "Partioning is wrong" sagt, dass der NFI Header nicht korrekt ist / zu der Box passt. Ich würde behaupten, dass Image passt nicht zur Box.
Ist es denn sicher, dass das ein Image für die V2 ist, und die Box wirklich eine V2 ist?
Ich würde mal die Images von dreamboxupdate.com probieren. Das jeweils letzte für die V2 und wenn das nich tgeht.. dann für die nicht V2 ..
Eins sollte sich eigentlich flashen lassen.
cu
It seems there is a problem on load hardware drivers.
We need a bootlog to investigate this.
Or maybe you can directly after bootup login via telnet / ssh and call dmesg > /tmp/bla.log and attach the bla.log here...
cu
