Samstag, 25. November 2023

„Altes“ von der Postbank

Wie Anfang des Jahres berichtet, hatte die Umstellung der IT-Infrastruktur bei der Postbank einige unschöne Nebenwirkungen. Aber es hat sich was getan.

Seit September dieses Jahres hat die Dateigröße der PDF-Kontoauszüge merklich zugenommen.
Seither kann man den Text wieder mit Auswählen/Kopieren/Einfügen aus dem PDF heraus kopieren und erhält dabei kein Kauderwelsch mehr, sondern tatsächlich den angezeigten Text.

Auch CSV-Dateien mit den Buchungsdaten lassen sich nun wieder erstellen... Ich bleibe jetzt aber bei Jameica.

Freitag, 24. November 2023

Web-Apps auf RaspberryMatic?

Web-Apps sind Programme, die im Webbrowser des Betrachters laufen. Aber warum sollte man so etwas mit RaspberryMatic einsetzen? Das hat doch schon eine GUI?

Jeder, der bereits ein RaspberryMatic-System aufgesetzt hat, kennt die RaspberryMatic-Weboberfläche. Mit ihr kann man alles einrichten, einstellen und programmieren, was bei einem Homematic-System notwendig ist.

Eines ist sie jedoch nicht: übersichtlich. Jemand, der das System nur oberflächlich kennt, findet sich darin kaum zurecht.

Es liegt also nahe, für solche Benutzer eine angepasste Oberfläche zu programmieren. Diese auf dem Raspberry selbst zu implementieren ist recht schwierig. Bei einer Webanwendung hingegen läuft die Weboberfläche auf dem Rechner des Betrachters, der wahrscheinlich um ein Vielfaches leistungsstärker ist, als ein Raspberry.

Und RaspberryMatic bringt im Prinzip auch alles mit, was man dazu braucht:

  • einen Webserver, über den die App ausgeliefert werden kann
  • mehrere APIs, mit denen Sensoren ausgelesen und Aktoren gesteuert werden können.

Allerdings, im Auslieferungszustand funktioniert diese Idee nicht – und RaspberryMatic trifft dabei nur eine geringe Schuld.

Grund ist ein in allen gängigen Webbrowsern eingebauter Schutzmechanismus: „Same Origin“. Dieser besagt, dass Sachen nur dann ungefragt von einem Webserver nachgeladen werden dürfen, wenn die aufrufende Seite (in diesem Fall die Web-App) auch von dort stammt.

„Same Origin“ bezieht sich hierbei leider nicht nur auf die gleiche Maschine, sondern auch auf den gleichen Port – und der Port, über den die APIs angesprochen werden, ist ein anderer als der HTTP(S)-Port, von dem die Web-App geladen wird.

Wenn die Web-App nun versucht, den API-Port anzusprechen, generiert der Webbrowser, in dem die App läuft, eine Nachfrage auf dem entsprechenden Port, ob der Zugriff gestattet ist: die sog. CORS-Anfrage. Diese versteht RaspberryMatic jedoch nicht und antwortet mit einem Fehler, der vom Webbrowser als ein „Nein“ interpretiert wird. Die Webbrowser blockiert dann die eigentliche API-Kommunikation.

Es gibt mehrere Möglichkeiten, dies zu beheben. Dieser Post beschreibt, wie man diesen Zustand „minimal-invasiv“ ändern kann.

Die hier beschriebene Lösung ermöglicht die API-Abfrage über den normalen HTTPS-Port und besteht aus einigen wenigen zusätzlichen Zeilen in einer Konfigurationsdatei. Damit wird die API-Abfrage wirklich „Same Origin“, die CORS-Anfrage entfällt und RaspberryMatic kann über eine Web-App gesteuert werden.

Hinweis: Die APIs sind eigentlich für „normale“ Programme (Skripts oder ausführbare Anwendungen) auf anderen Rechnern gedacht. Diese kennen den „Same Origin“-Schutz nicht und machen deshalb auch keine CORS-Anfrage.

Auswahl der API

RaspberryMatic kennt zwei APIs: die XML-API und die Homematic-Script-API.

