Aug 022013
 

This is a work still in progress with unsatisfactory results (image quality, delay, very low frame rate), but here’s for the brave-hearted and those who are researching into the same direction:

Set up Windows streaming host

This can be a multi-monitor machine. Your left-most monitor will be streamed.

I generally use FullHD resolution for testing.

  • Install a Direct Show Screen Capture Filter for Windows. We used the direct show filter provided with “Screen Capturer Recorder” by Roger D Pack. Roger also includes an audio direct show capturer. And all free of charge – a real bargain 😉
  • Maybe a reboot is necessary here
  • Install latest version of ffmpeg from Zeranoe. Opt for the static builds (probably 64 bit if you are running a modern Windows 64 bit OS on a modern computer)
  • extract the download to a safe location
  • Open PowerShell, and navigate to the location

List the available screen filter devices:

This and all following shell commands are to be issued in the PowerShell. 

.\ffmpeg -list_devices true -f dshow -i dummy

This will show you the available input devices to capture from. My list looks like this, for instance:

 DirectShow video devices
  "Integrated Webcam"
  "screen-capture-recorder"
 DirectShow audio devices
  "Microphone (2- High Definition Audio Device)"
  "virtual-audio-capturer"

Start the stream:

.\ffmpeg -f dshow -i video="screen-capture-recorder" -vcodec libx264 -vprofile baseline -preset ultrafast -tune zerolatency  -pix_fmt yuv420p -b:v 400k -r 30  -threads 4  -fflags nobuffer -f rtp rtp://192.168.1.14:1234

I used PowerShell to start this, thus the .\ is needed in front of an application in the current folder.

  • libx264 is used as video codec, rather than mpeg4 (for superior quality – the Raspi is capable of H264 hardware decoding)
  • baseline profile needs to be used together with –pix_fmt yuv420p – this basically reduces the encoding to a simple subset of the full standard. Leaving out these two options led to the streaming not working, but you may be able to figure out something – please comment!
  • -preset ultrafast and –tune zerolatency both accelerate the video output. I have a latency of about 1 – 2 sec. in our lab here
  • -b:v 400k sets the target bitrate (as variable)
  • -r 30 this sets the framerate to 30
  • -threads 4 – give more threads to ffmpeg
  • -fflags nobuffer – should decrease latency even further. Not sure if it does, though.
  • -f rtp – specifies the output format. Here we use rtp, and stream it directly to the raspberry – which has the IP 192.168.1.14 on our network. You can choose whatever you like for the port, by an odd coincidence we chose 1234. Aliens?!?

Hit “Enter” and ffmpeg will start streaming. It will show you handy statistics – current frame number, framerate, quality, total size, total time, current bitrate, duplicated capture-frames, dropped capture-frames (i.e. the capturing rate does not align with the streaming rate). Do not worry too much about those for now.

Please note that you need some horsepower for capturing, encoding and streaming in real-time.

Set up Raspberry Pi

omxplayer can’t handle RTP streams directly – thus, we resort to GStreamer.

GStreamer 1.0 includes special support for the Raspberry Pi’s Broadcom SoC’s VideoCore IV hardware video functions (also known as OpenMax). Unfortunately, the Raspbian maintainers do not want to include it (yet), in order not to diverge too far from the official Debian repositories.

Luckily for you, though, someone has precompiled the binaries and set up a repository. See this thread for more background information, or simply follow my instructions:

sudo nano /etc/apt/sources.list

This will open nano to edit your package repository list. Please add the following line into this file:

deb http://vontaene.de/raspbian-updates/ . main

After saving the file (Ctrl + O, Ctrl + X), run the following commands:

sudo aptitude update
sudo aptitude install libgstreamer1.0-0-dbg gstreamer1.0-tools libgstreamer-plugins-base1.0-0 gstreamer1.0-plugins-good gstreamer1.0-plugins-bad-dbg gstreamer1.0-omx gstreamer1.0-alsa

This will install the necessary gstreamer1.0 & components.

Start the stream receiver & decoder chain:

gst-launch-1.0 -v udpsrc port=1234 caps='application/x-rtp,payload=(int)96,encoding-name=(string)H264' ! queue ! rtph264depay ! h264parse ! omxh264dec ! autovideosink sync=True

This can be done as user pi. Please note, that this may not be the perfect command to achieve playback, but it is a good starting point – as it works!

