"Comprobar sistema de archivos" cada 2x3

Me acabo de dar cuenta en la firma de RedSpider que usa un FreeAgent de 500GB y si no recuerdo mal es exactamente el mismo al que le tuve que desactivar el spindown interno del disco.

Si tienes Windows, instalando el CD del disco duro puedes desactivarlo y si sólo tienes Linux son unos comandos (a ver si encuentro la página).

Posix escribió:
RedSpider, ¿puedes copiar el contenido de /etc/inittab?

Código:


#
# /etc/inittab
#

#----- system start -----

tty0::sysinit:/bin/mount -o rw,nosuid,nodev,noexec -t proc proc /proc
tty0::sysinit:/bin/mount -o rw,nosuid,noexec -t devpts devpts /dev/pts
tty0::sysinit:/sbin/ifconfig lo 127.0.0.1
tty0::wait:/bin/ash /etc/rc.mini

#----- system halt -----

tty0::shutdown:/bin/ash /etc/rc.halt



bittor escribió:
RedSpider puede probar a desactivar el TimeShift o modificar el script de apagado para que no desmonte el disco mientras el VDR está funcionando.

RedSpider ha desactivado el Timeshift y continua con el mismo problema.

Lo que no entiendo es porqué a esas horas de la madrugada se montan o desmontan las unidades, cuando yo he apagado el giga unas horas antes.

bittor escribió:Me acabo de dar cuenta en la firma de RedSpider que usa un FreeAgent de 500GB y si no recuerdo mal es exactamente el mismo al que le tuve que desactivar el spindown interno del disco.

Si tienes Windows, instalando el CD del disco duro puedes desactivarlo y si sólo tienes Linux son unos comandos (a ver si encuentro la página).

Pues si es ésto lo pruebo en cuanto sepa como hacerlo...

Respecto al FreeAgent, no recuerdo que me diera problemas en otros FW.

Gracias por la ayuda. Pero esto ya roza lo desesperante.

ya lo comente el otro dia ,en lugar de pegar trocitos, envianos un zip con el /etc entero de alguna manera. Asi sera todo mas agil. Si quieres mandanos un link por privado o algo asi para que no lo vea todo el mundo.
Sera mas facil analizar tu configuracion.

bittor escribió:
Es que RedSpider usa la versión del SVN 778 (ya vamos por la 802) y antes se ejecutaba rc.halt en lugar de rc.local.halt y se cerraba antes el webif que desmontar los discos, por lo que ese comportamiento sería normal.

¿Por qué se ha cambiado éso?. Se debería apagar el servidor web antes de desmontar los discos, porque si está accediendo a algún archivo (por ejemplo, sirviendo una grabación) impedirá un desmontado limpio de los discos. Lo mismo habría que hacer con el servidor telnet, por la misma razón.

E iría más allá: el apagado se debería abortar si hubiera una sesión telnet iniciada o alguna actividad en el servidor web (aunque habría que ver cómo señalar ésto último).

atinar escribió:

bittor escribió:
Es que RedSpider usa la versión del SVN 778 (ya vamos por la 802) y antes se ejecutaba rc.halt en lugar de rc.local.halt y se cerraba antes el webif que desmontar los discos, por lo que ese comportamiento sería normal.

¿Por qué se ha cambiado éso?. Se debería apagar el servidor web antes de desmontar los discos, porque si está accediendo a algún archivo (por ejemplo, sirviendo una grabación) impedirá un desmontado limpio de los discos. Lo mismo habría que hacer con el servidor telnet, por la misma razón.

El disco duro se intenta desmontar mientras el VDR está en ejecución, básicamente por las comprobaciones de disco del usbautomounter que acarreaban los siguientes inconvenientes:
- Mientras se hacía una comprobación de disco no respondía a los botones del mando, y si el giga había arrancado por una programación la tele estaba apagada y no podías encender la tele pulsando el Power, ahora sí y puedes incluso sintonizar canales mientras tanto, hacer programaciones, conectarte al webif, ftp, etc. y vemos el porcentaje comprobado con mensajes por el OSD.
- El apagado de la tele es instantáneo y no es necesario que se quede la tele encendida con las barras de progreso haciendo la comprobación de disco porque lo hace en background con el VDR funcionando y la tele apagada.
- Ya no se encenderá la tele por la noche en una programación con las barras de comprobación para comprobar el disco.

