Posts Tagged ‘Kunde’

Samstag, 24. März 2018

ABBYY FineReader Pro for Mac meldet „Internal program error: Src/DefaultFontMetrics.cpp, 56“

Ich schwöre auf die Digitalisierung von Dokumenten und verwende dazu einen Fujitsu ScanSnap iX500 (teuer, aber jeden Rappen wert) zusammen mit einer separat gekauften Volllizenz von ABBYY FineReader Pro for Mac, um die gescannten Dokumente auf Knopfdruck durchsuchbar zu machen.

Leider habe ich seit dem Umstieg auf einen iMac 27 Zoll (Late 2015) mit macOS High Sierra das Problem, dass mich der FineReader fast bei jedem Texterkennungsvorgang mit der folgenden Fehlermeldung nervt:

image-7826

Mein Workaround: Mittels Klick auf das „Read“-Icon die Texterkennung erneut starten. Manchmal reicht ein Klick, manchmal muss ich die Texterkennung bis vier Mal ankicken, bis die Software durchläuft.

Was manchmal auch hilft: Die Seiten rearrangieren respektive unnötige (leere) Seiten löschen.

Ich habe nun Mal beim Hersteller angefragt, was das Problem sein könnte und wie man es ein für allemal wegbringt.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 24. März 2018

Credit Suisse Direct markiert E-Rechnung als freigegeben, hat sie aber nicht zur Zahlung erfasst

Diese Woche scheint es bei Credit Suisse Direct, dem neuen Online-Banking von Credit Suisse, Probleme gegeben zu haben. Als ich am Montag-Abend eine E-Rechnung zur Zahlung freigeben wollte, erschien nach längerem Warten folgende Fehlermeldung auf dem Bildschirm:

image-7820

Fehler

Bitte versuchen Sie es später noch einmal. Sollte der Fehler erneut auftreten, rufen Sie bitte die Hotline an.

Fehlernummer: NOB00015

Die E-Rechnung war in der Folge als „freigegben“ markiert, die Zahlung fand sich aber nicht in der Liste der offenen, noch auszuführenden Zahlungen.

Ein Telefonat mit der Hotline führte zur Lösung: Offenbar gab es am Abend des 19. März Probleme in diesem Bereich. Um die Rechnung sauber einzuspeisen, muss man die „Freigabe zurücknehmen“ (oder sinngemäss) und diese Rechnung dann wie eine neu eingetroffene Rechnung abarbeiten. Ich hätte auch selber darauf kommen können, verstand den Befehl aber ursprünglich so, dass man die gesamte E-Rechnungsstellung mit diesem Anbieter storniert. Dem ist nicht so: Der Befehl nimmt die Freigabe für diese eine Rechnung zurück.

Tags: , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Maxview VuQube Satellitenempfänger kann keine Schweizer HD-Sender empfangen

Ein Bekannter hat sich kürzlich einen gebrauchten Maxview VuQube Satellitenempfänger und separat dazu das benötigte Viaccess-Modul gepostet, um bei Ausflügen mit dem Wohnmobil ins nahe Ausland weiterhin Schweizer Fernsehen konsumieren zu können.

In einem Forumsbeitrag im Schweizer Satforum liest man davon, dass dem Nickname nach ein Bündner Zeitgenosse am 13. Januar 2016 mit demselben Gerät Schweizer Sender empfangen konnte:

Maxview VuQube Auto

Der Verkäufer hatte meinem Bekannten ebenfalls angegeben, dass er mit der sich selbst-ausrichtenden, portablen Satellitenschüssel die Schweizer Sender empfangen konnte. Was er leider vergessen hatte zu sagen (ein Schelm, wer sich Böses denkt): Das war vor der HD-Umstellung Ende Februar 2016 … und somit fast 2 Jahre vor dem Wiederverkaufsdatum.

Leider hat sich bei mehrmaligen Tests herausgestellt, dass zwar viele Sender auf Hotbird gefunden und angezeigt werden — die Schweizer Sender wollten aber einfach nicht reinkommen.

Einen kurzen Lichtblick gab es, als der Bekannte die Plastic-Abdeckung des Satellitenempfängers entfernte und die Kabel befestigte (er geht davon aus, dass diese beim Posttransport lose geworden waren). Dann war es möglich, ein Signal hereinzubekommen. Sobald aber die Plastic-Haube wieder auf dem Empfänger aufgesetzt hatte, wurde es aber wieder dunkel.