Gstreamer sets up “pipelines”, in which data is passed on in transformed state from step to step. While it seems to be quite a bit at the first look, it is very logical in itself, once you have figured it out.

  • we specify a UDP source (udpsrc), the port, and “caps”
  • Without the RTP caps, playback is not possible. Apparently they are not provided along with the stream? Thus, we have to specify the caps manually.
  • In the caps we specify some information for the pipeline
  • queue may be omitted, I am not sure what it does
  • rtph264depay – depayload h264 data from rtp stream
  • h264parse – parse h264 data
  • omxh264dec – decode the data with BroadCom OpenMAX hardware acceleration
  • autovideosink – put the result on the display
  • sync=True – I am not sure whether this does anything, or whether it is in the right place and form. It was an attempt to fix the gst_base_sink_is_too_late problems (but it did NOT fix them).

Issues

slow screen updates

These are very likely caused by a slow screen capture refresh rate, this may be better with a different screen capturer.

On Windows 8, with a pretty powerful Core i7 machine, I get possible fps 15.41 (negotiated for 30 fps). This is using Roger’s / betterlogic’s screen-capture-recorder. Roger claims this is due to Aero.

See more about it here  and here (also provides a list of available other directshow screen capture filters).

artifacts

Gstreamer shows massive H.264 artifacts – Matthias Bock has opened an issue for this, and some further hints.

This seems to be related to the bitrate set in FFMPEG – if I lower it to ~ 400 k, the artifacts become less distorted, and image quality is quite OK. Also, use a variable bitrate instead of a constant one.

gst_base_sink_is_too_late()

This may be related to the Pi’s fake hardware clock (?). It also appears when running gstreamer with a simple test image setup:

gst-launch-1.0 videotestsrc ! autovideosink

gstbasesink.c(2683): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstEglGlesSink:autovideosink0-actual-sink-eglgles:
There may be a timestamping problem, or this computer is too slow.

 

The command above will display a test video image.

Sound

I have not tried sound yet. Sound shoud be input into ffmpeg using the following arguments:

-i audio="virtual-audio-capturer":video="screen-capture-recorder"

This directly from Roger’s GitHUB documentation.

Ideas

  • try to use gstreamer on Windows for streaming?
  • Adjust Parameters for betterlogic/Roger’s direct show capturer
    • apparently it hits the ceiling at 15 fps with Aero on
  • Use a different direct show capturer
  • Tune quality for ffmpeg stream

Background info

  • H.264 is MPEG-4 Part 10 or = MPEG-4 AVC – and is the more modern and data-efficient codec format (“advanced video coding”);
  • whereas MPEG-4 Part 2 = MPEG-4 Visual is based on the older image compression standards used in MPEG-2, and also implemented in DivX, Xvid, etc.
  • you can also use .\ffplay –i udp://:1234 to test the streaming output on the local machine. The video quality IS NOT TO BE USED AS A REFERENCE. It just shows, that it “works”. Change the target IP accordingly (“localhost” instead of the Raspi’s IP will do, I believe.)

References

Jul 232013
 

Update

We have released dfreerdp (FreeRDP for the DirectFB backend) as a package for the Raspberry Pi. Please go to our new blog post to get it!

Intro

RDP is a convenient way to connect to Windows and also other operating systems with RDP host software, e.g. Linux. RDP transmits display information more efficiently than VLC, as it sees the structure of the screen and it’s elements. It also allows to transmit audio information both ways – playback and recording, share printers, drives, and more. As it is an extensible protocol, efficient video / multimedia playback can be implemented – and has been implemented, albeit apparently only in Windows Media Player.

The Raspberry Pi is a low-power device, with Full-HD (and audio) capable HDMI output.

FreeRDP is a mighty utility to connect to RDP servers, and utilize many of their possibilities. It even supports the video extensions for RDP (in RDP lingo: video redirection virtual channel extension) with ffmpeg. Don’t get your hope up too high right now, though: while theoretically feasible in software, it still would have to be written for both the Raspberry AND the host (it is not a “plug & forget” solution, but the software run on the server has to support it specifically).

The current state: A marriage made in heaven?

Not quite. FreeRDP is easily installed, and used from an X session. But it is … agonizingly slow. Audio playback is in a bad state.

The problem: X adds a very high overhead to any application, but even more so a graphics intensive, such as FreeRDP. Even super-charging the Raspberry Pi with overclocking, Class 10 SD cards, a beefy power supply, etc. will NOT solve this problem! An RDP client compiled specifically for Wayland might, but this is still some way off.

Solution

FreeRDP can be compiled to draw to the Direct Frame Buffer. This eliminates all of the overhead, which X would add. This is perfect for people really trying to use the Raspberry as Windows / RDP thin client. It will work in FullHD resolution (over the local network), with sufficient performance (and 16 bit color depth).

