Beiträge von Technikus

onleihe:hilfe
Aktuelle Meldungen finden Sie stets auf der :hilfeseite für die Onleihe.

    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.

    Ist schon klar, dass das sozusagen noch nicht mal Alpha ist ;-). Aber wo es schon da war, wollte ich halt gucken, ob ich denReader schon mal gegen den PBR testen kann, der bei mir bisher am allerbesten performed (mit den richtigen Einstellungen). Beim Öffnen der FAZ springt er aber selbst auf die Eingabe der Adobe-ID, die aber auch im Unterpunkt Konten den Fehler auswirft.


    Zudem steht im Begleittext, dass die AID noch gebraucht wird zum externen Öffnen - was ja klar ist, da kein anderer Reader das neue DRM beherrscht. Dazu wäre es nach meiner Vorstellung allerdings nicht nötig, sie in der BETA einzugeben, aber wer weiß...?


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

    Nacheinander:


    1. Dass PDFs für eReader nicht geeignet sind bzw. eReader nicht für PDFs sehe ich auch so und meine Vergrößerungsversuche habe ich mit einem Display fast der doppelten Breite gemacht.
    2. Ich halte das für sehr individuell. Einen solchen Vorteil von e-Ink kann ich für mich nur draußen feststellen...
    3. ... wenn ich den Himmel nicht "ausblenden" kann oder es sehr hell ist.
    4. Beim Tablet ist Scrollen sehr intuitiv, weil die Anzeige förmlich am Finger klebt. Dagegen empfinde ich z.B. ein kurzes Zurückblättern beim e-Reader wegen der vergleichsweise lahmen Reaktion als viel anstrengender, weil man sich wirklich beherrschen muss, um sich nicht zu verblättern.
    5. Da ist nicht jeder so flexibel - meine bevorzugte Literatur gibt es halt oft als PDF...
    6. ... und gab es sie mal als ePub, so war das ein Graus, weil die Bilder nicht passend im Text eingebettet und nicht mal vernünftig zu vergrößern waren. Das sollte allerdings bei wirklich professioneller Nutzung des ePub3-Formates möglich sein. Natürlich muss auch das Lesegerät das beherrschen. Von daher Teile ich Deine Hoffnung, bin aber skeptisch, dass das schnell geht. (Es gibt da ja die bekannte Frage: "...trotzdem öffnen?"

    EmmaHerwegh


    Dann tu mal Butter bei die Fische: Welche deutschsprachigen Verlage sind bei Overdrive vertreten?


    Und vielleicht liefe es mit Amazon ja noch besser, wenn die den Markt aus einer plötzlichen Laune heraus mal passend beackern würden? Die können Verlage geradezu erpressen, jedenfalls versuchen sie es dauernd.


    Letztendlich wäre es vielleicht sogar im ureigensten Interesse der deutschen Medienkonzerne, aktiver und speditiver mit der Divibib zusammenzuarbeiten und eBooks vollumfänglich wie Bücher zu behandeln, anstatt weiter auf "Göschenen-Airolo" zu setzen. Aber was deutsche Manager und Politiker am besten vermögen, sah man ja jetzt erst am Hambacher Forst... (den entsprechenden Ausdruck dafür erspare ich Euch, der ist männerfeindlich)

    Nur als kurze Starthilfe in die Öffentlich-Rechtlichen Podcasts und Hörspiele:

    https://www.ardmediathek.de/radio/sendungen-a-z

    https://www.ardmediathek.de/ra…/mehr?documentId=21301890

    https://www.ardmediathek.de/ra…d=7263856&bcastId=7263856

    https://www1.wdr.de/radio/hoerspiel/


    Auch ÖRR-externe Sites bieten einen Überblick bzw. eine vielleicht einfachere Auswahl oder Suche. Hier mal eine solche als Beispiel:

    http://hoerspiele-gratis.de/wd…r-hoerspiele-download.htm


    Klar, man braucht ein Gerät mit Ton und Internet-Browser, keinen eReader. Und bei unseren Nachbarn wird es so etwas auch geben, also sicher kein Problem, auch an Fremdsprachiges zu kommen.

    Auch mit einem Tablet ist bei der Vergrößerung von PDFs nur ein Teilbereich sichtbar. Wie gesagt: stell dir das Gerät (Reader oder Tablet) als Vergrößerungsglas vor, das jeweils nur einen Ausschnitt anzeigt. Alles, was darüber/darunter/rechts und links liegt, wird “abgeschnitten“, weil es außerhalb des Bildschirms liegt.


    Bei ePubs gibt es dieses Problem nicht, weil sich Zeilen- und Seitenumbrüche bei einer Vergrößerung der Schrift anpassen.

    Da widerspreche ich zumindest in dem Sinne, dass der PBR das Lesen im Querformat sozusagen von der Rolle erlaubt. Ist zwar auch nur ein Fenster, aber eines, dass den Lesefluss kaum mehr behindert als Umblättern und geschätzt eine Vergrößerung auf mehr als doppelte Breite gegenüber einem 4HD ermöglicht, bei dem selbst ein vertikales Rollen anstrengend sein dürfte.


    Bester zukünftiger Ausblick für im Sehen eingeschränkte Menschen ist wohl ein großer Monitor am PC, der dann 2019 zur Geltung kommen könnte, wenn das Lesen mit neuem DRM im Browser eingeführt wird. Das sollte meinem Verständnis nach dann sogar mit einem Linux-PC klappen. Ein teures Tablet mit HDMI-Anschluss könnte das evtl. schon heute. Meine Versuche mit einem Chromecast zur drahtlosen Übertragung fielen wegen der dämlichen Anpassung des WUXGA-Formates auf 1080p unbefriedigend aus - das werde ich noch weiter probieren.


    Ich hoffe, diese Infos sind wenigstens für spätere Leser hilfreich, auch wenn sie erwinjosef nichts mehr nützen. Übrigens kann ich im Umfeld "Seheinschränkungen" auch wieder auf die Mediatheken des ÖRR hinweisen, die Unmengen von Hörbeiträgen auch als Hörspiele und (weniger) als Hörbücher anbieten. Die laufen auch auf PCs und sind sogar auf MP3-Player und Sticks etc. herunterzuladen, da ohne DRM.

    Es ist immer dasselbe WLAN und dasselbe Endgerät (Tablet), welches sich auch immer am selben Ort befindet. Und jedes mal Neuanmeldung.

    Mittlerweile habe ich zumindest für mich ja herausgefunden, dass der WLAN-Wechsel und sogar der Providerwechsel irrelevant sind. Aber das muss nicht für jede Onleihe bzw. für jede Bib so sein - siehe meinen letzten Post oben. Ich bin gleich in der Firma und checke da noch mit unseren WLANs und ebenfalls anderem Provider.