About daddle

björnp schrieb: @TheDoctor Es ist nach dem standby zwar teilweise immer noch kurz grau, verbindet sich dann aber von alleine ohne irgendwelche klimmzuge. Ebenso wenn das wlan wieder reaktiviert wird. Hi björnp, wie McB schon sagt, wenn und falls du die Wlan-> Drei Punkte > Erweitert > Option " Im Standby immer aktiv lassen" angeXt hast, muss das Wlan-Icon sofort beim WakeUp weiss sein; und Imap-Mails oder Push-Nachrichten müssen schon während des StandBy's empfangen worden sein, so dass sie direkt beim Wake Up vorhanden sind! So ist es jetzt bei mir! Und was meinst du mit "ebenso wenn das wlan wieder reaktiviert wird", du meinst nach Wlan Aus - und dann Wiederanschalten kommt die Verbindung sofort? Ok, aber das war eigentlich bei den meisten  immer so und machte man zur Fehlerbehebung, wenn i-net festhing oder trotz weissem Wlan-Symbol für vollem Empfang keine Inhalte durchkamen. grüsse,daddle d ... View more

Danke für die Erläuterungen.   Ja, ich war einer der geschrieben hatte der Wlan-Fehler tauchte bei mir erst nach OTA#3 auf!  Obwohl ich da das Fehlen von Pushs im Standby vorher nicht als Fehler registriert oder bemängelt hätte, kriege zu wenig davon; erst die Wlan- undi-Net-Verbindungsabbrüche fielen mir nach OTA #3 auf.   Allerdings habe ich das auch nicht nur an OTA #3 festgemacht sondern auch den Zeitfaktor ins Spiel gebracht, dass es bei Allen möglicherweise nur eine Koinzidenz mit einem OTA-Update war, weil wir  ja gerne nach nahe liegenden Erklärungen suchen!    In  OTA #3 wurde ja die  Boot gepatcht, angeblich um den Wlan-Fehler, den andere schon vorher hatten, zu beheben, und danach trat er erst  bei mir so massiv in Erscheinung, dass nach StandBy und WakeUp sogar ausser dem typisch orangenem  Icon für getörte Verbindung, selbst bei weissem Wlan-Symbol keine i-Net-Verbindung bestand, und erst ein voller Wlan-Reset überhaupt eine Verbindung  zu Stande brachte. Refresh der SSID-Verbindung  reichte da nicht aus.   Aber ich werde jetzt Ota #2 flashen mit allen passenden Dateien und altem Bios, und dazu die neue boot nehmen, bin mal gespannt.   grüsse, daddle     ... View more

