The latest posts in full-text for feed readers.
A couple of days ago someone contacted me by e-mail and told me of his problem with a Noxon iRadio Cube: He used it to listen to his favorite podcast, and that podcast had fully switched to HTTPS, and had stopped to provide HTTP feeds and files. Since the iRadio does not support HTTPS, he could not listen to the podcast anymore.
He asked if my noxon gateway software could help there and I said yes. After helping him setting up the software on his Linux machine, we found a bug that prevented the radio from fetching the encryption token and using the server at all. This was quickly fixed.
Registering a podcast on the noxon-gateway software is as easy as creating a text file with the feed URL inside. The gateway will then fetch the RSS, parse it and convert it to the menu structure that the iRadios understand.
The last problem was HTTPS: I wrote a small proxy script that you can pass any URL to, and it will fetch and stream the response to the client. If you have noxon-gateway running, simply set the following in your data/config.php file:
$enablePodcastProxy = true;
The radio now fetches the MP3 file from the gateway's HTTP proxy URL and is happy.
My conversation partner declared success; he could now listen to his podcast again on the old iRadio Cube.
Published on 2020-01-08 in hardware, noxon, server
Meine eigene Noxon-Serversoftware hat ein viel übersichtlicheres und vor allem auf mich zugeschnittenes Podcastverzeichnis. Allerdings schaffe ich es meist nicht, einen ganzen 2h-Podcast am Stück zu hören und würde beim nächsten Mal gern wieder an der letzten Stelle weiterhören.
Beim Noxon iRadio und dem iRadio Cube kann man durch Gedrückthalten der vorheriges-Lied-Taste oder der nächstes-Lied-Taste spulen - und zwar mit 1.5facher Normalgeschwindigkeit. Das hilft so gar nicht wenn man eine ganze Stunde vorspulen möchte.
Die Geräte sind UPnP MediaRenderer und unterstützen das AVTransport:1-Protocol. Dieses definiert den Seek-Befehl mit dem man dem Abspielgerät sagen kann, dass es bitte mal spulen soll.
Die Spezifikation definiert verschiedene Spulmodi (A_ARG_TYPE_SeekMode), unter anderem springe-zu-zeitpunkt ABS_TIME und springe-relativ REL_TIME. Mit diesen beiden Modi könnte ich eine manuelle Spul-Spring-Steuerung über meine Noxon-Serversoftware nachrüsten.
Nachdem ich mich tief genug in die Spezifikation eingelesen hatte um das Protokoll gut zu verstehen, fand ich in der Servicebeschreibung der beiden Radios Folgendes:
A_ARG_TYPE_SeekMode
string
TRACK_NR
]]>
Der einzig erlaubte Spulmodus ist TRACK_NR - der einzige, der laut Spezifikation implementiert werden muss. Sendet man den Befehl, ist der einzig erlaubte Wert 0, also die aktuelle Datei.
Sinnlos.
Damit sind die Noxon iRadios nicht für Podcast-Hören zu gebrauchen.
Während des Stöberns in den Radiointerna fand ich noch etwas vermutlich Interessantes:
urn:schemas-upnp-org:service:HtmlPageHandler:1
urn:upnp-org:serviceId:HtmlPageServiceID
/HtmlPageHandler/desc.xml
/HtmlPageHandler/ctrl
/HtmlPageHandler/evt
]]>
Dieser Service definiert folgende Befehle:
actHtmlTcpip hat Parameter wie argHtmlIPAddress, argHtmlNetMask und argHtmlGateway was darauf schliessen lässt, daß man damit die Netzwerkeinstellungen ändern kann.
Das Ir in actHtmlIrControl steht vermutlich für Infrarot - was meinen Wunschgedanken nach bedeutet, dass ich eine Fernbedienung simulieren und per Netzwerk Befehle ans Radio schicken könnte.
Leider habe ich es nicht geschafft, auch nur einen einzigen der Befehle ohne Fehler auszuführen :/ Falls jemand mehr Infos hat, bitte her damit!
Published on 2016-01-28 in bigsuck, noxon, upnp
2008 begann ich damit, das Haus mit Internetradios auszustatten . Die Noxon iRadio-Geräte (Noxon iRadio und iRadio Cube) haben leider fest eingebaute Menüeinträge , die man nur mit Internetverbindung nutzen kann.
Diesmal habe ich das von den Radios gesprochene Protokoll analysiert, dokumentiert und meine eigene Serversoftware implementiert, mit der ich jetzt die Heizung steuern kann.
Die iRadio-Geräte haben einige sehr störende Bugs:
Die Noxon-Internetradios telefonieren regelmäßig nach Hause. Ich habe deshalb von Anfang an die angefragten Domains auf 127.0.0.1 gemappt.
Die Uhrzeit ist - vor allem auf dem iRadio Cube - falsch, obwohl NTP eingstellt ist. Das ganze hängt auch noch von der Sommerzeit/Winterzeit-Einstellung ab; im Sommer zeigt das Radio fast eine komplette Stunde falsch an, im Winter sind es ~10 Minuten.
Wenn das Radio einen Tag im Standby ist, verliert es den UPnP-Server - und findet ihn auch nicht mehr, wenn man es wieder aus dem Standby weckt. Man muss das Radio richtig hart neustarten, damit man es wieder nutzen kann.
In UPnP-Ordnern mit vielen Einträgen (gefühlt ab 50, ich habs aber auch schon bei welchen mit 10 erlebt) kann man nicht mehr in die Ordner reinwechseln.
Man scrollt runter zum gewünschten Ordner, drückt -> und ist wieder am Anfang der Liste.
Ganz krass ist es bei Ordnern mit 200+ Einträgen: Einfach nach oben scrollen, so dass man am Ende rauskommt und dann noch ein paar mal nach oben drücken - schon ist man komplett aus dem Menü raus und im Hauptmenü.
Damit ist das Radio bei größeren Albenlisten unbenutzbar.
Da Terratec vermutlich irgendwann die Server abschalten wird, habe ich mit mitmproxy den Datenverkehr der Radios mitgeschnitten, analysiert und das Protokoll dokumentiert . Mit der API-Doku konnte ich nun meinen eigenen Noxon-Server bauen.
Ich hatte mehrere Ziele:
Da die Radios fest eingebaute Menüeinträge Internetradio, Podcasts und My Noxon haben - die niemals verloren gehen - war die erste Idee, das Internetradio-Menü mit dem Inhalt des UPnP-Servers zu bestücken
Ich hatte 2008 mehr aus Spaß geschrieben:
Knowing this format, one could make the menu entries actually useful by creating a noxonXml-to-MediaTomb gateway with Services_MediaTomb :)
Genau das habe ich auch gemacht; wenn man das Internetradio-Menü betritt sieht man genau denselben Inhalt wie wenn man den UPnP-Server-Menüeintrag ausgewählt hätte.
Zwei Vorteile:
Das iRadio Cube unterstützt - im Gegensatz zum originalen iRadio - leider kein ogg/vorbis. Da der UPnP-Server jetzt nicht mehr direkt von den Radios angefragt wird, musste ich die Konvertierung von .ogg-Dateien nach .mp3 selbst implementieren.
Als die grundlegende API zum Ausspielen von Menüs implementiert war baute gleich ich noch einen Datei- und Verzeichnisansichtsmodus ein.
Damit werden die Menüs Podcasts und My Noxon jetzt auf Pfade im Dateisystem abgebildet: Wenn man My Noxon aufruft, wird der Inhalt des Verzeichnisses var/mynoxon aufgelistet.
Ordner und Textdateien werden im Radio als Ordner dargestellt. Navigiert man in eine Textdatei hinein, wird jede Zeile der Textdatei als nicht-navigierbarer Menüeintrag ans Radio ausgeliefert.
Für die Anzeige auf dem Fernseher habe ich schon solche Textdateien für die letzten Anrufe, die nächsten Geburtstage, den Kontostand und die Zimmertemperaturen.
Ich nutze zur Darstellung auf dem Fernseher meine Dreambox-Extension curlytx .
Schnell kam ich auf die Idee, ausführbare Dateien (chmod +x) auch als Ordner darzustellen. Navigiert man in diesen Ordner hinein, wird die Datei ausgeführt und die Ausgabe des Programms wie bei Textdateien zeilenweise ans Radio gesendet.
Schnell kamen noch Autostartscripte hinzu, die automatisch ausgeführt werden, wenn man einen Ordner auflistet, und deren Ausgabe in die Ordnerauflistung integriert.
Wir haben eine Wärmepumpe von Dimplex, die per Netzwerkmodul (NWPM) ansprechbar ist.
Über HTTP kann man die aktuellen Einstellungen auslesen und ändern, wie ich es mit meinen dimplex-tools mache:
#!/bin/sh
set -e
ipaddress=1.2.3.4
res=`curl -sS "$ipaddress/usr-cgi/xml.cgi?I|1|1"`
echo "$res"\
| grep VALUE\
| tr -cd [:digit:]
echo
Dieses Script liest die aktuelle Einstellung der manuellen Anpassung der Rücklaufsolltemperatur aus. Wenn man diese ändert, wird das Haus wärmer oder kälter.
Schnell waren ein paar Scripte geschrieben, eins das die aktuelle Einstellung der Wärmepumpe im Ordner "Heizung" anzeigt, und Scripte zum Wärmer- und Kälterstellen der Heizung:
Die resultierende Serversoftware heisst noxon-gateway und ist auf meinem Git-Server zu finden.
Published on 2016-01-14 in blackbox, noxon, php, server, upnp
Since moving into our house, I've constantly been trying to make our lives more pleasing in the technical way. Here is a depiction of what has been achieved yet.
Despite the non-standardness of UPnP (based on a µ$-draft for HTTP-over-UDP that expired back in 2001), it's the only common protocol that most devices in our network understand. UPnP has been rebranded to DLNA some time ago, but it's still the same old crap. There are quite some devices that understand UPnP, but all in their own interpretation. The most unfamous UPnP player amongst the MediaTomb developers is the Sony Playstation 3 which seems to support their own UPnP dialect only, thus needing dozens of hacks on UPnP A/V servers just to see the list of audio and video files. Not to speak of "oh, I play only that format at this bitrate"-wtf features. I don't have one, but that had to be mentioned here.
As I said, many devices in my network understand UPnP: The kitchen radio (a noxon iRadio), our bedroom alarm clock (Freecom MusicPal) and the satellite receiver (Dream Multimedia's Dreambox) using djmount.
The main goal of our central MediaTomb UPnP A/V server is to serve the music collection for the above mentioned devices. Due to its transcoding capabilities, it is able to convert the ogg/vorbis music files transparently to audio/wav streams - which is necessary because the MusicPal does not play ogg. Using it, we are also able to listen to satellite radio in the kitchen, transcoding the Dreambox'es mpeg2/ts streams to wav.
During the time I needed a way to manipulate the MediaTomb server from my PHP scripts. The development of Services_MediaTomb, a library to remotely administer the - surprise - MediaTomb server is one of the public results of my home automation efforts. I use it to sync radio stations from the Dreambox and to make the LDAP addressbook available on the radios. In the house we have access to telephone numbers and addresses from everywhere.
Another use case for Services_MediaTomb is GravDigger, the MediaTomb playlist editor. It's a two-pane file manager like application you can use to create playlists on the server, a functionality that MediaTomb keeps missing.
Also in use is CorpseShovel - also based on Services_MediaTomb - which shuffles all playlists on the server every night (Yes, MediaTomb can't shuffle playlists by itself).
Years ago, I wrote a software to remind me of upcoming birthdays and other anniversaries - due to my elaborate wording skills named "birthday reminder". In the meantime, it works on every operating system and reminds many people every day. The only problem I had was that you need to use your computer to see the coming dates.
Then I discovered that Freecom's MusicPal supports RSS feeds (and only RSS, no Atom!). Within some hours I had a script which takes a birthday file and creates an Atom and RSS feed from it. Now every morning I wake up, the Radio clock shows the latest events. It has one drawback: You have to move your head and stare at the display - something that will change once I find a reasonably sexy female voice for the festival speech synthesizing engine. The DreamBox is also able to display them via its SimpleRssFeed plugin (that shows Atom!).
Beside audio files streaming to various radio devices the server also holds our video collection. I made a nice HTML frontend to browse the files (FileLister) that automatically creates thumbnails for videos and photos. It links the files to download to the ftp server, so we get higher transfer rates.
The DreamBox is very limited in the choice of video codecs it can play. Luckily we have a VLC plugin which plays videos streamed from remote vlc instances. Just fire up VLC on your desktop or laptop, enable the HTTP interface and you can play any videos on that machine - very comfortable for watching DVDs.
Due to my limited internet connectivity, I am forced to keep things as local as they can be. The server hosts its own CDDB service, acts as Gentoo portage mirror (and synces itself from the laptop), is the backup device (using rsync and nfs) and provides a nice HTML and REST interface to the ISDN dialup connection. Not to forget the time service (ntp and timed), Dreambox mirror and NNTP server :)
There are more things to come: The next steps on the plan are local Wikipedia and OpenStreetmap servers, a complete Asterisk based telephony solution that integrates with the LDAP address book and the gate intercom. It shall also be possible to open the gate from everywhere and see the telephone callee on every device (Radio, Dreambox, PC, network printer). And the mobile phones shall sync themselves with the address book :) Much to do, but all ideas are possible to realize.
Published on 2008-08-20 in dreambox, hardware, http, ldap, leben, network, noxon, offline, php, programming, server, upnp
My kitchen radio, a noxon iRadio, plays happily music from my UPnP server. This is what I bought it for. Unfortunately for me, it is also able to store favorites online, list thousands of online radio stations and play them.
So far so good. Two problems:
While this items are no problems themselves, the combination of them and the fact that I am offline at home are a problem. When you open one of those 5 menu entries or the favorites, the radio hangs. This is because it can't reach any servers it wants to connect to. A mail to the support got me in contact with one of the developers, and he told me that setting the timeout down to some seconds - so that it would be usable for me - is not possible, and never will. Not to speak of deactivating the whole online crap.
So with no help to expect from the producer (Ha! When do you ever get that?) I had to find a solution myself. By installing tcpdump on my home server (which also acts as gateway) and running
tcpdump -i ppp0 -s 1500 -w noxon.tcpdump
while clicking around the menu, I got some data that helped me to identify the problem. The file can be opened with Wireshark.
This lid up my mind: The radio sends 6 DNS requests and waits for the domains (radio567.vtuner.com, radio5672.vtuner.com and gatekeeper.my-noxon.net) to be resolved. This it what hangs the radio - when I'm offline, no DNS requests can be answered apart from the names of my own machines.
So some entries in the gateway's /etc/hosts file made the radio react even when I am offline: It simply redirects the host names to some non-existant ip address. Favorites, here we come!
Inspecting the network communication dump file further told me how the radio's menu system works. The main menu entries call just some hard coded URLs which responds with an XML file that tells what to display.
On all requests, the radio transmits its own MAC address, language and firmware version number. The MAC address authenticates you when retrieving your favorites. This means by providing a different MAC, you could retrieve someone else's favs.
To prevent that simple attack on your privacy, the radio retrieves an encryption token which is later used to encrypt the mac address. The only problem seems to be that this token does not change for at least a day. So as soon as you capture someone's radio network traffic, you have full access to their favorites as long as the token does not change.
What also bothers me a bit is that both servers (vtuner and my-noxon gatekeeper) return the same encryption token, although they are different boxes and they use different scripting languages (asp and PHP). This could be a sign that this token is hard-coded. In that case, the only thing that prevents one to retrieve everyone's favorites (and other my-noxon services the one could even have paid for) is that the encryption method is secret.
Seems a bit like security by obscurity. Here are some encryption examples. The token is used to get the encrypted mac address:
Real MAC: 00:16:E3:EA:52:B9 Encryption examples: token: 0000000000000000 mac: 3B834F07044E1DA94792258E5E777FE9 token: 0000000000000001 mac: E696881E02E16DBB6CD734CDE5413387 token: 1111111111111111 mac: 5F7B1751BB0AAB22F90A72B0997718EE token: a6703ded78821be5 mac: B2FB31BE594C9FD322408AB8CC8F7679
The XML data coming back from the sites is a ListOfItems that either tell the radio to display a message, or list some directories and radio station streams.
]]> Display -- Empty List --
or
]]> Previous http://radio567.vtuner.com/setupapp/radio567/asp/BrowseXML/loginXML.asp?gofile= http://radio5672.vtuner.com/setupapp/radio567/asp/BrowseXML/loginXML.asp?gofile= Dir Afrika http://radio567.vtuner.com/setupapp/radio567/asp/BrowseXML/navXML.asp?gofile=S-ByLocation-Africa http://radio5672.vtuner.com/setupapp/radio567/asp/BrowseXML/navXML.asp?gofile=S-ByLocation-Africa - ...
Dir Asien http://radio567.vtuner.com/setupapp/radio567/asp/BrowseXML/navXML.asp?gofile=S-ByLocation-Asia http://radio5672.vtuner.com/setupapp/radio567/asp/BrowseXML/navXML.asp?gofile=S-ByLocation-Asia
The lists can be made non-cachable (Why should we respect HTTP headers?) by providing a <NoCache>Yes</NoCache> directly after the opening ListOfItems tag.
Knowing this format, one could make the menu entries actually useful by creating a noxonXml-to-MediaTomb gateway with Services_MediaTomb :)
Published on 2008-07-26 in blackbox, network, noxon, offline, server
Dreambox + MediaTomb + Noxon iRadio = streaming satellite radio into the kitchen.
I'm on modem. Totally on modem - no DSL, no internet via satellite, no UMTS, nothing. Just a plain ISDN link to the outer world. Internet radio streaming is out of range for me.
Getting the networked kitchen radio, noxon's iRadio, to play ancient radio stations.
It probably helps to know that the iRadio is not able to play the stream directly from the dreambox, since - in my understandings - there are no proper headers in the stream. FFmpeg does not even recognize it. The dreambox just streams the raw data received from satellite into the network, without any modification.
As written previously, ffmpeg - the ideal audio converter - does not recognize the data format. The alternative, mencoder, does not like to convert streams without video. But mplayer/mencoder (and vlc) are the only ones to recognize the stream and play it.
The mplayer-users mailing list helped me: Mplayer itself can save audio streams to PCM/wav files, using the option -ao pcm. The first part of the puzzle was solved (Thanks, RC!).
In version 0.11, MediaTomb got transcoding capabilities. That basically means that any external tools can be used to convert files on the fly into formats that the requesting UPnP media renderers understand. You choose a non-existing MIME type that the player does not understand (e.g. audio/x-satellite-mpeg2) and create a transcoding profile for that MIME type into audio/x-wav, which is understood by the media renderer.
I added the following piece
of code
lines into MediaTomb's config.xml, directly after
<import>:
]]> audio/x-wav yes no no
The last easy step: Open the MediaTomb web frontend and add an item "External Link (URL)", put in the direct URL (not the m3u playlist link) and MIMEtype audio/x-satellite-mpeg2. (If you want to add the m3u, you need to add the -playlist parameter to the mplayer arguments.)
Select the radio station in your player and enjoy!
Instead of adding the items directly via the web interface, one could put text files with .mms extension into a folder. The files only need to contain an URL to the dreambox (m3u or direct stream), nothing more. Map .mms extensions in <extension-mimetype> to the non-standard MIME type, and you're done.
Published on 2008-04-19 in http, network, noxon, server, tools, upnp