0.7 Cambio automático desde radio a TV y hora.

Buenas tardes a todos.
Aprovecho para saludarles y agradecerles los firm's que mantienen vivo nuestro Gigaset.
Hasta ahora, simplemente leyendo iba solucionando todos los problemas que me iban surgiendo. Con el firma anterior (el 0.6) no he tenido ningún problema. He instalado el 0.7 desde un .ofi generado en un PC con Windows y no he restaurado nada. He buscado canales, accedo en red desde un PC con Debian, veo la epg accediendo a su IP, en fin lo esencial va bien. Solo lo tengo instalado desde hace 4 o 5 días.

Solo me he encontrado con dos temas que no consigo solventar:

1.- Cuando estoy en un canal de radio, a los 30 segundos salta y se va a uno de TV.
2.- Vivo en Las Palmas y el tema de la hora no consigo ponerlo en orden. Con el anterior firm, modificaba el archivo /etc/TZ cambiándole CET por WET y los 0 por 1, -1, etc. sin éxito, es como si no afectara en nada lo que ponga ahí. He puesto que coja la hora de la cadena autonómica, y también he probado a activar la opción de que actualice por internet. (no recuerdo la opción y no puedo mirar en este momento, la jefa está viendo la novela, jejejeje),

De momento es lo que me tiene trabado.
Agradecido si alguien tiene alguna solución.
Un saludo.

ohsielos escribió:1.- Cuando estoy en un canal de radio, a los 30 segundos salta y se va a uno de TV.

Revisa el archivo /var/log/messages para ver si dice algo al respecto.
Justo antes de sacar la versión 0.7 se detectó un problema que impide grabar radios y no se ha solucionado, quizás esté relacionado.

ohsielos escribió:2.- Vivo en Las Palmas y el tema de la hora no consigo ponerlo en orden. Con el anterior firm, modificaba el archivo /etc/TZ cambiándole CET por WET y los 0 por 1, -1, etc. sin éxito, es como si no afectara en nada lo que ponga ahí. He puesto que coja la hora de la cadena autonómica, y también he probado a activar la opción de que actualice por internet.

Prueba esta configuración a ver si te funciona.

Gracias Bittor por la respuesta.
En el log tengo dos archivos, messages y messages.0. En el primero y tras situarme en un canal de radio y esperar medio minuto, tenemos al final del archivo estas líneas:

May 29 16:13:48 (none) ftp.info vsftpd[353]: [root] OK LOGIN: Client "192.168.1.14"
May 29 16:13:49 (none) user.info vdr: [332] TShift: start online recording, channel 2
May 29 16:13:51 (none) user.err vdr: [357] cAudioRepacker(0xC0): skipped 170 bytes to sync on next audio frame
May 29 16:13:51 (none) user.err vdr: [357] cAudioRepacker(0xC1): skipped 170 bytes to sync on next audio frame
May 29 16:14:02 (none) ftp.info vsftpd[358]: [root] OK LOGIN: Client "192.168.1.14"

En cuanto al tema de la hora, de eses hilo me valí para cambiarla cuando tenía instalado el 0.6 y funcionó correctamente. Ahora mismo no recuerdo que datos eran los correctos pero si no recuerdo mal era: CET0CEST,M3.5.0,M10.5.0/03:00:00
Pero no hay forma, le he cambiado CET0CEST por WET0WEST y en vez de 0, 1 y -1 y es como si no hiciera nada. Por supuesto reinicio el VDR tras cada cambio.

Gracias de nuevo.
Un saludo

Parece que tienes el Time Shift puesto. Prueba a desactivarlo y seguramente ya no te pase. Tiene pinta de ser el problema de no poder grabar radios y que cuando intenta empezar a grabar automáticamente, falla y vuelve al canal anterior o algo así.

Ah, vale, lo desactivaré para probar. Peeero con el 0.6 iba perfect. Ya postearé con lo que haya.
Por cierto a nadie mas le ha pasado?.

Es un problema colateral de no poder grabar radios, que es un problema ya conocido de la 0.7. Seguramente le pasará a cualquiera que active el Timeshift.
https://vdr-m7x0.foroactivo.com.es/t1313-trunk-no-graban-las-radios