Weitere Google-Suchen förderten dann einen weiteren und neueren Forums-Thread zu Tage, welcher etwas klarer auf die Problematik hinweist:

Aber gerade für die Schweizer ist die [der Maxview VuQube] NICHT geeignet…..

Quelle: Megasat Campingman Portable oder Maxview VU Qube ll ?

Selbst auf der Web-Site des Herstellers liest man für das Nachfolgemodell klipp und klar:

image-7795

Hinweis: Die Maxview VUQUBE Auto 2 – Antenne ist für den Empfang der verschlüsselten schweizer Sender SRF1, SRF2 usw. nicht geeignet.

Quelle: MAXVIEW VUQUBE AUTO 2

Eine E-Mail-Antwort des Maxview-Kundendiensts in Deutschland brachte dann die endgültige Bestätigung/Ernüchterung:

Die Sat-Antenne respektive der Sat-Spiegel der VuQube ist zu klein um die schweizer HD Programm zu empfangen.

Tags: , , , , , , , , , , ,
Labels: Reisen

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 22. März 2018

Egal was, kauft einfach keine Tintenpisser

(fürs Briefe drucken)

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 30. Juli 2017

Betriebsunfälle beim Kauf von gebrauchten Apple Watches vermeiden

Gestern habe ich den Verstand ausgeschaltet und impulsiv auf Ricardo bei einer Auktion für eine „Apple Watch Series 2“ Milanese mitgeboten — und dann zu allem Unglück auch noch gewonnen.

Dem Namen nach ging ich davon aus, dass es sich um eine „Apple Watch Series 2 Stainless Steel Milanaise“ (Modellnummer MNP62ZD in der Schweiz, MNPU2ZD in Deutschland) handelt, welche zu einem Neupreis von 789 CHF über den Ladentisch geht. Auf Ricardo konnte ich die Uhr für nur gerade 300 CHF ersteigern.

Dabei kam mir das Angebot 927745882 von jones9427 von Anfang an komisch vor:

  • Der Body der Apple Watch erschien auf dem Photo gelbstichig/golden — Apple produziert keine goldenen Stainless Steel-Uhren
  • Das Milanaise-Armband schien dieselbe Farbe aufzuweisen — Apple produziert kein goldenes Milanaise-Armband
  • Die Originalverpackung ist nicht vorhanden
  • Einem anderen Fragesteller hatte der Verkäufer mitgeteilt, dass die Uhr ungefähr noch ein Jahr Garantie aufweist — dabei müsste doch ein ordentlicher Apple Watch-Besitzer mittels des Kaufbelegs sofort eruieren können, wie lange seine Uhr noch Garantie hat (2 Jahre ab Kaufdatum).

Der Verkäufer hatte mir bezüglich dem ersten Punkt Tage vor Ende der Auktion versichert, dass die Uhr „silbern“ sei — und ich habe ihm das geglaubt.

image-7429

Zum Glück blieb ich vor der Überweisung des Betrags an den Verkäufer hartnäckig und traf die nötigen Abklärungen. TL;DR: Ich bin vom Verkauf zurückgetreten.

Deshalb hier als Empfehlung an andere Zeitgenossen, die über Ricardo, Tutti und Anibis Schnäppchen machen möchten: Welche Abklärungen sollte man treffen, wenn man eine gebrauchte Apple Watch kaufen möchte?

Modellnummer in Erfahrung bringen und Modell googlen

Das wichtigste ist die Modellnummer der Apple Watch. Besitzt man den alphanumerischen Code, findet man mit Googlen innert Sekunden heraus, um welches Modell es sich handelt.

Die Modellnummer findet man folgendermassen heraus:

  1. Apple Watch mit einem iPhone koppeln
  2. Apple Watch.app
  3. General
  4. About

Ich bat deshalb den Verkäufer, mir einen Screenshot zu senden, was er am nächsten Tag auch tat:

image-7430

Bei der Uhr handelt es sich also um das Modell MLC72S/A. Eine kurze Google-Suche zeigt, dass es sich bei der Uhr die Version mit einem goldenen Aluminium-Body handelt:

Apple Watch Sport MLC72 42mm Gold Aluminum Case with Midnight Blue Sport Band

Falschaussage 1.

Seriennummer in Erfahrung bringen und Garantie prüfen

Dank der Seriennummer, welche man auf dem Screenshot ebenfalls sieht, kann man bei Apple unter Check Your Service and Support Coverage auch den Garantiestatus abfragen.