Die XML-API verwendet zur Abfrage von Sensoren und Steuern von Aktoren – wie der Name schon vermuten lässt – XML-Snippets. Der Grund weshalb ich sie in diesem Beispiel nicht verwende ist, dass die XML-API keinen Zugriff auf die bei der Homematic-Programmierung häufig verwendeten Systemvariablen bietet.

Die Homematic-Script-API hingegen erlaubt das Ausführen beliebiger kleiner Homematic-Scripts. Diese Skripts können dann Sensoren abfragen, Aktoren steuern aber eben auch Systemvariablen lesen und schreiben.

Der Zugriff auf die Homematic-Script-API muss in der RaspberryMatic-Firewall freigegeben werden (Einstellungen > Systemsteuerung > Firewall konfigurieren) - siehe nebenstehendes Bild.

Firmware ändern

Um die Firmware eines RaspberryMatic zu ändern, muss man sie zunächst entsperren, d.h. editierbar machen. Hierzu muss der SSH-Zugang im RaspberryMatic freigegeben sein (Einstellungen > Systemsteuerung > Sicherheit > SSH).

Dann kann man sich per SSH als Anwender eingeloggen und hat Root-Rechte. Das Entsperren der Firmware erfolgt dann mit dem Befehl:

mount -o rw,remount /

Nach dem Entsperren kann die Konfigurationsdatei lighttpd.conf des Web-Servers mit dem auf dem System installierten Editor vi editieren werden:

vi /etc/lighttpd/lighttpd.conf

Hängen Sie unten den folgenden Text am Ende der Datei an (Hinweis: Aufrufen des Einfügemodus bei vi erfolgt mit der Taste „i“):

$HTTP["url"] == "/regex.exe" {
  $HTTP["request-method"] == "POST" {
        url.access-allow = ("")
        proxy.server = (
            "" => (
                "localhost" => (
                    "host" => "127.0.0.1",
                    "port" => 8183,
                ),
            ),
        )
   }
}


Speichern Sie die Änderungen… (vi verwendet hierzu ESC : w q)

„Sperren“ Sie die Firmware wieder gegen Änderungen:

mount -o ro,remount /

Stoppen und starten Sie den Webserver

/etc/init.d/S50lighttpd stop
/etc/init.d/S50lighttpd start


oder starten Sie im Zweifelsfall das System über die normale WebUI neu (Einstellungen > Systemsteuerung > Zentralenwartung > RaspberryMatic-Neustart).

Der Zugriff auf die Script-API ist nun auch über den normalen Webport mit einem POST-Befehl an die URL

/regex.exe


möglich.

Beschreibung der Änderung

Bei der Untersuchung des Problems hat sich herausgestellt, dass der RaspberryMatic-Webserver lighttpd auch für die Kommunikation der API-Ports zuständig ist und diese Befehle einfach an einen weiteren internen Port (in diesem Fall 8183) weiterleitet. Und genau das ermöglicht diese Änderung auch für den Zugriff über den normalen Webport.

Persistenz

Diese Änderung übersteht einen Neustart des Systems.

Hingegen überschreibt eine Neuinstallation der Firmware oder das gelegentliche RaspberryMatic Firmware-Update auch Konfigurationsdateien und damit diese Änderung. Nach einem solchen recht seltenen Ereignis muss die Änderung in der Konfigurationsdatei, wie oben beschrieben, erneut vorgenommen werden.

Sicherheitsaspekte

Beim Satz „erlaubt die Ausführung beliebiger Scripts“ sollten eigentlich die Alarmglocken klingeln. Um das Risiko zu minimieren, sollte der Zugriff auf die Homematic-Script-API nur verschlüsselt (HTTPS) und nur passwortgeschützt erfolgen.
Benutzer mit einem gültigen Passwort können jedoch beliebige Scripts auch über die normale RaspberryMatic-Weboberfläche ausführen, d.h. das Risiko ändert sich durch die Web-App also nicht.