Kudos are in order to the Tao of Mac blog, which had the idea, and the instructions to get me up and running. You rock!

We will release a hardware & software package RDP client, based on the Raspberry, really soon now. If you’re interested, hit me up in the comments.

Step-by step instructions

With all that out of the way, let’s jump into the instructions!

Preparation

We suggest to use a Class 10 SD card, with ample space for the installation & build of the packages (8 GB Class 10 seems sensible). Install the newest Raspbian image, set up your locale and keyboard layout, aptitude update and aptitude upgrade.

Install the necessary packages:

aptitude install build-essential git-core cmake libssl-dev libx11-dev libxext-dev libxinerama-dev libxcursor-dev libxdamage-dev libxv-dev libxkbfile-dev libasound2-dev libcups2-dev libxml2 libxml2-dev libxrandr-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libavutil-dev libavcodec-dev libcunit1-dev libdirectfb-dev xmlto doxygen libxtst-dev

This should take quite a while.

Download the FreeRDP package (use a sensible location, we will be compiling there later. If in doubt, a sub-folder in your home folder is OK):

wget https://github.com/FreeRDP/FreeRDP/archive/1.0.2.tar.gz

You might also consider checking out the 1.0.3 pre-release version. It might turn stable in a couple of months.

Set up the build environment – this is analoguous to ./configure seen in many other compilations:

cmake -DCMAKE_BUILD_TYPE=Release  -DWITH_FFMPEG=OFF -DWITH_XINERAMA=OFF -DWITH_XCURSOR=OFF -DWITH_DIRECTFB=ON -DCMAKE_INSTALL_PREFIX=~/freerdp

A couple of hints for this:

  • You might want to adjust the –DCMAKE_INSTALL_PREFIX to something more suitable – if you compile as root, it will install the application and the libraries into the folder /root/freerdp otherwise.
    A good choice could be /usr – this way the binaries and libraries will be in the normal search path.
  • turning off FFMPEG means turning off virtual video extension. As discussed before, this is of limited use anyway, right now. But some experimenting might be interesting. FreeRDP also is built modularized on top of FFMPEG, so exchanging that for an omxplayer-like code thingy SHOULD be feasible.
  • Xinerama – is an X extension which allows X applications to span two or more displays a one large virtual display.

Check for the output of this command. It will tell you about skipped options and missed packages. It should find DirectFB amongst others (Found DirectFB: /usr/lib/arm-linux-gnueabihf/libdirectfb.so).

  • pulseaudio: this is a sound server, and another layer on ALSA. It is network capable. Users report varying mileage with pulseaudio and good playback quality. We have tested without the pulseaudio package, future tests will show whether there is an advantage in using it.
  • pcsc – this is for smart card support, most likely you will not need it
  • CUnit – a lightweight system for writing, administering and running unit tests in C – most likely you will not need this, either.

Compile the DirectFB RDP client:

cd client/DirectFB/
make

#optionally 
sudo make install

#for sound support
cd ../../channels/drdynvc
make
sudo make install
cd ../rdpsnd
make
sudo make install

This is all – but this will take quite a while (some hours).

Set up some configuration files

Edit your /etc/udev/rules.d/99-input.rules to be:

SUBSYSTEM=="input", GROUP="input", MODE="0660"
KERNEL=="tty[0-9]*", GROUP="root", MODE="0666"
KERNEL=="mice", MODE="0666"
KERNEL=="fb0", OWNER="root", MODE="0660"

The first line should aready be in the file, add the other three lines.

Optional, but recommended: Edit your /boot/config.txt to contain the following settings:

framebuffer_width=1920
framebuffer_height=1080
framebuffer_depth=16
# for other stuff
gpu_mem=128

arm_freq=800
disable_overscan=1
hdmi_drive=2
hdmi_ignore_edid=0xa5000080

This will

  • set your resolution as fixed [framebuffer_width, framebuffer_height] – be sure to adjust to your needs!
  • set bit depth to 16 – as we will connect to the RDP server using this depth for better performance.
  • ignore anything the monitor will tell the Raspberry – it might lead to blurry edges, otherwise [hdmi_ignore_edid=0xa5000080]
  • overclock the raspberry just a little [arm_freq=800]
  • disable the overscan – remove the black area around the display output on modern LCD monitors [disable_overscan=1]
  • set up the HDMI output to be a real HDMI output and carry audio – this will fix “no sound output” problems [hdmi_drive=2] don’t use this if you connect your Raspberry via DVI or VGA to the monitor

Edit /etc/fb.modes and add a new mode:

# Added as per taoofmac instructions
mode "1920x1080-24p"
   geometry 1920 1080 1920 1080 32
   timings 13468 148 638 36 4 44 5
endmode

You will have to adjust this if you use a different resolution than FullHD. The original article at Tao of Mac has some more resolution examples for you.

Create a new file /etc/directfbrc with the following contents:

system=fbdev
autoflip-window
desktop-buffer-mode=auto
vt-switching
graphics-vt
no-deinit-check
no-motion-compression
no-translucent-windows
memcpy=arm
mode=1920x1080
depth=16
dma
hardware
# for the moment, we need DirectFB's own cursor sprite
cursor

Reboot.

 

Usage

If you specified –DCMAKE_INSTALL_PREFIX to be /usr, you should be able to use FreeRDP DirectFB client without any path prefix, else just prepend your path:

dfreerdp -u "user name" -p secret_password_here -f -g 1920x1080 -x l -z --disable-full-window-drag  --gdi hw --plugin rdpsnd --data alsa --  host:port

Be sure to adjust this command:

  • “user name” should be your user name. If it contains a space, you should keep the quotation marks, else you can loose them.
  • secret_password_here should be your password, obviosly.
  • -g specifies the geometry. Adjust, as necessary.
  • -x = experience (l for LAN), will enable different bells and whistles. You might want to modify that, or use a more finegrained control of which features to enable, and which to disable
  • -z enable compression (useful)
  • –gdi hw – I’m not sure whether this is really necessary
  • –plugin rdpsnd –data alsa —  – this will enable remote sound output on the Raspberry. Drdynvc is said to have better quality, but I could not get it to work unfortunately. And, yes, the trailing double dashes are part of this option.
  • server:port – can be specified as domain or IP adress. The :port can be omitted, if you are connecting to the default RDP port (3389)

If you want sound output on the remote machine, use the –o switch.

 

FAQ

What about keyboard layout?

It will work exactly as you see your keyboard input on the Raspberry console itself. Even the Windows key should work. If your layout does not work on the Raspberry console, consider setting it up using raspi-config

Will this work over WLAN?

Sure it will. Just adjust your WiFi dongle for optimum throughput and latency (yes, literally change its position, tilt, etc. until you find the best performance spot!)

We recommend you the following packes for graphical / console adjustment of Wireless settings:

aptitude install wicd wicd-gtk wicd-curses

Will Skype work?

Not tested yet – enlighten us Smile This will need microphone redirection, too.

Will forwarding of devices work?

Not tested yet – inform us about usb printers, thumb drives, etc.

How can I test sound output on the Raspberry?

aplay /usr/share/scratch/Media/Sounds/Vocals/Singer2.wav -v -V mono

Will performance over WAN networks be OK?

Yes, pretty much – sound output will suffer (a lot), but the GUI will still be quite usable. You might want to adjust the flags to disable some eye candy.

Why do the browsers “stutter” during scrolling?

In my understanding: Unfortunately browsers need a very high degree of control over their screen outputs, and thus they render it themselves, instead of letting Windows do it – RDP sees browser output as image, which is retransmitted when scrolling. Playing with image compression options might alleviate this problem a bit.

Will accessing Linux hosts over RDP work?

Not out of the box – you will need to install an X to RDP conversion software.

In a very quick and rough test, a connection set up by the Scarygliders X11 RDP O Matic as a server backend did not work reliably enough (it was installed on a Pentium IV Linux server). It might do so with some tuning.

Or another backend / solution might do the trick. Looking forward to your input Smile

 

Known problems

  • Flash (isn’t it always on some list?) – will deliver horrible audio performance, native players (Foobar2000) will be OK, though.
  • Video playback – don’t even dream of playing YouTube videos over an RDP connection … the time is not ready yet, the software not written. Care to join a noble cause?
  • WLAN performance will depend on WLAN throughput and latency. The orientation of your dongle – especially nano dongles – will be very important. It can be tuned to a decent performance state, though.
  • I can’t get the new / style switches to work with FreeRDP, fallback to the legacy – switches for now.
  • Sound output: only rdpsnd works, –plugin drdynvc –data tsmf:audio:alsa:plughw:0,0 — will not work – maybe this is a configuration issue, though and some other parameters need to be passed. Drdynvc is said to have better quality. The issue might be with servers with no sound card drivers installed. I did not find an easy solution to this, and I am looking forward to your suggestions.
  • Connection to Linux RDP server compiled with X11 RDP O Matic is not stable for me.

References & further reading

May 272013
 

In unserem vorherigen Artikel haben wir über die Möglichkeit, eine NTFS Partition über das Pi im Netzwerk für Windows Rechner bereitzustellen, berichtet.

