Beiträge von Technikus

16.10.2018 | Nutzung von eAudio in der Onleihe-App und im Web-Browser
Neuigkeiten zu diesem Thema findet ihr HIER.

12.10.2018 | Das Ausrollen der beta-Version verschiebt sich.
Eine ausführlichen Kommentar gibt es HIER.

16.10.2018 | Aktuelle Schwierigkeiten bei der Nutzung von eBooks
Mehr Informationen sind HIER zu finden.

    Dann ist das Konzept aber irgendwie doof.


    Warum will man Hörbücher herunterladen anstatt sie zu streamen? Einerseits sicher, um die billigste Datentransfermöglichkeit zu nutzen und da fällt die bloße Autorisierung kaum noch ins Gewicht. Andererseits aber doch, um danach gar nicht mehr auf Datentransfer angewiesen zu sein, zum Beispiel im Flieger, auf See, im Zug, im Auto, im Ausland, im Gebirge, im Wald und auf der Heide... Stattdessen steht man in der Wüste.


    Was mögen sich die Programmierer dabei (nicht) gedacht haben? Sind mehrteilige Hörbücher so neu, dass man noch keine "Durchautorisierung" nach Download nachreichen konnte? Oder war das schon immer so kritisch bzw. im Ablauf unzuverlässig, dass man das nicht riskieren wollte?

    Ich versuchte damit zu erklären, dass und warum ich nicht mehr glaube, dass es sich spezifisch um Probleme beim Streamen und/oder beim Download bzw. bei Apple und/oder Android handelt, sondern um tiefere, die sich nur statistisch mehr bei Apple als bei Android bzw. mehr beim Download als beim Streamen auswirken.


    Dann nützt weder ein neues Phone noch ein Reinstallieren der Apps. Die anderen Probleme erscheinen mir als Nachlässigkeiten beim Programmieren, aber sie träten wahrscheinlich nicht oder nur selten auf, wenn der Hintergrund (die Onleihe) funktionierte.


    Früher waren sichere Wiederanlaufverfahren das A & O der Programmierung jeder Fernverarbeitung. Heute, bei den ach so schnellen Verbindungen, spart man sich den Aufwand lieber und setzt auf den User und den von ihm initiierten Neustart. ("Versuchen sie es später noch einmal!")

    Ich fürchte, dass es gewissermaßen eigentlich gleich ist, ob man herunterlädt oder streamed. Dass nur der tatsächliche (womöglich konzeptionelle?) Fehler beim Herunterladen sozusagen sicherer bzw. mit höherer Wahrscheinlichkeit auftritt (mit der Trackzahl als Multiplikator) und dann auch mehr nervt. Weil im Gegensatz zum Streamen die Wahrscheinlichkeit seines (Wieder-) Auftretens je Vorgang ja nicht geringer wird, sondern gleich bleibt.


    Gemeint ist die Wahrscheinlichkeit des Auftretens "für einen bestimmten Track" versus "für irgendeinen von allen Tracks": Ist die Fehlerwahrscheinlichkeit auch nur 1 zu 100, so wird es einen beim Streamen vieler Multitrack-Hörbücher mal irgendwo treffen, ggf. auch mehrfach. Beim Download von Hörbüchern mit über 99 Tracks aber geradezu sicher bei jedem Versuch... (und ansonsten um so öfter, je mehr Tracks)


    Dann wäre die Aussage (oder der Schluss), dass Hörbücher mit wenigen Tracks funktionieren und dass das Streamen funktioniert, so etwas wie das Gewinnversprechen bei einer Lotterie. (So wird es manchem eh schon erscheinen...)

    Okay, also iThing-spezifisch. Klar, da kann das DRM anders funktionieren müssen. Ansonsten ist das dann so ein typischer Fall von "Denkste!" Der Denke von Programmieren, dass sich alle so verhalten wie sie und das gewisse Abläufe und Nutzungsweisen, die ihnen logisch erscheinen, auch allen anderen logisch erscheinen müssen und womöglich noch einzig diese...


    Ich stell bei meinem Phone auch immer alles ab, was ich nicht brauche - um die Datensammelwut zu begrenzen und die Laufdauer zu erhöhen. Dauert dann halt mal ein bisschen, bis es sich ortet. Aber zu 99,99% brauche ich keine Ortung und keine mobilen Daten, nicht mal WLAN auf dem Ding.


    Jetzt "quält" mich noch die Neugierde, wie es ist, wenn man (ggf. alle) Tracks bereits angespielt hat: Hält die Autorisierung dann bis zum Ende der Leihdauer oder nicht? (Ich weiß, das "alle" ist nicht sonderlich praktikabel, aber es könnte ja jemand mal mit bereits gehörten Tracks probieren...)


    Ich bin immer am besten gefahren, wenn ich es geschafft habe, mich in die Denke von Microzoff zu versetzen. Aber ein Kunde (selbständiger Ingenieur) meinte mal, seine Kollegen sollten gefälligst ihre Arbeit machen - er könne auch keine Konstruktion verkaufen, von der der Benutzer im Detail wisse müsse, wie sie funktioniert und warum sie so und nicht anders konstruiert sei, um sie nutzen zu können. Und tatsächlich, die Zeiten, wo Nähmaschinen rot markierte Ölbohrungen haben, die in verschiedenen Zeitabständen der Aufmerksamkeit der Näherin bedürfen, sind seit den Sechzigern des letzten Jahrhunderts vorbei. Nur bei (Micro-) Software und vielen Gadgets mit eingebauter "Intelligenz" offenbar noch nicht...




    Derzeit kann ich ca. 89% der ausgeliehenen Hörbücher nicht laden. Es liegt wohl an dem bekannten Problem der vielen Einzeltracks. Meine Ausleihe füllt sich also mit Hörbüchern, die ich nicht nutzen kann.

    Frage: Kann man diese Produkte irgendwie markieren, damit ich schon vor der Ausleihe Bescheid weiß?


    Weiterhin muss ich auch ein geladenes Hörbuch immer erstmal morgens im heimischen wlan starten. Ansonsten wird mir ein drm Fehler gegeben. War auch toll im Urlaub als ich kein einziges Hörbuch nutzen konnte.

    Frage: Woran liegt das?

    Hab ich das richtig verstanden: Das Abhören eines heruntergeladenen Hörbuches muss im WLAN ein Mal gestartet werden (vermutlich Lizenzprüfung), sonst läuft es trotz Herunterladens nicht offline? Oder startet es auch Mobilfunk-Online nicht? Zumindest wäre es etwas dämlich, wenn die Lizenzbestätigung nicht direkt nach dem Download erfolgte - aber vielleicht klappt eine zeitliche Beschränkung beim verwendeten DRM auch nur per täglich mindestens einmaliger Abfrage? Behauptet ja keiner, dass ein DRM nutzungsfreundlich sein muss... Fällt vielleicht "normal" nicht auf, weil Otto Normaluser seinen Mobilfunk automatisch an hat, wenn er den Bereich bekannter WLANs verlässt?


    Über das erste hab ich auch nochmal nachgedacht:


    Irgendwie ist es "modern", Dinge sprachlich zu verschleiern. Ich tippe mal auf die unselige Tendenz unseres Gehirnapparates, einfache Erklärungen zu suchen, aber komplexe Lösungen... Das verstellt dann häufig den Blick aufs Wesentliche. Was wäre, wenn es gar kein Problem mit vielen Einzeltracks gäbe, es nur so erschiene? Das Problem realiter das eines jeden einzelnen Tracks wäre?


    Immerhin wird für jeden Track ein Verzeichnis angelegt und mit drei Dateien befüllt: Eine vermutlich verschlüsselte Mediendatei (hab gerade keine und es geht ja derzeit schlicht gar nichts in der App) und zwei, die sicher dem DRM dienen. Manchmal klappt offenbar schon das Anlegen der Verzeichnisse nicht, manchmal steht das Herunterladen, als ob auf dem Server die Dateien noch nicht bereitstünden oder er gerade alle "Kanäle" voll hätte. Wie oft wird das wohl statistisch auffallen, wenn nur ein paar, im besten Fall nur ein Verzeichnis zu verarbeiten ist? Und das noch unter der Maßgabe, dass die Fehler oder Verzögerungen jeweils am Anfang des einzelnen Downloads auftreten!


    Ich mutmaße mal frech und aus eigener IT-Erfahrung: Das ist originär ein (konzeptionelles) Problem der einzelnen Track-Verarbeitung (Vorbereitung, Bereitstellung usw.) und sieht nur aus wie eines von vielen Tracks bzw. wurde und wird erst dadurch so richtig evident, dass ein Hörbuch plötzlich zu praktisch hunderten von Hörbüchern wurde, ein User abbekam, was sonst auf hunderte verteilt gewesen wäre - aber mit viel durchschlagenderer Wirkung: Während sonst ein paar Prozent beim ersten und evtl. ein paar weiteren Versuchen sehr schnell in die Röhre guckten, trifft hier ein "Prozentversagen" (evtl. erst nach etlichen Minuten) einen User zu 100% = Totalversagen - und das ja dann höchstwahrscheinlich vielfach wieder, während es sonst immer mal einen anderen gebeutelt hätte (und auch eher nur beim ersten Versuch).

    Ich sehe zwei normale Möglichkeiten. Tipp mal in die Mitte der Buchseite und dann oben links auf den Stern im Kreismenü. Dann spiele ein wenig mit dem erscheinenden Regler oder setze einfach den Haken in "Sytem".

    Wenn's das nicht ist, den Rückpfeil in der Mitte betätigen und im Kreismenü den Stern mit dem Mond wählen. Hier sollte für normalen Tagbetrieb das untere, hellste Feld angeknipst sein.

    Der PBR merkt sich ein paar Einstellungen buchbezogen, vielleicht auch das (Nachtmodus für Gruselgeschichten? ;-) ) Nee, gerade probiert, er hat keinen Gruselbuchmodus.

    Der alte shine ist vielleicht nicht der sicherste Vergleich. Er basiert noch nicht auf Readium und das könnte ja durchaus gewisse Schwächen haben.


    Wenn man dem OpenSource-Verzeichnis von Tolino glauben kann (es ist nach der Reparatur des schiefgegangenen Updates etwas eigenartig), haben nur epos, vision4 HD und page Readium implementiert (seit 1.9.x - aber haben die Vorläufer nicht auch längst einen Softwarestand sogar größer als 1.9.x? Beim shine gab es Readium lt. Verzeichnis nie. Plausibel: zu wenig Arbeitsspeicher, zu altes Android) Über den shine3 gibt es noch keine entsprechende Verlautbarung, aber da darf man es wohl annehmen.


    Vielleicht kann noch ein Nutzer eines Gerätes, das lt. Tolino auf Readium basiert, etwas zu großen eBooks und der Suche mitteilen?

    Format definitiv ePub und nicht PDF? (Nur zur absoluten Sicherheit.)


    Dann würde ich das unter Angabe des Titels an Tolino melden. Bei PDF wäre ich sogar skeptisch, was mein Tablet daraus machte, je nach App. eReader haben eben vergleichsweise die schwächsten CPUs und GPUs. Hast Du es mal auf Deinem Smartphone probiert? Da aber neben "Onleihe intern" auch mit einer externen Reader-App (Bluefire, Aldiko, PocketBook, Tolino) nach dem Ausleihen per App oder Browser. Wobei ich PocketBook für die derzeit potenteste halte, aber das kann ja vom Buch abhängen.


    Bei Fach- und Sachbüchern ist immer auch interessant, ob es darin viele Bilder, Grafiken und Tabellen gibt, die man womöglich vergrößern und in Ausschnitten betrachten muss. Der Shine 3 soll ja eine andere Touch-Technologie haben als mein alter - aber ist die (inklusive Gesamtleistung) für Gesten tatsächlich responsiv genug?


    Da ich auch auf Netzrecherchen und spontane Fotos angewiesen bin und auf gescannte Dokumente ohne OCR und eh besser damit zurechtkomme, schleppe ich nur noch mein Tablet mit mir herum, maximal noch eine Powerbank dazu. Damit komme ich locker über 24h Dauerbetrieb, muss halt nur Sonne und Himmel meiden - aber meistens arbeitet man ja drinnen...


    Noch ein P.S. zu Grafiken: Überkomplexe Vektorgrafiken und überaufgelöste Pixelgrafiken erschweren meiner Erfahrung nach auch beim Tablet das Blättern, zumindest bei PDFs, wenn sich da schon mal etwas aus der Druckvorstufe "hineingerettet" hat. Beim Rendern zum Druck fällt das ja nicht so extrem auf, da ist evtl. die der Zielauflösung gerechte Bearbeitung langwieriger und teurer, als das Herunterrechnen beim Rendern.

    Ich hab jetzt um 23:15, wo alle braven Onleihe-User schon längst schlummern sollten, nochmal den Download probiert.


    Das erste Mal stürzte die (alte) App mit Ansage ab, also mit der Frage, ob sie beendet oder neu gestartet werden soll. Ergebnis: 175 Verzeichnisse (leer).

    Nach Neustart erwischt es sie ohne Ansage bei 186 leeren Verzeichnissen.

    Im dritten Anlauf schafft sie die 219 Verzeichnisse und nach etwas Verzögerung 3,xx MB, dann geht es aber sehr zügig durch bis zum Schluss.


    Alles vom Gerät gelöscht und neu: Kein Absturz, aber nach zügigem Anlegen aller Verzeichnisse ca. 2 Minuten nichts. Dann aber in etwas über 4 Minuten der komplette Datendownload. Selbst wenn ich die Pause mit berücksichtige: geradezu extremes Tempo!


    Dritte Runde: Nach 25 Sekunden sind alle Verzeichnisse da, nach weiteren 1,5 Minuten startet der Download, dauert aber diesmal knapp über 5 Minuten.


    Ich würde wirklich gerne wissen, was da so alles abläuft...


    Vierte Runde: BETA-App, nach 15 Sekunden sind die Verzeichnisse da, anderthalb Minuten später beginnt der Download. Erst schaut es wieder nach dem obigen Rekord aus, dann wird es langsamer, nach etwa 5 Minuten mit 591Dateien mit 567MB hängt es dann ganz und nach insgesamt 18 Minuten breche ich ab... Keinen Bock mehr, auf 617 zu warten oder auf Godot - gute Nacht!


    Übrigens lief (nur) bei der BETA wieder die Android Download Anzeige mit. Eine weitere Meldung, dass die Onleihe (TEST) läuft, flackerte dabei vor sich hin, als ob sie nach jedem beendeten Download (Datei oder Verzeichnis?) ein Mal kurz verschwände. Ich hielte es für speditiver, jedesmal nur eine einzige Datei herunterzuladen und die zum Schluss automatisch in die nötigen Verzeichnisse zu entpacken.

    _____________


    Nachtrag:


    Da ich das Hörbuch eh zwei Tage leihen musste, hab ich gestern abend ca. ab 21:00 Uhr noch mehrfach probiert, es downzuloaden. (Ich rechnete wegen des guten Wetters mit geringer Auslastung.) Mit der Beta-App ist mir das nie gelungen, da blieb es immer irgendwo ab 540 MB stehen, obwohl der Anfang vielversprechend war. Dagegen ist es mir mit der alten App gestern jedes Mal gelungen. Selbst, als sich das Tablet mal kurz in den Schlummer verabschiedet hatte, lief es beim sofortigen Aufwecken noch weiter. Das Anlegen der Verzeichnisse dauerte ca. 15", der Download startete meist noch in der ersten Minute, brauchte allerdings danach zwischen sechs und acht Minuten.


    Mag ja sein, dass es auf bestimmten Androids die App ist, die da quer schießt, aber bei mir muss es ja wohl eindeutig der Server-Hintergrund sein. Oder kann man eine App etwa "einfahren"? Und da die inoffiziella BETA ja sicher zumindest ein Beta-Kandidat war und kein zu vernichtendes Mangelexemplar und den Download auch nicht nur scheinbar begann, sondern bis zu etwa 3/4 durchzog, frage ich mich natürlich, wo das noch hinführt...


    Gibt es bei der Divibib bei den Tests nur ideale Laborbedingungen? Kein reales Internet? Keinen Test mit den Produktivsystemen zu "Produktionszeiten"? Keine Simulationen realistisch schlechter Bedingungen? Ich bin sicher, lange Antwortzeiten, Fehler und Abstürze vervielfachen sich quasi noch aufgrund ungeduldiger und genervter User. Ob man dann mal "durchkommt", ist bestimmt reiner Zufall - aber eben auch eine typische Erfahrung. Und so wird es mancher halt zehn Mal hintereinander probieren und sich damit das Problem insgesamt massiv verschärfen.


    Man sollte über einen Push-Download nachdenken. Ich beauftrage ihn und überlasse es dann der Onleihe, wann sie die Daten koordiniert und en bloc schiebt, anstatt irgendwann nur noch (unnötige!) Reibungsverluste zu produzieren. Außerdem wage ich zu bezweifeln, dass "Stellschrauben" noch reichen. Das technische Konzept oder seine Grundlagen müssen wohl auf den Prüfstand - bevor es ein anderer ad absurdum führt, was Emma Herwegh ja schon dauernd an die Wand malt...

    Um als User etwas genauer herauszufinden, was die Divibib eh wissen wird, müsste man einen Netzwerk-Trace aufsetzen, der die Kommunikation zwischen dem Endgerät und den Servern aufzeichnet und analysiert und das am besten zu verschiedenen Tageszeiten. Aber wozu? Das hilft ja keinem, dann weiß man nur, wie es hängt, aber nicht wo und warum. Das weiß nur die Divibib und die braucht dazu wohl auch keinen Trace.


    Aber je länger das nun schon geht, desto mehr habe ich das Gefühl, dass an vielen Stellen die historisch hinter der Onleihe steckende Logik vielleicht sehr logisch ist, aber durch Engpässe muss bzw. besonders unter Last selbst welche erzeugt, die sich rein aus ihr gar nicht erschließen, sondern erst aus "unlogischen" Betrachtungen, aus der typischen Diskrepanz zwischen Idealfall und schmutziger Realität.


    Anders gesagt: Ich stelle mir vor, die Onleihe ist nicht besonders realitätsfest, zu theoretisch-ideal. Sonst müsste man doch schneller an den richtigen Schrauben drehen können, oder? Die IT-Fuzzies sprechen auch immer gerne von guter Skalierbarkeit. Und die ist ja nicht nur unter der ansteigenden Nutzerzahl zu betrachten, sondern sicher auch (anders, aber doch gleich bremsend wirkend) unter der wachsenden Zahl der Medien.


    Ich hoffte, mit CARE und TEA würde auch das technische Gesamtkonzept neu gedacht. Aber da sind wohl zu viele Dinge unter einen Hut zu bringen. Und dazu kommen ja noch ganz andere Aspekte: https://netzpolitik.org/2018/d…nicht-im-netz-angekommen/

    Irgendwie kann ich mir auch kaum vorstellen, dass die Divibib es schafft, alle Medien gleichzeitig umzustellen und mit zwei DRMs anzubieten - die Papers sah ich da als Letztes, da der Aufwand ja ein täglicher wäre. Die Umstellung ist gefühlt sicher um ein Vielfaches komplexer, als die bisherige Onleihe und klar, ohne Serverumstellung (bzw. -erweiterung) funktioniert da noch nichts, wenn es nicht parallel mit der AID geht.


    Lassen wir uns überraschen...

    Das oben war wohl ein viel weiter reichendes Déjà-vu... Oder etwa Voodoo? Sorry... ;-)

    (Aktueller Stand Entwicklung der Onleihe-App Version 5.3 und neues DRM in der App)


    *duck und weg*

    Ist aber auch bei den Verlagen die Frage, wie sie darauf kommen. Für 11h CDA ist das zu wenig. Werden eventuell "höherwertige" MP3-Dateien von der Divibib "heruntergerechnet" (also umcodiert), um überhaupt zu passablen Downloadzeiten und Streamingvolumina zu kommen? Dann könnte sie aber auch das Ergebnis angeben, anstatt den Umfang des Ausgangsmaterials.


    Das mit den Servern darf man sich übrigens nicht so einfach vorstellen. Das ist ebensowenig monolithisch wie die Apps. Irgendwann ist plötzlich ein Zustand erreicht, wo Auslastung gegen Performance nicht mal mehr annähernd linear skalieren, sondern unglücklich produzierte Abhängigkeiten (vielleicht sogar total fernliegende, unlogisch erscheinende) das explodieren lassen. Deshalb testen ja große Websitebetreiber ihre Sites mit ganzen Farmen von virtuellen PCs, wobei sie die Tests scripten und fernsteuern (z. B. per Selenium), weil man nur so zu reellen Aussagen kommt, solange man sich beim Einschätzen der Nutzerzahl nicht massiv verhaut - aber dafür gibt es ja Logs. Bei diesen Tests machen dann tatsächlich hunderte von PCs jeweils praktisch zeitgleich das Selbe und wieder hunderte etwas anderes Selbes usw. usf. Dann kann man auch quasi zuschauen, wann und wo es hakt und muss weniger spekulieren, wo es haken könnte... Aber erwischen kann es einen völlig kalt.


    Damals bei den unbekannten oder unerwarteten Fehlern beim Stöbern konnte man zeitweise wenigstens noch sehen, dass offenbar der Prozess, der die App "bediente", sich die Coverbilder mühevoll zusammenkratzen musste, zumal die noch von verschiedenen Servern kamen (ich hab mal einzelne geblockt) die teilweise aber auch einen Lastausgleich schafften (zumindest ersetzte einer den anderen). Wenn man diesen aber so richtig geschickt fabriziert (zum Bleistift auch in der App selber), dann geht die Zahl der Serveranfragen hoch, weil immer mehr erfolglose zu immer mehr Wiederholungen führen. Und oben drauf kommt noch die Zeit für die Timeouts. Quasi wie beim Reißverschluss auf der Autobahn: Koordiniert wäre es kaum langsamer, auf jeden Fall gleichmäßig, aber unkoordiniert bricht es immer wieder und immer öfter zusammen. (Und die ungeduldigen User handeln ja eh unkoordiniert.)


    Man muss aber den Grund finden und eine Möglichkeit zur Koordination - oder den Verkehr vermeiden/beschränken. Weil "die Automobilisten" zu viele Blöde und Är...e umfassen, haben die Schweizer Spurampeln vorm Gotthardtunnel aufgestellt. Das ist immerhin effektiver als eine deutsche Autobahnverengung... Aber weit genug vor und hinter einer Baustelle sieht man nicht, dass die Autobahn überlastet ist. Genauso können Server CPUmäßig und Datenzugriffsmäßig geradezu vor sich hindümpeln und trotzdem geht nichts. Solche Effekte kann man mitunter sogar im eigenen PC bemerken: Da ist nix auf 100% und trotzdem steht das Ding offenbar. Typische Fehldiagnose: abgestürzt.


    Kreisverkehre sind auch so ein Beispiel: Prima automatischer Lastausgleich zwischen den Zufahrten. Aber ab einer gewissen Verkehrsdichte nur noch Chaos. Deshalb haben die Kölner Ampeln in gewissen Kreisverkehren (wie pervers ist das denn?) und wir leiten den Verkehr aus einer Richtung erst einmal per täuschender Beschilderung halb um die Stadt herum - wegen eines Kreisverkehrs am IC-Bahnhof... (Ob sich das bis in die Navis herumgesprochen hat?)

    Das hat mich neugierig gemacht und deshalb hab ich mir gestern den "Todesreigen" reserviert, der heute schon frei wurde. Heute morgen konnte ich ihn streamen, aber nicht downloaden - dabei passierte fast nichts. Es waren hinterher nur etliche Verzeichnisse im Dateisystem, aber von den 219 (entspr. den Tracks) fehlten viele.


    Heute abend hab ich es dann mit der inoffiziellen BETA versucht nach dem Motto: "Was könnte man denn vielleicht noch vorab testen?" Immerhin, der Download startete, alle Verzeichnisse waren da, aber bei etwa zwei Dritteln der Fortschrittsanzeige passierte wieder nichts mehr. Die Größe im Dateisystem blieb bei etwa 380 MB. Nach 20 Minuten habe ich abgebrochen und neu versucht. Erst hing die App, dann 617te sie ein paar Mal, auch beim Versuch zu streamen. Dann hab ich es nochmal mit der "alten" versucht, ebenso 617. Doch bei irgendeinem Anlauf streamte sie plötzlich wieder und direkt danach war sogar der Download wirklich gestartet, als ich nach dessen Aufruf gerade kontrollierte, dass alle Verzeichnisse angelegt worden waren. Das Tempo war auch deutlich höher und hielt bis zum Ende durch. Trotzdem finde ich ca. 10 Minuten für die dann vorhandenen 632MB in 219 Ordnern für 219 Tracks mit 657 Dateien nicht dolle, aber immerhin... (ca. 10Mbit/s an einem 50er Anschluss, der praktisch fast immer zwischen 40 und 47 pendelt).


    Ehrlich: Mir stellt sich das mal wieder als Serverproblem dar. M. E. "rechnet" die App nicht mit zeitweise lahmen, manchmal fast stehenden Servern. Das Ganze wäre dann vom Zufall und von der Tageszeit abhängig, ähnlich wie damals die unerwarteten Fehler in der App. beim Stöbern oder bei "Meine Medien". Der einzige, mir aufgefallende Unterschied zwischen alter und pre-BETA App war übrigens, dass bei zweiter die Downloadanzeige von Android mitlief. War aber vielleicht Zufall.


    Auf jeden Fall kann die App wohl tracklastige Hörbücher streamen und herunterladen, aber sie wird offenbar von den Servern veräppelt..


    P.S.: Wieso in den Detailinfos zum genanntem Hörbuch eine Größe von 1,6GB angegeben wird, verstehe ich auch nicht.