Über „Systemsteuerung > Einstellungen > Firewall konfigurieren“ kann man, wie oben gezeigt, den Zugriff auf das lokale Netzwerk (192.168.0.*) einschränken.

Wenn solche Systeme hinter einem Internetrouter laufen und nur aus dem lokalen Netzwerk von einem autorisierten Benutzer angesprochen werden können, ist das Risiko also überschaubar.

Diese Konfigurationsänderung wurde mit den folgenden RaspberryMatic-Firmwareversionen getestet: 3.65.11.20221005 und 3.71.12.20230826.

Weitere Links zum Thema





Samstag, 25. Februar 2023

„Neues“ von der Postbank


Ende letzten Jahres hat die Postbank mit viel Aufwand ihre betroffenen Privatkunden über einen anstehenden Umzug ihrer IT-Infrastruktur informiert. Das dies nicht reibungslos über die Bühne gehen würde scheinen sie schon geahnt zu haben.

So wurde etwa die Kreditkartenabwicklung auf eine andere Site ausgelagert und die Übertragung der Sicherheitscodes bei Online-Kreditkartenkäufen erfolgt im Augenblick wieder per SMS.

Zum Jahreswechsel war das System – angekündigter Weise – offline. Nach einigen Anfangsschwierigkeiten in den ersten Tagen ist es jetzt wieder wie gewohnt erreichbar.

Den IT-Umzug hat die Postbank zum Anlass genommen diverse Angebote zu ändern und zu streichen; die hier angegebenen Punkte beziehen sich jedoch nur auf ihr Online-Banking.

Einige sinnvolle Funktionen sind verschwunden. Und bei manchen Sachen fragt man sich, in welchem Jahr wir leben.

Umsatzabfrage



Eine der wichtigsten Funktionen beim Online-Banking ist wohl die Abfrage des Kontostands und der Umsätze. Dies ist auch im neuen System möglich, das war es dann aber auch.

Im „alten System“ bestand die Möglichkeit, diese Umsätze als CSV- oder XML-Datei zur weiteren Verarbeitung herunterzuladen. 

 

 

 

Diese Möglichkeit wurde ersatzlos gestrichen.



 

 

PDF-Kontoauszüge

Wer versucht, diese oder andere Daten aus den „neuen“ PDF-Kontoauszügen mit Markieren-Kopieren-Einfügen zu holen, erlebt sein blaues Wunder. Wenn man z.B. seine IBAN braucht und diese im Kontoauszug markiert – ja das geht – kopiert und dann woanders einfügt,  erhält man einen Buchstabensalat, der nur entfernt mit dem etwas zu tun hat, was das menschliche Auge lesen kann. 

Hier ein Beispiel einer Überweisung, deren Text sich augenscheinlich markieren lässt. Der kopierte Text in der Zwischenablage sieht aber sehr sonderbar aus. So fehlen z.B. alle Zahlen, was bei Kontoauszügen besonders auffällt:

pbmA Überweisung an
Bundesnetzagentur
fBAk abMUTRMMMMMMMMTRMMNMMT
BfC MAohabcNTRM
serwendungszweckL hundenreferenz
hassenzeicÜen VMN4VMMNU4UR J



Diese „neuen“ PDF-Auszüge erkennt man vor allem daran, dass sie oben rechts nicht mehr das gelbe Postbank-Logo der „alten“ PDF-Auszüge haben, bei denen das Herauskopieren im Übrigen einwandfrei funktioniert.

Der Buchstabensalat aus den neuen PDF-Auszügen erinnert an OCR-Ergebnisse aus der Anfangszeit, wobei man sich natürlich fragt, warum man bei computergenerierten PDF-Dateien überhaupt OCR einsetzen muss.

Daueraufträge


Vor der Umstellung gab es eine Möglichkeit, die Ausführung so zu terminieren, dass sie VOR einem eventuellen Sonntag oder Feiertag ausgeführt wurde. Diese Möglichkeit ist entfallen. Alte Daueraufträge mit der entsprechenden Option laufen zwar weiter, d.h. den dafür zuständigen Computercode muss es wohl noch geben.
 

 


 

Brokerage