Testreihe:   Bios-Flash mit capsule.bin aus OTA #3                          > Kein Droidboot möglich, mit oder ohne SD-Karte im Slot   Bios-Flash m. BIOSUPDATE:fv, erstes Recover-Paket  > Droidboot geht, ohne und mit  SD-Karte im Slot   Bios-Flash aus capsule.bin aus Recover-PaketV2.1      > Droidboot startet nur ohne Sd-Karte im Slot!  Mit SD-Karte nicht ! (= capsule.bin aus OTA #3v2)   Zusätzlich die capsule.bin aus dem Recover V2.1 mit der efilinux-user.efi, dem esp.img und droidboot(=fastboot).img aus dem funktionierenden Recover (V1.)geflasht, bleibt bei dem oben aufgezähltem Verhalten, booten ins Droidboot nur ohne SD-Karte im Slot; verschiedene boot- und recovery-images ändern daran auch nichts.     @TheDoctor   Warum lässt du bei der Flash.bat zum Flashen ohne Datenverlust die Zeile "fastboot.exe oem wipe ESP" aus? Ist clean flashen nicht besser? Oder bedeutet "...oem wipe ESP" auch das Löschen der Partition; habe allerdings meinem Flashen der esp.img auf die ESP immer wipe vorhergeschickt, auch ohne neues "oem partitioning" , und funktionierte.    Müsste ich  die Flash-Test-Reihe nochmal wiederholen, da ich sie durchgehend mit der efilinux-user.efi Version aus dem Recover V2.1 gemacht habe, die ja in Stage1 immer mit geflasht wird.  Wohin eigentlich??   Macht das einen Unterschied, da die neuere Version ein wenig verändert ist zu der aus dem ersten Recover-Paket (analog bei den OTA's)?  Hatte allerdings bevor das Recover-Paket 2.1 kam, also mit der zur Version jeweils passenden efililnux-user.efi geflasht, das jeweils o.a. selbe  Droidboot-Verhalten bzgl. primäres Booten in den Droidboot-Modus.   Dafür weiss ich eben zuwenig was das Flashen der efilinux-user.efi macht; und ob das Bios beim normalen Start einen integrierten osloader lädt, und der von uns in Stage1 geflashte osloader efilinux-user.efi wieder überschrieben wird und keine Rolle mehr spielt.   Noch etwas ist mir aufgefallen:   Wenn man im ersten Recover-Paket die boot.img mit dem neuen boot.img aus Recover-Paket V2.1 ersetzt, und das Recover-Paket (V1) mit dem ausgetauschten boot.img flasht, hat man erst mal alles was man will: Funktionierendes Droidboot Start-Verhalten mit und ohne Sd-Karte, und, wie ich früher schon hier geschrieben hatte, wieder die Ladeanzeige, und der Wlan-Standby Fehler ist (vorläufig) auch weg! (Ich weiss, wird wahrscheinlich nicht gut fürs nächste neue Lollipop-Ota wenn das kommt! Aber "for the time being.....")    Wollte nur aufzeigen, dass das Wlan-Problem eben doch nur an den Realtek-Treibern und Firmware gelegen haben kann. Als ich das vor zwei Monaten hier schrieb, wurde ich etwas unsanft korrigiert.     daddle ... View more

  B E S T Ä T I G T       Auf diese Idee muss man erst mal kommen! Auch die arme Qualitäts-Kontrolle!    Wäre interessant zu testen ob das auch die Ursache bei der anderen Bios-Version OTA #3 war, womit man ja auch nicht ins Droidboot kam!  Werde ich gleich mal testen! Und mit dem Bios aus dem ersten Recover-Paket.    Hatte allerdings bei der vorigen Bios-Version (BIOSUPDATE.fv) aus dem ersten Recover-Paket immer meine sd-Karte drin, soweit ich mich erinnere, schon um das CWM-Backup zum Restoren direkt zur Verfügung zu haben; und kam auch in den Droidboot-Modus.   Aber wenn das Bios oder der Bootloader beim Starten jetzt zuerst auf der sd-Karte eine boot-partition sucht ist das interessant. Sind denn diese Änderungen mit der neuen Bios-Version von Intel nicht dokumentiert?   daddle ... View more