Si el disco está siendo usado por el VDR, webif, ftp, telnet, etc. no se desmontará en ese primer intento y se matará el VDR, webif, inetd, etc. y se volverá a desmontar.

RedSpider escribió:

bittor escribió:Me acabo de dar cuenta en la firma de RedSpider que usa un FreeAgent de 500GB y si no recuerdo mal es exactamente el mismo al que le tuve que desactivar el spindown interno del disco.

Si tienes Windows, instalando el CD del disco duro puedes desactivarlo y si sólo tienes Linux son unos comandos (a ver si encuentro la página).

Pues si es ésto lo pruebo en cuanto sepa como hacerlo...

Respecto al FreeAgent, no recuerdo que me diera problemas en otros FW.

Gracias por la ayuda. Pero esto ya roza lo desesperante.

Aquí tienes lo que hice yo en Linux para que funcionara el FreeAgent correctamente:
http://alienghic.livejournal.com/382903.html

Sólo hace falta tener instalado el programa sdparm con "sudo aptitude install sdparm" y ejecutar esos comandos con el nombre de dispositivo (/dev/sdX) que tengas en el PC que lo sacarás ejecutando un "sudo fdisk -l".
Te aseguras al final que el STANDBY está a cero y ya no te desaparecerán las unidades misteriosamente.

@bittor
No he dicho nada acerca de apagar el VDR antes de desmontar los discos, así que no estoy seguro de si tu respuesta tiene algo que ver con lo que yo comento.

Y es cierto que se vuelve a intentar el desmontado de los discos, si algún proceso lo impide al primer intento, pero se hace en modo "lazzy", y eso provoca una comprobación de discos en el siguiente arranque. Al menos así me ha ocurrido en las ocasiones (bastantes) en que se me ha apagado el Gigaset con una sesión telnet iniciada.

Además lo que estoy sugiriendo en realidad es que se aborte el apagado en los casos en los que se detecte que haya alguien (diferente al que estaba viendo el televisor y ha decidido apagarlo) usando el Gigaset ...

Para que el VDR detecte que existe alguna aplicación en ejecución y pasar a apagado rápido, no sirve detectar el no desmontaje de los discos ya que el propio VDR los tiene ocupados y nunca se cerraría.

Lo de detectar una sesion abierta, no sabría como hacerlo. Pero si existe el método de detectarlo, se puede hacer lo que con el usbautomounter. Incluir una clase de detección que mantenga el VDR en apagado rápido hasta que se cierre la aplicación o vuelva a pulsarse Power.

Pero ¿es posible detectar las sesiones telnet, ssh, ftp, samba,... abiertas? y en ese caso ¿seguro que no queremos que se apague?

Posix escribió:Para que el VDR detecte que existe alguna aplicación en ejecución y pasar a apagado rápido, no sirve detectar el no desmontaje de los discos ya que el propio VDR los tiene ocupados y nunca se cerraría.

No tengo claro si, con "VDR" (el primero, al menos) te refieres al programa vdr o al Gigaset en general... No creo que el vdr (para mí es sólo el programa) tenga que detectar nada.

Posix escribió:Pero ¿es posible detectar las sesiones telnet, ssh, ftp, samba,... abiertas? y en ese caso ¿seguro que no queremos que se apague?

Los servidores de telnet, ssh y ftp sólo están en marcha si el demonio inetd los ha iniciado porque ha habido solicitudes del servicio correspondiente, y se apagan cuando no hay necesidad de ellos. Así que sólo habría que detectar si el demonio en cuestión se está ejecutando o no. Lo he probado y tanto vsftpd como telnetd, y dropbear sólo están en marcha durante la sesión de ftp, telnet o ssh respectivamente. Con el webifd no valdría esto, pero podría crear algún archivo que hiciera de semáforo al iniciar el streaming de una grabación y eliminarlo al terminar (el streaming es la única actividad que creo que habría que proteger).