Unter der Rubrik „Investieren“ werden bei der Umsatzanzeige die Anteile nur mit 2 Nachkommastellen angegeben, und nicht wie allgemein üblich (und auch im alten System implementiert) mit 3 Nachkommastellen.

Zumindest enthalten die – jetzt nicht mehr computerlesbaren – PDF-Abrechnungen diese 3 Nachkommastellen.

Open-Source-Software, um die Auswirkungen dieser „Verbesserungen“ etwas abzumildern

Der meines Wissens einzige Weg, um im Augenblick Umsätze und Salden ohne Umwege computerlesbar von der Postbank zu bekommen, ist die HBCI-Schnittstelle, wie sie z.B. in Finanzsoftware implementiert ist.

Aber auch das freie Programm Jameica/Hibiscus kann über die HBCI-Schnittstelle kommunizieren.

Über diese Software können – neben anderen Funktionen – Kontoabstände und Umsätze abgefragt, verarbeitet, aber auch exportiert und von anderen Programm weiterverarbeitet werden.


Was die PDFs angeht, die nur so tun, als könnte man ihren Inhalt herauskopieren, so kann man hier eine „richtige“ OCR-Software einsetzen.

Im Linux-Umfeld bietet sich gimagereader an. Der Nachteil hier ist, dass gimagereader ein Programm mit einer GUI ist. Es setzt jedoch die OCR-Engine tesseract ein, die man auch separat, z.B. in Skripts, aufrufen kann.

tesseract verarbeitet jedoch keine PDFs, sodass diese zuerst in eine Bilddatei umgewandelt werden müssen, wie beispielsweise im folgenden Python3-Skript:

from pdf2image import convert_from_path
import pytesseract

pil_image_list = convert_from_path("x.pdf")

# pro Seite ein PPM
# print(pil_image_list)

# erste Seite
img = pil_image_list[0]
text = pytesseract.image_to_string(img, lang="deu")
print(text)


Warum dieser nicht immer 100% fehlerfreie Umweg überhaupt notwendig ist, weiß nur die Postbank.

Reaktionen

Auf diese und andere gemeldete Fehler und Bugs reagiert das Unternehmen allerdings mit Baustein-E-Mails, sodass meine Hoffnung nicht besonders hoch ist, dass diese Meldungen tatsächlich gelesen werden und sich jemand darum kümmern wird.


Sonntag, 9. Januar 2022

Docker: temporary error ... try again later

In case you encounter this error message while creating docker images I want to draw your attention to a more unusual reason (DNS), how to fix it, and the somewhat embarrassing root cause in my case.

Have fun.


When setting up a docker installation on an Ubuntu Server 20.04 LTS system the build process for a docker image that had worked fine on my desktop computer failed with this misleading error message:

fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.4/main: temporary error (try again later)


Strangely enough I could wget this file from the command line.

If you google this error the standard advice is to update docker. I did (to version 20.10.12) ... but it didn't help though.

With problems like this it's always good advise to try to replicate it with the most simple setup possible.

In this case:

  • Get a small Linux system image from the repo (alpine)
  • and start a command line inside the container: sh
  • try to install a package (curl) within the container


$ docker run -it alpine:3.4 sh

/ # apk --update add curl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.4/main: temporary error (try again later)
WARNING: Ignoring APKINDEX.167438ca.tar.gz: No such file or directory
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.4/community: temporary error (try again later)
WARNING: Ignoring APKINDEX.a2e6dac0.tar.gz: No such file or directory
ERROR: unsatisfiable constraints:
  curl (missing):
    required by: world[curl]


Docker did download the alpine image but inside the container downloading the APKINDEX failed. And yeah - I did wait and tried again later... no luck.

Back inside the container I tried:

/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=117 time=14.639 ms
64 bytes from 8.8.8.8: seq=1 ttl=117 time=13.921 ms
64 bytes from 8.8.8.8: seq=2 ttl=117 time=13.956 ms
^C

/ # ping google.com
ping: bad address 'google.com'


Which means: I can reach the internet from inside the container but the DNS resolution obviously isn't working. Let's see who is resolving:

/ # cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 129.168.0.1
search local


Who is 129.168.0.1 and how did it became the nameserver? To be honest - it was my fault (more on that later).

Using the only text editor available in a base alpine install I changed it to

/ # vi /etc/resolv.conf
nameserver 8.8.8.8


And yes, when using vi I always have to think very hard how to get the changes written back to disk.

Trying to add the package now works like a charm:

/ # apk --update add curl
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
(1/4) Installing ca-certificates (20161130-r0)
(2/4) Installing libssh2 (1.7.0-r0)
(3/4) Installing libcurl (7.60.0-r1)
(4/4) Installing curl (7.60.0-r1)
Executing busybox-1.24.2-r14.trigger
Executing ca-certificates


So the problem is definitely a faulty DNS name server .... How can this be fixed?

If I start the container with the --dns option ...

docker run --dns 8.8.8.8 -it alpine:3.4 sh

apk add runs without a problem. And if I check /etc/resolv.conf it says 8.8.8.8

Slight problem: --dns works with docker run but not with docker build.

You have to tell docker itself to use a different DNS server.

Googles first advise is modifying /etc/default/docker like this

DOCKER_OPTS="--dns=my-private-dns-server-ip --dns=8.8.8.8"

But Ubuntu 20.04 LTS uses systemd and in this case these settings are ignored.
You have to create an override files for this systemd service using

sudo systemctl edit docker.service

with the following content

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --dns 8.8.8.8 -H fd:// --containerd=/run/containerd/containerd.sock

I first located the original docker.service file, copied the ExecStart line, and added the dns option.
The first empty ExecStart is needed to clear its original value before setting the new one... good to know (thanks - herbert.cc).

Everything worked.


So - who is 129.168.0.1? Well, it's a typo. It should read 192.168.0.1 - my cable modem.

I later found it in /etc/netplan/00-installer-config.yaml which sets up the machine's IP address, gateway, DNS resolver, etc.
I must have made this typo while installing the system onto the hard drive using the Ubuntu installer.

But why did the internet connection work at all? I could download files... the docker image for example.

My specific setup made the system use a fixed IP address (as servers usually need one) but it did NOT disable DHCP.

So eventually the DHCP server updated the faulty DNS resolver setting with the correct value and all worked fine.

It seems that docker samples the DNS nameserver during boot-up at a time after the yml-file had set the wrong value and before the DHCP server could replace it with the correct one.  It then hands this value to the docker build and docker run processes instead of the nameserver currently in use. As those values are usually identical nobody does notice.

I don't know if I would call this a bug but it is unexpected behaviour.

Now you know.


Useful links

  • https://serverfault.com/questions/612075/how-to-configure-custom-dns-server-with-docker
  • https://serverfault.com/questions/1020732/docker-settings-in-ubuntu-20-04
  • https://docs.docker.com/config/daemon/systemd/
  • https://www.herbert.cc/blog/systemctl-docker-settings/


Montag, 7. Juni 2021

Grabbing EPGs from Schedules Direct


TL;DR


You can now find my EPG json grabber client for Schedules Direct on Github.

The utilities download and cache the EPG data in a sqlite database.  They can produce an output in xmltv format for systems like EyeTV, MythTV etc..  They can also create short overviews (e.g. by genre) if you want to check what sci-fi episodes are coming up.

The utilities are written in Python3 and should run on any python3 base installation.

The story


A few weeks ago the EPG function in EyeTV on my old Mac Mini stopped working.

Until then I used the Gracenote service integrated in EyeTV to download EPGs.   As far as I can tell the Gracenote downloader tries to contact its server but fails.  System logs indicate that the OS rejects the connection due to some SSL handshake error.  The machine is to old for the installed Mac OS to be updated … so, no hope to get the SSL issue fixed.

This happened – of course – just weeks after I renewed the Gracenote subscription, and unsurprisingly Geniatech – the seller of the subscription – didn’t react on my bug report or plea for help.

What to do?


EyeTV offers two other sources for EPGs: DVB and xmltv