Hallo @TheDoctor,   das Bios hatte ich bereits nach Ändern der flash.bat in der von dir beschriebenen Weise einzeln neu geflasht, zum Testen bevor ich meinen bösen Post schrieb!  "Batterie" leer ist  leider falsch, habe dies bei mindestens 75% Akku gemacht.   Die kompletten Flash-Zeilen mit den vielen Unterabschnitten laufen durch, kein Error zwischendurch. Am Ende steht, "Alle Bios Komponenten upgedated", dann kommt die Mitteilung das die SEC- firmware nicht upgedated wird da old version = new version (1.1.0.1030 gaub ich), dann ESRT wird aktualisiert. Danach "Press any key to continue".  Alles aus dem Gedächtnis.   Hatte bereits mehrfach das Bios geflasht, im Verbund für die Versionen ota#2, ota#3, ota#3v2, und im Rahmen des alten und neuen Recovery-Paketes. Dabei soweit möglich die Mitteilungen mitgelesen, immer der selbe Ablauf, bis auf den Bios-flash mit OTA#3, da wurde soweit ich mich erinnere zusätzlich die SEC-firmware von xxx.1013 auf xxx-1030 mit upgedatet.   Booten in den Droidboot-Modus funktionierte nicht nach OTA #3, wohl nach dem ersten Recovery-Paket (v1), und nach dem Lollipop-Update. Nach Recovery-Paket V2, (hatte selber die fehlende  Zeile für das flashen der capsule.bin RICHTIG  nachgetragen), habe ich den  Zugang zum Droidboot-Modus nicht mehr getestet, da ich zu sehr darauf fokussiert war, wie ihr wahrscheinlich auch, das Wlan-Verhalten zu testen.   Da dies mit Recover-Paket v2.1  funktionierte, Rückflash auf Stand Ota#2 um mich der OTA-Kette entlang hangeln zu können, wie dir schon mal hier beschrieben,  In Stand OTA #2 Droidboot getestet (wg. wie du mal sagtest critical bios-downgrade). Da funktionierte Booten ins Droidboot. Dann nacheinander die Updates OTA #3 und OTA #3v2 geflasht, echt  "over the air", nicht mein gesichertes OTA #3,  und jetzt nur das Wlan-Verhalten getestet,  das ja sehr erfreulicherweise  mit dem neuen Kernel funktioniert.   Bis gestern der andere User adamp den Droidboot-Fehler meldete, und ich genauso überrascht wie du, es testete, und eben auch nicht mehr in den Droidboot-Modus booten konnte. Bios nachgeflasht, mit und ohne esp- und droidboot.img, Sorry no way.    Komme in die shell, komme in den DnX, aber nicht mehr ins Droidboot, auch nicht nach dem singulärem Bios-flash aus dem Recover-Paketv2. (für mich ist V2 undV2.1 gleich, da ich die fehlende Zeile ergänzt hatte; daher schrieb ich schon mal V2 und V2.1, sind bei mir gleich im Inhalt; (ist  immer mit der ergänzten Zeile "fastboot.exe flash capsule capsule.bin")   Gruss, daddle Sorry, to mess up your day!       Es sollen mal andere User die Recover-Paket v2.1 geflasht haben hier testen, zum be- oder entkräften:   Tablet aus USB-Kabel ab Lautstärke leiser(-) drücken und festhalten, dazu die Power-Taste drücken bis das Tab in 's Droidboot bootet; wenn nicht startet der "Lifetab"-Schriftzug. @adamp   "Deshalb hat es mich auch gewundert, da das OTA 3 V2 den Droid Boot Modus zulassen sollte. Ich kann ja immer noch das gesamte Recovery Image drüberbraten. Ich wollte es aber an sich vermeiden."   >>>>Wieso gewundert, in dem RecoveryPaketV2 ist das selbe Bios und esp- und droidboot-image. Hier ist meine biosflash.bat:    Achte auf die drei mit der Raute auskommentierten Zeilen, oder lösche die auch.     echo off echo "" echo "***********************************" echo "*** Intel flash process stage 1 ***" echo "***********************************" echo "" fastboot.exe flash osloader efilinux-user.efi fastboot.exe boot droidboot.img timeout 10 echo "" echo "***********************************" echo "*** Intel flash process stage 2 ***" echo "***********************************" echo "" #fastboot.exe oem wipe ESP #fastboot.exe flash ESP esp.img #fastboot.exe flash fastboot droidboot.img fastboot.exe flash capsule capsule.bin fastboot.exe continue echo "" echo "***********************************" echo "*** Finished. ***" echo "***********************************" echo "" @TheDoctor   Hatte mit der esp und droidboot und ohne die beiden getestet, daher die drei Zeilen für den letzten Flash auskommentiert! Machte aber keinen Unterschied.   ... View more

adamp schrieb: Hallo. Ich habe nun folgendes Problem.   Das Einspielen von beiden Updates verlief fehlerlos und das Tablet funktioniert an sich auch fehlerfrei.   ABER: Trotz OTA 3 V2 kann ich mit Vol - und Power nicht in den Droid Boot Modus.   Normal sollte das Problem ja mit dem OTA 3 V2 gefixt sein.   Habt ihr eine Idee was da schief gelaufen sein könnte?    Und was mich noch wundert: Android 5 wurde wegen der zahlreichen Bugs beim Lifetab zurückgezogen (zumindest aktuell). Im aktuellen Aldi Prospekt ab 24.09.2015 wird das TAB mit Android 5 beworben. Wie kann das sein? Welche Version ist da installiert? Schöne Grüße Adam     Hi Adam, Das muss ich leider bestätigen, auch ich komme mit den gewohnten Tasten nicht mehr ins Droidboot. Zustand bei mir ebenfalls nach OTA #3v2! Das heisst nur das Bios aus dem alte Recovery-Paket(v1) erlaubte Booten in den Droidboot- Modus,  und jene vor Update #3. Welch ein Mist!   Vorläufige Abhilfe;  die flash.bat aus dem Recovery-Paket ins eigene Verzeichnis zurück kopieren, dabei in droid.bat umbenennen, sonst geht das rückkopieren nicht.    Dann editieren und nur den ersten Abschnitt Intel Stage1 belassen, also alles nach "Timeout 10 Sek". löschen.    Ist das Tab jetzt im DnX -Modus und ruft man die droid-bat auf, wird nur die efilinux-user.efi geflasht und der droidboot-modus gestartet, so das man dann von da ins recovery booten kann.   Oder ersetzt in der gekürzten droid.bat die Zeile "fastboot.exe boot droidboot.img "durch "fastboot.exe boot recovery.img".   Ich werde nochmal das Bios aus dem alten Recovery-Paket flashen; damit ging droidboot, und testen ob das Einfluss auf das Wlan hat und nicht wieder die alten Probleme zurück bringt. Sollte ja nicht, da eher die neue Realtec Treiber, supplicant und was weiss ich nich noch im Kernel die Wlan-Fehlerbehebung gemacht haben soll.   An TheDoctor,   wie hängen eifilinux-user.efi und esp.img zusammen. Ist der osloader Teil des esp.img oder gar das selbe?   Theoretisch und praktisch müsste doch jedes Rom (system und kernel) mit jeder Bios-Version funktionieren, genauso mit jeder Fastboot.img (droidboot)-Version. Oder soll/muss gehören esp.img und droidboot.img und efilinux-user.efi eines Updates odet Paketes zwingend zusammen? Antwort gerne auch als PN, werde alle Kombinationen durch flashen, erst jeweils die zusammen gelieferten, danach unterschiedliche;  aber Antworten von dir würde es mir deutlich vereinfachen und abkürzen.   Es kann doch nicht sein dass ihr wieder ein Bios und osloader liefert, sagt Booten ins  droidboot und recovery würde wieder funktionieren, dabei ist das damit schlechter als im alten Recovery-Paket, womit es wenigstens funktioniert hatte.   Wer macht denn da die Qualitätskontrolle, erinnere auch an die fehlende Zeile zum Flashen des neuen Bios in der flash.bat! Und das bei eurem momentanem "Flagschiff", dem S10346.   daddle ... View more