Und siehe da, die Aussage von „ca. 1 Jahr“ Garantie für die Apple Watch mit Seriennnummer FHMQ9DTYGR7N löste sich vor meinen Augen in Luft auf:

image-7431

Quelle: Check Your Service and Support Coverage

Falschaussage 2.

Nicht nur das, Apples Web-Site sagt mir gleichzeitig auch, um was für ein Modell es sich handelt: WATCH SPORT 42MM (1ST GEN). Es handelt sich also um die Originale Apple Watch, deren Verkauf im April 2015 begann und nun schon zwei Generationen veraltet ist.

Falschaussage 3.

Mal schauen, was der Ricardo-Kundendienst tut … wahrscheinlich nichts, denn man will ja nicht seine Einkommensquelle absägen.

Tags: , , , , ,
Labels: Apple, Gesellschaft

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 1. November 2016

upc cablecom Performance an der Melchtalstrasse im Breitenrain

Eine Bekannte von mir hat sich vor einigen Wochen darüber beschwert, dass die Performance ihrer Internetverbindung von upc cablecom (Quadruple Play Kabel-Anbieter hier in der Schweiz) in ihrer Wohnung an der Melchtalstrasse im bernischen Breitenrain gelegentlich zu wünschen übrig lässt.

Sie war sich sicher, dass die in ihrem aktuellen Internet-Abo als Best Effort versprochene 200 MBit/s Downloadgeschwindigkeit und 20 MBit/s Uploadgeschwindigkeit während den angesprochenen Phasen nie und nimmer erreicht werden.

Ich habe ihr deshalb Anfangs Oktober 2016 einen Linux-Laptop (Lenovo X200s mit Gigabit-Ethernet, welcher mit Cat 5e-Kabel direkt am Router TP-LINK WNDR3600 hängt) ins Netzwerk gehängt, welcher jede Stunde einen Ookla Speedtest mit dem Fiber7-Server durchführt und mir die Werte zurückmeldet.

Nach drei Wochen Monitoring verfestigt sich das Bild, dass mit der Internet-Anbindung tatsächlich etwas faul ist. An praktisch jedem Tag zeigt sich im RRDtool-Graph dasselbe Bild: Ab ca. 18 Uhr bricht die Downloadgeschwindigkeit von annähernd 200 MBit/s zunehmend ein, erreicht mit ca. 40 MBit/s den Tiefpunkt und erholt sich ab 22 Uhr langsam wieder:

upc-cablecom-melchtalstrasse-bern-tag
image-7027

upc-cablecom-melchtalstrasse-bern-woche
image-7028

Meine Vermutung: Im Breitenrain könnte die Studentendichte sowie die Dichte der Yuppies sehr hoch sein. Diese schauen nach Feierabend nicht TV, sondern werfen sich Netflix & Konsorten (vielleicht sogar Bittorrent?) an und streamen sich die TV-Sendungen und Filme ihrer Wahl. Was dafür spricht: Am letzten Wochenende war der Einbruch noch dramatischer als unter der Woche. Der Graph zeigt, dass ausserhalb der Stosszeiten die versprochenen Bandbreiten erreicht werden.

Und nein, meine Bekannte sabotiert sich nicht selber: Sie hat unregelmässige Arbeitszeiten (Früh- und Spätschicht, manchmal auch an Wochenenden), weshalb sie in vielen Fällen von den Geschwindigkeitseinbrüchen gar nichts mitbekommt.

Und was tut der ISP, der hoffentlich über ein viel, viel ausgeklügelteres Monitoring verfügt als ich? Nichts. Wie für unsere Halunken-ISPs hier in der Schweiz so üblich versteckt man sich hinter der Vertragsklausel Best Effort, überbucht das Netz gnadenlos und lenkt den Umsatz nicht in den Ausbau des Netzes, sondern lässt diesen in die Taschen der grosskapitalistischen Shareholder in Übersee fliessen. Und natürlich hofft man darauf, dass der dumme Benutzer nicht auf die Idee kommt, regelmässig Geschwindigkeitsmessungen durchzuführen.

upc cablecom, bitte aufwachen! Im Breitsch braucht es eine grössere Leitung, aber bitte zack zack!

Tags: , , , , , , , , , , , , ,
Labels: Schweiz

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 28. September 2016

WhatsApp kann nicht auf iCloud backupen

Nachdem ich meinen Mac mini endlich auf OS X 10.11 El Capitan gelüpft hatte, konnte ich endlich auch iCloud Drive über all meine Geräte (Mac mini, MacBook Air, iPhone SE, iPad Air 2, iPad 4) aktivieren.

Leider aber bockt WhatsApp auf meinem iPhone SE und will partout nicht nach iCloud backupen:

whatsapp-iphone-se-ios-10-backing-up
image-6949

Uploading: 0 bytes of 456.0 MB (0%)

Und genau in diesem Zustand verweilt die Anzeige, minuten- und stundenlang, ohne dass ein einziges Byte in die iCloud hochgeladen wird.

Gestern und heute habe ich ein, zwei Stunden investiert, um dem Problem auf den Grund zu gehen. Leider habe ich die Lösung (noch?) nicht gefunden.

Ein Blick auf dem iPhone SE unter Settings > iCloud > iCloud Drive zeigt, dass iCloud aktiviert ist, WhatsApp der Zugriff auf iCloud erlaubt ist und das iPhone auch über das Mobilfunknetz mit iCloud kommunizieren darf:

iphone-se-icloud-drive-top
image-6950

iphone-se-icloud-drive-bottom
image-6951

Soweit so gut. Spannend wird es, wenn ich den iCloud Speicherverbrauch genauer anschaue. Hierzu gehe ich zu Settings > iCloud > Storage > Manage Storage, wo ich unter der Rubrik „DOCUMENTS & DATA“ den Eintrag

WhatsApp Messen… 2.1MB

entdecke:

iphone-se-icloud-manage-storage
image-6952

Gestern reagierte das iPhone nicht, als ich diesen Eintrag antippte.

Versuch unter iCloud Web

Als nächste loggte ich mich auf die Web-Oberfläche von iCloud ein und versuchte es dort mit einer Bereinigung. Unter Einstellungen fand ich folgendes Dialogfeld:

Apple iCloud Web Reset Documents and Data
image-6953

Leider klappte das auch nicht:

Apple iCloud Web Could not reset Documents and Data
image-6954

Versuch unter macOS

Man kann übrigens auch versuchen, das WhatsApp-Backup unter OS X zu entfernen — doch gestern schlug auch das fehl:

os-x-icloud-manage-storage
image-6955

os-x-icloud-manage-storage-whatsapp
image-6956

os-x-icloud-manage-storage-whatsapp-delete-documents-and-data
image-6957

os-x-icloud-manage-storage-whatsapp-delete-documents-and-data-failed-try-again-later
image-6958

In der Console las ich die nichtssagende Fehlermeldung:

com-apple-preferences-icloud-remoteservice-js_log-error-deletedate-returned-error-code-500
image-6959

Erneuter Versuch auf dem iPhone

Doch heute gelange ich auf dem iPhone schnurstracks in die Detailansicht:

iphone-se-icloud-manage-storage-whatsapp
image-6960

Edit angetippt, dann erscheint die Möglichkeit, die Daten zu löschen:

iphone-se-icloud-manage-storage-whatsapp-edit
image-6961

iphone-se-icloud-manage-storage-whatsapp-delete-all
image-6962

Dies habe ich soeben getan, und tatsächlich, WhatsApp erscheint nun nicht mehr in der Liste. Immerhin ein Fortschritt zu gestern — wobei ich felsenfest überzeugt war, dass wenn einmal dieses veraltete Backup weg ist das Backup funktionieren wird. Falsch gedacht; WhatsApp hängt immer noch bei 0 Bytes.

Ein kompletter Neustart des Gerätes änderte schlussendlich alles! Als ich den Button Back Up Now anklickte, lud das iPhone nach ein paar Sekunden „Preparing“ Daten in irrer Geschwindigkeit nach iCloud:

whatsapp-chat-backup-preparing-28
image-6963

whatsapp-chat-backup-uploading-433-2-mb
image-6964

whatsapp-chat-backup-last-backup-today-at-19-53
image-6965

Seither kann ich endlich beruhigt sein, bei einem Verlust meines Telefons garantiert noch alle WhatsApp-Mitteilungen als Sicherung auf iCloud zu besitzen:

Die Lösung?

Leider für mich immer noch ein Mysterium. Doch was ich gestern gemacht habe: iCloud Drive auf all meinen Geräten ausgeschaltet, die Geräte heruntergefahren, neugestartet und erst dann wieder eingeschaltet.

Update 2016-11-17: Ich vermute mittlerweile, dass das iOS-Upgrade meines ehrwürdigen iPad 4 das Problem gelöst hat. Meine Hypothese: Da auf dem Gerät noch iOS 9 installiert war, verhinderte das Gerät so, dass meine iCloud upgegradet werden kann. Sobald das Gerät auf iOS 10 migriert war, konnte die von Apple durchgeführte, transparente Migration endlich losgetreten werden.

iCloud Drive-Zugang über iCloud.com

Während dem Debugging-Prozess ist mir aufgefallen, dass ich weder über meinen Mac mini, noch mein iPad Air 2 auf das (webbasierte) iCloud Drive unter iCloud.com zugreifen kann. Folgende Fehlermeldung erscheint:

icloud-com-icloud-drive-there-was-a-problem-loading-the-contents-of-this-folder
image-6966

There was a problem loading the content of this folder.

Der nette Herr von der Apple Support-Hotline konnte mir heute mit diesem Problem leider auch nicht weiterhelfen. Seine einzige Empfehlung: Cookies löschen und den Mac mini neu starten. Immerhin hat mich Apple angerufen und so den Anruf auf das Mobilfunknetz bezahlt.

Er beharrte zudem darauf, dass ich diesen Screen auf meinem iPad nicht anzeigen lassen könne — doch, kann ich, wenn ich in Safari lange auf dem Reload-Button verharre und dann „Request Desktop Site“ auswähle.

iCloud Drive-Ablage auf dem lokalen Mac

Im Laufe der Untersuchung kam ich zudem auf die Idee, den WhatsApp-Ordner auf iCloud über meinen Mac zu löschen. Das iCloud Drive wird auf meinem Mac mini unter OS X 10.11 in folgendem Verzeichnis gecached:

~/Library/Mobile Documents/

Mit dem Tool Plain Cloud erhält man eine Übersichtsliste in Form eines GUIs:

plain-cloud-whatsapp
image-6967

Dort habe ich dann auch WhatsApp wiedergefunden, welches im folgenden Pfad liegt (lag):

~/Library/Mobile Documents/57T9237FN3~net~whatsapp~WhatsApp

Der Inhalt gestern (vor rm -rf):

57t9237fn3netwhatsappwhatsapp
image-6968

Dieses Verzeichnis auf der Kommandozeile von Hand zu löschen brachte gestern leider nicht den gewünschten Erfolg.

brctl

Apple stellt mit brctl ein Kommandozeilentool zur Verfügung (Kommentar von Mendel Kucharzeck vom 11.07.16 um 22:08 Uhr), welches beim Debugging eventuell auch noch weiterhelfen könnte. Hier der Output für gestern:

$ brctl log
[note]    0.000 [2016-09-27 02:40:22.115] sqlite.clientTruth             sync-down.periodic-sync BRCPeriodicSyncOperation.m:137
        scheduled a useless periodic sync
[note]  28798.505 [2016-09-27 10:40:20.620] sqlite.clientTruth             sync-down.periodic-sync BRCPeriodicSyncOperation.m:137
        scheduled a useless periodic sync
[ERROR] 32416.649 [2016-09-27 11:40:38.764] cloudkit.operation.callback    sync.down            BRCSyncDownOperation.m:201
        fetch operation 57T9237FN3.net.whatsapp.WhatsApp error: <CKError 0x7ff7cd9f6220: "Server Rejected Request" (15/6000); server message = "Zone migration failed"; Retry after 43200.0 seconds; uuid = 1CFAE291-105A-4BA7-B0DA-663C5F5EA27F; conta
[note]  56254.108 [2016-09-27 18:17:56.223] brc.sync                       container.scheduler  BRCContainerScheduler.m:819
        received a push for container 57T9237FN3~net~whatsapp~WhatsApp
[note]  56254.412 [2016-09-27 18:17:56.527] brc.sync                       container.scheduler  BRCContainerScheduler.m:808
        received a push for the container-metadata zone
[note]  56261.563 [2016-09-27 18:18:03.677] brc.sync                       container.scheduler  BRCContainerScheduler.m:808
        received a push for the container-metadata zone
[WARN]  56318.506 [2016-09-27 18:19:00.621] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6392c0; recordType=AppContainer, recordID=iCloud.com.microsoft.lync2013.iphone:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=3>
[WARN]  56318.506 [2016-09-27 18:19:00.621] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd68bb00; recordType=AppContainer, recordID=iCloud.com.kayak.travel:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=4>
[WARN]  56318.507 [2016-09-27 18:19:00.621] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6caad0; recordType=AppContainer, recordID=iCloud.com.reddit.alienblue:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=5>
[WARN]  56318.507 [2016-09-27 18:19:00.622] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd631250; recordType=AppContainer, recordID=LWL9XTYF8Q.com.syniumsoftware.macfamilytree7:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=6>
[WARN]  56318.507 [2016-09-27 18:19:00.622] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6392c0; recordType=AppContainer, recordID=iCloud.QW9YDLAY9G.com.hotels.HotelsNearMe:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=7>
[WARN]  56318.508 [2016-09-27 18:19:00.622] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6caad0; recordType=AppContainer, recordID=ZKENARDFWN.com.ifolor.ifolor-designer:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=8>
[WARN]  56318.508 [2016-09-27 18:19:00.623] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd631250; recordType=AppContainer, recordID=iCloud.com.getdropbox.Dropbox:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=9>
[WARN]  56318.509 [2016-09-27 18:19:00.623] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd68b2e0; recordType=AppContainer, recordID=com.apple.mobilemail:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=a>
[WARN]  56318.509 [2016-09-27 18:19:00.623] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd6392c0; recordType=AppContainer, recordID=L996Q9B5UB.com.landi.weather:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=b>
[WARN]  56318.509 [2016-09-27 18:19:00.624] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd68b2e0; recordType=AppContainer, recordID=iCloud.com.apple.iBooks:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=c>
[WARN]  56318.509 [2016-09-27 18:19:00.624] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd68bb00; recordType=AppContainer, recordID=F6266T9T75.com.apple.iMovie:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=d>
[WARN]  56318.510 [2016-09-27 18:19:00.625] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7ca980b30; recordType=AppContainer, recordID=com.apple.Numbers:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=e>
[WARN]  56318.510 [2016-09-27 18:19:00.625] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c860c6c0; recordType=AppContainer, recordID=com.apple.QuickTimePlayerX:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=f>
[WARN]  56318.511 [2016-09-27 18:19:00.625] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8610550; recordType=AppContainer, recordID=com.apple.Preview:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=g>
[WARN]  56318.511 [2016-09-27 18:19:00.626] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd906ac0; recordType=AppContainer, recordID=com.apple.Notes:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=h>
[WARN]  56318.511 [2016-09-27 18:19:00.626] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c860c6c0; recordType=AppContainer, recordID=8YE23NZS57.com.kayak.travel:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=i>
[WARN]  56318.512 [2016-09-27 18:19:00.626] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8610550; recordType=AppContainer, recordID=com.apple.Pages:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=j>
[WARN]  56318.512 [2016-09-27 18:19:00.627] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c860c6c0; recordType=AppContainer, recordID=iCloud.com.tinyspeck.chatlyio:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=k>
[WARN]  56318.512 [2016-09-27 18:19:00.627] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8610550; recordType=AppContainer, recordID=com.apple.mail:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=l>
[WARN]  56318.513 [2016-09-27 18:19:00.627] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7cd9e2800; recordType=AppContainer, recordID=com.apple.TextEdit:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=m>
[WARN]  56318.513 [2016-09-27 18:19:00.628] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8610550; recordType=AppContainer, recordID=57T9237FN3.net.whatsapp.WhatsApp:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=n>
[WARN]  56318.513 [2016-09-27 18:19:00.628] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c860c6c0; recordType=AppContainer, recordID=37GSA6A9EQ.com.benkazez.FlightTrack:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=o>
[WARN]  56318.514 [2016-09-27 18:19:00.628] cloudkit.operation.callback    sync-down.container-metadata BRCContainerMetadataSyncDownOperation.m:44
        no data in record <CKRecord: 0x7ff7c8611e30; recordType=AppContainer, recordID=CZF32S63U5.com.phaidon.wallpaperParis:(com.apple.CloudDocs.container-metadata:__defaultOwner__), recordChangeTag=p>
[WARN]

Spannend ist insbesondere dieser Eintrag mit dem Fehler „Zone migration failed“:

[ERROR] 32416.649 [2016-09-27 11:40:38.764] cloudkit.operation.callback    sync.down            BRCSyncDownOperation.m:201
        fetch operation 57T9237FN3.net.whatsapp.WhatsApp error: <CKError 0x7ff7cd9f6220: "Server Rejected Request" (15/6000); server message = "Zone migration failed"; Retry after 43200.0 seconds; uuid = 1CFAE291-105A-4BA7-B0DA-663C5F5EA27F; conta
[note]  56254.108 [2016-09-27 18:17:56.223] brc.sync                       container.scheduler  BRCContainerScheduler.m:819
        received a push for container 57T9237FN3~net~whatsapp~WhatsApp
[note]  56254.412 [2016-09-27 18:17:56.527] brc.sync                       container.scheduler  BRCContainerScheduler.m:808
        received a push for the container-metadata zone
[note]  56261.563 [2016-09-27 18:18:03.677] brc.sync                       container.scheduler  BRCContainerScheduler.m:808
        received a push for the container-metadata zone

Tags: , , , , , , , , , , ,
Labels: Apple

1 Kommentar | neuen Kommentar verfassen

Sonntag, 22. Mai 2016

Milchkuhinitiative: Ich bin auch ein Velofahrer und Fussgänger …

Vor einigen Wochen erhielt unser Haushalt eine Broschüre zugestellt, welche sich für die Annahme der Milchkuhinitiative stark macht … Obwohl sich die Vorlage klar an die gefühlten Könige der Strasse Autofahrer des Landes richtet, hat man realisiert, dass man so wohl nicht genügend Stimmen zusammenkriegt, um das Land mit achtspurigen Autobahnen zu überziehen.

Die geniale Idee des Politmarketings: Wir müssen auch Velofahrer und Fussgänger ansprechen! Gesagt getan:

Milchkuhinitiative Velofahrer Fussgänger
image-6682

Nun, ich bin nicht ganz sicher, ob sich diese beiden Gruppierungen für blöd verkaufen lassen. Auf den Strassen wird es für uns dann sicherer, wenn nicht mehr motorisierter Individualverkehr unterwegs ist, sondern weniger. Jeder Hinterwäldler sollte begreifen, dass man mit grösseren und breiteren Strassen nicht weniger Verkehr, sondern mehr Verkehr anlockt …

Tags: , , , ,
Labels: Politik

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. April 2016

billiger-mietwagen.de: Toller Anbieter, bis auf den 10 Euro-Gutschein

Früher schwor ich auf Holidayautos.ch, doch irgendwann einmal bekehrte mich billiger-mietwagen.de zu ihrem Service. Eine andere Web-Site für Mietwagenbuchungen braucht der Ferienreisende nicht.

Doch wehe, man versucht diese ominösen 10 Euro-Gutscheine rückerstattet zu erhalten, welche der Anbieter gelegentlich per E-Mail versendet. Diese Gutscheine werden beim Erfassen und Bezahlen der Mietanfrage nicht etwa automatisch angerechnet, sondern müssen nach Rückgabe des Mietwagens online geltend gemacht werden.

Und hier begann für mich die Odyssee: Man hat erstens nur 30 Tage Zeit, die Vergütung einzufordern. Das heisst, dass man sich sofort nach der Rückkehr im E-Mail-Ordner umschauen und den Link im Erinnerungs-E-Mail anklicken sollte (immerhin ist der Anbieter so nett, dieses unaufgefordert zu versenden). Doch ohalätz, die Rückerstattung erfolgt zweitens nicht etwa auf die Kreditkarte, die man für die Online-Buchung verwendet hat (wäre ja zu einfach und die Auszahlungsrate läge bei 100 Prozent). Nein, man muss seine IBAN-Nummer angeben. Diese alleine reicht aber nicht, das Unternehmen wüsste gerne auch noch die Bankleitzahl. Und zu guter Letzt muss mit dem Geburtsdatum sichergestellt werden, dass auch wirklich der Kunde der Nutzniesser der Auszahlung ist.

Nun gut … ich tat, wie mir befohlen wurde, füllte das Formular aus, um dann mit folgender Fehlermeldung konfrontiert zu werden:

billiger-mietwagen Gutschein Rückerstattung
image-6645

Wähle ich mich auf mein Benutzerprofil ein, steht dort mein Geburtsdatum aber klipp und klar:

billiger-mietwagen.de Kundenangaben
image-6646

Das Problem könnte ich seinerzeit trotz mehrer Versuche nicht lösen (ein Schelm, wer Böses denkt …). Ich schrieb deshalb genau an dem Tag, an welchem das Angebot auslief, eine E-Mail an den Anbieter (info@billiger-mietwagen.de) und teilte diesem mein Problem mit. Eine Antwort erhielt ich nie.

Als ich heute die Buchhaltung nachführte strahlte mir die erfreuliche Botschaft auf dem Kontoauszug entgegen: Halleluja, eine gute Seele hatte meine manuell übermittelten Rückerstattungsangaben gesichtet und entschieden, dass ich für eine Rückerstattung qualifiziert sei:

Credit Suisse Zahlungseingang SilverTours GmbH
image-6647

Tags: , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Samstag, 6. Juni 2015

Ctrl-l bei Cyon SSH-Zugängen wieder zum Laufen bringen (sowie: Kritik an Cyon)

Vor Jahren war der Shared Hosting-Anbieter Cyon ein Lichtlein am Horizont — klasse Design, einfach zu bedienende Admin-Oberfläche ohne irgendwelchen Schnick-Schnack.

In den letzten Monaten hat der Anbieter bei mir leider viel Goodwill eingebüsst; es scheint, als passe Cyon bald im Monatsrhythmus seine Infrastruktur an, und der Leidtragende ist der Kunde:

  • Web Application Firewall. Unter dem Motto „Wir machen Web-Hosting noch sicherer!“ wurde primär einfach mal mein auf PHP und MySQL basierendes Site Management Tool zerschossen, welches seit bald 15 Jahren bei unzähligen Hostern produktiv läuft (und von mir auch regelmässig angepasst wird). PHP-Code darf nun nicht mehr per HTTP POST übermittelt werden, denn das sei grundsätzlich einmal ein Sicherheitsrisiko. Und überhaupt. Was zur Folge hat, dass meine Daten sowie diejenigen meiner betroffenen Kunden auf einen anderen Web-Server gezügelt werden mussten, welcher von einer nicht so paranoiden WAF abgeschirmt wird.
  • Lüpfen ohne Vorwarnung oder Testsystem. Ungefähr jedes halbes Jahr lüpft der Anbieter über Nacht die PHP-Standardversion. Finde ich im Grunde Klasse und äusserst fürsorglich. Wenn dann die Sysadmins dort wenigstens ein wenig Hirn walten lassen würden und meine für Cyon adaptierte php.ini ebenfalls von Version zu Version portieren würden. Aber nein, bei jedem PHP-Upgrade kriegt man eine liebevoll von Cyon vorbereite php.ini vorgesetzt, welche natürlich alle selber vorgenommenen Spezialeinstellungen nicht enthält. Ohne irgendwelche Vorwarnung, teilweise um 10 Uhr morgens. Dann heisst es auf der Arbeit, alles liegen und stehen lassen, irgendwie per SSH Verbindung zum Web-Server aufnehmen und die zerschossene php.ini mit einer Sicherheitskopie überschreiben. Dasselbe passierte übrigens mit oben genannter Problematik: Von einem Tag auf den anderen waren alle meine Web-Sites plötzlich wieder hinter einer amoklaufenden WAF aufgeschaltet und funktionierten wieder einmal nicht mehr. Nach Interventionen und langer Wartezeit bequemte sich ein System Engineer dort, den althergebrachten Zustand wieder herzustellen.
  • Kommunikation? Vergesst es. In der heutigen Zeit wäre es mittels E-Mail, Blog und RSS-Feeds ja echt keine Sache, die professionellen und semi-professionellen Kunden über geplante Änderungen zu informieren. Mit genügend Vorlaufzeit, damit das Datum im Kalender markiert werden kann und allenfalls bereits Anpassungen am Code vorgenommen werden können. Aber bei Cyon lebt man nach dem Grundsatz „Was der Kunde nicht weiss, macht ihn nicht heiss.“ Was halt leider dazu führt, dass der Kunde immer wieder aus heiterem Himmel eine grundlegende Anpassung vorgesetzt erhält.

Was mich zu meinem eigentlichen Problem führt: Es scheint, als hätte Cyon kürzlich den Web-Server von LiteSpeed auf Apache gewechselt (ich kämpfe derzeit mit Zeichensatzproblemen, weil AddDefaultCharset utf-8 in .htaccess nicht mehr beachtet werden). Nun gut und recht. Zusammen mit diesem Wechsel kommt auch die SSH-Shell komisch daher.

Insbesondere nervte mich tödlich, dass ich neuerdings das aktuelle Terminal-Fenster nicht mehr mittels Ctrl-l löschen konnte (analog zum Befehl clear, halt simpler und schneller). Wenn ich die Tastenkombination betätigte, erschien einfach eine neue Zeile mit der Befehlseingabe.

Nach einigen längeren Nachforschungen und Pröbeleien (wohl so eine Eigenheit von bash mit .bash_profile und .bashrc) löste folgender Eintrag in .bashrc mein Problem.

...
# User specific aliases and functions
bind -x $'"\C-l":clear;'

Quelle: To bind clear to ^l in Bash

Tags: , , , , , , , , , , , , ,
Labels: IT

5 Kommentare | neuen Kommentar verfassen