Siemens Gigaset HD795 T

Buenas chicos! He estado surfeando un poco por los posts de este hilo pero no he encontrado nada relacionado con mi duda existencial actual...
Si entras por red al gigaset ves el HDD del equipo (hdd1) pero es posible (aunque sea desde telnet) montar un disco duro externo que tengas conectado al gigaset por usb?

A ver si podeis iluminarme un poco...
Gracias!

Iniciado por stormy

Buenas chicos! He estado surfeando un poco por los posts de este hilo pero no he encontrado nada relacionado con mi duda existencial actual...
Si entras por red al gigaset ves el HDD del equipo (hdd1) pero es posible (aunque sea desde telnet) montar un disco duro externo que tengas conectado al gigaset por usb?

A ver si podeis iluminarme un poco...
Gracias!

Hola stormy, la respuesta es fácil: NO tienes que hacer nada, "pincha" el disco USB y ya está.
Las ubicaciones de los discos en el sistema son:

Código:

Disco duro interno:
/tmp/hdd/volumes/HDD1

Disco USB:
/tmp/usbmounts/sdb1

Otra cosa es desmontar el USB correctamente, porque cada vez que he montado un disco USB en el equipo, al apagarlo y volverlo a montar sobre Windows 7, siempre me dice que el disco tiene errores y que si quiero repararlo, si lo reparas ya queda bien... hasta que vuelves a montarlo en el equipo.
Parece que esto sucede porque el disco USB no se demonta correctamente, yo la solución que he encontrado es desmontarlo desde telnet con el comando:

Código:

umount -f /tmp/usbmounts/sdb1

y luego desenchufar el USB directamente.

Pero esta solución es por ensayo y error, si alguien sabe de alguna mejor que lo diga, please.

Saludos

PD: Por cierto, con el disco USB montado puedes elegir que las grabaciones se hagan sobre este disco, y funciona (yo lo he probado con el firmware anterior, supongo que con este también).

Hola a tod@s, como estamos viendo en el foro, las grabaciones se comportan de una forma errática y parece que es debido a que el equipo no maneja correctamente las grabaciones solapadas.

Yo me he encontrado multitud de casos en los que al editar o programar algo me da el error: Schedule conflict!, cuando en realidad no hay tal conflicto, si se miran las grabaciones que hay al principio y al final de la "conflictiva", se ve que no pasa nada.

Hay como dos casos, uno es cuando termina una grabación periódica y se tiene que reprogramar para el siguiente periodo, en este caso, PARECE que el equipo sólo tiene en cuenta UN sintonizador, y si hay una segunda grabación que se solapa con esta nueva, entonces el equipo pone la nueva en "Pause" y se fuma un puro .
El segundo caso es cuando esto se realiza a traves del menú Timer REC, en este caso, PARECE que a nada que se solape una grabación por el principio y por el final, nos da el "Schedule conflict!", y no se programa nada, y si es una edición de un evento existente, pues lo pone en "Pause" y otro puro que se fuma (en la calle ¿eh?) .

Yo he encontrado la solución a este problema y estoy muy contento con las pruebas que he hecho.
¿Cual es el problema?, pues que el equipo no controla bien el uso de los dos sintonizadores automáticamente.
¿Cual es la solución?, pues que si el equipo no sabe, lo tendremos que hacer NOSOTROS
¿Como se hace esto?, pues diciéndole al equipo que lo que nosotros programemos, que no lo desprograme el hombre, digo el equipo; o sea, que lo que NOSOTROS digamos VA A MISA y punto. Qué bíblico me está quedando ¿no?
¿Cuales son los "efectos secundarios"?, pues que si el equipo peca de "conservador", nosotros nos podemos pasar de "listos" y podemos decirle al equipo que grabe tres o mas cosas a la vez "tranquilamente", en cuyo caso no se lo que pasaría (no lo he probado), pero creo que se colgaría y no grabaría nada
Así pues, la solución es un poco peligrosa porque nos deja todo el CONTROL y la RESPONSABILIDAD a nosotros.

Lo que vamos a hacer es meter un trigger sobre el campo DATE_DAY de la tabla TIMER_RECORD_TABLE de la base de datos /usr/local/etc/dvdplayer/schedule_record.db
El trigger en cuestión es este:

Código:

CREATE TRIGGER TIMER_AFT_DAY_UPD AFTER UPDATE OF DATE_DAY ON TIMER_RECORD_TABLE
BEGIN
UPDATE TIMER_RECORD_TABLE SET Enable=0
WHERE Enable=1;
END;

La forma de activarlo es:
1) Tienes que tener instalado sqlite (ver mi post #514, pero sin instalar el cron, aunque no hace daño)
2) Entra con telnet en el equipo, y ejecuta exactamente lo siguiente:
3) /usr/local/etc/opt/bin/sqlite3 /usr/local/etc/dvdplayer/schedule_record.db
4) CREATE TRIGGER TIMER_AFT_DAY_UPD AFTER UPDATE OF DATE_DAY ON TIMER_RECORD_TABLE
5) BEGIN
6) UPDATE TIMER_RECORD_TABLE SET Enable=0
7) WHERE Enable=1;
8) END;
9) .quit

Y ya está!!

