Posts Tagged ‘Kunde’

Donnerstag, 22. März 2018

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

Link zu diesem Artikel

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:

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

Link zu diesem Artikel

(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

Link zu diesem Artikel

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.

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:

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:

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

Link zu diesem Artikel

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

upc-cablecom-melchtalstrasse-bern-woche

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

Link zu diesem Artikel

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

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

iphone-se-icloud-drive-bottom

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

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

Leider klappte das auch nicht:

Apple iCloud Web Could not reset Documents and Data

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

os-x-icloud-manage-storage-whatsapp

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

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

In der Console las ich die nichtssagende Fehlermeldung:

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

Erneuter Versuch auf dem iPhone

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

iphone-se-icloud-manage-storage-whatsapp

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

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

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

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

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

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

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

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

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

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

3 Kommentare | neuen Kommentar verfassen

Sonntag, 22. Mai 2016

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

Link zu diesem Artikel

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

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

Link zu diesem Artikel

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

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

billiger-mietwagen.de Kundenangaben

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

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)

Link zu diesem Artikel

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

Donnerstag, 30. April 2015

Amazon, DCC und Swisscard AECS AG

Link zu diesem Artikel

Im Juli 2014 bestellte ich über Amazon USA ein Transcend JetDrive Lite 130 128GB und liess die Ware zu einer in Kalifornien lebenden Bekannten meiner Frau liefern.

Beim Online-Checkout bot mir Amazon an, die Währungsumrechnung für mich vorzunehmen und die Kaufsumme meiner Kreditkarte in Schweizer Franken (CHF) anstelle von US Dollars (USD) zu belasten. Im Fachjargon nennt sich dies Dynamic Currency Conversion DCC.

Ob man DCC wählt oder nicht – als Kreditkarteninhaber wird man bei Transaktion im Ausland so oder so gemolken: Im Falle von DCC resultiert für Amazon ein kleiner Gewinn basierend auf für das Unternehmen vorteilhaften Umrechnungskursen. Bezahlt man hingegen in USD, schaut für Amazon nichts raus. Die Swisscard AECS AG (heute: GmbH) hingegen schlägt einem zwei Prozent Gebühren auf den Kaufbetrag, und bei der Fixierung des Wechselkurs wird wohl auch noch der eine oder andere Rappen zum Nachteil des Kunden abgezwackt.

Jetzt die Stunde der Wahrheit: Was habe ich bezahlt, und was hätte ich bezahlt?

Warenpreis (inkl. CA-Taxes) 86.99 USD
Warenpreis (zum Kaufzeitpunkt umgerechnet mit Google.com) 77.80 CHF
Amazon.com in USD (mit Gebühren und Wechselkursen von Swisscard AECS AG; Wechselkursfixierung zwei Tage nach dem Kauf) 80.30 CHF
Amazon.com in CHF (mit DCC) 80.82 CHF

DCC über Amazon hätte mich also 52 Rappen zusätzlich gekostet, während Swisscard bereits 2.50 CHF auf den Preis geschlagen hat.

Tags: , , , ,
Labels: Leben

1 Kommentar | neuen Kommentar verfassen

Freitag, 13. Februar 2015

Track & Trace der Post mit zwei grossen Schnitzern

Link zu diesem Artikel

Wie man Empfängern einer Postsendung die URL zur Track & Trace-Funktion generiert, habe ich hier bereits erläutert.

Doch die Funktion bietet noch etwas äusserst nützliches mehr: Wer auch immer die Track & Trace-Nummer einer Sendung kennt, kann auf ebendieser Web-Site seine E-Mail-Adresse erfassen und wird in der Folge über jede Status-Änderung der Sendung informiert.

Leider haben die Web-Entwickler der Post bei diesem Feature zwei grobe Böcke geschossen:

  1. Eine E-Mail-Adresse kann unzählige Male registriert werden. Nun gut, nicht weiter schlimm mag der Web-Entwickler denken — dann fügt die Post Einträge halt mittels INSERT IGNORE oder INSERT REPLACE in die Datenbank ein. Denkste. Wenn ich meine E-Mail-Adresse zehnmal abspeichere, erhalte ich für jede Statusänderung zehn identische Mail. Das Problem wird dadurch noch verschäft, dass ich bei der Registrierung einer E-Mail-Adresse keine visuellen Hinweise erhalte, dass die Hinterlegung der E-Mail-Adresse auch wirklich geklappt hat. Deshalb habe ich es bereits mehrere Mal geschafft, meine Adresse drei Mal zu registrieren, bis ich feststellen durfte, dass die Speicherung längst durchgeführt worden war.
  2. Obwohl einem der Erläuterungstext zur Captcha-basierten Turing Tests weismachen will, dass man zwei Wörter erkennen und eingeben muss, geht es (mittlerweile?) nur noch darum, Hausnummern auf Photos eines Google Street View-ähnlichen Dienstes zu erkennen (Google Street View scheint dieses Vorhaben mit viel wissenschaftlichen Hirnzellen und Hardware automatisiert zu haben). Ich frage mich, wie viele Leute beim Anblick dieses Captchas gerätselt haben, wo auf dem Photo überhaupt irgendein Wort abgebildet sein soll?

Post Track Trace Captcha

Tags: , , , , ,
Labels: Schweiz

Keine Kommentare | neuen Kommentar verfassen

« Older Entries
Newer Entries »