Administrator's Blog

Was ich vor 2 Jahren in Deutschland noch schmerzlich vermisste hatte (Bericht aus meinem damaligen Österreich-Urlaub), gibt es nun seit einer Weile: Prepaid UMTS. Warum nun gerade N24, was sich ja eigentlich als Nachrichtensender versteht, einen der besten Tarife im Angebot hat, kann man nur erahnen. Auf jeden Fall ersetzte die N24 SIM jetzt den bisherigen web'n'walk-Tarif von T-Online, der monatlich mit 59 EUR für die gelegentliche Nutzung einfach unnötig teuer ist.

Bestellt hatte ich nur die SIM, den USB-Stick brauche ich dank eingebautem 3G-Modul im Sony Vaio TZ31WN glücklicherweise nicht. 14,99 EUR inkl. 10 EUR Startguthaben sind ein fairer Preis, surfen im Inland kann man damit zu folgenden Preisen: 60 Minuten 0,99 €, 12 Stunden 2,99 € oder 7 Tage 9,99 €. Maximal 1 GB Traffic darf pro Session anfallen, das ist mehr als ausreichend. Klar, für Power-User ist der Tarif jetzt nicht unbedingt günstiger als z.B. die web'n'walk-Variante. Für den Einsatzzweck als "Urlaubs- oder Unterwegstarif" wie in meinem Fall ist es aber perfekt geeignet.

Die Einrichtung war dank der Anleitung und aktuellem Ubuntu kein Problem, inzwischen taugt der Gnome-Network-Manager auch zum Verbindungsaufbau, so dass Tools wie "umtsmon" (Bericht) endlich nicht mehr nötig sind.

Der Speed ist angenehm (Vodafone-Netz eben..), die Auswahl des jeweiligen Zugangstarifes erfolgt beim ersten Aufruf einer Website. Dort kann man auf Wunsch auch gleich den Account aufladen. Auf die Seite n24.de kann man national jederzeit kostenlos zugreifen, sofern man dies möchte. Für ein kurzes News-Update im Urlaub vielleicht gar nicht mal schlecht. Ich habe mich auch bewusst gegen ein Angebot von E-Plus oder O2 entschieden, da mir dort die UMTS-Netzabdeckung einfach noch nicht weit genug ist.

Im Ausland kann man das Paket "International" zum Preis von 19,95 EUR täglich buchen. Für den Notfall geht das schonmal, besser ist aber sicher die Variante, sich vor Ort eine Prepaid-Datenkarte eines heimischen Providers zu besorgen.

Leider unterstützt Apple im aktuellen OS-X den ATA-Befehl TRIM nicht. Das ist für User einer SSD (wie mich, ich berichtete) doppelt ärgerlich. Zum Einen kann dadurch im Laufe der Zeit die Zugriffsgeschwindigkeit signifikant einbrechen, da nach dem Löschen von Files die entsprechenden Blöcke nicht direkt wieder benutzt werden können. Zum Anderen nervt es, dass sowohl Linux ab 2.6.28 sowie Windows 7 diesen ATA-Befehl bereits unterstützen, während "das weltweit fortschrittlichste Betriebssystem" (Zitat von Apple) dies nicht kann. Ob bzw. wann mit einem Update diesbezüglich gerechnet werden kann, ist leider ungewiss.

So kann man derzeit als SSD-User unter Snow Leopard nur einige Workarounds anwenden, um die Probleme durch den fehlenden TRIM-Support zu umgehen. Die ganz Harten bauen ab und an ihre SSD aus, stecken sie in einen Windows-PC und lassen dort Tools wie z.B. die Intel-SSD-Toolbox laufen, um die SSD wieder in den Ursprungszustand zu versetzen. Dank TimeMachine hat man dann zwar wieder sein altes OS-X drauf, der Zeitaufwand von mehreren Stunden für diese Aktion ist aber eher unangenehm. Ein reines Neu-Formatieren reicht an dieser Stelle nämlich leider nicht aus, die Blöcke werden dabei nicht explizit wieder freigegeben.

Hier nun also ein paar Tipps, um die SSD nicht ganz so sehr zu belasten, Anwendung auf eigene Gefahr:

sudo pmset -a hibernatemode 0
sudo rm /var/vm/sleepimage