@TheDoctor   Danke für die Bestätigung. Habe mir ja schon die Fingerkuppen wund schreiben müssen!     Gruss, daddle     Edit:   Ich habe das korrekte Recovery-Package_V2.1 als Interims-Lösung auf meinen Google-Drive hochgeladen, Da steht zwar V2, ist aber nur die Namensabkürzung in 7z, Beim Entpacken kommt V2.1.   Ich hoffe das ist in dieser Ausnahme-Situation erlaubt und eine willkommene Hilfe!     daddle ... View more

Hallo KlausX,   wie ich schon mehrfach schrieb, mal kommt bei Links-Klick Forbidden..., ein anderes Mal startet der Download, stoppt aber wechselnd bei 1029 bis zu 1085 MB und speichert die als xxx.zip. Nix mit xxx.part.zip, sondern als normale Zip, aber korrupt und nicht zu öffnen.   Ich habe das Paket ja schon längst, es ist aber jetzt nicht nur bei "daddle", es sind mehrere User bei AH die den Download nicht hinbekommen und mich über PN angemailt haben, bei denen es auch nicht klappt. Daher habe ich den Download nochmal getestet!   Siehe auch den Link in meinem vorigen Post über einen anderen User der hier beim Handbuch-Downloaden ebenfalls "Forbidden..." bekommt.    Und Rechtsklick auf den Downloadlink bietet mir keine Option  "Ziel speichern unter" (Chrome-Browser); das heisst der Menü-EIntrag ist von einem Downloadmanager, oder In Firefox integriert, daher speichert er bei dir die unvollständige Zip als xxx.part.zip, und du kannst es später fortsetzen.   Auf jeden Fall ist das kein normales Verhalten des Servers, ob nun Rechtsklick, Linksklick usw., das ist doch Quatsch. Ausser dass ein Download-Manager hilft. Aber es muss ja auch ohne gehen!   Gestern mittag noch habe ich das Recovery-Paket V2.1 problemlos runterladen können, vorgestern abend das v2,  ab gestern abends gibt es aber mit dem selben Equipment die Downloadprobleme!   Ich finde es ja toll dass, aus und nach einer Einzel-Beobachtung empfohlen wird  "Mach es so, dann klappt es auch" Nope, Es klappt zwischendurch schon mal und nicht immer, und wenn dann kommt die Zip z.Zt. als unvollständige, zu kleine Zip. Und das ist ein Problem des Medion-Servers. Andere grosse Downloads aus anderen Quellen klappen problemlos.   Auch dass bei dir und McB  Abbrüche stattfinden, und man den Rest exra vervollständigen muss, ist  kein normales Download-Verhalten!   gruss, daddle   Edit: "KausX schrieb:   Da hier keiner eine Differenzierung zwischen Links und Rechts-Klick gemacht hat, habe ich auf die diskutierte "Meldung Forbidden" hingewiesen, die bei mir mit Links Klick kommt."   >>>> genau das sagt  dass ein Downloadmanager aktiv ist, der die Fehlermeldung puffert und es immer wieder versucht auf die Seite zu kommen. Genauso dass die Datei bei dir als xxx.part.zip gespeichert wird. Frag dich doch mal lieber warum der Download unterbrochen wird?   Gruss, daddle ... View more

