Von Entertain, Rechten und meinen Visionen

Ich muß mal wieder etwas Luft ablassen, eine Kategorie »Contentmafia« ist wohl langsam überfällig … Wie dem auch sei, die Vorstellung von »Entertain to go« möchte ich zum Anlaß nehmen, ein bißchen über das technisch machbare, aus meiner Sicht notwendige Grenzen der Einflußnahme der Rundfunkanstalten sowie meine Visionen hinsichtlich des Medienkonsums (Schwerpunkt Bewegtbild; Musik ist abgedeckt durch Squeezecenter und -player) zu reden.
Continue reading

NAT or no-NAT — what the firetruck?

I have to admit defeat. Yes, I’m out of ideas currently …

Thing is: I have three TL MR-3020 (well, 2 3020 and one 3040 right now, but they should be identical except for the lack of buttons and the existence of a battery in the 3040 case), all running, installed from a local copy of the repository, …

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 ATTITUDE ADJUSTMENT (Bleeding Edge, r32930)
 -----------------------------------------------------
  * 1/4 oz Vodka      Pour all ingredients into mixing
  * 1/4 oz Gin        tin with ice, strain into glass.
  * 1/4 oz Amaretto
  * 1/4 oz Triple sec
  * 1/4 oz Peach schnapps
  * 1/4 oz Sour mix
  * 1 splash Cranberry juice

Continue reading

TL-MR 3020 as a webcam server

Took me a while, but I’m now rather confident that the issues I was having with the MR3020 as a mjpg-streamer powered streaming webcam server are related to the camera(s) used, not (only) to the tiny box. As you can see below, “only” in daylight the images gets distorted:

As of now I assume that the framerate reported by the camera is responsible for this, as that cam is reporting only 30 fps for all resolutions. It’s working nicely on a SheevaPlug with full-blown Debian, but Sheeva is a different hardware to the MR3020 (and 3 to 5 times as expensive per box); I might try a Dockstar as the host for this cam, but time will tell.

Just FTR, with a quickly ordered Logitech C270 HD, the MR320 is serving just nicely as a streaming webcam server (cam reports 5 and 10 fps for 1280×720, I choose 5, which is sufficient for now):

Webcam server with TL-MR 3020?

Hmm. Previously, I build two nice webcam-servers out of Fonera 2.0g boxes (German posts: 1 & 2). cpuinfo of the Foneras is as follows:

root@cam-serv3:~# cat /proc/cpuinfo 
system type             : Atheros AR2315
processor               : 0
cpu model               : MIPS 4KEc V6.4
BogoMIPS                : 183.50
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : no
ASEs implemented        :
shadow register sets    : 1
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

There I run two jobs, for /dev/video0 and /dev/video1, of mjpg_streamer -i input_uvc.so -f 10 -r 960x720 ..., which results in this top output:

Mem: 19836K used, 10080K free, 0K shrd, 1140K buff, 6096K cached
CPU:  19% usr  11% sys   0% nice   1% idle   0% io  31% irq  34% softirq
Load average: 2.57 2.51 2.45
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
 1518  1064 root     R     8732  29%  33% mjpg_streamer -i input_uvc.so -d /dev
 1517  1060 root     R     8572  29%  26% mjpg_streamer -i input_uvc.so -f 10 -
 1065  1064 root     R     8732  29%  20% mjpg_streamer -i input_uvc.so -d /dev
 1061  1060 root     S     8572  29%   7% mjpg_streamer -i input_uvc.so -f 10 -
 1577  1520 root     R     1960   7%   6% top -d 2 
 1519   933 root     S     1996   7%   1% /usr/sbin/dropbear -p 22 
 1064  1058 root     S     8732  29%   0% mjpg_streamer -i input_uvc.so -d /dev
 1058     1 root     S     8732  29%   0% mjpg_streamer -i input_uvc.so -d /dev
 1067  1064 root     S     8732  29%   0% mjpg_streamer -i input_uvc.so -d /dev
 1060  1056 root     S     8572  29%   0% mjpg_streamer -i input_uvc.so -f 10 -
 1056     1 root     S     8572  29%   0% mjpg_streamer -i input_uvc.so -f 10 -
 1066  1060 root     S     8572  29%   0% mjpg_streamer -i input_uvc.so -f 10 -
 1055     1 root     S     1976   7%   0% udhcpc -t 0 -i ath0 -b -p /var/run/at
  520     1 root     S     1972   7%   0% udhcpc -t 0 -i eth0.1 -b -p /var/run/