Damit deaktiviert man, dass OS-X beim Ruhezustand (z.B. default bei "Deckel zu" beim MacBook der Fall) den ganzen RAM-Inhalt zusätzlich auf die Platte nach /var/vm/sleepimage schreibt. Das kann zwar im schlimmsten Fall (=Akku alle) zu Datenverlust führen, sollte aber in der Praxis keine Rolle spielen. Das vorhandene Sleepimage mit der Größe des vorhandenen RAM kann dann natürlich direkt gelöscht werden.

sudo pmset -a sms 0

Dies deaktiviert den "Sudden Motion Sensor", der normalerweise die HDD bei Erschütterungen ausschaltet. Da eine aber SSD resistent gegene Erschütterungen ist, macht diese Einstellung natürlich keinen Sinn bzw. arbeitet eher kontraproduktiv.

Das sind meiner Meinung nach die wichtigsten Einstellungen. Ich habe von vielen Usern gelesen, dass sie seit dem SSD-Einsatz "sicherheitshalber" Spotlight komplett deaktiviert haben. Der Sinn davon erschließt sich mir nicht wirklich, zumal ich ohne Spotlight nicht mehr wirklich leben wöllte.

Ein weiterer Ansatz ist, den Cache im Safari komplett zu deaktivieren oder auf eine Ramdisk auszulagern. So richtig schick finde ich diese Lösung aber auch nicht, zumal bei Safari so ganz ohne Cache keinerlei POST-Uploads von Files z.B. bei Flickr oder Facebook möglich sind. Daher habe ich den Safari erst einmal unangetastet gelassen.

Es bleibt zu hoffen, dass Apple in einem kommenden Update den TRIM-Support integriert, schließlich werden SSD mehr und mehr massentauglich und die neueren Geräte unterstützen auch fast alle diesen Befehl.

Man ist schon sehr verwöhnt, aber 30+ Sekunden für den Boot und beispielsweise 10+ Sekunden für den Start von OpenOffice.org oder anderen "Größen" wie Photoshop summieren sich bei der täglichen Arbeit schnell auf mehrere Minuten. Also bestand schon lange der Wunsch nach einer SSD im MacBook Pro. Die vorhandene Seagate Momentus mit 320 GB und 7200 RPM musste dafür natürlich ersetzt werden. Nach diversen Recherchen fiel die Wahl auf die Intel X25-M G2 mit 160 GByte, die durch gute Benachmarks auffiel. Der Preis von rund 370 EUR ist für eine SSD dieser Klasse in Ordnung, zumal Intel bei 20 GByte Transfer täglich eine Lebenszeit von mind. 5 Jahren garantiert.

Nun war die große Frage, den Einbau in das Unibody-MacBook Pro selber machen, oder nicht? 2 lokale Händler riefen Preise um die 50 EUR für den Einbau auf - etwas teuer für 5min Arbeit. Allerdings hatte ich natürlich Angst um die Garantie. An der Apple-Hotline meinte der Berater, die Garantie wäre futsch nach dem Einbau. Ein netter Mensch an der Apple-Hotline von Cyberport behauptete aber das Gegenteil. Also das MBP nach der Anleitung von ifixit.com aufgeschraubt. Warum in der Anleitung dort der Ausbau des Akku beinhaltet ist, weiss ich nicht. Man kann die Platte zumindest problemlos tauschen, ohne den Akku anfassen zu müssen. Denn dort klebt in der Tat ein Aufkleber drauf, nach dessen Entfernung die Garantie futsch ist. Auf der Festplatte hingegen nicht. Der Umbau ging schnell voran und bereitet mit einem kleinen Schraubenzieher keine Probleme.

Anschließend also von der Snow-Leo DVD gebootet, die SSD via Festplatten-Dienstprogramm formatiert und die Wiederherstellung via TimeMachin ausgewählt (vorher hatte ich nochmal manuell ein TM-Backup angeworfen, nur zur Sicherheit). Hier gab es allerdings Probleme, denn die TimeMachine-Backups auf der lokalen NAS im Büro (keine TimeCapsule!) wurden nicht erkannt. Im Netz fand sich dann aber schnell eine gute Anleitung, wie man im Terminal das NAS-Volume mounten und die Backups somit verfügbar machen kann. Funktionierte auf Anhieb perfekt! Der Restore von rund 60 GB Daten dauerte dann gute 3 Stunden, trotz GBit LAN.