Respecto a sí queremos o no que se apague, si soy yo el que está haciendo una sesión telnet (o ssh, si se diera el caso) o viendo una grabación en el VLC, pues no, yo no quiero... Con el ftp no lo tengo tan claro.

Para mí es un usuario tan legítimo el que está viendo una grabación en red como el que está viendo el televisor, aunque no tenga un mando en la mano.

Pero aún en el caso de que no entremos en estas complicaciones, si estoy haciendo una sesión telnet y alguien en el salón apaga el Gigaset, dado que la sesión va a terminar a lo bruto igualmente, preferiría que se matara al demonio antes de desmontar los discos que después, porque al menos me ahorro la comprobación en el siguiente arranque.

Así que, cuando menos, creo que se tendría que cambiar el orden de apagado y apagar el webifd y el inetd antes de desmontar los discos.

atinar escribió:@bittor
No he dicho nada acerca de apagar el VDR antes de desmontar los discos, así que no estoy seguro de si tu respuesta tiene algo que ver con lo que yo comento.

No me he explicado bien.

Comentabas que se debería apagar el servidor web antes de desmontar los discos y lo que intentaba explicar es que el funcinamiento es como ha sido siempre, es decir, se cierran todos los programas antes de desmontar el disco, pero si el disco duro no está siendo usado por nadie se desmonta antes de cerrar todos los programas (incluido el VDR), por eso en el log aparece el usbautomounter con el VDR funcionando y el webif, ssh, etc.

atinar escribió:

Posix escribió:Para que el VDR detecte que existe alguna aplicación en ejecución y pasar a apagado rápido, no sirve detectar el no desmontaje de los discos ya que el propio VDR los tiene ocupados y nunca se cerraría.

No tengo claro si, con "VDR" (el primero, al menos) te refieres al programa vdr o al Gigaset en general... No creo que el vdr (para mí es sólo el programa) tenga que detectar nada.

Cuando pulsamos el botón Power, el programa VDR tiene que detectar si hay algún proceso (grabación, escaneo de disco duro, programación que inicia en menos de 5 minutos, etc.) que impida el apagado total y dejarlo en apagado rápido para que se apague totalmente cuando termine.
Si se quiere que cuando el disco esté siendo usado por el webif o cualquier otro programa no se apague del todo, habría que hacerlo ahí.

atinar escribió:Así que, cuando menos, creo que se tendría que cambiar el orden de apagado y apagar el webifd y el inetd antes de desmontar los discos.

Así se está haciendo en las últimas versiones del SVN, pero hubo algunas versiones que no se hacía correctamente y por eso tendrías la comprobación al inicio si estabas usando el disco con el webif o algún otro programa por red.

bittor escribió:

atinar escribió:Así que, cuando menos, creo que se tendría que cambiar el orden de apagado y apagar el webifd y el inetd antes de desmontar los discos.

Así se está haciendo en las últimas versiones del SVN, pero hubo algunas versiones que no se hacía correctamente y por eso tendrías la comprobación al inicio si estabas usando el disco con el webif o algún otro programa por red.

No es del todo cierto. Desde siempre, se cierra el proceso principal del inetd antes de desmontar los discos, pero inetd no cierra el resto de procesos telnet, ssh, ftp, o samba que estén arrancados.
En realidad esos procesos se cierran con el killall5 o el pic_tool ${action1} del final de rc.halt

Pensar en detectar todos esos procesos y no lanzar el apagado total me parece muy complicado.

Yo creo que es suficiente con el "apagado rápido" para aquellos que usamos el Giga como servidor además de para ver y grabar de la tele.

Además, se daría el caso contrario. Si desde telnet queremos apagar, debería consultarse el estado de VDR, ftp, samba, servidor web,... para decidir si se produce el cierre.