In dem Post ist bereits angeklungen, dass NTFS auf dem Pi leider nur sehr langsam läuft (zumindest ntfs-3g, was für Partitionen > 2 TB Größe benötigt wird).

Daher haben wir auf der 3 TB Festplatte eine ext4 Partition eingerichtet. ext4 ist ein natives Linux-Dateisystem, performanter als ext3, und durch Journalling sicherer als ext2. ext2 ist in manchen Tests ein wenig schneller als ext4. btrfs befindet sich immer noch in Entwicklung, reiserfs ist nach dem Skandal um den Chefentwickler (reiser) eingeschlafen / eingestellt worden, xfs und andere Dateisysteme scheinen ihre Stärken eher bei vielen Zugriffen gleichzeitig auszuspielen, noch nicht im niedrig-tourigen Bereich. Fazit: ext4 ist eine gute Wahl.

Das Share ist schnell nach unserer alten Anleitung eingerichtet, die /etc/fstab schaut danach so aus:

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, so no using swapon|off from here on, use  dphys-swapfile swap[on|off]  for that
UUID=DA0E27C90E279E0F   /mnt/bigdata    ntfs    defaults        0       2
UUID=f70cc6cc-fa33-4df7-9e69-2d17333fba75       /mnt/e4data     ext4    defaults        0       2

Die  beiden UUIDs unterscheiden sich deutlich, da die eine für eine NTFS Partition, und die zweite für eine native Linux-Partition eingerichtet wurde.

Die weiteren Schritte befinden sich in unserem vorherigen Post.

Geschwindigkeit / Auslastung

image

Während wir beim Schreiben auf die ntfs Partition eine 100 % Auslastung, hauptsächlich durch den ntfs Treiber, sehen, sehen wir hier eine Auslastung von 50 % des Raspberrys – dabei ist der smb Daemon mit 32 % beteiligt und htop selbst immerhin mit 13 %.

Der wichtigste Unterschied ist jedoch, dass bei einem Kopierprozess das Abspielen von einem Video über den Samba Share (NTFS-Partition) nicht mehr beeinträchtigt wird, wie es bei Kopieren auf die ntfs Partition der Fall war (Prozessorüberlastung).

image

Die Top-Geschwindigkeit ist allerdings ähnlich wie mit ntfs mit ca. 2,5 – 3 MB limitiert. Vielleicht können die Samba Share Einstellungen weiter optimiert werden, um höhere Durchsatzraten zu erzielen.

Rein Technisch gesehen sollten ca. 100 Mbit/s ~ 10 MB /s erreichbar sein (Limit durch LAN Port des PI). 480 Mbit/s Bandbreite am USB Port “sollten” ausreichen um die Daten wieder auf die Festplatte zu schreiben.

Weitere Tests werden folgen.

Windows Shares: nur ein User gleichzeitig

Eine “so gewollte” Besonderheit von Windows Shares ist am Windows Rechner anscheinend die Möglichkeit sich nur mit einem User zum gleichen Server zu verbinden. Sogar wenn ich am Samba Server also zwei User für zwei unterschiedliche Shares einrichte, erhalte ich Probleme am lokalen Rechner. Die Fehlermeldung ist leider irreführend!! Man kann “Connect using different credentials” also nur EINMAL pro Server einsetzen.

Die einfachste Lösung dafür ist, einen speziellen User pro Computer auf dem Samba Server anzulegen, und allen Shares hinzuzufügen, auf die dieser User zugreifen darf.

May 212013
 

Das ist eine Anleitung wie man eine mit NTFS formatierte Festplatte über den Raspberry Pi im heimischen (Windows-) Netzwerk freigibt. Der Samba-Teil kann (und sollte) natürlich auch mit Linux Partitionen verwendet werden.

penguinadmin

ntfs-3g installieren

Dieses Paket wird benötigt um NTFS – Partitionen größer als 2 TB einbinden zu können. Ich habe diesen Absatz ganz an den Anfang gestellt, damit etwaiige Probleme erst gar nicht auftreten. Sollte man nur Linux Partitionen einbinden wollen, kann das entfallen.

Da der ntfs-3g Treiber sehr ressourcenintensiv ist, sollte man wenn möglich native Linux (ext4 / ext3) Partitionen bevorzugen.

Die dazugehörige Fehlermeldung, falls man es ohne dieses Paket  versuchen würde, würde lauten:

pi@andromeda /mnt $ sudo mount -a
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

