Ich nutze Materials schon ewig, auch für mich einer der schönsten Skins. Ich bleib dabei

Guter Tipp, werde ich mir die Tage mal in Ruhe anschauen.

hat das sonst keiner von Euch?

wie gesagt das Problem tritt nur auf, wenn man die DM900 ausschaltet und sie dann den Fernseher ausschaltet.

Umgekehrt klappt es wunderbar.

Vor dem Update ging das meines Erachtens auch ohne Probleme andersherum.

Wird die Unterstützung für H264 bzw. AVC High@L5.1 kommen?

Habe hier ein 4k Video, wird aber nicht abgespielt.

Danke

im idle Modus....

Ach ja, wenn eine Aufnahme auf der DM900 läuft, gibt es das oben beschriebene Problem nicht. Die Geräte bleiben aus.

Das Problem gibt es erst seit dem Update am 23.03.

Ich besitze einen Sony KD55XD8599 und die DM900.

Nutze ich die Sony Fernbedienung und schalte den Fernseher aus, geht die DM900 auch aus und alles bleibt auch aus!

Seit dem Update gibt es aber folgendes Problem.

Schalte ich die DM900 mit der Dreambox Fernbedienung aus, geht die DM900 und auch der Sony Fernseher aus. Nach einer Weile geht die DM900 aber wieder an und damit auch der Fernseher. Das war vor dem Update nicht so!

[82149.901688] si2183(0): DVB-S(2) voltage disabled now
[82149.902089] si2183(0): DVB-S(2) voltage disabled now
[82456.881621] CEC recv ok!
[82456.945614] CEC send ok!
[82457.013819] CEC send ok!
[82457.202764] CEC recv ok!
[82457.474620] CEC recv ok!
[82457.866870] CEC recv ok!
[82457.868586] set input to 0
[82457.868596] set fb to 2(-1)
[82457.868606] using 50.00Hz as MonitorRefreshRate
[82457.868620] VIDEO1: shared window not available
[82457.868687] SET FORMAT: display[0], format='2160p50'
[82457.868700] HDMI mode
[82457.868705] use EDID to detect colorspace
[82457.868713] using colorspace: Itu_R_BT_2020_CL
[82457.868717] using 10bit output
[82458.042432] VIDEO1: shared window not available
[82458.042473] set current avs auto aspect to 16:9
[82458.042490] HDMI: using SDR eotf
[82458.042509] set sb to 3(1)
[82458.042748] set mute 0 0
[82458.055231] si2183(0): DVB-S(2) voltage is 18V now

how did you fix it?

Das kommt scheinbar.

534.224724] VIDEO0: set streamtype!
[ 534.224740] -> set MPEG2
[ 534.224749] -> sw rave disabled!
[ 534.224981] sync0 is off so we enable it
[ 534.224991] sync0: allocated pcroffset 0
[ 534.225002] sync0: playback!
[ 534.225028] VIDEO0: total delay: 0 (0 ms)
[ 534.230009] VIDEO0: start decode
[ 534.230043] VIDEO0: flush video decoder
[ 534.260629] VIDEO0: first pts 0x0
[ 534.260654] VIDEO0: framerate changed 3
[ 534.260662] VIDEO0: resolution changed (1280 720)
[ 534.260819] using 50.00Hz as MonitorRefreshRate
[ 534.260839] VIDEO1: shared window not available
[ 534.260881] SET FORMAT: display[0], format='2160p50'
[ 534.260943] HDMI mode
[ 534.260953] use EDID to detect colorspace
[ 534.260961] using colorspace: Itu_R_BT_2020_CL
[ 534.260967] using 10bit output
[ 534.386622] VIDEO0: stop decode
[ 534.386635] sync0 1fff no decoder left in sync handling so disable
[ 534.386640] sync0: was last pcroffset0 user so free it
[ 534.405928] VIDEO1: shared window not available
[ 534.423994] set current avs auto aspect to 16:9
[ 534.424019] HDMI: using SDR eotf

Quote from dre

Hat es nicht mal geheissen, dass experimental auch auf den unstable feed geht?

Ja genau. Ich habe nichts geändert. Daher ist der Feed auch unstable.

Da ist leider nix, nur USB und Net

Maybe you should try out DreamUP

Hallo,

ich habe 1-2 4k MKV Filme und wenn ich versuche zu spulen bzw. die Sprache ändere kommt es sehr oft vor, dass Enigma neu startet, sprich es gibt einen Crash.