En mi caso lo tengo claro. No puedo apagar el giga sin preguntarle a mi hija si quiere ver la tele desde su habitación en el portátil o a mí mismo si necesitaré mañana acceder al servidor de archivos o a la red VPN o a añadir una nueva programación. Solo puedo permitirme el apagado rápido. Antes tenía siempre encendido un servidor en casa. Ahora, solo el Giga y el router se mantienen encendidos siempre.

Posix escribió:

bittor escribió:

atinar escribió:Así que, cuando menos, creo que se tendría que cambiar el orden de apagado y apagar el webifd y el inetd antes de desmontar los discos.

Así se está haciendo en las últimas versiones del SVN, pero hubo algunas versiones que no se hacía correctamente y por eso tendrías la comprobación al inicio si estabas usando el disco con el webif o algún otro programa por red.

No es del todo cierto. Desde siempre, se cierra el proceso principal del inetd antes de desmontar los discos, pero inetd no cierra el resto de procesos telnet, ssh, ftp, o samba que estén arrancados.
En realidad esos procesos se cierran con el killall5 o el pic_tool ${action1} del final de rc.halt

Pues tienes razón y parece que es un bug del BusyBox o hay que matarlo de otra forma:
http://www.mail-archive.com/busybox@busybox.net/msg07579.html

Pues parece entonces que el problema no tiene que ver con el orden de apagado, como creía, sino con el bug del inetd.

Para apagar los procesos iniciados por el inetd se podría poner algo como esto en rc.local.halt:

Código:

if [ X"${inetd}" != X"NO" ]; then
   grep -v "^\s*#" /etc/inetd.conf | awk -F " " '{print $7}' | while read proc; do
      for pid in `pidof $proc`; do
         echo -n " stopping $proc with pid $pid"
         /bin/kill -15 $pid
      done
   done
   echo -n ' inetd'
   while read pid; do /bin/kill -15 $pid; done < /var/run/inetd.pid
fi


Aunque seguramente se puede hacer de forma menos farragosa...

Por cierto, ¿sirven de algo los "echo"?, porque no queda nada registrado en messages. En versiones anteriores del busybox había un comando logger, pero ha desaparecido. ¿Depende de algún parámetro en la compilación que haya cambiado?.

Y una última pregunta: ¿hay alguna forma de decirle al vdr, por programa, que apague el sistema?. Porque, si he entendido bien lo que he mirado, el código que permite el reinicio es la llamada a pic_tool que se hace en shutdownvdr, así que si se llama directamente a /sbin/halt, supongo que no se reiniciará sólo. ¿Es así?

Posix escribió:Además, se daría el caso contrario. Si desde telnet queremos apagar, debería consultarse el estado de VDR, ftp, samba, servidor web,... para decidir si se produce el cierre.

Sí, tienes razón. Y no sólo eso: si el script abortara el apagado en caso de detectar una sesión activa de telnet, y ejecutamos el script desde 'una sesión activa de telnet' pues ...

Pero podríamos hacer que el script comparara el pid del proceso que lo ejecuta con cada proceso que ... y si ...

Bueno, ya me callo.

atinar escribió:Para apagar los procesos iniciados por el inetd se podría poner algo como esto en rc.local.halt...

Lo mejor sería corregir el bug del inetd para que cerrara todos los procesos que ha lanzado.
No me gusta hacer este tipo de cambios en los scripts porque son muy poco eficientes, pero en este caso concreto es peor que el disco se desmonte mal porque no se han cerrado los procesos de inetd.
Si inetd no hace su función ¿no sería mejor lanzar los programas de ftp, telnet, etc. directamente y que guarden su pid en /var/run/xxx.pid para matarlos como el resto de programas?
La única mejora que se me ocurre que aporta inetd sería que si un proceso hijo se cierra volvería a lanzarlo, pero este mismo problema también lo tenemos con webif, ntpclient, lircd, syslog, ...

atinar escribió:Por cierto, ¿sirven de algo los "echo"?

Sólo sirven si ejecutas el apagado por telnet que vas viendo lo que está haciendo, pero con lo rápido que va la utilidad es mínima por no decir ninguna.

atinar escribió:En versiones anteriores del busybox había un comando logger, pero ha desaparecido. ¿Depende de algún parámetro en la compilación que haya cambiado?.