McB   Gelegentlich kommt ja auch die Download-Mitteilung, aber dann ist bei 1029 MB Schluss. Datei korrupt! Egal, ich hab es ja; war ja auch als Info für Medion und Downloadwillige andere User hier gedacht, wollte keine lange Diskussion.   Gute Nacht, daddle   Zu deinem Edit 4: Man landet sowieso auf der selben Download-Seite, egal von welchem Einsprungspunkt du kommst.   Edit 2: Heute morgen auch nochmal getestet; Manchmal kommt Forbidden..., manchmal startet der Download, aber Zip weiterhin zu klein und korrupt Android_4.4.4_Recovery_Package_V2.1.zip 1.079.770.821 12.09.2015 09:24 -a--   Es muss am Medion-Server liegen. ein anderer User, der sich ein kleines Handbuch runterladen will, bekommt ebenfalls: Forbidden.....   http://community.medion.com/t5/Netzwerk-Speicher/Handbuch-f%C3%BCr-WLAN-Festplatte-MD-90216-MSN-50047220/m-p/13500#   Bitte keine weiteren Kommentare zu meinem Post, ein Medion-Admin soll ja die Fehlermeldung hier noch erkennen können! ... View more

Hi McB,   klicke ich deine beiden Link's   kommt genauso Forbidden  usw   daddle   Edt:  Nee, Laptop Win7 64-bit         ... View more

Hatte ich bisher noch nie! Kann auch nicht auf Download wiederholen klicken, da der Download "regulär" beendet wird und die zu kleine Zip als Zip abgespeichert wird; es erfolgt kein Abbruch oder Meldung über unvollständigen Download.  Andere User bei Android-Hilfe melden die selbe Problematik. Nimmst du einen Download-Manager! Ich habe den Chrome-Browser. dein edit, es ist ja dann ein Download-Mager in Firefox integriert?   Die korrekte Grösse der runtergeladenen Zip aus vorherigem Download ist Android_4.4.4_Recovery_Package_V2.1.zip 1.136.408.386 10.09.2015 13:34 -a--, die du auchangegeben hast.   Ausserdem fällt auf, dass bei jedem zweiten Versuch den Downloadlink aufzurufen, ein Fehler kommt mit der Meldung 403 Forbidden:   "Forbidden You don't have permission to access /downloads/software/Android_4.4.4_Recovery_Package_V2.1.zip on this server."   Und wenn diese Fehler-Meldung nicht kommt, dann startet der Download und es kommt  eine zu kleine, korrupte Zip.   Irgendwas stimmt z.Zt. mit der Medion-Download Server Seite nicht.   Nenn mal bitte deinen Link, meiner, über den ich bereits dreimal erfolgreich runtergeladen hatte, nur heute Abend eben nicht, heisst:   http://download2.medion.com/downloads/software/Android_4.4.4_Recovery_Package_V2.1.zip   daddle   ... View more

@TheDoctor oder den Thread-Admin!   Zur Zeit ist die Zip im Download für das Android_4.4.4_Recovery_Package_V2.1.zip korrupt. Statt 1083 M des funktionierenden Android_4.4.4_Recovery_Packages endet der Download konstant in drei Versuchen bei 1029 M als Zip, und diese lässt sich nicht öffnen.   daddle   ... View more

@TheDoctor   I hope I made your day (Weekend)!  ... View more

