Beiträge von Technikus

Ich habe gerade mal alles versucht, um die Anmeldung abzuschießen: App wieder und wieder über den "Beenden erzwingen"-Button gestoppt, die Beta wieder mit angemeldet, beide den Standby-Apps zugeordnet, die nicht im Hintergrund laufen (die reguläre war da eh schon), Tablet neu gestartet...

"Half" alles nichts, die Anmeldung an der Onleihe blieb in beiden erhalten. Ich verfolge das mal spaßeshalber weiter. Aber im Moment sieht es für mich so aus, als wäre das nicht von den Apps oder von Android abhängig, sondern vom Onleihe- oder Bib-Server. Wie sonst könnte die Divibib auch "im Vorübergehen" etwas daran ändern? (Natürlich kann man jedes mit Servern verbundene Programm aus der Ferne quasi-statisch oder dynamisch parametrisieren - hab ich selbst Jahrzehnte lang so gemacht. Aber was das Aufrechterhalten einer Session/Anmeldung angeht wäre das unnötig kompliziert.)

Ich hatte das Häufig-Anmelde-Problem vor einigen Tagen plötzlich, als ich aber gleichzeitig mit der Pre-Beta rumgespielt habe. Weil die auch noch auffällig verkündet, dass sie im Hintergrund läuft, hab ich dem keine Bedeutung beigemessen. Ich müsste nochmal probieren, ob das unmittelbar voneinander abhing, meine aber, ich hätte sogar beide Versionen parallel angemeldet gehabt. Meist hab ich die Beta irgendwann hart beendet.

Wahrscheinlich wäre es (meinerseits) stattdessen sinnvoller, mal danach zu schauen, ob mehrere Geräte den selben Account nutzen (können) und (andererseits) welche Android-Version (resp. iOS) welcher Firma jeweils darauf läuft und die Divibib könnte sich mal äußern, ob das nicht auch an der Bibliothekssoftware liegen kann. Was, wenn die Bib wegen irgendwelcher Probleme ihr System öfters neu hochfährt? Sollte man die anmeldende Bib auch angeben? Nicht jede in einem Verbund muss ja die selbe Software einsetzen. Unsere hat offenbar Software aus der selben "Familie", sprich EKZ und macht vielleicht deswegen keine Probleme?

Im Falle, dass es noch weiter auftritt, würde ich also die Zeit, die Bibliothek, die zugehörige Onleihe, das Gerät und die Betriebssystem-Version angeben.

Ich bin übrigens gerade in einem Arbeitsplatznetz und habe nach einem ersten Test auch noch auf VPN ins Heimnetz umgeschaltet und jetzt gerade von da auf Mobilfunk und war und bin nach jedem Wechsel immer noch in der App angemeldet. (Galaxy Tab, siehe Sig)

Ergänzung: Aber vielleicht sagt das auch nichts, weil so flott gar nicht überprüft wird, ob ich noch derselbe bin, die Bib-SW erst nach Stunden nochmal "nachschaut"?

Zitat von Sonnenblumenfeld

Mein Lesegerät bleibt so allerdings unsichtbar für divibib.

Das macht nichts, da Du ja mit ADE erst einmal ACSM-Dateien herunterlädst, die dann zum Herunterladen einer EPUB-Datei mit Adobe-DRM führen. Das DRM ist also für die Divibib ganz eindeutig "das Alte". Wir haben es noch nicht gesehen, aber vermutlich kommen Medien mit neuem DRM zudem von einem anderen Server. Dann bietet schon der Vergleich der Serverstatistiken eine Aussage über das Nutzungsverhältnis beider DRM-Systeme. Fraglich erscheint mir höchstens, ob die Divibib oder (einzig?) Adobe die Anzahl der aktiven Reader an einem ADE erkennen kann. Prinzipiell müsste das möglich sein inklusive der Verteilung der geliehenen Bücher auf den Geräten, also quasi deren separate Nutzungsstatisriken

Vermutlich ist die Nachbearbeitung von Kunden-/Agenturinput in der Druckvorstufe mittlerweile teurer (und gewissermaßen risiko-/ verantwortungsbehaftet), als die zusätzliche Zeit, die ein Raster Image Processor (RIP) mit der Aufbereitung ausgeuferter Datenmengen für den Druck, die Film-Belichtung oder die Druckplattenherstellung verbringt (inkludiert: die Maschinenzeit).

Das Optimieren einer zweiten Druckvorlage für ein reines Onleihe-Format liegt da noch ferner. Man könnte höchstens die Werbewirtschaft sensibilisieren, die ja für die zusätzliche Reichweite per Verleih sicherlich bezahlt und Negativeffekte auf das Image ihrer Kunden vermeiden möchte...