Cuando actualicé el BusyBox le quité muchos comandos que no se estaban usando para reducir el tamaño del binario y que fuera más rápido.
Pensé que si alguien necesitaba alguno ya lo pediría, ¿lo necesitas para algo?.
Si editas el archivo "configs/busybox/1.16.0/busybox.config" puedes activarlo cambiando el parámetro "CONFIG_LOGGER" a "CONFIG_LOGGER=y".
Después ejecutas un "make distclean-busybox && make" y ya tendrás el nuevo firm con ese comando.

atinar escribió:¿hay alguna forma de decirle al vdr, por programa, que apague el sistema?. Porque, si he entendido bien lo que he mirado, el código que permite el reinicio es la llamada a pic_tool que se hace en shutdownvdr, así que si se llama directamente a /sbin/halt, supongo que no se reiniciará sólo. ¿Es así?

Efectivamente es así, si haces un halt a secas no se guardará en el PIC la hora del próximo inicio (se mantendrá la que ya tuviera si tenía alguna).
El VDR no puede apagar el sistema si tiene algo pendiente, como por ejemplo una grabación.
Si no hay nada pendiente, el VDR puede apagarse remotamente así:

Código:

svdrpsend 127.0.0.1 2001 "HITK Power"

bittor escribió:Lo mejor sería corregir el bug del inetd para que cerrara todos los procesos que ha lanzado.

Claro. Yo llego a lo que he puesto, pero lo de corregir el busybox se lo voy a dejar a otros...

bittor escribió:No me gusta hacer este tipo de cambios en los scripts porque son muy poco eficientes, pero en este caso concreto es peor que el disco se desmonte mal porque no se han cerrado los procesos de inetd.

Se hace sólo una vez y al apagar. Mejor tardar medio segundo más en apagar que diez minutos más en arrancar.

bittor escribió:Si inetd no hace su función ¿no sería mejor lanzar los programas de ftp, telnet, etc. directamente y que guarden su pid en /var/run/xxx.pid para matarlos como el resto de programas?
La única mejora que se me ocurre que aporta inetd sería que si un proceso hijo se cierra volvería a lanzarlo, pero este mismo problema también lo tenemos con webif, ntpclient, lircd, syslog, ...

Lo que pasa es que inetd puede lanzar varias veces un mismo servidor, una por conexión. Si un servicio se configura con "wait" en inetd.conf, se crea un sólo servidor que responde a todas las peticiones, pero si se configura con "nowait" (en nuestro caso, todos los que están por defecto: telnet, ftp, ssh) se crea una instancia por cada conexión. Además, haciéndolo a través de inetd, si un servicio no se utiliza, no se consumen recursos ejecutando el servidor.

bitor escribió:Cuando actualicé el BusyBox le quité muchos comandos que no se estaban usando para reducir el tamaño del binario y que fuera más rápido.
Pensé que si alguien necesitaba alguno ya lo pediría, ¿lo necesitas para algo?.

Sí, tengo un par de scripts que lo usaban y he tenido que modificarlos. Quizá estaría bien consultarlo, antes de quitar funcionalidades. Además se podría utilizar en los scripts de inicio y apagado, y tener registrado lo que pasa en el syslog, en lugar de todos esos echo que, en la práctica, son inútiles.

bitor escribió:Si no hay nada pendiente, el VDR puede apagarse remotamente así:

Código:

svdrpsend 127.0.0.1 2001 "HITK Power"

Gracias, eso servirá.

bittor escribió:Aquí tienes lo que hice yo en Linux para que funcionara el FreeAgent correctamente:
http://alienghic.livejournal.com/382903.html

Sólo hace falta tener instalado el programa sdparm con "sudo aptitude install sdparm" y ejecutar esos comandos con el nombre de dispositivo (/dev/sdX) que tengas en el PC que lo sacarás ejecutando un "sudo fdisk -l".
Te aseguras al final que el STANDBY está a cero y ya no te desaparecerán las unidades misteriosamente.