Voila, alle Daten und Programm waren wieder da. Da dies mein erstes Restore via TimeMachine war, hatte ich doch ein wenig Schiss . Man kann aber wirklich sagen, dass die TM perfekt funktioniert. Mein MBP ist genau im Zustand des letzten Backups. Nur Spotlight und Mail mussten jeweils den lokalen Index neu erstellen, das dauerte aber dank der flotten SSD nur wenige Minuten. Sicherheitshalber wurde die SSD anschließend gleich noch mit der neuesten Firmware von Intel bestückt, die trotz "pack date 05.02.2010" (laut Packung) nicht auf dem aktuellen Firmware-Stand von November 2009 war. Mit der Boot-CD von Intel war das Update aber binnen weniger Minuten erledigt.

Zur Performance kann ich nur sagen: WOW! Ich bin restlos begeistert. Die Programme fliegen nur so auf den Desktop. Auch Schwergewichte wie Photoshop, Netbeans oder OpenOffice.org. Wie das konkret aussieht, kann man im folgenden Video ganz gut sehen. Auch die Boottime hat sich mehr als halbiert. Ein Xbench-Ergebnis mit der neuen Platte gibt es hier, Werte von bis zu 200 MB/sek lesend und 100 MB/sek schreibend sprechen für sich. Mit der alten HDD waren übrigens in beide Richtungen kaum mehr als 65 MB/sek drin.

Um die Platte zu schonen habe ich noch die Mount-Option "noatime" gesetzt, womit die Accesstime eines Files nicht dauernd sondern nur beim tatsächlichen Schreiben in das File aktualisiert wird. Das spart einige Zugriffe und schont die SSD. On the fly kann man "noatime" via sudo mount -uvwo noatime / setzen. Um die Einstellung permanent zu haben, kann man dieser Anleitung folgen und ein plist-File erstellen.



Ich bin also restlos begeistert und kann nur Jedem eine SSD empfehlen, dem das Geld nicht zu schade ist. Bei der täglichen Arbeit werde ich mich jedes Mal freuen, wenn sich die Programme ohne Verzögerungen öffnen etc. ..

[UPDATE]
Hier noch ein Graph des AJA-Systemtests, die die gute Performance grafisch darstellt. Im Schnitt wurden 99,2 MB schreibend und 237,2 MB lesend erreicht:

Derzeit ist ja NoSQL im Trend, und das wohl zu Recht. Bei vielen Projekten ist eine relationale Datenbank einfach nur Overkill, da oft stupide immer wieder die gleichen Datensätze abgefragt werden und die Möglichkeiten einer relationen DB nur zu einem Bruchteil verwendet bzw. benötigt werden. Aus diesem Grunde haben wir uns einmal intensiver mit den aktuellen NoSQL-Engines beschäftigt und sind zu überraschenden Ergebnissen gekommen.

Als Testumgebung diente eine VMware VM bzw. anschließend ein Dedizierter-Server (Quad-Opteron, 8 GB RAM), um noch besser die echte Performance messen zu können. Wir haben mit einem kleinen Java-Programm immer mehrere 100k bzw. millionen Datensätze (je nachdem, was so reinpasste ) geschrieben und wieder ausgelesen, jeweils mit nur einem Key in Form eines Integer. Ein kompletter "Datensatz" bestand aus jeweils so um die 200 Byte in Form eines Zufalls-String. Die Tests wurden auf zwei via GBit zum Server verbundenen MacBook's Pro durchgeführt. Die Reads wurden meist mit 30-40 Threads zu je 500-800 Datensätzen ausgeführt, um halbwegs eine echte Situation mit mehreren Clients nachzustellen.

Als erstes war Cassandra dran, wovon wir uns viel erhofften. Denn Digg, Facebook, Twitter und Andere können ja nicht irren. Oder etwa doch? Ehrlichgesagt waren unsere Tests mehr als ernüchternd. Sowohl mit Java, PERL und auch PHP schafften wir nicht mehr als 100 Writes pro Sekunde, egal wie wir es anstellten (batched, einzeln). Auf dem Server selbst gab es komischerweise keinerlei CPU- oder I/O-Last. Wir machen daher das Thrift-Interface für die schlechte Performance verantwortlich. Thrift ist ein Code-Generator, der auf Wunsch aus einem Template für viele Programmiersprachen API's baut. Das ist zwar sehr angenehm und schick, aber offenbar langsam. Abschließend konnten wir allerdings nicht gänzlich klären, warum Cassandra bei uns versagt hat. Auch die durchaus freundliche Mailingliste konnte auf unsere Anfrage hin das Problem nicht klären. Fakt scheint, dass Cassandra erst bei vielen Clients aufblüht. Wenn man von 100 Clients aus tatsächlich jeweils 100 Writes/sek schafft, sieht das Ergebnis schon wieder besser aus. Erwähnen sollte man vielleicht an dieser Stelle auch noch, dass Cassandra und Thrift relativ schlecht dokumentiert sind, was sicher auch an den Versionen 0.x liegt. Die Reads haben wir aufgrund des ernüchternden Write-Performance gar nicht erst getestet, sorry..