Apfel oder Birne (Android)?

So, noch ein ergänzender Test mit Android 4.4.2:

Da läuft immer die Download-Anzeige von Android mit, schon beim Anlegen der Verzeichnisse. Das ging heute Morgen sehr schnell, der Start des Downloads dauerte zwischen etwa einer und ein Mal mehreren Minuten. Er lief selbst dann aber zügig durch. Streamen mit wilden Sprüngen war auch kein Problem. Auch das Stöbern in der Onleihe klappt wieder anständig, inklusive eigene Medienanzeige und Covern (gegenüber gestern Abend). Wäre mal interessant, wie sich apploide iThings zu solchen Zeiten mit Hörbüchern um die 200 Tracks verhalten... (hier: "Todesreigen")

Ich weiß nicht, ob man sich so 100% sicher sein kann, dass sich Hörbücher verschiedener Verlage (und wie) unterschiedlich verhalten, von der Anzahl der Tracks mal abgesehen. Dazu sind unsere Stichproben doch wahrscheinlich zu wenig signifikant und vor allem die Onleihe in ihrem Verhalten zu instabil, zu sporadisch. Da können viele sicher geglaubte Ergebnisse eher Zufall sein. Solche Aussagen kann man treffen, wenn man auf einem Testsystem hunderte oder tausende von divers synchronisierten, definierten Zugriffen stattfinden lässt. Zu dem Thema gibt es eine regelrechte Industrie und Communities um die entsprechenden Testsysteme und deren Programmierung.

Bezüglich Einzelfällen kann man hier höchstens dann etwas mehr sagen, wenn man die inneren Unterschiede zwischen den Medien herausarbeiten kann oder die Unterschiede ihrer Behandlung im System kennt und dessen Dynamiken. Das bleibt uns aber unzugänglich.

Auf komischerweise genau passende Zufallseffekte bin ich bei Windoof schon oft hereingefallen. Manche Fehler hängen in ihrem Auftreten schlicht davon ab, wie das System startet (und das tut es eben nicht immer gleich) oder welche Programme der Nutzer in welcher Reihenfolge startet und wie nutzt. Bei Linux gibt es unter anderem aus dem erstem Grund eine Spaltung in SysVinit und systemd Verfechter.

(Nur mal so als Anregung, über die "Verselbständigung" so mancher Systeme in Richtung Chaos nachzudenken. Deshalb zweifele ich ja auch noch am autonomen Fahren. Auch das wird ein Mengenproblem werden, denn da ist es nicht mit der Schwarmintelligenz von Vogel- oder Fischschwärmen getan. Die basieren auf simplen Mechanismen und sehen nur so wunderbar nach höherer Intelligenz aus... Und sie schützen nicht das einzelne Individuum - nein, sie opfern es!)

P.S.:

Über die Unterschiede zwischen Download und Streaming hab ich hier ja schon mal nachgedacht. Dabei hab ich allerdings die Vorgänge auf dem Server noch außer Acht gelassen. Gibt es beim Streamen überhaupt ein individuelles DRM? Muss der Server die Daten nicht nur für jedes gerade angefragte Hörbuch, sondern auch für jeden gerade hörenden Nutzer (wie m. E. für jeden gerade downloadenden) komplett (und möglicherweise ebenso individuell) vorhalten oder stellt er sie nur jeweils "vorhersagend" zur Verfügung (dann wären aber wilde Sprünge eher lahm, was ich bei meinem letzten Versuch nicht bestätigen konnte im Gegensatz zu anderen Usern...)?

Hab es (Flugmodus) gerade auch probiert mit Android 7. Aber anhand der Aussagen anderer war es ja eigentlich schon klar, wenn man davon ausgeht, dass nicht jedes Android bei jedem Hersteller da eventuell seine/dessen eigene Geige spielt.

Die Download-Probleme halte ich aber aus erklärten Gründen nicht für OS-spezifisch, die iOS-App aus irgendwelchen Gründen bloß für empfindlicher. Wobei ich 617 für einen Fehler halte, der grob aussagt, dass die Anzahl der Tracks nicht festgestellt/übermittelt werden konnte. Hatte ich gerade wieder und da war noch kein Verzeichnis angelegt. Tritt das Problem währenddessen auf, stürzt die App ab (nicht alle Verzeichnisse angelegt). Gibt es erst einmal die Verzeichnisse, kann offenbar nur noch der Download im Zweifel halbe Ewigkeiten dauern. Bei mir waren es jetzt über 10 Minuten, nachdem er etwa 1,5 Minuten nach Anlegen der Verzeichnisse gestartet war. War schon mal meine schlechteste Zeit. Aber für mehr als 20 Minuten bin ich auch zu ungeduldig.