No consigo instalar el sdparm ...

Código:

ubuntu@DESKTOP-UBUNTU2:~$ sudo aptitude install sdparm
Reading package lists... Done
Building dependency tree     
Reading state information... Done
Reading extended state information     
Initializing package states... Done
Building tag database... Done     
No candidate version found for sdparm
No candidate version found for sdparm
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
Writing extended state information... Done
Reading package lists... Done           
Building dependency tree     
Reading state information... Done
Reading extended state information     
Initializing package states... Done
Building tag database... Done 

La ayuda me dice ésto:

Código:

ubuntu@DESKTOP-UBUNTU2:~$ sdparm --help
The program 'sdparm' is currently not installed.  You can install it by typing:
sudo apt-get install sdparm
You will have to enable the component called 'universe'

Si pruebo con

Código:

sudo apt-get install sdparm

Me aparece esto otro:

Código:

ubuntu@DESKTOP-UBUNTU2:~$ sudo apt-get install sdparm
Reading package lists... Done
Building dependency tree     
Reading state information... Done
Package sdparm is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package sdparm has no installation candidate


Así que supongo que debo instalar otro paquete antes, no?

Bueno. Ya lo he conseguido. Por si alguien más lo necesita, hay que bajarse el paquete de aquí:
http://packages.ubuntu.com/dapper/i386/sdparm/download

Ya está desactivado el STANDBY.

Código:

ubuntu@DESKTOP-UBUNTU2:~$ sudo sdparm -a /dev/sdf
    /dev/sdf: Seagate  FreeAgentDesktop  100D
Power condition mode page:
  IDLE        0  [cha: n, def:  0, sav:  0]
  STANDBY    0  [cha: n, def:  1, sav:  0]
  ICT        0  [cha: n, def:  0, sav:  0]
  SCT        0  [cha: n, def:9000, sav:  0]


Ahora a probar ...

Prueba fallida...

¿y el log?

Ahora el problema tiene que ser otro porque el disco no va a desaparecer sin avisar al sistema como hacía antes.

No sé cual será el problema. Pero esto es un sinvivir. Quizá la última prueba que haga sea un nuevo formateo del disco. Y van ...

Gracias!

Vale, ahora al menos se ve que las unidades están y se desmontan correctamente (un problema menos), pero se aprecian unos cuantos errores:
- Tienes un problema de señal bastante importante con el canal 23.
También tienes errores en otros canales que pierden paquetes y provocan errores de grabación y reproducción.

Código:

M7X0 TS-Buffer on device 2 has lost 0 during Recording. Buffer Stats 247448 Bytes (15%)
cAudioRepacker(0xC1): skipped 184 bytes to sync on next audio frame
ERROR: /var/vdr/video0/timeShift/0/vdr-000000: Input/output error

Solución:: Mejora la calidad de la señal.

- Has cambiado la configuración del Skin Enigma para que te muestre los iconos pero no los has subido.
Solución: Te bajas los plugins de aquí con sus configuraciones y copias los iconos del Skin Enigma (Config-dir/plugins/skinenigmang) a /etc/vdr/plugins/skinenigmang

- Has cambiado la configuración del EPGSearch para que envíe correos pero no tienes correctamente configurado el archivo de configuración ssmtp.
Solución: Configura el archivo /etc/ssmtp/ssmtp.conf como se ha explicado alguna vez por el foro.

Es raro que se haya desmontado bien el disco y luego haga el escaneo.

bittor escribió:Vale, ahora al menos se ve que las unidades están y se desmontan correctamente (un problema menos), pero se aprecian unos cuantos errores:
- Tienes un problema de señal bastante importante con el canal 23.
También tienes errores en otros canales que pierden paquetes y provocan errores de grabación y reproducción.

Código:

M7X0 TS-Buffer on device 2 has lost 0 during Recording. Buffer Stats 247448 Bytes (15%)
cAudioRepacker(0xC1): skipped 184 bytes to sync on next audio frame
ERROR: /var/vdr/video0/timeShift/0/vdr-000000: Input/output error

Solución:: Mejora la calidad de la señal.