TheDoctor schrieb: daddle schrieb: 2. Frage:  Beim Rückflash auf Ota #2 mit der älteren passenden capsule.bin verhält sich der Flash-Vorgang anders.....   Antwort @TheDoctor: 2) Kann ich nicht 100% beantworten. Das BIOS ist für uns leider eine Black Box, in die wir selbst keinen Einblick haben. Generell würde ich davon abraten, auf die ältere BIOS-Version von OTA#2 zurückzuflashen, weil die Daten des BIOS nur in eine Richtung kompatibel sind. Bei diesen Experimenten können Dir Sachen wie die Seriennummer und der DRM-Schlüssel des Geräts verloren gehen, und dann musst Du es einschicken. >>>> Generell ja. ist aber bei mir nicht so gewesen; mittlerweile 3x den Rückflash gemacht, beim ersten Mal dirty, aber zweimal mit kompletten Erase. >>>> Flashen mit dem Recovery-Paket mit den bis auf das system.img darin ersetzten ota #2-Images (boot und recovery.img's aus CWM-Backup, esp.img und Bios aus Update-OTA #2 und fastboot (droidboot).img von einem zweiten Ota #2-Tab per dd gezogen), und nach dem Recovery-Paket-Flash Wiederherstellung und Austausch der geflashten "falschen" ota3-system.img mit CWM-Backup mit advanced restore nur der ota2-system, und alles funktioniert einwandfrei !  DRM-Schlüssel und Seriennummer sind unverändert vorhanden. Antwort@TheDoctor: 3) Der Parameter "-S 200M" weist Fastboot an, Partitionen in Häppchen maximal dieser Größe zu übertragen. War bei einer älteren Version nötig. Die neuere erkennt automatisch, was die Gegenstelle auf dem Gerät verträgt. >>>>Hatte ich mittlerweile auch nachgelesen. Trotzdem vielen Dank für die Beantworung dieser Anfänger-Frage. Zitat @TheDoctor: So, und jetzt bitte Ende der Detaildiskussionen zu unseren Flashscripten. Könnte bitte irgendwer von den ganzen Leuten, die hier vorher über das katastrophale WLAN geklagt haben, mal Feedback zu diesem Thema geben? 🙂 Grüße & ein schönes Wochenende,  Der Doktor _________________________________________ Hallo und guten Morgen Doktor!   Keine Flash-und Skript-Diskussionen mehr, damit es nicht verwirrt. Versprochen. Andererseits hatte ich dadurch frühzeitig entdecken können, dass ein Unterschied zwischen dem Bios in Ota #3 und im Recovery-Paket v1 bestand, und dass in Paket v2 der flash-Befehl für das neue Bios fehlte! Hatte also auch was Gutes, diese jetzt im Thread verpönte Skript-Diskussion!   Zu dem Wlan-Verhalten nach Ota 3 #v2 und Flashen des Recovery-Paketes v2.1:   Es ist gerade mal 24 Stunden voll funktionsfähig im Download, und seriöse oder belastbare Angaben kann man beim besten Willen nach so kurzer Zeit nicht erwarten; inbesondere in Anbetracht der Tatsache, dass bei den Vorgänger-Versionen die Wlan-Problematik in den verschiedensten Ausprägungen bei vielen Usern erst nach längerer Nutzungsdauer des Tablets auftrat.   Hier also meine ersten Erfahrungen aus 36-Stunden Dauerbetrieb des Tabs nach Recovery-Paket v2.1 (hatte vorgestern selber die fehlende Bios-flash Zeile eingefügt, daher v2.1 und 36-Stunden-Zeitraum):   Ein Fehler ist im Wlan-Betrieb bisher nicht aufgetreten; Wlan mit Zugang zum i-net ist direkt nach WakeUp voll verfügbar, auch im StandBy werden Push-Nachrichten jeder Art empfangen und akustisch gemeldet. Geschwindigkeit des Wlans unverändert gut.    Alle diese Funktionen an drei verschiedenen Access-Points und Router getestet mit den gleichen guten Ergebnissen.   Durch den veränderten Kernel sind keinerlei  andere Fehler oder Funktions-Einschränkungen  aufgetreten.   Der System-Software-Stand ist 100% gleich zwischen Ota-Update #3v2 und Android-Recovery-Paket V2.1. Beide getesteten Varianten funktionieren gleich gut; die meiste Zeit verbracht mit dem an der Ota-Update-Kette entlanggehangeltem Update Ota #3v2.      Soweit mein vorläufiges Resumee: es funktioniert alles! Und der positive Ausblick auf das weitere Verhalten ist, dass nach Flashen des Recovery-Paketes v1, also komplettes Neu-Aufsetzen des Tabs, der Wlan-Fehler sofort auftrat. Jetzt nach dem Android-Recovery-Paket v2-Flash sind bisher nach 36 Std.-Dauerbetrieb keinerlei Fehler feststellbar.   Grüsse, daddle   Edit: Kleine Korrektur im Resumee:   "Soweit mein vorläufiges Resumee: es funktioniert alles! Und der positive Ausblick auf das weitere Verhalten ist, dass nach Flashen des alten Recovery-Paketes v1, also dem komplettem Neu-Aufsetzen des Tabs, der Wlan-Fehler sofort auftrat, und nach Recovery-Paket V2.1 nicht! Jetzt nach dem  Android-Recovery-Paket v2-Flash, bzw. zeitlich überwiegend auch nach dem OTA-Update #3v2 sind bisher nach 36 Std.-Dauerbetrieb keinerlei Fehler feststellbar." (Mittlerweile über  44 Stunden) ... View more

@TheDoctor   Vielleicht kann man ja diesen Thread anpinnen, und den alten "LIFETAB S1034X Updates #3 und #4 (Lollipop)", der eh geschlossen ist,  und den "LIFETAB S1034X Update #2" ent-pinnen?    Würde der Anfang des Forums wieder etwas übersichtlicher werden und die aktuellen Update-Threads könnten dadurch leichter gefunden werden.   Wenn die neue Lollipop-Version kommt müsste dafür sowieso  ein neuer Thread geöffnet werden.   Gruss, daddle ... View more