pi@andromeda /mnt $ sudo dmesg | tail
(...)
[23556.245263] NTFS driver 2.1.30 [Flags: R/W MODULE].
[23556.265987] NTFS-fs error (device sda1): parse_ntfs_boot_sector(): Volume size (2TiB) is too large for this architecture.  Maximum supported is 2TiB.  Sorry.
[23556.266018] NTFS-fs error (device sda1): ntfs_fill_super(): Unsupported NTFS filesystem.

Daher installieren wir das Paket ganz einfach:

sudo apt-get install ntfs-3g

Einbinden einer neuen Festplatte

  • Schließe die Festplatte an.
  • Überprüfe mit lsusb ob sie erkannt wurde
pi@andromeda ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 006: ID 0bc2:3320 Seagate RSS LLC

In unserem Fall ist die Festplatte eine Seagate 3 TB USB 3.0 Festplatte (abwärtskompatibel mit USB 2.0 für den Raspberry Pi). Sie wird erkannt.

  • Liste die angeschlossenen Speichermedien auf mit:

sudo lsblk -o NAME,FSTYPE,MOUNTPOINT,LABEL,UUID,MODEL,SIZE,STATE,OWNER,GROUP,MODE,TYPE 

image

Wenn Deine Ausgabe anstelle der Baumsymbole links komische Zeichen ausgibt, stelle die Zeichensatzkodierung deines SSH-Clients (z.B. PuTTY) auf UTF-8 um. (Klick auf das Bild öffnet eine größere Version)

In unserem Beispiel wird also sowohl die SD Karte von der der Pi gebootet wird ( /dev/mmcblk0 ) mit ihren zwei Partitionen /dev/mmcblk0p1 und /dev/mmcblk0p2, sowie die Seagate Festplatte als /dev/sda mit der einzigen Partition /dev/sda1 angezeigt.

Wichtig an dieser Stelle anzumerken ist, dass die Buchstaben, z.B. das a bei /dev/sda nach der Reihenfolge des Einsteckens vergeben werden. Um jedesmal sicher die richtige Festplatte anzusprechen (z.B. wenn man mehrere Festplatten an dem Pi anschließt, oder zusätzliche USB Sticks / SD Reader / …), sollte man sich daher der UUID bedienen.

  • Liste die UUIDS auf, und verifiziere deren Zuordnung:

ls –lR /dev/disk/by-uuid/

image

 

  • Mountpoint erstellen und /etc/fstab editieren (hier erstmal die Default Einstellungen in dieser Datei zur Referenz):
pi@andromeda /mnt $ sudo su
root@andromeda:/mnt# mkdir /mnt/bigdata
root@andromeda:/mnt# nano /etc/fstab

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1

Der Mountpoint ist nötig, um die Festplatte in das Hauptdateisystem “einhängen” und damit später adressieren zu können  Es sollte sich um einen leeren Ordner handeln, der aber nicht unbedingt in /mnt liegen muss. (Nur das Verzeichnis /tmp sollte man vorsichtig benutzen – es wird bei jedem Neustart geleert).

Wie bereits oben ausgeführt, sollte man hier NICHT /dev/sda1 eintragen, sondern den Pfad mit der UUID, um sicherzustellen dass die richtige Festplatte angesprochen wird.

Wir fügen folgende Zeile in die /etc/fstab hinzu:

UUID=DA0E27C90E279E0F   /mnt/bigdata    ntfs    defaults        0       2

Dabei sind die einzelnen Spalten jeweils mit einem Tab getrennt.

  • die UUID solltest Du mit Deiner UUID ersetzen, die der Partition entspricht die Dich interessiert
  • den Mountpoint ebenfalls mit dem, den Du erstellt hast
  • das Dateisystem ggf. anpassen, falls es nicht ntfs ist
  • defaults bedeutet: standard-Einstellungen (z.B. ob das Dateisystem beim Start automatisch eingehängt werden soll – normalerweise ja)
  • die zahl 0 bedeutet “dump-freq” – Archivierungsfrequenz für das Programm dump – 0 bedeutet “disabled”
  • die zahl 2 spezifiziert die Reihenfolge des Dateisystem-Checks. Nicht-root Partitionen sollten hier eine 2 oder eine 0 (disabled) haben.

 

  • initiales Mounten

Die Partition ist jetzt in /etc/fstab eingetragen, und wir sollten sie jetzt einhängen (nach einem Neustart wird das automatisch gemacht werden):

sudo mount -a

Sollte hier ein Fehler auftreten, schaue bitte den allerersten Absatz nochmal an – hast Du das Paket ntfs-3g installiert?

 

Samba

Samba ist eine “Kompatibilitätsschicht” mit der Windows-Welt von der Linux-Seite her. Es dient nicht nur zur Freigabe von Dateien, sondern auch um z.B. Drucker für Windows zur Verfügung zu stellen.

Aus meiner Sicht ist die Freigabe unter Linux deutlich einfacher als unter Windows selber, also herein ins Vergnügen:

  • wir installieren samba
pi@andromeda ~ $ sudo su
root@andromeda:/home/pi# aptitude install samba samba-common-bin

Samba liest seine Einstellungen aus der Datei /etc/samba/smb.conf – wir schlagen vor die Default Datei als Backup zu verschieben, und eine neue Datei mit einfachen Einstellungen anzulegen. Eine einfache funktionierende Beispieldatei (in Anlehnung an diesen Artikel) ist im folgenden wiedergegeben:

# Global parameters
[global]
       workgroup = HOME
       netbios name = ANDROMEDA
       server string = Samba Server %v
       map to guest = Bad User
       log file = /var/log/samba/log.%m
       max log size = 50
#       socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
       preferred master = No
       local master = No
       dns proxy = No
       security = User

# Share
[bigdata]
       path = /mnt/bigdata
       valid users = my-samba-user
       read only = No
       create mask = 0777
       directory mask = 0777

Die Gruppe global ist ein Sonderbezeichner, es gibt außerdem weitere, z.B. für Drucker. Die workgroup “HOME” hat für uns ganz gut funktioniert, evtl. könnte man noch “WORKGROUP” ausprobieren.