Esto no lo entiendo. ¿Al grabar canales que no tienen una señal óptima puede provocar el "Comprobar sistema de archivos"?
¿O simplemente me lo comentas como algo anecdótico?
¿Cuál es el canal 23? Porque aparte de algunos canales locales, el único con el que tengo verdaderos problemas es con Aprende Inglés TV, que no grabo porque ni se ve. Y en ocasiones La1 y La2 que pierden algo de señal aleatoriamente.

bittor escribió:- Has cambiado la configuración del Skin Enigma para que te muestre los iconos pero no los has subido.
Solución: Te bajas los plugins de aquí con sus configuraciones y copias los iconos del Skin Enigma (Config-dir/plugins/skinenigmang) a /etc/vdr/plugins/skinenigmang

Con tanto actualizar FW y formatear discos es posible que no me haya dado cuenta de este detalle.Gracias.

bittor escribió:- Has cambiado la configuración del EPGSearch para que envíe correos pero no tienes correctamente configurado el archivo de configuración ssmtp.
Solución: Configura el archivo /etc/ssmtp/ssmtp.conf como se ha explicado alguna vez por el foro.

Esto está bien configurado, no te preocupes ...;-)

bittor escribió:Es raro que se haya desmontado bien el disco y luego haga el escaneo.

RedSpider escribió:¿Al grabar canales que no tienen una señal óptima puede provocar el "Comprobar sistema de archivos"?

No creo, simplemente que al tener mala calidad de señal estás perdiendo datos que ni se graban ni se reproducen.
Los drivers tienen un bug (entre tantos otros que no podemos corregir porque no tenemos su código fuente), que cuando hay mala señal en un canal durante mucho tiempo terminan bloqueando el VDR.
Esto también pasa en los firms wavebox, pero en el VDR tenemos una opción que ante esta situación puede reiniciar el VDR (está Configuración VDR -> Varios -> Salida de emergencia) para evitar ese bloqueo que impide ver cualquier canal.

RedSpider escribió:¿Cuál es el canal 23? Porque aparte de algunos canales locales, el único con el que tengo verdaderos problemas es con Aprende Inglés TV, que no grabo porque ni se ve. Y en ocasiones La1 y La2 que pierden algo de señal aleatoriamente.

Pon el 23 con el mando y sabrás el canal que es

Cuando te hizo el escaneo de disco, la anterior vez que lo apagaste ¿estabas usando telnet, ssh o el ftp?

bittor escribió:

RedSpider escribió:¿Cuál es el canal 23? Porque aparte de algunos canales locales, el único con el que tengo verdaderos problemas es con Aprende Inglés TV, que no grabo porque ni se ve. Y en ocasiones La1 y La2 que pierden algo de señal aleatoriamente.

Pon el 23 con el mando y sabrás el canal que es

Jajaja. Creía que te referías a un Mux.

bittor escribió:
Cuando te hizo el escaneo de disco, la anterior vez que lo apagaste ¿estabas usando telnet, ssh o el ftp?

Negativo. De hecho no lo tenía conectado en red.
En las primeras ocasiones tras modificar los parámetros de parada del disco, parecía que todo funcionaba, pero a los dos días empezaron de nuevo los problemas. Ahora cada vez que apago y enciendo tiene que comprobar el sistema de archivos. Habitualmente con las particiones vdr2 y vdr3.

Además de temas menores como calidad de señal y smtp, yo creo que el punto importante es:
ERROR: /var/vdr/video0/timeShift/0/vdr-000000: Input/output error

Antes de iniciar cualquier grabación, VDR intenta "despertar" el disco por si está dormido creando esos ficheros del 0 al 9.

Mientras se va cambiando de canal, el timeShift inicia y detiene grabaciones sin problemas.

Cuando ha pasado mucho tiempo sin grabar, con el primer intento salta el error, pero el sistema lo reintenta con el 1 y todo es ok. Salvo que se pierde el inicio de la grabación no afecta mucho más.

Concretando. Cuando el disco esta un tiempo sin usarse, con el primer acceso se produce un error.