À propos de daddle

björnp schrieb: Danke für den tip. Habe den Haken gerade entfernt. Würde aber dagegen sprechen das es in der nacht auch passiert ist, mit angeschlossenem Netzteil. Test aber jetzt trotzdem.   Hi Björnp,   die Annahme entsprechend dem nominellen Eintrag, dass  das Wlan nur im Akkubetrieb minimiert wird  und bei Netzteilbetrieb nicht, könnte irreführend sein, Denn den Strom holt sich das Wlan-Modul immer vom Akku.   Minimierung des Akkuverbrauchs bedeutet erst mal eine Reduktion der Sendeleistung, Jede Funktion im Tab holt sich den Strom vom Akku, Netzteilbetrieb heisst nur dass nachgeladen wird.      Es könnte also durchaus der Wlan-Optimierung schnurzpiepe sein, ob ein Netzteil angeschlossen ist oder nicht. Wenn doch, wird eben Energie nachgeladen; wenn nicht, macht die Optimierung= Minimierung des Akkuverbauchs= Minimierung des Stromverbrauches  Sinn, um den Akku zu schonen!   daddle     ... Afficher plus

Hallo Lifetabber,   die Updates müssen sequentiell installiert werden, also nacheinander, Wenn du Ota #3 installiert hast, wird dir OTA #3v2 als Update angeboten. Der Flash-Vorgang dauert jeweils nur ein paar Minuten , Bios-Flash abwarten, dann eine Taste Vol. - oder + zum neuen System-Start.    Du kannst zwar das recovery-paket V2.1 direkt installieren, dann aber werden deine Daten gelöscht, oder du editierst dir die flash.bat oder flash.sh wie TheDoctor das in einem vorherigen Post beschrieben hat, um die Daten zu erhalten.   Aber du landest auf beiden Wegen bei Version OTA #3V2. also gleicher Softwarestand. Und mit den OTA's bist du auf der sichereren Seite; keine Editier-Fehler in der Flash.bat!   daddle ... Afficher plus

  Hi @björnp   Auch ich hatte (bei mir direkt  nach OTA #3-Update, bei anderen schon vorher) das Problem, dass entweder Wlan nicht aufwachte > Abhilfe war ein Refresh des Netzwerkes (der SSID), oder das Wlan-Symbol zeigte Weiss für volle Aktivität an, trotzdem gab es keinen Daten aus dem i-Net. Da half nur WLan ganz aus und wieder anschalten.   Zusätzlich war im StandBy Wlan trotz Häkchen bei "Immer aktiv" nicht aktiv, und beim WakeUp dauerte es mehr als eine Minute,  bis die Wlan-Verbindung wieder stand, oder Icon blieb Orange ohne Verbindung.so dass nur  ein SSID-Netzwerk-Refresh (neu verbinden lassen) half.   Hast du das Häkchen bei Wlan-Optimierung> Akkuverbrauch bei aktiviertem Wlan optimieren angeXt? Nimm das mal raus, vielleicht senkt das die Sende-Leistung des Wlan-Moduls zu stark ab, dass ein unempfindlicherer Router denkt das Tab wäre abgeschaltet.   Auf jeden Fal hat bei mir und anderen das letzte Update OTA #3v2, bzw. das Recovery-Paket V2.1 alle diese Wlan-Fehler behoben.  Und ob du am Router so genau ablesen kannst das Tab verlöre die Verbindung bezweifle ich, da laufen meist im Hintergrund noch shake hands Prozesse ab, die dir nur nicht angezeigt werden; und bei aktivem Daten-Traffic sofort die Verbindung voll aktivieren.  Aber da weiss McB mehr dazu als ich. (hoffe ich!)   daddle ... Afficher plus

Blaubär schrieb: ich schau mal, wie es mit dem WLAN jetzt läuft, hatte bisher aus dem Standby heraus und im laufenden Betrieb immer wieder Abbrüche. Hi Blaubär,   wofür fragts du vorher eigentlich hier und antworten dir andere User? Es wurde eindeutig gesagt, der Wlan-Fehler ist mit dem   neuesten Update behoben wurden! Da "brauchst net zu schaun", geniesse es lieber!   Und TheDoctor gibt das Update von Beta auf Allgemein frei. Mehr Reassurance können wir dir nicht bieten.   MfG, daddle   ... Afficher plus

 HI @Blaubär    die Option Am Beta-Test teilnehmen ermöglicht Medion die Updates zuerst an interessierte User freizuschalten, Dies wurde  bei dem Lollipop-Update erstmals eingeführt, da es eindeutig experimentell war, die User (und der neue Verkaufsprospekt drängten) Lollipop einzuführen und zu veröffentlichen, und User konnten damit steuern wer es ausprobieren möchte.   Da Lolllipop noch buggy war, wurde es zurückgezogen, die mit OTA #3 erstmalig eingeführte Beta-Testteilnahme-Option für das Lollipop-Update, bot jetzt die Möglichkeit auch das verbesserte, den Wlan-Fehler ausmerzende KitKat-Update OTA #3v2 vorab von einigen Usern testen zu lassen, und KitKat-Ota #3v2 wurde daher als Beta markiert. Siehe Post 1 von @TheDoctor.   Da mit OTA #3v2 der Wlan-Fehler beseitigt wurde, neue Fehler(chen) bisher nicht aufgetreten / gemeldet  sind, kann man m.E. unbesorgt Ota #3v2 als Beta installieren, eine Notwendigkeit zum Zurück-Flashen besteht daher nicht. Wobei das mit dem veröffentlichtem Android-Recovery-Paket (V2.1) ein Kinderspiel ist.   Das Wlan funktioniert jetzt einwandfrei. Ich denke die Freigabe für alle wird schnell folgen.   daddle     ... Afficher plus

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 ... Afficher plus

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     ... Afficher plus

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 ... Afficher plus

  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 ... Afficher plus

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.   ... Afficher plus

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 ... Afficher plus

@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 ... Afficher plus

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 ... Afficher plus

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! ... Afficher plus

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

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   ... Afficher plus

@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   ... Afficher plus

@TheDoctor   I hope I made your day (Weekend)!  ... Afficher plus

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) ... Afficher plus

@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 ... Afficher plus

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!  ... Afficher plus