Perdona, ya había leído ese comentario tuyo, lo que no sabía que habías hecho la prueba teniendo ya la versión 1.4.6 instalada. Gracias por responder.Cita:
Iniciado por cbc
Versión para imprimir
Perdona, ya había leído ese comentario tuyo, lo que no sabía que habías hecho la prueba teniendo ya la versión 1.4.6 instalada. Gracias por responder.Cita:
Iniciado por cbc
Bueno, parece que el amigo Nalor ya ha colgado las explicaciones de su procedimiento (RockchipDumpsplit) para hacer backups:
En alemán: http://www.android-hilfe.de/sonstige...ml#post7472925
Más resumido, en inglés: http://www.freaktab.com/showthread.p...638#post167638
Voy a tratar de resumirlo en español.
Si recordáis, el procedimiento que referenciaba Jotam, en el post 170 de este hilo: http://www.freaktab.com/showthread.p...ew-RK-2-1-tool y usando la herramienta Android tool 2.1 (http://www.freak-tab.de/finless/rk_tool21_how_to.zip) se podía hacer un backup de todo el ereader.
Las instrucciones de Finless son muy detalladas y, siguiéndolas al pié de la letra, no debe haber problema alguno.
Pero fijaros que se trataba de ir extrayendo uno a uno cada uno de los ficheros *.img que componen la memoria que queremos guardar. Para ello, la guía esencial es el fichero parameter.txt que es una especie de mapa de la memoria: de donde a donde va cada imagen, esto es la madre del cordero, lo que hay que respetar a ultranza pues, en caso contrario, las imágenes van a solaparse.
Por ejemplo, si una parte del fichero parameter.txt es así:
0x00002000@0x00002000(misc),0x00006000@0x00004000( kernel),0x00006000@0x0000a000(boot),
y queremos extraer el fichero boot.img, hacemos lo siguiente: en AndroidTool2.1 (en ROM_Dumper_Tool, Advanced function, Extractimage) y en la casilla Start debemos copiar y pegar 0x0000a000 y luego en Count, lo que va delante de la arroba: 0x00006000 .
Este procedimiento ya es laborioso de por sí. Además, para extraer user.img, que es el resto de nuestra tarjeta sd interna que no está ocupado por las img del sistema operativo, había que hacer una complicada operación con cifras hexadecimales, pasarlas a decimales, luego otra vez a hexadecimales, etc.... Ya digo que, siguiendo estrictamente las instrucciones de Finless no debe haber problema, pero es ciertamente complejo.
El procedimiento propuesto por Finless tiene dos riesgos:
1) Copiar y pegar mal los datos de cada img (olvidándonos de poner algún cero, por ejemplo).
2) Calcular mal los datos de user.img
El riesgo de hacer eso mal, es que las imágenes van a contener datos de otras imágenes. Es fácil de entender: si tú no pones bien hasta donde llega una imagen, va a coger un trozo de la siguiente, y luego, al restaurarla, se va a montar una sobre otra y, sencillamente, el ereader o no va a arrancar o va a entrar en bootloop (en un bucle infinito) (cosa, por cierto, que me pasó a mí!!!)
La herramienta RockchipDumpsplit de Nalor, es genial, simplemente evita todo ese riesgo y hace todo el trabajo por nosotros (particularmente los complicados cálculos hexadecimales).
Lo que va a hacer, para que tengamos un esquema mental en la cabeza, es lo siguiente:
1) Extraer de golpe toda la memoria con AndroidTool2.1 (lo de Finless): es decir, un backup completo que tendrá un tamaño del que tenga la SD interna, 4GB u 8GB o lo que sea.
2) Dividir (to Split) ese fichero global en las distintas particiones o imágenes del backup: system.img, boot.img, recovery.img, etc.
3) Cuando queramos restaurar nuestro backup, debemos, con la otra herramienta incluida en el Androidflashtool 2.1 (ROM_Flash_Tool_137.exe), flashear todas esas imágenes, y ya está.
La ventaja es que nos ahorramos todos los pasos previos de extracción de las img y no corremos ningún riesgo.
Pasos a dar:
1) Bajar todas las herramientas, primero el AndroidFlashtool: http://www.freak-tab.de/finless/rk_tool21_how_to.zip y lo descomprimimos en un directorio que llamaremos c:\Flash o lo que queramos (propongo ese nombre para que no nos liemos). Se creará un directorio llamado c:\Flash\RK Rom Dumper and Flasher for Windows\ que dentro tiene otros subdirectorios que luego veremos.
2) Bajar la herramienta de Nalor: http://www.android-hilfe.de/attachme...split_0.91.zip y descomprimirla en un directorio que llamaremos c:\Split
3) En el directorio c:\Flash\RK Rom Dumper and Flasher for Windows\, ejecutamos ROM_Dumper_Tool.exe y se abre una aplicación llamada AndroidTool 2.1 (abajo nos sale una leyenda que pone: "No found any devices" , .
4) Conectamos el lector al PC con el cable USB (no es preciso que hayamos activado la depuración USB ni que seamos root, ni nada por el estilo, ni que aceptemos conectarlo al ordenador para transferir datos, a pelo).
5) En AndroidTool 2.1 (en la pestaña Download Image) vemos que, abajo, la leyenda ha cambiado a: "Found one MSC device". Es posible que, la primera vez, tarde algo mientras carga el driver. A continuación hacemos click en Switch y la leyenda cambia a "Found one LOADER device", eso significa que nuestro ereader está listo para ser restaurado o para hacer backups o extraer imágenes individuales. Lo dejamos así, de momento.
6) Nos vamos al directorio c:\Split y ejecutamos RockchipDumpSplit.exe y nos sale una ventana preguntándonos si queremos ir a la calculadora, aceptamos con RETURN: y nos pregunta por el tamaño de nuestra flash (nuestra tarjeta interna, en el caso del Tagus Lux 2014 son 4096MB) luego nos pregunta por las las páginas Flash (esto lo explica Finless en sus instrucciones, yo no se muy bien lo que es, pero ponemos 1). Nos sale un mensaje diciendo que ha copiado en el portapapeles 0x800000 que es el dato que necesitamos en AndroidTool 2.1 para indicar la longitud de todo el backup, de toda la memoria (además nos calcula el tiempo que tardaremos en extraer toda la imágen: 7m ).
7) Volvemos a Androidtool2.1 y vamos a la pestaña Advanced, abajo, en Exportimage, ponemos 0 en Start y pegamos lo del portapapeles (0x800000) en Count. Le damos a Exportimage y emnpieza a exportar el backup (tarda unos 7 u 8 minutos). Cuando termina nos sale un mensaje: Export Image Success
8) Vamos al Directorio Output que está dentro de c:\Flash\RK Rom Dumper and Flasher for Windows\ y ahí veremos un fichero llamado ExportImage.img, que tiene exactamente 4GB o 4096MB!!!, el tamaño de nuestra SD interna: ese es el backup completo de nuestro ereader. Lo primero que hacemos es cambiarle el nombre y ponerle lo que queramos, ejem: CopiaSeguridad.img . Copiamos este fichero, y nos vamos al directorio C:\Split\
9) Cerramos la ventana del RockchipDumpSplit.exe que se nos había quedado abierta, y dejamos caer el fichero (que habíamos copiado, el CopiaSeguridad.img) sobre el nombre de la herramienta de dividir: RockchipDumpSplit.exe y se nos vuelve a abrir una ventana del Sistema Operativo, pero en este caso sale un listado de todas las imágnenes cuya información está contenida en el fichero parameter.txt, que el programa ha detectado dentro de nuestra CopiaSeguridad.img!!!!. Es decir, ha detectado toda la información que antes, debíamos ir detallando según el procedimeinto de Finless (ver arriba).
10) Le damos a RETURN y empieza a extraer todas las imágenes, una por una, y nos las coloca en un directorio con el mismo nombre de nuestra CopiaSeguridad.img : CopiaSeguridad_Split !!!!, por si repetimos el proceso con otras imágenes.
11) Ya tenemos hecho nuestro backup completo y separado por imágenes y si queremos hacer un restore, basta con utilizar la otra herramienta: ROM_Flash_Tool_137 que está dentro de c:\Flash\RK Rom Dumper and Flasher for Windows\, lo único que necesitamos es el Loader (que ahora mismo no sé donde lo tengo, pero lo busco y lo subo)
Bueno, pues colorín colorado,...
Por supuesto no me hago responsable de lo que le pueda pasar a quien pruebe todas estas cosas, en el fondo todos somos un poco aprendices de brujo.
Evidentemente, el autor de todo esto es Nalor: el amigo austriaco cuya página es: http://www.android-hilfe.de/allgemei...ml#post7472925
Seguimos aprendiendo del amigo Nalor,
Su herramienta también crea dos ficheros cfg que aparecen en el directorio donde se guardan las img (ver mi post anterior).
Acabo de preguntarselo y me ha explicado su utilidad.
Cuando vamos a restaurar nuestro ereader, lo mejor es utilizar la herramienta ROM_Flash_Tool_137 que está dentro de c:\Flash\RK Rom Dumper and Flasher for Windows\. La otra, AndroidTool 2.1 genera ciertos errores con user.img (el backup de nuestros datos en la tarjeta SD interna) y en userdata.img (nuestros datos personales, contraseñas, etc...).
Pues bien, en el ROM_Flash_Tool_137 hay que ir poniendo, una a una, las imágenes que queremos restaurar y buscándolas en el directorio en que estén. Con el procedimiento de Nalor, habíamos visto como se situaban en un directorio bajo el nombre de la imagen backup completa, pues bien, los ficheros cfg sirven para cargar en ROM_Flash_Tool_137 directamente la situación de las img a restaurar. Para ello basta con situarse sobre la pantalla del ROM_Flash_Tool_137 y con el botón de la derecha seleccionar el fichero cfg que se ha creado en el mismo directorio de las img (el que termina en _ASCII.cfg).
Por cierto, el Loader, me dice Nalor, no hay que cargarlo, por ello en sus cfg aparece en blanco, sin situación en ningún directorio.
Mola! Un gran trabajo el que os habéis currao. Podéis estar contentos.
Pero ahora estáis funcionando en base a generar imágenes de particiones y restaurarlas, la repanocha sería que se pudiera cambiar el recovery por CWM, CTR o TWRP.
De esa forma se podría hacer el backup desde el propio lector a la SD y restaurar cuando se quisiera. Aunque quizá no sea tan interesante como en un teléfono.
Por otro lado permitiría instalar también algunas cosas como el root, actualizaciones, ROMs cocinadas, borrar caches, cargar aroma file manager para gestionar archivos que no se puedan mover desde Android, etc.
Yo lo tengo en el móvil, y aunque estoy empezando, esta muy bien.
Usando la aplicación que comentáis, sería como hacer hard reset todas las veces.
En cualquier caso, ya os sirve para tener un backup, que es lo importante.
Enviado desde mi bq Aquaris mediante Tapatalk
¡Buen trabajo!
Controlado el proceso de backup y flasheado con seguridad, el segundo paso sería la sustitución en los zip de actualización de aquellas aplicaciones mejorables.
Por ejemplo el CoolReader que trae por defecto por el de jotas, el FBReader por otro más actual y versatil, sustitución de fuentes no compatibles por otras compatibles para nuestro idioma, diccionarios, screemsavers, etc.
Todo en su conjunto convertiría a este lector en el más versatil y completo de los que se comercializan, ahora mismo, en 6". Sobre todo si se comparan con sistemas cerrados como los del Kindle, Kobo y demás.
Y si algun programador se pusiera en la faena, lo siguiente sería una nueva compilación del OS que optimizara su rendimiento y consumo.
Al final, el "invento" de Android en los lectores electrónicos pudiera ser una buena noticia para los sufridos usuarios de esta tecnología.
Saludos.
Absolutamente de acuerdo, creo que sería el siguiente paso, pero ahí, tanto mi amigo Nalor como yo patinamos bastante, ya sería cuestión de que otros tomaran el testigo.Cita:
Iniciado por Barba Gris
Yo estoy de acuerdo de que este lector en realidad es una tableta Android con pantalla de tinta electrónica, y por tanto debería ser muy adaptable a las necesidades del usuario, entre ellas lo que tu citas, y no solo eso, también está el tema del TTS, que aunque cuando lo compras te dan una licencia de IVONA que luego no funciona. Si esperas que los fabricantes lo solucionen te puedes pasar meses, mientras que alguien que sepa como arreglarlo puede dar la solución en muy poco tiempo.
Poco a poco.
Por probar no se pierde nada. Y en mobileread hay una sección dedicada que se lee bastante, con miles de usuarios, entre los que se cuentan reputados programadores.Cita:
Iniciado por paconovaton2
Creo que sería interesante que Nalor y tu publicárais los hallazgos presentes. Tanto en lo referente a las diferencias hard entre modelos (5 y 8 leds), firmwares y finalmente método de backup y flasheo.
El hilo en que se comenzó a comentar es este: http://www.mobileread.com/forums/sho...d.php?t=210843
Donde recibió bastantes críticas de algunos usuarios...
Sería como echar la caña, a ver si alguien pica y esto se convierte en proyecto. ;)
Saludos.
Sobre el TTS,
mi amigo Nalor ha investigado por qué no va el TTS en los TAGUS LUX y, después de decompilar, o como se diga, el fichero OnyxTTS ha visto que, los ficheros de voz que busca son:
" private static final String mSupportedLanguages[][] = {
{
"deu", "DEU", "libvoice_de_marlene", "vox_de_marlene22v", "marlene", ""
}, {
"deu", "DEU", "libvoice_de_hans", "vox_de_hans22v", "hans", ""
}, {
"eng", "GBR", "libvoice_en_gb_amy", "vox_en_gb_amy22v", "amy", ""
}, {
"eng", "GBR", "libvoice_en_gb_brian", "vox_en_gb_brian22v", "brian", ""
}, {
"rus", "RUS", "libvoice_ru_tatyana", "vox_ru_tatyana22v", "tatyana", ""
}, {
"pol", "POL", "libvoice_pl_agnieszka", "vox_pl_agnieszka22v", "agnieszka", ""
}
};"
Evidentemente, como nuestra conchita no está incluida en ese casting, no va a funcionar en la vida. Yo no sé por qué, cuando adaptan el software chino, no repasan las cosas un poco, en vez de ¡hala! a vender aparatos y luego que los usuarios se vuelvan locos. Desde luego que el responsable de la adaptación del software (RAS) puede estar contento.
Evidentemente, me refiero a IVONA, la voz robotizada de PICO se ve que es la que mejor le suena al RAS y por eso la deja y nos obliga a escucharla. Ya sabemos que sobre gustos no hay nada escrito, pero que no nos obliguen a comernos el plato que no nos gusta.
Gracias, paconovaton2, muy interesante.
Lamentable eso de que se limite el soporte de idiomas y quienes lo adaptan a España no se preocupen. Así que sólo inglés, alemán, ruso y polaco. Pues que bien! Y el español (o francés o portugués o italian u holandés o ...) que le den.
Pero no me sorprende. En los Onyx de 2011-2012 (y anteriores) por ejemplo son incapaces de partir las sílabas correctamente desde Coolreder, porque para silabear sólo puede usar un fichero que se llama "Russian_EnUS_hyphen" y por tanto sólo funciona en ruso e inglés. Y ese bug no sólo estaba en los Onyx de 2011 (y nunca fue resuelto) sino que ya estaba en los de 2009 e incluso en los primeros Papyre (Jinke Hanlin) de 2007. La única solución es renombrar el fichero "Spanish_hypen" a "Russian_EnUS_hyphen" .
Y siguiendo con los Onyx de 2011: muchas fuentes no permiten acentos, así que se cargan caracteres en español (y francés, alemán, portugués, checo, polaco ...) pero mira como en inglés funciona nadie se molestó. La única solución es borrar esas fuentes y sustituirlas por otras.
Hace años que esos errores se comentaron tanto aquí como en los foros de Mobileread, pero ni caso
Yo me imagino que esta empresa, que por lo visto es todo lo mismo, Tagus = CDL = Espasa Calpe, debe tener algún mecanismo de control de calidad.
Debe haber un responsable de la adaptación del software que mande en algunos programadores y que a su vez, ese responsable, debe responder ante algún superior. Pues se ve que toda la cadena es una chapuza, y deben estar cobrando incentivos por productividad o algo así, porque probablemente el de más arriba sea el campeón de la chapuza y no se dé cuenta de lo que está pasando.
Lo bueno sería tener acceso a los directores de la empresa y poder decirles: "oiga, que tienen ustedes una manada de incompetentes".
Y es una pena, porque este aparato, si corrigieran esos problemas, podría ser uno de los mejores del mercado.