[...]

Recently I joined the MR3020 hype, them being quite similar to the Fonera 2.0g systems, i. e. Atheros-based, supported by OpenWR, rather cheap (<30 EUR) and with USB; only drawback is the ridiculously small on-board Flash:

root@cam-serv5:~# cat /proc/cpuinfo 
system type             : Atheros AR9330 rev 1
machine                 : TP-LINK TL-MR3020
processor               : 0
cpu model               : MIPS 24Kc V7.4
BogoMIPS                : 265.42
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0000, 0x0280, 0x05d0, 0x0630]
ASEs implemented        : mips16
shadow register sets    : 1
kscratch registers      : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

But to my big disappointment, running even only one process of mjpg_streamer, /usr/bin/mjpg_streamer --input input_uvc.so --device /dev/video0 --fps 1 --resolution 1280x720 ..., seems to max the system out, and anything above 1 fps, I tested 2, 5, 10, gives quite chopy images, distorted in odd ways. top says:

Mem: 25868K used, 3308K free, 0K shrd, 1412K buff, 5392K cached
CPU:   0% usr   0% sys   0% nic  97% idle   0% io   0% irq   0% sirq
Load average: 0.06 0.11 0.11 1/41 1542
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 1514     1 root     S    24424  84%   0% /usr/bin/mjpg_streamer --input input_
 1541  1431 root     R     1496   5%   0% top -d 2
 1430  1362 root     S     1216   4%   0% /usr/sbin/dropbear -P /var/run/dropbe
 1431  1430 root     S     1504   5%   0% -ash
  592     1 root     S     1504   5%   0% /sbin/syslogd -C16
 1140     1 root     S     1504   5%   0% /sbin/udhcpc -t 0 -i wlan0 -b -p /var
...

So, it does not seem to be a CPU limitation; the CPU should be even more powerful than the Fonera’s, and the minor increase in resolution, 1280×720 instead of 960×720, should be compensated by far by the two USB cams served by the Fonera. Any opinions or tips?

Schnee-Timelapse, die nächste ;)

Eigentlich war ich im Begriff, die lustigen Skripte, die mir aus vielen Teilen der Welt Webcam-Bilder archivieren, zu deaktivieren und die paar hundert GB zu recyclen, als doch noch mal was Sehenswertes über Deutschland passierte: Schnee im (meterologischen) Frühling — ansich nichts ungewöhnliches, denn, wie ich seit Jahren eine alte Weißheit wiederhole: »zur CeBIT schneit’s nochmal«.
Naja, wie dem auch sei, viel Spaß mit dem Zeitraffer zum neuerlichen Wintereinbruch über Ostwestfalen ;)

Wie Miss #Daisy uns hängen lies …

Tja.
All den guten Ratschlägen zum Trotz: weder hundert heiße Ladenhüterdecken konnte man gestern an den Mann oder die Frau bringen noch stellte sich der herbeigeredete Stillstand Deutschlands durch Schnee im, Obacht!, Winter ein. Ja, es war frisch; nicht kalt, die Kälte war nur gefühlt. Durch den Wind. Der, zumindest in Mediatown City, eher mehr so spürbar war denn auffällig. Und groß anders war es offensichtlich nicht in Bielefeld (oben links), Detmold (oben rechts) oder Lemgo (unten links); vielen Dank an dieser Stelle an die Stadtverwaltungen und sonstigen Betreiber der öffentlichen Webcams für die Bereitstellung minütlicher Updates (über Mobotix-Standardzugänge)! Trotzdem waren im zu Fuß – auch während einer Eiszeit – erreichbaren LIDL in Steinwurfnähe unter anderem Toastbrot und andere Dinge des täglichen Bedarfs schon seit Freitag ausverkauft — go figure.