Edit: Durch auskommentieren der socket options Zeile (durch die Raute #)  – wie durch den Kommentar von Basti empfohlen, kann man die Geschwindigkeit auf nahezu den vollen Durchsatz des 100 Mbit/s Ports des Raspberrys anheben! (=> ca. 10 MB/s)

Der netbios name ist der wichtigste Teil unter global. Das ist der neue Windows-Name des Raspberry Pi’s. Es macht Sinn ihn genauso zu benennen, wie den echten hostnamen des Raspberrys (das was üblicherweise auf der Kommandozeile immer angezeigt wird).

Der Name des Shares wird später unter Windows im Pfad eingegeben, ist hier in rechteckigen Klammern, bigdata.

Der vorher erstellte Pfad zum mountpoint sollte hier verändert werden, unter valid users einzutragen ist ein frei wählbarer Name (hier als Beispiel “my-samba-user”), für den wir im nächsten Schritt einen Benutzer anlegen werden.

  • Samba User anlegen, Einstellungen testen, Samba Server neustarten
root@andromeda:/etc/samba# useradd -c "Pi Samba user" my-samba-user

root@andromeda:/etc/samba# smbpasswd -a my-samba-user
New SMB password:
Retype new SMB password:
Added user my-samba-user.

root@andromeda:/etc/samba# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[bigdata]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

[global]
        workgroup = HOME
        server string = Samba Server %v
        map to guest = Bad User
        log file = /var/log/samba/log.%m
        max log size = 50
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
        local master = No
        dns proxy = No
        idmap config * : backend = tdb

[bigdata]
        path = /mnt/bigdata
        valid users = my-samba-user
        read only = No
        create mask = 0777
        directory mask = 0777

root@andromeda:/etc/samba# service samba restart
[ ok ] Stopping Samba daemons: nmbd smbd.
[ ok ] Starting Samba daemons: nmbd smbd.

root@andromeda:/etc/samba#

Das ist alles was auf Linux Seite erforderlich ist.

 

Einfacher Verbindungstest

image

Man kann jetzt im Windows (falls man den Startknopf noch hat) Dialog “Ausführen” bzw. “Run” auswählen, und den Pfad des neuen SAMBA Shares einfach angeben. In unserem Beispiel “\\ANDROMEDA\bigdata” – ANDROMEDA ist der Pi und bigdata der Share. Man beachte die BACK-Slashes!

Es geht ein Dialog auf, in dem man den ebenfalls bereits auf dem Raspberry Pi angelegten SAMBA-Benutzer und das Passwort eingeben muss, danach öffnet sich ein Explorer-Fenster mit dem Inhalt des neuen Netzlaufwerkes.

 

Dauerhafte Verbindung einrichten

 

Windows 8

image

Explorer aufmachen, Computer anklicken, Reiter “Computer”, “Map Network Drive” klicken. (Map Network Drive kann man auch per Rechtsklick auf “Computer” aus dem Kontext-Menü auswählen).

image

Hier muss man einen (lokalen) Laufwerksbuchstaben auswählen, und den Pfad des Netzlaufwerkes angeben. Bequemerweise kann man auch mit dem Knopf “Browse …” den Ordner auswählen, der Pi taucht in der HOME Gruppe einfach auf. Sollte es das nicht tun, dennoch den Pfad manuell eintippen – das sollte so klappen.

Wichtig ist, dass “Connect using different credentials” angekreuzt ist – wir haben auf dem Raspberry einen eigenen User für die Verbindung eingerichtet.

Ein Klick auf “Finish” ruft den Dialog für die Passwort / Nutzer – Eingabe auf:

image

Hier sollte man die Login Daten des speziell dafür angelegten SAMBA Nutzers eingeben. Es empfiehlt sich in sicheren Umgebungen vermutlich auch, “Remember my credentials” einzugeben, damit sich der Rechner die Zugangsdaten merkt.

That’s it – jetzt steht das Laufwerk zur Verfügung!

 

Windows 7

image

Man öffnet den Explorer, klickt auf “Computer”, und auf “Map network drive”. (Falls man es in der Leiste oben nicht findet, kann man es auch per rechts-Klick auf “Computer” erreichen).

Ansonsten analoges Vorgehen wie bei Windows 8, siehe oben!

 

Windows XP

netzlaufwerk-verbinden

Im Explorer wählt man unter Extras den Menüpunkt “Netzlaufwerk verbinden …” aus …

netzlaufwerk-dialog

es erscheint dieser Dialog, in dem man den Pfad (analog wie bei Windows 8 bzw. 7) eingeben sollte. Anders ist hier, dass man anstelle einer Checkbox “als anderer Benutzer verbinden” eine Art Hyperlink hat, den man anklicken sollte.

verbinden-als

Es erscheint daraufhin dieser Dialog, in dem man die Zugangsdaten die auf dem Raspberry Pi für Samba eingerichtet wurden, eingeben sollte. Ein Klick auf OK hier, und auf Fertig stellen im vorherigen Dialog sollte das Netzlaufwerk verbinden und gleich ein Explorer-Fenster mit dessen Inhalt öffnen.

 

Q & A

Web browser

Ein wichtiger Vorteil von SAMBA ist, dass man den Pi ab sofort unter seinem (Samba) Namen per Webbrowser erreichen kann. Z.B. kann ich einfach andromeda als Adresse angeben, und vorausgesetzt dass ein Webserver installiert ist, wird die Webseite problemlos aufgerufen

image

 

Was für eine Geschwindigkeit kann man erwarten?

Edit: Durch auskommentieren der socket options Zeile (durch die Raute #)  – wie durch den Kommentar von Basti empfohlen, kann man die Geschwindigkeit auf nahezu den vollen Durchsatz des 100 Mbit/s Ports des Raspberrys anheben! (=> ca. 10 MB/s)

image

>> ca. 5 – 6 MB/s

Dabei war die angeschlossene Festplatte eine USB 3.0 Festplatte, es wird das 100 Mbit/s Netzwerk des Raspberrys benutzt, angeschlossen sind das Zielnotebook und der Raspberry am gleichen Gigabit-Switch, und es wird auf eine SSD kopiert, was den Raspberry selber bzw. die USB Implementatoin darauf zu der Engstelle macht.

Das ist natürlich nicht besonders schnell, aber zum Streamen von Filmen, Musik, Dokumenten und für Background-Backups reicht es. Lieber allerdings nicht alles gleichzeitig Smile

Mögliche Gründe für diese niedrige Geschwindigkeit sind – neben den Flaschenhälsen LAN, USB (was sowohl für lesen von der Festplatte als auch für das LAN benötigt wird) das Dateisystem NTFS bzw. der Treiber ntfs-3g dafür. Er ist bekannt, sehr ressourcenfressend zu sein. Vielleicht ist der Default-Treiber für ntfs ressourcenschonender, bei unserem Test mussten wir jedoch ntfs-3g wegen der 3 Terabyte Größe der Festplatte verwenden. Bevorzugen sollte man wie schon erwähnt Linux-eigene Partitionsformate. Wir werden demnächst einen Test damit veröffentlichen.

Die Geschwindigkeit über WLAN (an das Notebook, Raspberry Pi ist weiterhin per LAN angebunden) ist mit ca. 700 KB/s deutlich niedriger – seltsamerweise. Wir würden uns hier über ein paar Erfahrungen von euch freuen (einfach als Kommentar posten). Evtl. liegt das auch an unserer Netzwerk-Topologie / Timing-Problemen …

 

Referenzen / weitere Information

Optimization WordPress Plugins & Solutions by W3 EDGE