Nach dem o. g. Test und folgendem Löschen des Hörbuches und dann dem Online-Hörstart trat 617 nochmals auf und der Player zeigte keine Tracks. Beim zweiten Anlauf bekam er sie und dann konnte ich ein paar Mal ohne Probleme wild springen. Die Track-Anlaufverzögerungen waren kürzer als bei manchem CD-Player. Aber auch da könnte die iOS-App empfindlicher sein oder ich hab zufällig eine gute Zeit erwischt.

Zitat von EmmaHerwegh

Anscheinend zicken jetzt aber die Android teilweise auch bei vielen Tracks. Das würde eher auf ein nicht apple-spezifisches Problem hinweisen...

Das hatte ich ja hier und im Folgenden zu durchdenken versucht. Aber das Autorisieren einzelner Tracks beim Hören ist nach den Aussagen hier eindeutig ein Apple-Effekt. Ich selbst hab noch nicht probiert, ob der Flugmodus bei meinen unterschiedlichen Androiden das Abhören verhindert.

Wie so gerne in der IT kommen hier mehrere Probleme und mehrere Ursachen zusammen. Übrigens lahmte eben auch die Onleihe wieder mit ihren Coverbildern, die sie von mehreren Servern zusammenkratzt - zumindest noch beim letzten Mal.

Zu 1. fürchte ich, dass nur ein schnellerer PC mit schnellerer Grafik helfen könnte. Freilich könnten auch die Verlage ihre PDFs sinniger aufbereiten - aber da rechne ich eher nicht mit Entgegenkommen.

Computerbild und Welt am Sonntag lahmarschelten gerade testweise auch auf meinem Android-Tablet, dass sich sonst recht gut für ePapers und eMags eignet. Bei einem Magazin hatte ich mal eine einzelne Anzeige als Ursache für langsames Blättern in berechtigtem Verdacht. Die Seite selbst führte mitten im Aufbau zum Aufhängen. Hielt ich auch für plausibel - wahrscheinlich werden Inputs von Anzeigenkunden nicht bearbeitet und sind viel zu hochauflösend bzw. unnötig komplex. Hier war es eine photorealistische Vektorgrafik einer Armbanduhr - soviel konnte man in den Ansätzen erkennen. Leistungsfetischismus der Werbebranche jenseits dessen, was das Zielmedium leisten kann.

Zitat von Gernleser

So ist es. Eigentlich können alle iOSNutzer dankbar sein, dass das Herunterladen von Einzeltracks nicht funktioniert. Auch wenn die Datenvolumen im Abo immer größer werden, kommt schon einiges zusammen, wenn das Handy sich (unbemerkt) alle 2 - 3 Minuten wieder Daten vom Server holt. Und das Anspielen von 300 Einzeltracks, um diese Problematik zu vermeiden, ist auch wenig praktikabel.

Ich denke, im Gegensatz zum Datenvolumen der Tracks ist das zu vernachlässigen. Ich kann es mangels iThing nicht messen, aber mehr als ein paar Megabyte pro Hörbuch dürften da kaum zusammenkommen. Eher rechnete ich mit <1kB pro Track, aber selbst, wenn es zwei oder drei wären...

Richtig ärgerlich an dem Konzept ist, dass es völlig offline nicht geht bzw. nur mittels vorherigem Durchzappen. Sollte das an iOS liegen und grundsätzlich seitens der Divibib nicht zu korrigieren sein, wäre es für Vielhörer tatsächlich ein Grund, sich ein billiges 7" Tablet oder Smartphone zuzulegen. Aber Vorsicht: Nicht auf Angebote mit Android kleiner 7 hereinfallen. 6 müsste schon seeehr günstig sein.

Zitat von nika

Das wird eher zu den Problemen mit den iOS-Geräten zählen. Unter Android ist/war es eigentlich möglich die eAudios "echt" offline zu hören. Zumindest bei mir.

Das ging so aus dem Verlauf des Threads hervor und wurde auch aufgegriffen:

Zitat von Technikus

Okay, also iThing-spezifisch.

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?

Danke! Auch nach Tagen noch?

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!")

Wenn sich jetzt alle gleichzeitig draufstürzen, knallt es womöglich schon wieder...

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...

Zitat von Mandelauge

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).

Gehe ich falsch in der Annahme, dass da massenhaft Grafiken enthalten sind, eventuell sogar chemische Formeln als Grafiken gesetzt wurden?

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.