Memcached darf in dieser Runde natürlich nicht fehlen, zumal wir damit bereits gute Erfahrungen im Produktiveinsatz gemacht haben. Unser Java-Testprogramm schaffte hier 1000 Writes/sek und ganz ordentliche 10k Reads/sek. Was bei Memcached auffällt, ist die nahezu nicht vorhandene CPU-Auslastung, egal wie sehr man den Server quält. Diese Tatsache und auch Erfahrungen aus der Praxis zeigen, dass sehr viele Connects und gleichzeitige Abfragen wunderbar schnell beantwortet werden könnne. Problematisch ist natürlich, dass kein Backup vorliegt, wenn der Server abstirbt. Es gibt zwar einige Tools/Scripte, die einen Dump erlauben, getestet haben wie dies allerdings nicht.

Diese Lücke füllt MemcacheDB - hier werden die Daten zusätzlich zu der Kopie im Speicher noch in eine Berkeley DB geschrieben. Leider ist das letzte MemcacheDB-Release von 2008. Ob das nun daran liegt, dass die Software perfekt funktioniert oder ob die Entwickler keine Lust mehr haben, kann man nur erahnen. Wir mussten zumindest Berkeley DB 4.7 von Hand kompilieren, da die MemcacheDB nur damit zusammenarbeiten wollte. Aktuelle wäre Berkeley DB 4.8. Die Ergebnisse waren nicht direkt schlecht, wir schafften 600 Writes/sek und um die 5k Reads. Da die Daten eben noch sicher auf Platte geschrieben werden, kann die Performance nicht mit Memcached mithalten. Natürlich merkt man auch die Arbeit auf der Platte entsprechend an der Serverlast, die Werte waren aber im Rahmen.

Redis war ebenfalls einen Blick wert und beeindruckt mit dem wohl größten Funktionsumfang. Die Command Reference liest sich beeindruckend, teilweise schon fast wie die eines "echten" Datenbankservers. Ebenso beeindruckend sind eigentlich auch die Testergebnisse: 30k Writes und Reads pro Sekunde. Allerdings war die CPU hier auch ziemlich gut ausgelastet, wenn man viele gleichzeitige Zugriffe simuliert. In der Config kann man bestimmte Intervalle festlegen, in denen ein Dump auf die Platte geschrieben wird, z.B. "alle 300 Sekunden, wenn sich in dieser Zeit mindestens 1000 Datensätze verändert haben". Das macht einen Restore im Fehlerfall problemlos möglich.

Zu guter Letzt kam ein von einem netten Kollegen geschriebenes Java-Programm zum Einsatz. Es lauscht auf einem Port und nimmt dort Anfragen entgegen, nachdem es vorher über einen anderen Port mit Daten gefüttert wurde. Die Daten werden im Speicher in Form einer Hasttable gehalten. Als Key dient auch hier die Integer-ID. Der Speed ist wahrlich beeindruckend. 330k Writes pro Sekunde sind hier möglich (im Test wurden 5mio Zeilen in ca. 15 Sekunden geschrieben!!). Auch der lesende Zugriff kann sich sehen lassen, hier werden nahezu die gleichen Werte erreicht. Damit hätten wir auf keinen Fall gerechnet, aber wahrscheinlich ist eine minimale Lösung manchmal einfach die Beste . Mal schauen, wie sich die eigene Lösung in weiteren Lasttests beweist - vielleicht kommt sie ja bis zum Produktiveinsatz. Von der Geschwindigkeit und Anpassbarkeit her ist die eigene Lösung zumindest bisher die erste Wahl. Auch einen Dump z.B. einmal pro Stunde auf die Platte zu schreiben ist damit einfach möglich, ebenso das Restore aus diesem Dump. Achja, die CPU-Auslastung hält sich erstaunlicherweise ebenfalls in Grenzen. Einzelne Ausschläge an nahezu 100%, sonst eher moderat. Java wurde übrigens jeweils mit -Xmx7168m gestartet, konnte sich also bis zu 7 GByte RAM abzapfen.

