G
glonline
Invitado
[QUOTE = "Killogy, post: 55644, member: 5185"]
¿Pero has cambiado el firmware con el de la primera página?
[/ CITAZIONE]
Si
¿Pero has cambiado el firmware con el de la primera página?
[/ CITAZIONE]
Si
Reproductor M9702 (Clon Oppo UDP-203 - Chinoppo)
- Iniciador del tema Tocinillo
- Fecha de inicio
Si has formateado el pendrive en fat32 y te has asegurado de que en AutoScript.TSS lo has puesto todo correctamente con la IP de tu PC o NAS y el nombre que tiene puesto como recurso tu carpeta compartida y sin usar tildes y asegurándote que AutoSript.TSS lo tienes con sus mayúsculas, puede que te esté pasando lo mismo que a otros usuarios que mencionaban lo mismo tras ese cambio de firmware, que no lograban hacerlo funcionar.
A mi incluso viniéndome con el AutoScript habilitado con el mismo script tan pronto me iba como que no.
Prueba en las opciones del reproductor a eliminar los datos persistentes o algo así se llama que por defecto creo que los guarda en la memoria flash del reproductor y deja el pendrive puesto al arrancar el chinoppo.
G
glonline
Invitado
Actualicé el firmware solo porque AutoScript no funcionó ... Intento eliminar los datos persistentes.
G
glonline
Invitado
Memoria persistente eliminada y restablecimiento a los datos de fábrica.
Intentado pero nada. Luego intenté poner el formato de ventanas de línea final CR + LF ... ¡y FUNCIONA!
Aquí está el archivo en la memoria USB
También intenté volver a colocar solo LF pero no funciona. Solo funciona con CR + LF
Por qué ?
Intentado pero nada. Luego intenté poner el formato de ventanas de línea final CR + LF ... ¡y FUNCIONA!
Aquí está el archivo en la memoria USB
También intenté volver a colocar solo LF pero no funciona. Solo funciona con CR + LF
Por qué ?
G
glonline
Invitado
Telnet ahora funciona ...
Me alegro, solucionado pues.
G
glonline
Invitado
ahora tengo que montar las carpetas ... otra noche ... gracias!
rpelayo
Miembro UHD SDR
- Registrado
- 19 Abril 2019
Increible.
Un cambio de firmware para que un sistema linux funcione con ficheros DOS/Windows y no lo haga con Ficheros tipo UNIX?
Me cuesta creerlo, pero si a tí te funciona así, pues así será. Ver para creer.
G
glonline
Invitado
es extraño para mí también ...
P
pedranic
Invitado
Comprobado con mi Chinoppo de la última conjunta y con el firmware de fábrica y no tengo autoscript habilitado.
G
glonline
Invitado
Seguí probando y encontré que
- CR + LF solo funciona para activar telnet pero luego el comando de montaje no funciona porque solo necesita LF
- en realidad LF funciona, pero tuve que cambiar la pausa de 1000 a 5000
seguro
- solo funciona LF pero con una pausa de 5000
- CR + LF solo funciona para activar telnet pero luego el comando de montaje no funciona porque solo necesita LF
- en realidad LF funciona, pero tuve que cambiar la pausa de 1000 a 5000
seguro
- solo funciona LF pero con una pausa de 5000
rpelayo
Miembro UHD SDR
- Registrado
- 19 Abril 2019
Eso ya me parece mucho más razonable.
En cuanto a lo de la pausa es el tiempo razonable para que arranque la interfaz de red del Chinoppo. 5000 (5 seg), parece suficiente, pero en caso de que fuera algo ajustado no hay problemas en subirlo algo más.
Por cierto, no habeis notado que inmediatamente tras arrancar el Chinoppo empezais a navegar por las opciones del menu, hacia la derecha, y tras un instante el Menu "se resetea" de nuevo a la primera opcion de la izquierda? Luego ya funciona bien. Si espero un rato tras el arranque sin tocar el mando, esto no ocurre. Lo cual quiere decir que algo está arrancando del sistema operativo y lleva su tiempo.
Como referencia incluyo aquí de nuevo las líneas de codigo de script que ejecutan un bucle de espera hasta que la interfaz de red del Chinoppo ha arrancado:
while ! ip route | grep -q -F "eth0"; do
/bin/sleep 1s
done
Estas lineas, si estan embebidas en el AutoScript, deben ir encapsuladas en el CLI(CLI_exec linea-de-comando )
EDITADO: Era una sugerencia mía, pero es posible que ese código de bucle solo funciona en bash script independiente del código embebido en el AutoScript con el CLI(CLI_exec...
Última edición:
Sí de eso también me he dado cuenta, luego pensé que igual ocurre cuando detecta/comprueba en la rutina de encendido los USB y es cuando se va a la opción de Disco.
¿Cómo quedaría esas tres línea encapsuladas con CLI(CLI_exec ?.
Es que en esa página usé otro script que las incluía pero que a mi no me funcionó, pero como a mi cualquier script me iba cuando le daba la gana no sé si es funcional o no puse bien la parte de shares y dirs. Ahora me detecta y monta lo compartido sin problema, pero a saber más adelante.
El Script es este.
rpelayo
Miembro UHD SDR
- Registrado
- 19 Abril 2019
No precisamente. A mí siempre me lo ha hecho con los dos Chinoppos sin AutoScript y sin nada pinchado en los USB.
Sí, este es un bash script que parametriza los shares a montar.
Pero echo en falta la parte de código que arranca la red y servidor de Telnet, que en otra version más amplia también lo parametriza con variables al principio.
Supongo que tendrás un AutoScript.TSS con alguna línea (CLI...) que es la que llama a este bash scrpt, no? Y También habría que arrancar la red con su comando correspondiente. No habrás puesto este script directamente como AutoScript, no? También verifica lo del (LF) al final de cada línea.
Para ver si este script se va ejecutando puedes poner líneas de control del estilo:
/bin/echo "Paso1: Lanzando ejecución de..." > /mnt/sda1/paso1.txt
por ejemplo, al principio del script, a ver si entra y luego antes y después de cada comando mount.
Así vas viendo si ha pasado por ahí,
También puedes redirigir la salida y error estandar de cualquier comando, para ver, en caso de que se ejecuta, si da error:
comando > /mnt/sda1/fichero_error.txt
con un fichero_error.txt distinto para cada comando.
PERO, tiene que haber un AutoScript.TSS con los comandos (CLI... ) que sean los que llamen a este bash script. Lo tienes así?
Pues ahora que lo pienso, no sé si ese encapsulamiento del bucle "while" del bash script funcionaría encapsulado en líneas de AutoScript (CLI...), puesto que estaría funcionando a distintos niveles de ejecución de script cada una de las líneas.
Se podría probar, pero a lo mejor no funciona.
Los ejemplos de programación que estan haciendo en avforums van orientados a un minimo AutoScript.TSS
#MTKAT 0.xx script
CLI(CLI_exec /mnt/sda1/AutoScript/i.sh)
que es el que lanza la ejecución de un bash script ( i.sh en este caso, ubicado en la carpeta AutoScript ) para que pueda funcionar con toda la funcionalidad de shell script, en lugar de ir lanzando comandos (CLI_exec...) uno a uno secuencialmente.
TAMBIEN ES IMPORTANTE que el fichero bash script (i.sh en el ejemplo) tenga permisos de ejecución, que se le podría dar en una linea previa del AutoScript.TSS mediante comando chmod
En fín es lo básico para empezar a programar en shell de UNIX/Linux.
Lo que decia es que puede que lo haga incluso sin tener nada conectado en los USB, simplemente que al comprobar o escanear los USB por si hay algo conectado es cuando coincide que se va a Disco, solo es una sospecha, ya que cuando hay algo en un USB y aparece el icono en pantalla del USB, quizá un poquito antes , es cuando se va a Disco.
Supongo que tendrás un AutoScript.TSS con alguna línea (CLI...) que es la que llama a este bash scrpt, no? Y También habría que arrancar la red con su comando correspondiente. No habrás puesto este script directamente como AutoScript, no? También verifica lo del (LF) al final de cada línea.[/QUOTE]
Pues sí, pensé que iba ahí, vi el código y di por hecho que tenía que ir como AutoScript, por eso no funcionó
no me fijé que el AutoScript es el que contiene los camandos para llamar a ese otro script que estaría en otro archivo . Así que ese batch script debe guardarse como init.sh dentro de la carpeta AutoScript.TSS cuyo script para llamarlo sería...Ahora lo tengo como siempre con el ejemplo de AutoScript que hay en el primer mensaje de este hilo, por ahora estaba cargando lo compartido las últimas 10 veces, pero ahora no, va cuando quiere, por lo que al probar el otro método con el batch script tampoco funciona y no sé si es por el script en si mismo o porque al chinoppo le da que funcione o no cuando quiere.
(LF) está en cada línea.
rpelayo
Miembro UHD SDR
- Registrado
- 19 Abril 2019
Pues si quieres seguir probando y diagnosticando, mi recomendación es la que te puse en el post anterior de ir insertando lineas que escriban mensajes a ficheros de texto, así confirmas si por ahí ha pasado. Y también lo de redirigir la salida estandar y de error a un fichero:
# Si lo haces con un bash script
comando > /mnt/sda1/fichero-error.txt
ó
# Si lo haces desde el AutoScript
CLI(CLI_exec comando > /mnt/sda1/fichero-error.txt)
Suerte.
Última edición:
Nada, que sucede lo mismo que ayer, que va cuando quiere y no crea ningún archivo con mensaje de error ni nada ni el mount.txt es como si no se ejecutase el AutoScript y da igual el tiempo de espera que use. De hecho aún no me deja conectarme por Telnet ,se queda en negro ni me pide usuario.
Probé con otro pendrive que solo me deja formatearlo en FAT y al conectarlo me cargó lo compartido pero al quitarlo y ponerlo otra vez ya no me lo montó y tampoco me creó ni el mount.txt ni el archivo fichero_error.txt .
rpelayo
Miembro UHD SDR
- Registrado
- 19 Abril 2019
SI haces un "reset to factory", por si se limpia algo en su interior, quizá ayude... o no.
Se me ocurre también que en cada arranque, como el aparato tiene 2 USB, asigne sda1 y sda2 segun los timing de arranque y a veces los cambie, por lo que si el pendrive queda conectado a sda2, obviamente no funcionará nada.
Si esta ocurrencia fuese cierta, y si tambien ejecutase AutoScript desde sda2, podrían añadirse lineas con sda1 y tambien con sda2, a ver si alguna de las dos funciona. Porque pinchar dos pendrive replicados en cada uno de los dos USB, a lo mejor es demasiado, pero sí un buen ejercicio de diagnóstico si no hay otra cosa que hacer.
He probado tanto el USB1 que es el lateral como el USB2 que es el trasero 3.0 y nada, ahora ni monta ni deja por telnet, he probado con una APP del móvil para telnet pero me pide puerto.
Lo del Factory lo hice ayer y no mejoró nada.
Me queda por probar si la vez que me monta lo compartido coincide con que me deja entrar por telnet. porque por ahora ni una cosa ni otra y ayer me montó todo 10 veces al menos y hoy también 1 vez cuando fuí a calibrar los ajustes de la TV para HDR y Dolby Vision.
EDITO: "Confirmado" que cuando me logra montar lo compartido es cuando puedo conectar por Telnet.
He creado otro AutoScript añadiendo algunas líneas de otro que he visto en Avforum creo y a parte de estar en CR LF, no crea el archivo ejecutado.txt, pero me monta lo compartido tanto en la carpeta Video como cuando quité esa parte de la línea para que me lo montase en la Raíz del USB. Eso sí la mayoría de las veces que se monta lo compartido lo hace con el USB con nombre USB1 y no con el nombre que le haya puesto yo.
Este es el Script que me lo montó en la carpeta Video (lo cual hace que al entrar en el pendrive veo la carpeta AutoScript y Peliculas o cualquiera que hay en el pendrive, lo cual no me gusta)
El contenido del archivo mount.txt es...
/dev/sda1 on /mnt/sda1 type texfat (rw,gid=100,uid=100) //192.168.1.3/Peliculas on /mnt/sda1/Video type cifs (ro,mand)
Eliminé el archivo mount.txt y las carpetas Video, Peliculas.
Y este cuando quiero que me aparezca al entrar al USB1 y no ver el contenido del pendrive (carpeta AutoScript, BUDA, Video)
No me creó el archivo mount.txt ni ejecutado.txt. Sí me creó las carpetas Películas y Video. Y el AutoScript está en CR LF
Última edición:
