Beiträge von eingemaischt

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

    Selbstverständlich habe ich meine Uhrzeiten geprüft. Und ich habe es auf 3 Geräten ausprobiert. u.A. mit Digital Editions auf PC und auf Android. Die Response kam so vom Server. Wegen 7h dachte ich an einen Konfig-Fehler irgendwo auf einem der Server?


    Jetzt isses egal, wenn jemand einen ähnlichen Fehler hat, kann man ja sammeln. Danke für dein Engagement!

    Ich wollte gerade auf den letzten Drücker ein E-Book zuende lesen, es sollte der Onleihe nach noch 7h von mit geliehen und damit verfügbar sein. Leider zeigt die Adobe-Software "E_ADEPT_REQUEST_EXPIRED".


    Ist das gerade ein allgemeiner Adobe-Fehler oder hat da jemand etwas falsch auf dem Server konfiguriert, so dass die Leihfrist ein paar h vor der deutschen Zeit endet?

    Meine Android-App behält die Daten, ich musste die noch nie neu eingeben.


    Kann es sein, dass du ein "automatisches Säuberungstool" oder "Backuptool" einsetzt, welches die Daten der Apps säubert?


    Ich hatte neulich ein Problem, als ich mit adb backup mein Handy sichern wollte und dadurch etliche Apps wohl ihren Daten-Bereich verloren...

    Wenn ich in der Android App die c't lesen will, stürzt der Reader dabei ab. Immer. Schon beim Aufruf.


    Und zwar bei ALLEN c't-Ausgaben, andere Zeitschriften gehen teilweise.


    Kommt der Reader nicht mit dem " ' " zurecht? Wäre ein ulkiger Fehler. Injection by BookTitle....


    (Getestet auf allen Androids, die ich zu Hause habe)

    der Datentransfer der onleihe wird sehr kleinteilig gesendet. Laut logischem Algorithmus machen das nur böse Hacker. Deshalb wird onleihe geblockt.

    Das ist Quatsch.


    Belegt ist, dass, wenn Google Analytics nicht zugreifbar ist, das "neue" DRM-Verfahren nicht funktioniert. (Ein Skandal, der niemanden interessiert.) Deshalb klappt es mit einem lokalen Pi-Hole nicht.


    Die Fehlermeldungen oben sehen aber eher nach ADE aus.


    Nichtsdestoweniger: Wenn der VPN-Zugang an sich funktioniert, muss man schauen, ob der vielleicht trotzdem etwas blockt. Das machen die manchmal, wenn sie "Super-Privacy" verkaufen wollen; quasi mit integriertem AdBlock. Wenn andere Seiten über VPN gehen, spielt kaum noch die chinesische Zensur eine Rolle

    *schmunzel* Und dann wird wieder ne Beta-Version auf den Markt geworfen, wo die Userschaft als Testpersonal rangezogen wird - dann passts auch wieder nicht: Man soll doch bitte ausgereiftere Technik auf den Markt bringen und nicht die Leute als Betatester missbrauchen...

    scnr

    Naja, ne.


    Das ist meistens der Alpha-Test. Bei dem man dann seine Erfahrungen auch hier ins Forum schicken soll - und nur entweder "das muss so" oder gar nichts zurück bekommt. Ein geregelter Prozess sieht anders aus.


    Der Beta-Test ist gefühlt immer das Release an die Endkunden. Sowohl bei Tolino, als auch hier.

    Liste (wird ständig erweitert) der Titel hier: --> Titelliste

    Der Freudsche Vertipper ist gut.


    Ich hoffe, dass die Liste nicht erweitert, sondern verkürzt wird.


    Außerdem hoffe ich, dass die Divibib, die die Liste auch kennt, dann bei den Titeln den Download per Care auf dem Tolino sperrt oder mit einem Hinweis versieht.


    PS: Premium wäre natürlich, bei den Titeln dann den CARE-Download gar nicht mehr, sondern stattdessen den Adobe-ACSM-Download anzubieten, auch auf den Tolinos.

    Der Ausfall hat wohl um 3 Uhr begonnen und es wäre möglich, dass da auch bei der Divibib nicht sofort jemand dort war. Glaube das Problem ist, dass diejenigen, die die Fehler dann beheben und vermutlich auch schon früh da waren, nicht diejenig sind, die auch die Meldungen schreiben....

    Absolut klar. Aber dann muss man halt die Prozesse anpassen. Überlegt mal: Wenn ihr als Supporter in den Bibs schon vor der ersten Kundenmeldung von der Divibib die Info bekämt "Anmelden gerade nicht möglich, wir arbeiten dran". Auch wenn durch das Tippen des Satzes die Behebung um 5 Minuten verzögert wird, wäre das im Zuge der Nutzerzufriedenheit Gold wert.


    Nicht zuletzt hätten sich wahrscheinlich mehrere Support-Mitarbeitende in den Bib das Schreiben der Tickets sparen können.


    Natürlich nur bei Störungen, die vorraussichtlich länger als 1h dauern oder so.


    Hier muss man zu Gute halten: Die Störung war schnell behoben, danke dafür!

    Kann ich bestätigen, geht wohl gerade wieder. Glück gehabt, dann war's nur ein Schluckauf. (Oder der Webserver ist beim Standard-Restart von Logrotate um 6 Uhr heute morgen nicht wieder aufgewacht ;-P )

    Kann dort dann wenigstens ein größerer Teil des Teams schreiben?


    Bisher habe ich den Eindruck, dass für das Einstellen der Meldungen exakt eine Person verantwortlich ist. Die bekommt wohl intern die Infos und schreibt dann, wenn sie Zeit hat, ein bisschen Marketing-Sprech drum herum und stellt die Meldungen ein.


    Bei dem ganzen Umzugschaos gab es nicht eine Meldung, die irgendwie ansatzweise Background lieferte. Es hieß immer nur lapidar "wir prüfen Unregelmäßigkeiten, bald sollte es wieder gehen".


    Dafür, dass ihr eigentlich aus der Diskussion mitgenommen haben solltet, transparenter mit Fehlern und abgestürzten Systemen umzugehen (die Meisten haben sich nur sekundär an der Umzugspause, sondern vielmehr an eurer Art zu kommunizieren gestört), ist das ein derber Rückschritt.

    Von dem Buch gibt es 2 Exemplare. Du hast es vorgemerkt.


    Auf der DetailSeite steht das "Vorraussichtlich Verfügbar ab" für das Datum, ab dem alle bereits eingetragenen Vormerker (inkl. deinem) bei der max Leihdauer abgearbeitet werden.


    Weil es 2 Exemplare sind liegt das Datum nur 1 Tag weiter als deine Zuteilung deines eigenen Vormerkers. Hätte aber jede Zahl zwischen 0 und 21 Tage sein können.

    Na cool. Dachte, es wäre alles erledigt. Nun bekomme ich in der App beim Zugriff auf "meine Medien" (Vormerker und co) einen javax.net.sslSSLException / Connection reset by peer.


    Bei allem Verständnis - habt ihr eigentlich ein anständiges Servermonitoring inkl. Integration Tests eurer Anwendung?