DVB gets the EPG information from the TV signal itself.  The problem: In order to receive the signal you must switch to that channel for a few minutes.  With over 40 channels this becomes infeasible.  And even then you only get 3 days worth of EPG (compared to 14 days with Gracenote).

The xmltv option takes the information from a text file in xmltv format.  The format is well documented and EyeTV can read an xmltv file using a special command.  But where to get the information from?

Schedules Direct is a provider of EPG information and also offers – unlike many other providers – listings for stations in Europe.   However rather than providing the information in xmltv format you have to query their API and get chunks of information back in JSON format.

The utilities


And that’s where the utilities come in.

  • sdjsongrab.py is the part that talks to the API and caches the information in a sqlite database.
  • You have to run sdconf.py first to configure your name and password and select the lineups (sets of stations) whose schedule you want to download.
  • genepg.py will create the xmltv file from the information stored in the database.
  • maintenance.py will perform some database related operations.


The most difficult part is to select which lineups to use.  A lineup determines the stations whose EPG you can access.  There are hundreds of lineups available from which you can choose up to four.  They mostly contain stations grouped by geographic location, cable provider, etc.  sdconf.py exposes the part of the SD API that helps you select suitable ones.

With the help of filter definition files geneps.py can generate quick overviews of all programs with a given genre and/or name.  This can be used for example to get a quick overview of all sci-fi programs or all programs containing “Star Trek” in their title.

maintenance.py can be used to display various information from the database itself.  Most notably a list of genres that can be used in the filter definition files.

You can find more information in the README and doc files of this project.

Comimg up...

The software is still in development.  Currently I’m observing how the size of the database grows and if and when a pruning is needed.  At the moment it's to early to tell.

I only use the generated xmltv file with EyeTV and can’t check it with other software.  If you have any suggestions let me know.

Dienstag, 26. Januar 2021

Tagesschau - Coronavirus Live-Feed - RSS-Feed

Es war zugegebenermaßen lästig, jeden Morgen auf tagesschau.de den Corona Live-Feed zu suchen, ihn aufzurufen, ganz nach unten zu rollen und den RSS-Link aus dem entsprechenden Icon zu kopieren, um ihn dann in meinen RSS-Reader einzufügen.

Bei der allgemeinen Umgestaltung der Tagesschau-Seiten scheint dieses RSS-Icon jedoch untergegangen zu sein.

Der Feed als solcher ist jedoch noch da und seine URL folgt dem nachstehenden Muster:

URL der Seite:

https://www.tagesschau.de/newsticker/liveblog-coronavirus-dienstag-175.html

URL des RSS-Feeds:

https://www.tagesschau.de/newsticker/liveblog-coronavirus-dienstag-175~rss2feed.xml

Wochentag und Zahl ändern sich täglich.


Update: 30. Januar 2021

Das Format der URL hat sich leicht geändert. Aus "coronavirus" wurde nur "corona".

https://www.tagesschau.de/newsticker/liveblog-corona-samstag-109.html

Grund dürfte sein, dass die gleiche URL mit "coronavirus" bereits im Mai verwendet wurde.Am Prinzip hat sich aber nichts geändert.

Donnerstag, 13. August 2020

Retro Music Player app and playlists

Until now I've used the Google Play Music app. One reason was that I could store songs I regularly hear locally on my device and didn't need to stream them over and over again via the mobile data connection.


As Google Play Music is being discontinued and I have transferred my collection to its successor - the Youtube Music App - only to find that I have to pay 9,99 € a month for the privilege to have the music I already bought played back locally without streaming.

I've managed - with some difficulty - to download my collection and my playlists from Google Music and I'm now trying to find an app which can play my music (most do) and can import my playlists (here lies the problem).

The Retro Music Player app is an open-source music player for Android which claims to be able to import and export playlists. But this is only partially true.

The export works perfectly as it is implemented in the app. The import is (currently) performed by the operating system and its implementation ranges from "works perfectly" to "doesn't work at all" as many bug reports on GitHub can attest to.

Until RMP decides to implement the playlist import in the app itself the functionality of this feature is left to chance.