War kein copy&paste Fehler soweit ich erkennen kann. Habe aber den Satzbau extra für dich nochmal umgestellt, damit auch jeder den Satzinhalt verstehen kann.     Aber wenn jeder eine xml lesen kann, dann hättest du doch nicht danach gefragt?  Wie gesagt die fastboot-Befehls-Syntax in der flash.bat macht das m.E. im  Recover-Paket.   Ich glaube die xml kommt nur zum Zuge wenn man das über einen Installer macht; jener der auf der Droidboot-Maske u.a mit nachfolgender Meldung immer für Irritationen sorgt:   "E: No valid installer medium found"   Aber genug OT, sonst wird hier nur noch mehr "gespammt".  grüsse, daddle     Edit:  Im neuen Paket V2.1 wurde die flash.xml weggelassen. Das beantwortet doch deine Frage!   Allerdings ist die installer.cmd verblieben, braucht man doch auch nicht soweit ich das überblicke!  Aber ich bin kurzsichtig!  ... View more

TheDoctor schrieb:  Nein, geht auch unter Linux nicht. Erklärung, vermutlich (müsste Intel uns beantworten): Wird zwar geflasht wie eine Flash-Partition, geht aber tatsächlich nicht ins Flash, sondern ins EEPROM des BIOS. Ist also eine Besonderheit des Intel-Systems. Wir haben das BIOS erstmalig für Euer Recovery Package in unser normales Flash-Script aufgenommen, die Fehlermeldung aber offenbar ignoriert, weil das eigentliche Flashen des BIOS ja geklappt hat.   Grüße Der Doktor   @TheDoctor    Danke für die Erklärung. Es könnte auch noch einen weiteren Grund geben; liest man während des Bios-flash die kleinen Mitteilungszeilen, steht da dass Anteile des alten Bios in mehreren Schritten zwischengespeichert werden, damit der nächste Flash-Abschnitt weitergehen könne. Würde es vorher erased, würde das Update vermutlich stoppen. Dazu die Zeile aus dem Biosflash-Verlauf zu Anfang:    > "Backed up Bios Image for seamless recovery" , und noch andere Zwischen-Backups im weiteren Verlauf Danach erased das capsule.bin oder im Bios eingebaute Routinen diese Abschnitte selbstständig. (Meldung: xxx destroyed)   2. Frage:  Beim Rückflash auf Ota #2 mit der älteren passenden capsule.bin verhält sich der Flash-Vorgang anders als beim Flashen auf eine höhere Version; vor allem zum Schluss wenn die SEC-Firmware  geflasht werden soll, sagt es   All Bios ingredients updated - continue with SEC firmware update... NewVersion 1.1.0. 1013 (zu flashende) OldVersion 1.1.0. 1030 (vorhandene) und dann laufen jede Menge immer gleichlautende Zeilen durch: . Fw Update in progress - Percentage 20%, Stage: 6/17, Last Update Status 572, . . gefühlt ca. 100 Male, und zum Schluss 'Updating ESRT table', und 'press any key to ...`' Flashe ich dann das neuere Bios mit dem RecoverPaket V2 (oder auch nur die neuere capsule.bin, sicherheitshalber im Verbund  mit esp.- u. droidboot.-img ), sieht man das die SEC-Firmware den neueren Stand 1.1.0.1030 beibehalten hat, und jetzt, da gleicher SEC-FW-Stand, nicht neu geflasht wird.   Das  bedeutet die SEC-Firmware wird nicht auf 1.1.0.1013 zurück geflasht, es bleibt immer SEC-firmware Version 1.1.0.1030 drauf!     3.Frage:  Was bewirken die Parameter "-S 200M"?  Diese wurden ja bei Paket V1 in der Linux flash.sh nicht benutzt, wohl in der flash.bat,  und im neuen Paket V2 weder in der flash.sh noch in der flash..bat  benutzt?   Bitte beantworte mir Unwissendem diese Fragen, kurz und knapp genügt mir!    Grüsse, daddle     @McB   Die flash.xml  hat mir auf jeden Fall geholfen den Flashvorgang zu verstehen, besonders da das Bios sonst in den OTA-Updates  "capsule.bin", im Recover-Paket V1 aber BIOSUPDATE.fv heisst, im Paket V2 wieder capsule.bin. Folgender Auschnitt aus der xml erklärt wieso:   </code_group> <code_group name="capsule"> <file TYPE="capsule"> <name>BIOSUPDATE.fv</name> <version>eng.bios</version> </file> die file TYPE "capsule" hat also den <name> BIOSUPDATE.fv, eine Art Platzhalter-Funktion.   und in der >command> Anweisung steht:   <command> <string>fastboot flash capsule $capsule_file</string> <timeout>1800000</timeout> <retry>2</retry> <description>Flashing 'capsule' image.</description> <mandatory>1</mandatory> </command>  In der Zeile <command string> fastboot flash capsule... wird dann für "$capsule_file" aus der <code_group> für file TYPE"capsule" der angegebene <"name"> <BIOSUPDATE.fv> genommen. Im Recover-Paket V2 ist wieder eine abgeänderte xml, in der dieser Umweg über das Namen-Wechsel-Dich-Spiel nicht mehr nötig ist. Ich glaube die xml braucht man hier sowieso nicht, da ja in der flash.bat die Zeile: "fastboot.exe flash capsule BIOSUPDATE.fv"  genau diese Anweisung, die BIOSUPDATE.fv in den Bereich "capsule" zu flashen, direkt an fastboot gibt!,   Schema: fastboot.exe flash <Bereich od.Partitionsname> <Name des zu flashenden Image od. zu flashender Bin-Datei>   Grüsse, daddle ... View more