Falls ihr Erfahrungen mit NoSQL habt, freuen wir uns über Kommentare. Außerdem möchten wir zu bedenken geben, dass unsere Tests natürlich nicht repräsentativ sind. Nicht immer kommt es nur auf schnelle Writes und Reads an. Diesmal aber eben schon ..

Das "Time Machine" - Konzept hat mich ja schon immer begeistert, auch wenn das Backup auf "normalen" Shares teilweise etwas umständlich einzurichten ist. Aber imho bietet kein anderes OS dem Nutzer per Default eine solch gute Möglichkeit, Backups zu erstellen.

Da sich mein Mac-Zoo stetig erweitert, d.h. ich habe zu Hause schon 3 Mac's im Einsatz (MacBook Pro, MacBook und MacMini), und meine externe USB-Festplatte (1 TByte) nicht wirklich als "Time Machine" - Speichermedium zu gebrauchen ist (man müsste sie schließlich via USB an den jeweiligen Mac anschließen, am besten täglich) und zudem noch mit durchaus hörbaren Laufwerksgeräuschen nervt, musste eine neue Lösung her.

Und natürlich lag in diesem Fall nichts näher als die Time-Capsule von Apple. Zwar schlägt die Anschaffung mit rund 400 EUR zu Buche, man hat aber immerhin 2 TByte Speicherplatz für Backups und andere Daten (Zugriff via SMB oder AFP möglich), einen flotten WLAN-Router (Draft-N, optional auch 5 GHz - Benchmarks weiter unten) und eine nette Optik in einem Paket.

Die Einrichtung war Apple-Like einfach und problemlos, ich musste allerdings mein "Airport-Dienstprogramm" mit der mitgelieferten CD auf den neusten Stand bringen. Ein Webinterface hat die Time Capsule nicht, was eigentlich ein wenig schade ist. Aber nach der initialen Einrichtung hat man eigentlich keine Grund mehr, noch groß an der Config rumzuschrauben. Dank SNMP- und Syslog-Support kann man zumindest recht einfach prüfen, wie es der Capsule so geht.

Etwas seltsam finde ich allerdings, dass man nur einen einzigen externen (SMB/AFP)-Share einrichten kann - bei mir heisst er "Storage". Ich habe bisher keine Möglichkeit gefunden, weitere Shares einzurichten oder die Festplatte zu partitionieren. Dies ist insofern etwas unschön, dass die Sparsebundles von Time Machine sowie meine MP3-Sammlung und einige Filme jetzt alle im selben Share liegen. Kein Beinbruch, aber da wäre mir eine weiter Unterteilung lieber. Oder habe ich nur Etwas übersehen?

DSL funktioniert auch problemlos, die Time Machine fungiert bei mir jetzt als WLAN-Accesspoint, die den Traffic an den angeschlossenen DSL-Router weiterleitet. Auch DHCP übernimmt weiterhin der DSL-Router. Traumhaft wäre natürlich noch, wenn es die Capsule alternativ mit DSL- oder Kabelmodem gäbe. Das würde wieder ein Gerät im heimischen Elektrosmog-Kabinett weniger bedeuten..

Der WLAN-Speed ist über jeden Zweifel erhaben, zumindest im Vergleich mit dem des DSL-Routers von vorher (G, 54 MBit/s brutto). Auch dem Draft-N Accespoint von Linksys im Office ist die Capsule haushoch überlegen. Anbei ein paar Benchmarks zur Verdeutlichung, jeweils mit dd if=/dev/zero of=1gb bs=1024k count=1000 (1 GByte mit Nullen schreiben..) von meinem MacBook Pro aus auf dem Time Capsule Volume erzeugt:

LAN 1 GBit/s
1048576000 bytes transferred in 26.168565 secs (40070061 bytes/sec)

WLAN N Linksys Office
1048576000 bytes transferred in 198.631303 secs (5279007 bytes/sec)

WLAN N TimeCapsule
1048576000 bytes transferred in 116.920349 secs (8968293 bytes/sec)