Und wer noch immer nicht die Lust an derlei Filmchen verloren hat: die Nacht von Daisy in Gütersloh, mit dem Tag davor und danach, aus anderer Perspektive nochmals im Zeitraffer:

Wireless-Web-Cam, die 2.

Angespornt vom super Wetter (Schnee!), habe ich nun meinen zweiten Fonera 2.0g in einen drahtlosen Kameraserver verwandelt. Zwar leider nicht für ältere Webcams, aber bei den UVC-kompatiblen Kameras gibt es ja auch einige schmucke Geräte. Diesmal habe ich mir das OpenWRT-Image selbst zusammengebaut, im Endeffekt ist es reichtlich simpel, auf dieser Basis eine wireless Webcam zusammenzubauen, die, wie man sehen kann, auch bei unter -10 Grad Celsius noch funktioniert. Eine Creative Optia AF hatte ich schon im Sommer in ein entsprechendes Gehäuse (Baumarkt-Druckguß-300W-Halogenstrahler) gepackt und auf der Terrasse moniert (parallel zu einem ungeschützt aufgehängten alten Philips-pwc-Ei), nur leider klappte es seinerzeit nie, jene Cam weder mit blanken USB-Verlängerungskabeln noch mit aktiven USB2-Verlängerungskabeln noch mit letzteren plus eines außen dazwischengeschalteten netzgespeisten USB-2.0-Hubs irgendwie an den »cam-serv« und das darauf laufende »motion« anzuschließen. Lustige USB-Fehlermeldungen oder nur einen Start nach dem Reset überlebende Konstellationen waren die Folge; schade eigentlich, da jene Cam eine der wenigen ist, die unter Linux einen funktionierenden Autofocus mitbringen. Allerdings zeigt sich grade jetzt im Nachteinsatz, daß dieser Autofocus bei schlechten Lichtverhältnissen arg zum ziellosen pumpen neigt :(
Ich habe also heute abend, nachdem mein dedizierte Cam (s. o.) schneehöhenbedingt nur noch ein Schwarzbild zu liefern vermochte, auch meine zweiten Fonera 2.0g der kalten Unwirtlichkeit übereignet – und besagte Optia AF angeschlossen. Deren Bild liefert jetzt – leider liefert sie nur 800×600 als MJPEG-Stream – als kleines Einblendimage zusätzliches Bildmaterial, da mein Hauptimage ja schneehöhenbedingt uninteressant geworden ist.
Kurzer Abriß der eingesetzten Technik: Die »Himmelscam« als auch die »Parkplatzcam« sind Notebook-Pro-USB-Cams von Logitech, die an einem SheevaPlug (Parkplatz) bzw. einer Fonera-2.0g mit OpenWRT (Himmel); die Wetterdaten werden empfangen über FHEM in Verbindung mit CUL und CUN sowie S300TH/S555TH als Sensor. Ferner tut eine WS3600 Dienst, welche minütlich seriell über FHEM ausgelesen wird; deren Werte wandern allerdings, anders als jene der S300-Sensoren, noch nicht in die rrd-Datenhaltung, weshalb nur zwei Werte, die des Sensors in der Gartenhütte und die des Sensors oberhalb des Parkplatzes, in den Plot auftauchen. Bedingt durch die Funkübertragung gibt es gelegentlich Aussetzer, die im Graphen sich als fehlende Fortschreibung der entsprechenden Linie manifestieren; in der Folge fehlen dann entsprechend auch einen Tag später die als Fläche aufgetragenen Werte des Vortags. Warum es diese Aussetzer, insbesondere Nachts, gibt, ist eines der Themen, an denen ich derzeit kaue … Anyway, der Film der letzten zwei Tage: