Como se ha visto a lo largo del mes y medio que llevo manejando cheese, las aplicaciones gráficas generan o sufren limitaciones que muchas veces solo podemos superar con el terminal. La primera limitación era la dependencia de evitar la suspensión del monitor, que habíamos superado en gnome 3 con unas ordenes simples en terminal
xset s off # Disable X windows screen saver
xset -dpms
# Disable display power management system
setterm -blank 0
Sin embargo, la limitación que no he podido superar ha sido la limitación del número de fotos extraídas por cheese. Sin embargo, gracias a motion, un programa de vigilancia y monitorización mediante cámaras GPL2, y a mi amigo hckorootx ya no hay ningún límite a las fotos en ráfaga, salvo el que nos imponga el hardware del que disponemos.
La instalación de motion en Fedora es tan simple como
$ su -
palabra
# yum install motion
La ejecución sería algo más compleja, pero hckorootx nos ha preparado un itinerario simplificado que yo he seguido al pie de la letra y funciona perfectamente
1. Crea un directorio "motion" (o cualquier otro nombre) en home
2. Dentro del directorio crear un archivo "motion.conf" con el siguiente contenido:
process_id_file /var/run/motion/motion.pid
# 1 captura por segundo:
snapshot_interval 1
output_normal off
# tipo de paleta a utilizar (3 = JPEG):
v4l2_palette 3
framerate 2
brightness 0
contrast 0
hue 0
saturation 0
# anchura de la imagen
width 1280
# altura de la imagen
height 720
# calidad de la imagen (porcentaje de 0 a 100)
quality 75
# directorio de destino de las capturas
target_dir /home/lince/motion
# formato para los nombre de los archivos
snapshot_filename %d-%m-%Y/%H-%M-%S
3. Desde terminal, ejecuta:
$ motion -c /home/usuario/motion/motion.conf
Como se puede ver solo he cambiado sobre el original de hckorootx la anchura y altura de las fotos, ya que ahora mismo estoy usando una Logitech 525, que me permite mayor resolución.
El resultado es magnífico; una foto por segundo, sin tener que preocuparse por el apagado del monitor.
Además, tal como ha diseñado el fichero hckorootx las fotos se van guardando en un directorio diferente cada día, con lo cual podemos ir eliminando los días no válidos con un simple rm en terminal o de manera gráfica en nautilus. No recomiendo el uso del explorador gráfico, ya que estamos hablando de decenas de miles de ficheros y nautilus tarda mucho en escanear los ficheros y responder.
El siguiete objetivo será conseguir sacar fotos desde dos cámaras distintas con un solo ordenador. Nos ponemos a ello.
Muchas gracias a Kenneth Lavrsen por escribir esta magnífica aplicación y a hckorootx por estudiarla por mi y facilitarnos su uso.
Mostrando entradas con la etiqueta WebCam. Mostrar todas las entradas
Mostrando entradas con la etiqueta WebCam. Mostrar todas las entradas
martes, 10 de abril de 2012
jueves, 29 de marzo de 2012
Limitaciones de cheese
Como he señalado en algunas entradas (1, 2), estoy utilizando cheese y unas simples cámaras web baratas (Logitech C200 y C525) para hacer fotos en ráfagas para hacer vídeos de la evolución de unas fases larvarias de un insecto. Como decíamos, el primer problema ha sido controlar el apagado del monitor, que provocaba eue cheese dejase de hacer fotos. Gnome 3 no ofrece la posiblidad "nunca" en el apagado de monitor, así que hay que recurrir al terminal; lo hemos logrado mediante la ejecución como administrador de estas 3 órdenes:
xset s off # Disable X windows screen saver
xset -dpms # Disable display power management system
setterm -blank 0
Sin embargo, ha surgido una nueva dificultad. Al disparar en ráfaga, cheese tiene un límite de 10.000 fotos, lo que reduce las horas en las que puede estar disparando automáticamente, según los segundos de espera que configuramos. Esto nos obliga a controlar el programa varias veces al día, incluido el fin de semana. Mi amigo hckorootx ha estudiado el código de cheese y me ha señalado donde tiene escrito ese límite y como cambiarlo. Con un simple
$ su -
palabra de administrador
# /usr/share/cheese/cheese-prefs.ui
editamos el fichero y podemos cambiar ese límite.
Sin embargo, el programa no parece admitirlo, por que a pesar de que luego en la configuración indiqué 30.000 fotos en ráfaga, el programa se apaga al llegar alrededor de la 18.800, por algún bug interno o control de ficheros por Linux, falta de memoria (esto lo dudo, por que ese ordenador tiene 16GB de RAM DDR3) u otras razones que aun no se nos hayan ocurrido. Este "killed" que podemos ver
pasó 3 veces seguidas; la primera a las 18.894, la segunda a las 18.816 y la última a las 18.000, como se puede ver en esta captura
Para intentar solucionar este problema hckorootx me recomendó instalar cheese desde código fuente. Una vez desinstalado, la instalación desde código siguió la rutina habitual (./configure, make y make install), pero para terminar ./configure me encontré en un infierno de dependencias que duró hora y media, con una acción cruzada del terminal y yumex para ir añadiendo librerías de desarrollo y algunos paquetes que cubren ciertas opciones de cheese que no se cubren al instalar desde binarios.
El resultado fue aun peor, ya que este nuevo cheese de origen código fuente no me permitió editar el fichero cheese-prefs.ui. Mejor dicho, me lo deja editar, pero el sistema genera un nuevo cheese-prefs.ui~ con los valores básicos originales (hasta cuatro veces y un fichero final cheese-prefs.ui~~~~).
En resumen, hasta ahora hemos solucionado el problema provocado por el monitor y el renombrado en masa de los ficheros mediante script para luego hacer correctamente el vídeo con mencoder. Sin embargo, seguimos como antes en el límite de 10.000 imágenes y tenemos que lanzar la ráfaga por la mañana temprano, al mediodía y por la noche.
Posiblemente la mejor solución sería usar un programa de vigilancia, como motion, pero no disponemos del tiempo necesario para estudiar los manuales (es un programa de terminal bastante complejo) para saber usarlo.
xset s off # Disable X windows screen saver
xset -dpms # Disable display power management system
setterm -blank 0
Sin embargo, ha surgido una nueva dificultad. Al disparar en ráfaga, cheese tiene un límite de 10.000 fotos, lo que reduce las horas en las que puede estar disparando automáticamente, según los segundos de espera que configuramos. Esto nos obliga a controlar el programa varias veces al día, incluido el fin de semana. Mi amigo hckorootx ha estudiado el código de cheese y me ha señalado donde tiene escrito ese límite y como cambiarlo. Con un simple
$ su -
palabra de administrador
# /usr/share/cheese/cheese-prefs.ui
editamos el fichero y podemos cambiar ese límite.
Sin embargo, el programa no parece admitirlo, por que a pesar de que luego en la configuración indiqué 30.000 fotos en ráfaga, el programa se apaga al llegar alrededor de la 18.800, por algún bug interno o control de ficheros por Linux, falta de memoria (esto lo dudo, por que ese ordenador tiene 16GB de RAM DDR3) u otras razones que aun no se nos hayan ocurrido. Este "killed" que podemos ver
pasó 3 veces seguidas; la primera a las 18.894, la segunda a las 18.816 y la última a las 18.000, como se puede ver en esta captura
Para intentar solucionar este problema hckorootx me recomendó instalar cheese desde código fuente. Una vez desinstalado, la instalación desde código siguió la rutina habitual (./configure, make y make install), pero para terminar ./configure me encontré en un infierno de dependencias que duró hora y media, con una acción cruzada del terminal y yumex para ir añadiendo librerías de desarrollo y algunos paquetes que cubren ciertas opciones de cheese que no se cubren al instalar desde binarios.
El resultado fue aun peor, ya que este nuevo cheese de origen código fuente no me permitió editar el fichero cheese-prefs.ui. Mejor dicho, me lo deja editar, pero el sistema genera un nuevo cheese-prefs.ui~ con los valores básicos originales (hasta cuatro veces y un fichero final cheese-prefs.ui~~~~).
En resumen, hasta ahora hemos solucionado el problema provocado por el monitor y el renombrado en masa de los ficheros mediante script para luego hacer correctamente el vídeo con mencoder. Sin embargo, seguimos como antes en el límite de 10.000 imágenes y tenemos que lanzar la ráfaga por la mañana temprano, al mediodía y por la noche.
Posiblemente la mejor solución sería usar un programa de vigilancia, como motion, pero no disponemos del tiempo necesario para estudiar los manuales (es un programa de terminal bastante complejo) para saber usarlo.
lunes, 27 de febrero de 2012
Cheese, fotos en ráfaga y conversión a vídeo
He logrado, o mejor debemos decir hemos logrado, por que he tenido ayuda "experta", superar algunas de las dificultades del uso de cheese que decíamos aquí. En primer lugar, el apagado del monitor ha sido bastante simple, ejecutando estas ordenes:
xset s off # Disable X windows screen saver
xset -dpms # Disable display power management system
tomadas de aquí.
Sin embargo, han aperecido otras dificultades. Cheese, además de limitarse a 10.000 imágenes, ha presentado otra dificultad; guarda los ficheros con unos nombres que dificultan la conversión a vídeo. Los ficheros, para poner un ejemplo, tienen unos nombres que muestran un cuerpo inicial común formado de la fecha de inicio y la hora, minutos y segundos de comienzo:
- Primero: 2012-02-17-173235_1.jpg
- Último: 2012-02-17-173235_10000.jpg
Luego se numeran desde el 1 en adelante, pero sin mantener un número común de caracteres. Esa falta de ceros a la izquierda de los números hace que el ordenador, y los programas que generan el vídeo desde las imágenes, los ordenen de manera equivocada, siendo por ejemplo el último el 2012-02-17-173235_9.jpg. Así, cada determinado número de frames hay una imágen equivocada que genera bastantes molestias.
Por suerte mi amigo hckorootx generó unos scripts para cambiar en masa el nombre de los ficheros, como podemos ver en los comentarios de esta entrada. En concreto, este script funcionó perfectamente (muchas gracias, hckorootx):
#!/bin/bash
for archivo in *.jpg; do
long_total=`expr length $archivo`
long_util=`expr $long_total - 18`
nombre_inutil=`expr substr $archivo 1 18`
nombre_util=`expr substr $archivo 19 $long_util`
if [ $long_util -eq 5 ]; then
ceros="0000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 6 ]; then
ceros="000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 7 ]; then
ceros="00"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 8 ]; then
ceros="0"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
fi
done
Además, como se ve es muy explicativa por si misma. Menos mal, por que yo de script en bash no tengo ni idea, y eran casi 40.000 ficheros en 6 tandadas los que había que renombrar.
Una vez convertidos adecuadamente desde el primero 2012-02-17-173235_00001.jpg hasta el último 2012-02-17-173235_10000.jpg, ya solo quedaba dar una orden de conversión. Después de haber pensado en usar openshot, decidí usar directamente mencoder, por que el terminal es siempre más rápido.
Con esta orden,
$ mencoder "mf://*.jpg" -mf fps=25 -o output.avi -ovc lavc -lavcopts vcodec=mpeg4
que tendré que pulir leyendo más profundamente las guías modernas de mencoder, me salió un conjunto de vídeos de los que cortando trozos y pegando con VirtualDubMod a través de wine logré un total de 4minutos y 12 segundos bastante buenos (me ha felicitado mucha gente), a partir de algo más de 6300 imágenes del total de 40.000.
No, no enseñaremos aquí el vídeo, por que es un objeto científico, y hasta que sea publicado los científicos no compartimos nada de nada. Después de publicarlos los derechos dejan de ser nuestros y ya no podemos disponer de nuestros hallazgos para difundirlos y hay que pedírselos a editoriales como Elsevier, Springer y otras similares. Si me dejan ponerlo en Youtube, según el uso al que esté destinado, lo pondré también aquí, pero no prometo nada.
El siguiente paso sería aprender lo suficiente de motion para poder evitar esa limitación de 10.000 imágenes de cheese... pero esa será otra historia
xset s off # Disable X windows screen saver
xset -dpms # Disable display power management system
tomadas de aquí.
Sin embargo, han aperecido otras dificultades. Cheese, además de limitarse a 10.000 imágenes, ha presentado otra dificultad; guarda los ficheros con unos nombres que dificultan la conversión a vídeo. Los ficheros, para poner un ejemplo, tienen unos nombres que muestran un cuerpo inicial común formado de la fecha de inicio y la hora, minutos y segundos de comienzo:
- Primero: 2012-02-17-173235_1.jpg
- Último: 2012-02-17-173235_10000.jpg
Luego se numeran desde el 1 en adelante, pero sin mantener un número común de caracteres. Esa falta de ceros a la izquierda de los números hace que el ordenador, y los programas que generan el vídeo desde las imágenes, los ordenen de manera equivocada, siendo por ejemplo el último el 2012-02-17-173235_9.jpg. Así, cada determinado número de frames hay una imágen equivocada que genera bastantes molestias.
Por suerte mi amigo hckorootx generó unos scripts para cambiar en masa el nombre de los ficheros, como podemos ver en los comentarios de esta entrada. En concreto, este script funcionó perfectamente (muchas gracias, hckorootx):
#!/bin/bash
for archivo in *.jpg; do
long_total=`expr length $archivo`
long_util=`expr $long_total - 18`
nombre_inutil=`expr substr $archivo 1 18`
nombre_util=`expr substr $archivo 19 $long_util`
if [ $long_util -eq 5 ]; then
ceros="0000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 6 ]; then
ceros="000"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 7 ]; then
ceros="00"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
elif [ $long_util -eq 8 ]; then
ceros="0"
nombre_final=$nombre_inutil$ceros$nombre_util
mv $archivo $nombre_final
fi
done
Además, como se ve es muy explicativa por si misma. Menos mal, por que yo de script en bash no tengo ni idea, y eran casi 40.000 ficheros en 6 tandadas los que había que renombrar.
Una vez convertidos adecuadamente desde el primero 2012-02-17-173235_00001.jpg hasta el último 2012-02-17-173235_10000.jpg, ya solo quedaba dar una orden de conversión. Después de haber pensado en usar openshot, decidí usar directamente mencoder, por que el terminal es siempre más rápido.
Con esta orden,
$ mencoder "mf://*.jpg" -mf fps=25 -o output.avi -ovc lavc -lavcopts vcodec=mpeg4
que tendré que pulir leyendo más profundamente las guías modernas de mencoder, me salió un conjunto de vídeos de los que cortando trozos y pegando con VirtualDubMod a través de wine logré un total de 4minutos y 12 segundos bastante buenos (me ha felicitado mucha gente), a partir de algo más de 6300 imágenes del total de 40.000.
No, no enseñaremos aquí el vídeo, por que es un objeto científico, y hasta que sea publicado los científicos no compartimos nada de nada. Después de publicarlos los derechos dejan de ser nuestros y ya no podemos disponer de nuestros hallazgos para difundirlos y hay que pedírselos a editoriales como Elsevier, Springer y otras similares. Si me dejan ponerlo en Youtube, según el uso al que esté destinado, lo pondré también aquí, pero no prometo nada.
El siguiente paso sería aprender lo suficiente de motion para poder evitar esa limitación de 10.000 imágenes de cheese... pero esa será otra historia
viernes, 17 de febrero de 2012
Cheese y fotos en ráfaga. Problemas al apagarse el monitor
Estoy experimentando la mejor forma de sacar tandadas de fotos con una cámara para luego hacer un vídeo. El modelo es una larva en desarrollo y la intención es seguir algunas de las fases de transformación. La primera prueba fue "casi" exitosa. Y digo casi por que mi cámara cutre Logitech C200 sacaba una resolución 640x480 decente con cheese, hasta que descubrimos varios defectos. Primero, no se puede pedir más de 10.000 fotos (lo intenté con 30.000 y 15.000, y siempre marca 10.000). Segundo, y mucho más importante, al llegar horas después para comprobar como ha salido todo, descubro que cheese para de fotografiar cuando el monitor se apaga. Además, en gnome 3 no hay una opción gráfica para negar el apagado de la pantalla. El máximo tiempo es de una hora (ha desaparecido el never).
El resultado ha sido que a lo largo de la noche se ha parado repetidas veces de fotografiar. Lo más sorprendente es que unas después, siempre aleatoriamente, volvía a empezar. Sospecho que se debe a vibraciones que activa el monitor por movimientos del ratón. Por supuesto, he intentado encontrar soluciones:
1. Uso de motion. Tiene varias ventajas. Es un programa de vigilancia, así que se puede activar para sacar solo fotos cuando hay movimiento. Es en consola, con lo que supongo que no se verá alterado por un monitor apagado.
2. Editar xorg.conf. Aquí podemos ver como editando la sección ServerFlags
Section "ServerFlags"
Option "blank time" "0"
Option "standby time" "0"
Option "suspend time" "0"
Option "off time" "0"
EndSection
se anula el apagado. El problema es que en las distribuciones modernas la mayor parte de los conf de toda la vida han dejado de existir o se localizan en otro sitio en directorios conf.d. En resumen, en Fedora 16 no existe xorg.conf. Mejor aun, al querer generarlo como administrador, simplemente al escribir estas líneas,
su -
palabrita
gedit /etc/X11/xorg.conf
sin escribir en el fichero y sin guardarlo cheese dejó de funcionar (y tardó un rato antes de poder llamarlo de nuevo). Por lo de ahora he dejado esta posibilidad aparte
3. Ordenes más sencillas a través de setterm. Por ejemplo aquí indica alguna posibilidad
$ setterm -powersave off -blank 0
Empezaré probando esta última. Si no funciona, seguiremos generando un xorg.conf y finalmente con motion (es un programa de terminal cuyas opciones dan para un kilómetro y medio de papel impreso). La versión gráfica kmotion creo que precisa apache, lo que para hacer unas fotos de 50 kb me parece mucho.
Finalmente, si todo sale bien, compraré una cámara con más resolución.
El resultado ha sido que a lo largo de la noche se ha parado repetidas veces de fotografiar. Lo más sorprendente es que unas después, siempre aleatoriamente, volvía a empezar. Sospecho que se debe a vibraciones que activa el monitor por movimientos del ratón. Por supuesto, he intentado encontrar soluciones:
1. Uso de motion. Tiene varias ventajas. Es un programa de vigilancia, así que se puede activar para sacar solo fotos cuando hay movimiento. Es en consola, con lo que supongo que no se verá alterado por un monitor apagado.
2. Editar xorg.conf. Aquí podemos ver como editando la sección ServerFlags
Section "ServerFlags"
Option "blank time" "0"
Option "standby time" "0"
Option "suspend time" "0"
Option "off time" "0"
EndSection
se anula el apagado. El problema es que en las distribuciones modernas la mayor parte de los conf de toda la vida han dejado de existir o se localizan en otro sitio en directorios conf.d. En resumen, en Fedora 16 no existe xorg.conf. Mejor aun, al querer generarlo como administrador, simplemente al escribir estas líneas,
su -
palabrita
gedit /etc/X11/xorg.conf
sin escribir en el fichero y sin guardarlo cheese dejó de funcionar (y tardó un rato antes de poder llamarlo de nuevo). Por lo de ahora he dejado esta posibilidad aparte
3. Ordenes más sencillas a través de setterm. Por ejemplo aquí indica alguna posibilidad
$ setterm -powersave off -blank 0
Empezaré probando esta última. Si no funciona, seguiremos generando un xorg.conf y finalmente con motion (es un programa de terminal cuyas opciones dan para un kilómetro y medio de papel impreso). La versión gráfica kmotion creo que precisa apache, lo que para hacer unas fotos de 50 kb me parece mucho.
Finalmente, si todo sale bien, compraré una cámara con más resolución.
domingo, 23 de enero de 2011
Vídeos "azules"
Como decía hace unos días, tengo el ordenador principal en un "casi" perfecto estado de revista. Y digo casi, por que desde que instalé Ubuntu desde el DVD de UbuntuUsers los vídeos tenían un cierto tono azulado (ejemplo con mi WebCam).
No me molestaba mucho, pero hoy después de misa tenía un rato, así que busqué en la red, donde salen miles de cambios y cosas para solucionarlo (por ejemplo aquí), pero lo más fácil está en una de las respuestas de esa página, complemetada por esta otra; llamamos a totem (Aplicaciones, Sonido y vídeo, Reproductor de películas) y en Editar, Preferencias descubrimos que Tono está totalmente a la izquierda, así:
Presionamos sobre Restablecer predeterminados, con lo que Tono se coloca en el centro
y el resultado es
Perfecto. Esas imágenes son la prueba de video de la orden en terminal
$ sudo gstreamer-properties
y se traduce en la reproducción de cualquier video, tanto en totem como en VLC. Ahora sí está el ordenador a mi gusto; solo le falta poder instalar el 10.10, pero creo que tendré que esperar al 11.04
No me molestaba mucho, pero hoy después de misa tenía un rato, así que busqué en la red, donde salen miles de cambios y cosas para solucionarlo (por ejemplo aquí), pero lo más fácil está en una de las respuestas de esa página, complemetada por esta otra; llamamos a totem (Aplicaciones, Sonido y vídeo, Reproductor de películas) y en Editar, Preferencias descubrimos que Tono está totalmente a la izquierda, así:
Presionamos sobre Restablecer predeterminados, con lo que Tono se coloca en el centro
y el resultado es
Perfecto. Esas imágenes son la prueba de video de la orden en terminal
$ sudo gstreamer-properties
y se traduce en la reproducción de cualquier video, tanto en totem como en VLC. Ahora sí está el ordenador a mi gusto; solo le falta poder instalar el 10.10, pero creo que tendré que esperar al 11.04
domingo, 5 de septiembre de 2010
Novedades
Me esta costando mucho superar el fin de las vacaciones y comenzar de nuevo las actividades habituales. El trabajo es mucho, con lo que casi no he sacado tiempo (ni ganas) de empezar con el resto, es decir, las aficiones, y por ello no he leido ningún blog ni he escrito entrada alguna. Forzándome, me obligo a escribir alguna de las novedades técnicas.
En primer lugar, he cambiado de móvil. Como para mi es solo una máquina siempre encendida pero nunca usada salvo emergencia, no hay nada más que decir. Tenía cierto interés en un HTC Nexus One (el de Google, vamos), pero como mi operador -R, la empresa de comunicación por fibra óptica, no R paquete estadístico- no disponía de él, he decidido aceptar el "mejor" de los gratuitos entre los ofertados.
Segundo, he instalado una WebCam en mi ordenador; sé que para los que me conocen parecerá una sorpresa (para mi también), pero tengo ganas de probar algunos códigos de Fotogramas -sí, la revista de cine- para conectarme a información adicional, y la condición es leer algunos marcadores que trae el número de septiembre con una webcam. Me ha comprado una BBB (buena, bonita y barata), basándome sobre todo en la última B, así que me encontré en mi tienda favorita una Logitech WebCam C200 y parece que funciona. Cuando tenga un rato la usaré con esos códigos.
Tercero,como decia en un comentario a una entrada anterior mi amigo Julián, he tenido que instalar Java oficial para lograr que JDownloader funcione de manera continua. Me he resistido todo cuanto he podido, pero no puedo estar controlando varias veces al día que JDownloader aun está ahí y no ha "desparecido".
Finalmente no quisiera dejar de comentar una noticia que oí el otro día de refilón; en un programa de economía mencionaron que Telefónica estaba tanteando controlar el coste de la conexión a Internet no en función del ancho de banda teórico que te ofrece, si no por el volumen de descarga que realizas. Obviamente tendrán que reunirse todas las operadoras de forma ilegal, para decidir todas en conjunto la manera de extorsionar a los usuarios; como todas estas decisiones, nunca sabremos ni cuando ni donde lo harán, pero podremos intuir que fue así unos meses después. Si una de ellas lo hiciera unilateralmente se quedaba sin clientes. Es decir, ya estamos con un globo sonda en marcha para encontrar la forma de controlar lo que bajamos, cuanto bajamos y recordárnoslo cada fin de mes en el bolsillo. Pues que avisen, que así nos volvemos al modem de 56kbps para mandar algún correo y a ver quien gana más. Sin embargo, mi operadora me acaba de ofertar 30MBPS reales por 5€ más (puedo asegurar que con R la banda es real, ya que tengo contratado 10MBPS, que se traduce a 1500KB/s y muchas veces bajo en ancho superior, aproximadamente 1750KB/s). ¿Qué sentido tiene que R me oferte 4500KB/s y Telefónica 3000KB/s, si luego me va a estar vigilando y si llego a la cuarta parte de ese nivel me va a cobrar más? ¿Será que la SG*E le pide también canon a Telefónica? ¿Será que están ofertando algo que no pueden cumplir? Quizá pensaban que alguien que contrata 4500KB/s lo usa solo para mandar unos correos y descubren ahora que si se le ofrece la posibilidad a la gente, esta en general baja copias privadas "de todo". Si me ofreces 30MBPS por 55€, será así, ¿o no? Continuará
En primer lugar, he cambiado de móvil. Como para mi es solo una máquina siempre encendida pero nunca usada salvo emergencia, no hay nada más que decir. Tenía cierto interés en un HTC Nexus One (el de Google, vamos), pero como mi operador -R, la empresa de comunicación por fibra óptica, no R paquete estadístico- no disponía de él, he decidido aceptar el "mejor" de los gratuitos entre los ofertados.
Segundo, he instalado una WebCam en mi ordenador; sé que para los que me conocen parecerá una sorpresa (para mi también), pero tengo ganas de probar algunos códigos de Fotogramas -sí, la revista de cine- para conectarme a información adicional, y la condición es leer algunos marcadores que trae el número de septiembre con una webcam. Me ha comprado una BBB (buena, bonita y barata), basándome sobre todo en la última B, así que me encontré en mi tienda favorita una Logitech WebCam C200 y parece que funciona. Cuando tenga un rato la usaré con esos códigos.
Tercero,como decia en un comentario a una entrada anterior mi amigo Julián, he tenido que instalar Java oficial para lograr que JDownloader funcione de manera continua. Me he resistido todo cuanto he podido, pero no puedo estar controlando varias veces al día que JDownloader aun está ahí y no ha "desparecido".
Finalmente no quisiera dejar de comentar una noticia que oí el otro día de refilón; en un programa de economía mencionaron que Telefónica estaba tanteando controlar el coste de la conexión a Internet no en función del ancho de banda teórico que te ofrece, si no por el volumen de descarga que realizas. Obviamente tendrán que reunirse todas las operadoras de forma ilegal, para decidir todas en conjunto la manera de extorsionar a los usuarios; como todas estas decisiones, nunca sabremos ni cuando ni donde lo harán, pero podremos intuir que fue así unos meses después. Si una de ellas lo hiciera unilateralmente se quedaba sin clientes. Es decir, ya estamos con un globo sonda en marcha para encontrar la forma de controlar lo que bajamos, cuanto bajamos y recordárnoslo cada fin de mes en el bolsillo. Pues que avisen, que así nos volvemos al modem de 56kbps para mandar algún correo y a ver quien gana más. Sin embargo, mi operadora me acaba de ofertar 30MBPS reales por 5€ más (puedo asegurar que con R la banda es real, ya que tengo contratado 10MBPS, que se traduce a 1500KB/s y muchas veces bajo en ancho superior, aproximadamente 1750KB/s). ¿Qué sentido tiene que R me oferte 4500KB/s y Telefónica 3000KB/s, si luego me va a estar vigilando y si llego a la cuarta parte de ese nivel me va a cobrar más? ¿Será que la SG*E le pide también canon a Telefónica? ¿Será que están ofertando algo que no pueden cumplir? Quizá pensaban que alguien que contrata 4500KB/s lo usa solo para mandar unos correos y descubren ahora que si se le ofrece la posibilidad a la gente, esta en general baja copias privadas "de todo". Si me ofreces 30MBPS por 55€, será así, ¿o no? Continuará
Suscribirse a:
Entradas (Atom)