Hi, guten Morgen!   Ist noch zu kurz zum beurteilen.   Die Flash-Orgien kosten immer viel Zeit, besonders da ich von jedem Zwischenschritt jeweils ein CWM-Backup mache, alles bisher ohne Root, versteht sich!   Besonders das letzte CWM-Backup nach zig App-Updates hat Stunden gedauert, so dass ich darüber eingeschlafen bin, und ich erst ab heute morgen rebooten und das WakeUp-Verhalten testen kann. (Kein Wunder dass es so lange dauerte, hat 3x hintereinander das Backup gezogen???)   Habe daher nur kurze Sleep -Phasen von nicht mehr als einer viertel Stunde! Da funktioniert es bisher insoweit dass Wlan nach WakeUp immer sofort aktiv war.  Push-Verhalten im StandBy habe ich noch nicht testen können. Sobald ich sicherere Erkenntnisse habe melde ich mich wieder.   Eine Frage noch, warum funktionierte in der flash.bat das "fastboot.exe erase capsule " nicht, wenn es doch in der flash.sh so von Euch angegeben (benutzt) war? Oder kann das nur die fastboot Linux-Version?   Hatte ich genau wie in der flash.sh zwischen oem partition und oem stop partitioning nach erase factory eingefügt..   Grüsse, daddle ... View more

Hallo!   Doch, erst kommt Ota #3, danach kommt Ota #3v2! Bin gestern abend nochmal mit einem Clean Flash von Lollipop zurück auf Stand Ota #2,. Dann wird zuerst das Update Ota #3, danach Ota #3v2 zum Download angeboten. Ota #3v2 ist auch mit ca 10MB nur halb so gross wie Ota #3 mit ~24MB!   Und die Images in Ota #3R2 und im RecoveryPackage V2 (esp.img und capsule.bin) sind diesmal nach Grösse und Inhalt identisch.    daddle ... View more

@TheDoctor              - W I C H T I G  -   Hallo, und danke für das neue Recovery-Paket V2 und das Update Ota #3R2.   Habe das Recovery-Paket runtergeladen, und mir fällt auf, dass in der flash.bat die Zeilen: fastboot.exe erase capsule (?) (in der flash.sh "fastboot erase capsule") . . fastboot.exe flash capsule capsule.bin nicht enthalten sind. Sie stehen aber wohl in der flash.sh.    Da die capsule.bin im KK-Recover-Paket 2 enthalten ist, müsste sie auch wie in der flash.sh mit Flash-Befehlen in der flash.bat für Win-User enthalten sein; sonst bliebe ja das "alte" Bios und gäbe es wieder Verwirrung und Reklamationen und der Thread liefe erneut über!     Sollte ich mich irren, dann korrigiere mich bitte.   lg, daddle   Edit: Ergänzung der fehlenden "fastboot.exe erase capsule"- Zeile   Edit2: Dieser Befehl funktioniert in der Windows  flash,bat nicht  >  geht das vielleicht nur mit der Linux-Version? Andererseits  kommt beim Flashen eine Zeile > "erase capsule failure no such device" (oder so ähnlich!), vielleicht ist ja die  Ziel- Bezeichnung nicht korrekt, bzw. nicht erreichbar?   ... View more