WLAN 5GHz TimeCapsule
1048576000 bytes transferred in 73.029436 secs (14358265 bytes/sec)

Im 5GHz-Netz bekommt man also im Durchschnitt fast 15 MByte/s über das WLAN. Das liegt deutlich über dem Wert einer Fast Ethernet Leitung mit 100 MBit/s und ist für den normalen Gebrauch mehr als ausreichend. Damit kann man auch mal ein ISO-Image oder große Backups auf die Capsule übertragen, ohne dafür den Mac 2 Tage durchlaufen zu lassen. Auch der LAN-Speed ist ziemlich gut, 40 MByte/s schaffen zumindest viele der SoHo-NAS-Geräte nicht.

Die Time Capsule ist also durchaus empfehlenswert und ziemlich flott unterwegs, was den Netzwerkzugriff angeht. Einziger Wermutstropfen bleibt die Tatsache, dass man nur 1 Share einrichten kann je Festplatte. Aber vielleicht hat ein Kommentator noch einen Tipp für mich ...

Da ich zu Hause sowie im Office nahezu den ganzen Tag den chilligen Klängen meines #1 Radiosenders Lounge-Radio.com lausche, musste jetzt mal ein (W)LAN-Radio her. Immer einen PC/Mac zu booten, um Musik zu hören, hat irgendwie doch etwas genervt. Außerdem sind die Speaker am Apple Cinema Display nicht wirklich der Reißer, wenn man Musik mag.

Nun begann natürlich die Suche nach einem geeigneten WLAN-Radio. Es gibt ja diverse Modelle von Hama und Logitech, die aber keine eigenen Lautsprecher haben und somit ausschieden. Seltsamerweise haben sehr viele Modelle auch nur eine Box, bieten also nur Radiowecker-Sound in Mono an. Bei einem 128kbit - Stream darf es aber ruhig schon Stereo sein.

Nach langen Recherchen bei Amazon und Co. kam ich dann zum Sangean WFR-20. Den offenbar niederländischen Hersteller kannte ich bisher nicht, die guten Kritiken zu dem Gerät hatten mich aber überzeugt. Also bei Redcoon für 198 EUR bestellt und prompt geliefert bekommen.

Nun steht das Radio seit einer knappen Woche hier rum und dudelt 8 bis 10 Stunden am Tag ohne irgendwelche Aussetzer. Wir haben es allerdings nicht via WLAN, sondern klassisch via Kabel ans Netz angeschlossen, da es direkt neben einem Switch steht. DHCP klappt problemlos, so dass wir keinerlei Netzwerkeinstellungen machen mussten. Anschließend machte das Gerät erstmal ein Firmware-Update, was auch problemlos funktionierte.

Der Sound ist wirklich gut, was natürlich auch vom jeweiligen Stream abhängt. Man kann Bässe sowie Höhen getrennt regeln, das bietet auch nicht jedes Modell in dieser Preisklasse an. Mit 128kbit Streams erreicht man also einen recht guten Klang, der über jeden kleineren PC-Speaker erhaben ist.

Für seine Lieblingssender kann man auf der IR-Fernbedienung (im Chipkarten-Format, nicht unbedingt ein optisches Highlight - funktioniert aber sehr gut) 6 Sendertasten belegen. Vielleicht etwas zu wenig, reicht uns aber derzeit noch aus. Außerdem kann man vom Radio aus auf den Dienst live365.com zugreifen, wo sich Senderlisten etc. abspeichern lassen. Dies haben wir allerdings noch nicht getestet.

Was fehlt, ist eine Mute-Taste. Wenn z.B. das Telefon klingelt, wäre dies schon hilfreich. So bleibt entweder das Ausschalten oder manuelle herunterregeln der Lautstärke. Witzig war auch, dass in der Anleitung explizit auf den Internetdienst reciva.com zur Senderlisten-Verwaltung hingewiesen wird - leider unterstützt offenbar die aktuelle Firmware diesen Dienst nicht mehr. Geht aber auch ohne derartige Dienste problemlos, man muss sich eben nur durch die Senderlisten bzw. Genres hangeln..

Fazit: Ein WLAN-Radio mit gutem Klang zu einem eigentlich auch ganz guten Preis, wenn man sich Konkurrenzmodelle mit ähnlicher Ausstattung ansieht. Klare Kaufempfehlung!