A partir de ahora el equipo grabará todo lo que tu le digas, y se "tragará" todos los eventos que le eches.

Por favor, NO olvides NUNCA que la responsabilidad de que no se pisen los programas es TUYA.
Mira todo lo que grabes dos veces y repasalo bien, cuando el equipo te avise del error "Schedule conflict!", asegúrate de que lo que tu quieres hacer está bien. Porque diga lo que diga el equipo, la grabación se quedará en Ready SIEMPRE.

Aún así, lo "peor" que te puede pasar es que no se grabe algo por TU culpa, pero piensa que ahora tampoco se van a grabar ciertas cosas por SU culpa, así que creo que salimos ganando.

Saludos

Carva, encuentro genial tus ayudas, pero me queda una duda en cuanto al CRON (lo digo por no leerte el hilo completo), si hago como tu dices en el mensaje 514 + lo que pone en 706, ya estara todo bien?, me puede crear algun problema el cron?
Muchas gracias por tu ayuda

Iniciado por marcelg

Carva, encuentro genial tus ayudas, pero me queda una duda en cuanto al CRON (lo digo por no leerte el hilo completo), si hago como tu dices en el mensaje 514 + lo que pone en 706, ya estara todo bien?, me puede crear algun problema el cron?
Muchas gracias por tu ayuda

Hola marcelg, el cron es inocuo, pero no lo necesitamos, simplemente hay que hacer todo lo del post #514 menos el último punto, el punto 14 que se refiere a la instalación del cron.
Si lo instalas o ya lo tienes instalado no pasa nada.

Y si, con hacer ahora los pasos del post #706 ya estaría todo y no te crearía ningún problema el cron.

Aunque parezca muy complejo, lo que hacemos en el post #706 es sólo añadir un nuevo trigger a la base de datos.

Me interesa saber si os funciona y si os soluciona el problema.

Saludos

Iniciado por Carva

Hola stormy, la respuesta es fácil: NO tienes que hacer nada, "pincha" el disco USB y ya está.
Las ubicaciones de los discos en el sistema son:

Código:

Disco duro interno:
/tmp/hdd/volumes/HDD1

Disco USB:
/tmp/usbmounts/sdb1

Otra cosa es desmontar el USB correctamente, porque cada vez que he montado un disco USB en el equipo, al apagarlo y volverlo a montar sobre Windows 7, siempre me dice que el disco tiene errores y que si quiero repararlo, si lo reparas ya queda bien... hasta que vuelves a montarlo en el equipo.
Parece que esto sucede porque el disco USB no se demonta correctamente, yo la solución que he encontrado es desmontarlo desde telnet con el comando:

Código:

umount -f /tmp/usbmounts/sdb1

y luego desenchufar el USB directamente.

Pero esta solución es por ensayo y error, si alguien sabe de alguna mejor que lo diga, please.

Saludos

PD: Por cierto, con el disco USB montado puedes elegir que las grabaciones se hagan sobre este disco, y funciona (yo lo he probado con el firmware anterior, supongo que con este también).

========================
Si si... vale, eso me ha ayudado pero no tanto como esperaba. Mi pregunta era que al montar un disco duro usb, cuando en mi windows me voy a network y veo el gigaset, al entrar solo veo el HDD1 como recurso al que acceder via ethernet (red) y mi pregunta era que como podia acceder al usb montado desde windows para mover ficheros como hago con el disco fisico del gigaset.
Gracias por adelantado.

Stormy, yo hago eso desde telnet, con comandos copy (cp) y move (mv) de linux, pero desde Windows no se ve el disco USB.

En linux no hay unidades como las conocemos en Windows, sino que todos los discos se montan sobre el sistema de ficheros de linux, o sea que el disco USB es una ruta mas dentro de la estructura general. Aunque todo parece homogéneo, dentro de esas rutas puede haber (y hay de hecho) varios sitemas de ficheros a la vez, por ejemplo el ext1 de linux, el NTFS del disco duro principal y el FAT32 del disco USB (suponiendo que lo estuviera formateado en FAT32); y todo junto aparece como una superestructura de carpetas.

Cada uno de esos sitemas de fiocheros se monta y desmonta con mount y umount, y hay muchos montados (en concreto 11 al arrancar, lo puedes ver poniendo el comando mount desde telnet), de estos 11, no todos son visibles y no todos son de escritura.

Desgraciadamente, no se si el disco USB se puede hacer visible desde Windows, si encuentro como hacerlo lo postearé.

Saludos

Iniciado por stormy

========================
Si si... vale, eso me ha ayudado pero no tanto como esperaba. Mi pregunta era que al montar un disco duro usb, cuando en mi windows me voy a network y veo el gigaset, al entrar solo veo el HDD1 como recurso al que acceder via ethernet (red) y mi pregunta era que como podia acceder al usb montado desde windows para mover ficheros como hago con el disco fisico del gigaset.
Gracias por adelantado.

Prueba con Filezilla accediendo a través de la IP y credenciales de acceso (root/ ), es muy similar al acceso a través de telnet pero con visibilidad de toda la estructura Linux. ( Si no me equivoco...) Si da algún error de acceso mira como tienes la configuración del cortafuegos, creo que se tiene que desactivar.