Efectivamente. Al desactivar el timeshift ya no salta de canal. Primer problema solucionado, al menos para mi que solo oigo la radio una hora diaria aproximadamente.
Gracias Videre y Bittor.

Ahora solo me queda el tema de la hora. Me marca una menos que la real aquí. Seguiré modificando el TZ y desactivaré el servicio NTP que no ha servido, a ver si doy con la configuración adecuada.
Es obligatorio reiniciar tras cada cambio del TZ, verdad? porque me tarda un rato en reiniciar....

ohsielos escribió:Es obligatorio reiniciar tras cada cambio del TZ, verdad?

Sí, es necesario reiniciar.

Decididamente el modificar el archivo TZ con CET o WET y con -2, -1, 0, 1, 2 e incluso 10 no afecta en nada. Es como si no modificara nada.
También he intentado las combinaciones que hay en la página 2 del hilo enlace que pusiste mas arriba y tampoco afecta en ningún sentido.
Ya no sé por donde echar.....

OK, he abierto un nuevo ticket para revisarlo.

OK, gracias Bittor.

Creo que tengo la solución al problema de la hora. No sé cómo se leería antes el fichero /etc/TZ, pero el caso es que lo tradicional en Unix es que se haga caso a la variable de entorno TZ si está definida. Con poner esta línea en algún script del arranque funciona:

Código:

export TZ=`cat /etc/TZ`


Yo la he puesto al principio de /etc/rc y me pone una hora menos, tanto por telnet como en el OSD. ¿Como lo ves ahí, Bittor? ¿Subo el cambio tal cual?

Según la FAQ de uClibc tendría que leer ese fichero para la zona horaria, por lo que aunque ahora funcione con el export porque no hace caso de /etc/TZ, en un futuro cuando uClibc haga bien su trabajo se establecería dos veces y no sé si podría haber algún problema.

Puedes subirlo (en el /etc/rc es un buen sitio para que el syslog tenga la hora correcta) como solución temporal hasta corregir el problema real y de momento cualquiera que tenga este problema puede arreglarlo de esta manera editando un simple archivo.

Me da en la nariz que este problema y el de grabar radios va a ser por la actualización a gcc 4.7.0.
Ya en su día al actualizar la versión de uClibc se produjo el problema de que no se podían hacer grabaciones, así que habrá que retomar el tema para ver si va bien con la última versión de uClibc.

He hecho una pequeña prueba cambiando la zona horaria y funciona bien sin el "export TZ=`cat /etc/TZ`" en /etc/rc.

Aquí los comandos por telnet:

Código:

~ # cat /etc/TZ
CET-1CEST,M3.5.0,M10.5.0/03:00:00
~ # date
Sat Jun  9 11:56:58 CEST 2012
~ # echo CET0CEST,M3.5.0,M10.5.0/03:00:00>/etc/TZ
~ # date
Sat Jun  9 10:57:41 CEST 2012
~ # tail -4 /var/log/messages
Jun  9 11:53:10 (none) user.info vdr: [190] EPGSearch: check for timer conflicts
Jun  9 11:53:10 (none) user.info vdr: [190] EPGSearch: check for timer conflicts - done
Jun  9 11:56:39 (none) auth.info login[213]: root login on 'pts/0'
Jun  9 10:59:38 (none) user.info vdr: [189] system time changed from Sat Jun  9 10:59:14 2012 (1339235954) to Sat Jun  9 10:59:38 2012 (1339235978)

Pensaba que era necesario reiniciar, pero se cambia de hora al momento.

He probado a reiniciar y se ha mantenido una hora menos.

¿puede alguien confirmar que va bien (asegurándose que no tiene el "export TZ=`cat /etc/TZ`" en /etc/rc)?