Habe keine Festplatte eingebaut und beziehe alles über einen CIFS Share.

Wo schreibt er denn das Crash Log hin, wenn keine Platte eingebaut ist?

-Murdock

Warum antwortet eigentlich keiner der DEVs?

Irgendwie muss das Problem doch zu greifen sein, oder?

Und noch einen Test, wenn ich all die Leerzeichen aus der Datei lösche, dann geht es ohne Fehler!!!

Sprich diesen Befehl:

more datei_mit_recovery_key.txt | base64 -d > trustedkeys.gpg

Habe noch einmal ein wenig in der librecovery nachgeschaut.

Das Problem ist bei mir echo $1

Wenn ich das ausgebe, sieht es so aus. Mit all den Leerzeichen davor.

mQENBFfS0TQBCADLP/mDLWiIF/dJmVFVzQf9CJ7jtb5ilVf4SOasXkPEbdtDsvIIE8ShAHPUgmYC
                                YGAl5FJNxaPZMhyylC9BZOLeYdUgJVRJXjY2WX/bE/6/J5z9UWj+XPzbnbxC+ZnzOGwyUAiHtwbF
                                YLH0SnCN6LEl+nqgwRwpKBgFp64YyAAJ/Rpj5tK6T9v5QuN5CK/UcClmLSqlC/KSbjf93+W9AyOM
                                9F/apxNnhWyEPPjEQbJV8G1WTDL12j4NER3CwwGr+WlKidNdtqDZYYMx89p/qLoV0kbk8tOB7Szx
                                STFQIpetPi++WlKduS5K1gmVYSU8v9WdSAIDujbH1lqOtBq6AaIFABEBAAG0NERyZWFtYm94IERN
                                OTAwIFJlY292ZXJ5IDxkbTkwMEByZWNvdmVyeS5kcmVhbWJveC5kZT6JATgEEwECACIFAlfS0TQC
                                GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPAqD3Z9onVhi9YIALa4eA9XRbyNT/kz2fj9
                                gJ9aLfoxPACbkc2pxwVmLtqeCvsgzEvG62QkFwfL+HDQy2G3YgOSYM8/Z1Y8Agp0iS/QNzNE9v7u
                                cniOy7bX+L+M/zZtLnmY4ixIWcPdMraipjaH3v1c9SUg4eeN6WRgQnPmDA2w+PBViXoAAuqKQrG/
                                7DrGLzXiUzRgxoub4hm1au6KSnEgthn7O33dtCKRDwlCFDHNqdOpgayfGKZ+ENrP5FPZIuSmJH+Z
                                GWxsi2P4cmVwsSE0i1REX3pk1xd4lefdmminxhgsrHnlh4q5O6fSrSlIfNKZ3SZZ3KeSCB21g/9L
                                5jAezlvBvp2M0qC2EDQ=

Wenn ich dann ein "more datei_mit_recovery_key.txt | base64 -d > trustedkeys.gpg" eingebe, bekomme ich ein invalid input.

Sobald ich das "-d" lösche, startet zwar der download, der kann aber nicht verifiziert werden.

Danke für den Tipp, ich dachte es wäre ein binary.....

Sieht bei mir aber genauso aus:

root@dm900:/etc/apt# md5sum /usr/sbin/update-rescue /usr/sbin/librecovery
838e3864c1a72e4869be1bb13b747a3b /usr/sbin/update-rescue
c8bac44a523176af585105947b772f31 /usr/sbin/librecovery

Das Problem liegt wohl in der librecovery

create_keyring()
{
export GNUPGHOME="${WORKSPACE}"
echo "${1}" | base64 -d > trustedkeys.gpg abort 'Failed to write public key'

Habe ein experimental, aber als Feed unstable.

tcpdump auf der Firewall zeigt, das die Box noch nicht einmal versucht nach extern zuzugreifen. Bei meiner DM7080 geht es ja ohne Probleme.

Bin daher ein wenig ratlos.

update-rescue versucht ja per wget die URL zu laden, dabei scheint es zu scheitern, da base64 die Datei nicht lesen kann?

Weiß jemand, welche Datei da geladen wird? Unter /etc/apt ?

Wie kann man das Problem beheben?

root@dm900:~# update-rescue -v
base64: invalid input
Fatal: Failed to write public key