Te adjunto mi archivo rc. Por cierto cuando Videre puso su post puse en la línea 2 (a continuación de #!/bin/ash) el texto que puso él: export TZ=`cat /etc/TZ` quedando así las dos primeras líneas:

Código:


#!/bin/ash
export TZ=`cat /etc/TZ`
.
.


pues al reiniciar me quedé sin imagen y el led parpadeando sin llegar a cargar el S.O., me tocó reinstalar el firm.
Bueno, te dejo mi rc a ver como lo ves...

Código:

#!/bin/ash

if [ X"${OSDLOG}" = X"YES" ]; then
    source /etc/rc.debug
fi

source /etc/rc.conf

if [ X"${syslogd_flags}" != X"NO" ]; then
    /bin/mv /rw-flash/log/messages* /var/log
    echo -n "starting syslogd ... "
    /sbin/syslogd ${syslogd_flags}
fi

echo -n "execute pic_tool ... "
/usr/sbin/pic_tool ${pic_tool_flags} &

echo "lircd daemon"
/usr/sbin/lircd ${lircd_flags}

exec /bin/ash /etc/rc.local

Yo entro siempre con filezilla subo y bajo los archivos pertinentes. Por telnet no lo he hecho nunca, tendrías que darme una charla

Es cierto, bittor. Ya no sé cómo probé la otra vez, quizá supuse que con la versión 0.7 funcionaba mal en cualquier caso y no leía el fichero. Lo que he comprobado ahora es que ambos métodos funcionan. La variable de entorno tiene prioridad sobre el fichero, pero si no está establecida, el comando date lee el fichero /etc/TZ cada vez que se llama. Lo he visto con el strace.

Así que el problema de ohsielo no lo podemos reproducir. ¿Quizá en Canarias la emisión de la hora de los canales es distinta? Ohsielo, ¿qué otros canales has probado aparte de la autonómica? Las privadas nacionales son las únicas que emiten en toda España con las mismas frecuencias. Si el problema viene de que las públicas emiten la hora de otra forma, quizá con las privadas no te pase. Aún así sería un bug a corregir.

Si no recuerdo mal, por defecto salió Antena 3 y como la hora no cuadraba, puse que cogiera la hora de la autonómica canaria con idéntico resultado.

ohsielos escribió:Por telnet no lo he hecho nunca, tendrías que darme una charla

Para conectarte por telnet te hace falta un programa (normalmente también llamado telnet), en los últimos Windows no viene instalado por defecto, así que tendrás que ir a los programas de Windows e instalarlo y si usas Linux casi seguro que ya lo incluye.

Luego tendrás que abrir una consola (en Windows "Símbolo de sistema" y en Linux "terminal") para poder escribir comandos, luego ejecutas "telnet 192.168.1.3" (sin las comillas y cambiando el 192.168.1.3 por la ip local de tu giga), después te pedirá el usuario que es root y la contraseña que es l1nux (es una ele minúscula y un uno después).
Ahora ya puedes ejecutar los comandos que he puesto antes (los que están después de la almohadilla) para ver si te cambia la hora.

Hola Bittor. Entro desde un PC con Debian. Esto es lo que me sale con los comandos que pusiste antes. Te comento que las primeras líneas son el archivo TZ que me iba bien en el firm 0.6 y que tenía guardado en el ordenador desde hace un montón, por eso salió diferente. Observo que sale unos errores al final.......

Código:

~ # cat /etc/TZ
CET0CEST,M3.4.0,M10.5.0/03:00:00
~ # date
Mon Jun 11 18:19:53 UTC 2012
~ # echo CET0CEST,M3.5.0,M10.5.0/03:00:00>/etc/TZ
~ # date
Mon Jun 11 19:20:51 CEST 2012
~ # tail -4 /var/log/messages
Jun 11 19:20:44 (none) user.err vdr: [482] cAudioRepacker(0xC0): skipped 392 bytes to sync on next audio frame
Jun 11 19:20:44 (none) user.err vdr: [482] cAudioRepacker(0xC1): skipped 110 bytes to sync on next audio frame
Jun 11 19:20:44 (none) user.info vdr: [312] EPGSearch: timer conflict check finished
Jun 11 19:20:45 (none) user.err vdr: [482] PES packet for stream 0xC0  shortened by 184 bytes (expected: 3470 bytes)
~ # tail -4 /var/log/messages
Jun 11 19:20:44 (none) user.err vdr: [482] cAudioRepacker(0xC0): skipped 392 bytes to sync on next audio frame
Jun 11 19:20:44 (none) user.err vdr: [482] cAudioRepacker(0xC1): skipped 110 bytes to sync on next audio frame
Jun 11 19:20:44 (none) user.info vdr: [312] EPGSearch: timer conflict check finished
Jun 11 19:20:45 (none) user.err vdr: [482] PES packet for stream 0xC0  shortened by 184 bytes (expected: 3470 bytes)

Pero la hora ha salido bien

Gracias compañeros.

Pienso que lo estabas editando con un editor que no es compatible con los retornos de carro de Linux, por eso al añadir la línea que decía Videre luego no te arrancó, porque no "reconocía" el archivo y no sabía qué hacer.

Al hacerlo por telnet eliminamos ese problema.

Entonces no hay ningún bug al obtener la zona horaria de /etc/TZ.

Utilizaba el Gedit para editarlo. Yo imaginaba que al trabajar en linux se iban a entender de rechupete, pero puede ser que no como bien apuntas.
El caso es que, sospechando algo de eso, una vez guardado el archivo TZ una vez editado y subido con filezilla al gigaset, lo revisé un par de veces bajándolo de nuevo para comprobar que se había grabado bien y, efectivamente, se había guardado en TZ tal como yo lo había editado en el PC con Gedit..

Lo que si es seguro es que cuando tenía el firmware 0.6 lo edité con notepad++ desde un PC con windows, ya que por aquel entonces no había empezado a hacer mis pinitos con linux.

Concluimos entonces que el Gedit no nos sirve para editar los archivos??? cual sería válido?

Si editaste con gedit el archivo que habías guardado con notepad++ sí es posible que te mantuviese el formato de Windows. Pero si el fichero es nuevo o viene de Linux dudo mucho que no te lo haga correctamente en formato Linux. De hecho, viendo en ejecución el gedit, veo que al "guardar como" tiene un campo para elegir el formato de fin de línea. Así es como se comporta el editor que yo uso, el emacs, que por cierto permite editar ficheros directamente por ftp. Aunque también es muy cómodo usar el scp para copiar en uno y otro sentido.

Si el problema es ese, lo extraño es que en 0.6 te funcionaba bien y ahora no, pero cualquier pequeño cambio en la librería de C puede haber hecho que deje de funcionar el fichero TZ en formato Windows.

No se si 'mespliquè' bien, a veces soy muy espeso, lo reconozco.

El firm 0.6: lo compilé en windows y el cambio del TZ lo hice con el notepad++ ya que leyendo vi que no servía el notepad de Microsoft. No tenía ni idea de linux ni PC con ese S.O. en aquellos tiempos.

El firm 0.7: obtuve el .ofi desde windows porque me parecía complicado con linux, pero eso fue todo. Entraba y salía por red con filezilla desde un PC con linux Debián. Editaba el TZ o el rc con este PC y con el editor gedit que trae instalado.

Ahora le echaré un vistazo para entender los comandos por telnet por si en un futuro he de entrar por ahí. Entiendo que la primera línea: cat /etc/TZ en para leer el archivo TZ que nos da a continuación, date para ver la fecha, la de echo CET0CEST,M3... es para sobrescribir dicho archivo, date de nuevo para verificar el cambio y tail para ver el log supongo.

Como colofón: el gedit servirá o no para editar estos archivos?

El gedit sí que serviría porque es un editor de Linux, pero como dice Videre tiene un parámetro para los retornos de carro, así que si usas el gedit y guardas el archivo con los retornos de carro de Windows pues no sirve.

Hace mucho tiempo usaba el editor del Krusader y por defecto no guardaba en UTF-8 y me estropeaba los acentos, eñes, etc., por lo que es necesario mirar que la configuración por defecto sea correcta.

Hay veces que el editor no es capaz de reconocer correctamente el formato del archivo o lo guarda con "trucos" que no son estándar para poder reconocer el archivo y surgen estos problemas.

Sobre los comandos los has entendido todos bien, aunque lo suyo será que se pueda cambiar el archivo /etc/TZ desde el VDR.