Montag, 22. Juli 2024

In Frankreich schlicht nicht auffindbar: Pic Nic-Eier und Hüttenkäse

Seit ich zu Beginn des Jahres meine Diät angepasst habe (Stichwort: „Low carb, high protein“), esse ich fast täglich ein gekochtes Ei (Coop-Artikel) und Hüttenkäse (mein Favorit: Hirz 115 Gramm, aus dem Coop).

In diesem Jahr war ich bereits zwei Mal in Frankreich: Einmal um Ostern herum in Dijon, sowie bis letzten Donnerstag in Nizza.

Das Problem: In den dortigen Supermärkten findet man einfach keine Pic Nic-Eier (mich nervt es, die Eier selber kochen zu müssen), und in dem gefühlten Laufkilometer Käsekühltheke findet sich kein Hüttenkäse.

Stichprobenraum: Carrefour Dijon La Toison d’Or, Carrefour Nice Gambetta, U Express Nice Rue de France.

Offenbar stellt Danone Hüttenkäse her, und das Produkt wird auch auf Carrefour.fr als auch für Hyper U aufgeführt, doch in den Läden fand ich die Ware nicht.

Ich bin nicht der einzige, der diese Produkte sucht: Forum-Artikel: Cottage cheese?

Tags: , , , , , , ,
Labels: Essen, Shopping, Wirtschaft

1 Kommentar | neuen Kommentar verfassen

Dienstag, 2. Juli 2024

AirPods Pro Case im Bahnhof Bern verloren

Freitag, 28. Juni 2024, vormittags: Ich komme mit der S6 aus Schwarzenburg um 10:54 Uhr im Bahnhof Bern an, und verschiebe gleich anschliessend von Gleis 13 über die Welle zu Gleis 2, um dort um 11:02 Uhr den IC nach Zürich zu besteigen.

Dabei muss es passiert sein: Während ich auf meinen AirPods Pro Kopfhörern Musik hörte, muss mir das AirPods Pro Case mit eingraviertem „EMEIDI“ irgendwie aus der rechten Hosentasche meiner neuen kurzen Hosen gefallen sein.

Es handelt sich um das Lightning-Case, welches mit meinen AirPods Pro A2698 mitgeliefert wurde („AirPods Pro (2nd generation) with MagSafe Charging Case (Lightning)“, gemäss Apple 2022 veröffentlicht). Die Kopfhörer und das Case tragen die Seriennummer Q0F2TGMY55.

Spätestens um 11:59 Uhr, kurz vor der Ankunft in Zürich, realisierte ich den Verlust, weil ich zu dem Zeitpunkt zum ersten Mal einen Screenshot des Case in meiner Find My App auf dem iPhone machte. Dazumal zeigte die App noch an, dass das Case zuletzt um ca. 7 Uhr morgens zu Hause gesehen wurde. Das konnte aber nicht stimmen.

Um 12:11 Uhr dann meldete die Find My App, dass das Case vor einer Stunde zuletzt an der Schanzenstrasse 5A in 3008 Bern gesehen wurde. Ein späterer Screenshot um 23:28 Uhr meldete als „Last seen“ Zeitpunkt 10:55 Uhr.

Am Samstag, 29. Juni 2024 um 20:07 Uhr zeigte mir Find My an, dass das Case vor einer Stunde zu Beginn des Zugangs zu Gleis 49 und 50 an der Welle gesehen wurde. Um 23:57 Uhr war das Case 5 Minuten zuvor gesehen worden. Immer noch an derselben Stelle.

Dito für den 1. Juli um 00:15 Uhr (26 Minuten zuvor gesehen), und dann noch einmal um 03:04 Uhr.

Am Montag, 1. Juli 2024, bin ich am Vormittag in Bern, um einen alten Bekannten zu treffen. Da ich zu früh in Bern bin, verwende ich die verbleibenden 20 Minuten, um meinen Weg am Freitag abzuschreiten. Dann treffe ich mich mit dem Bekannten. Anschliessend an den gemeinsamen Kaffee überrede ich ihn, mit mir meinen Weg vom Freitag durch den Bahnhof abzuschreiten und nach dem AirPods Case Ausschau zu halten. Ich versuche die Ortungsfunktion der Find My App, kann aber das Case weder orten, noch eine Verbindung aufbauen, um einen Ton abzuspielen. Mein iPhone 13 mini wird bei der konstanten Suche sehr heiss, und der Akku leert sich gefühlt im Minutentakt um ein Prozentpunkt.

Später hilft mir meine Frau, das Perron abzuschreiten, und im Kiesbett nach dem AirPods Case Ausschau zu halten. Nichts. Mein iPhone empfängt kein Signal des Cases, obwohl die Find My App etwa eine halbe Stunde später anzeigt, dass das Case während unserer Suchaktion geortet wurde.

Am späten Abend entschliesse ich mich, noch einmal nach Bern zu fahren, um im halbleeren Bahnhof weiter nach dem Case zu suchen. Ich erhoffe mir durch die deutlich weniger Leute (und somit elektronischen Geräte), das Case einfacher kontaktieren zu können. Dieses Mal habe ich auch mein iPad auch dabei. Leider verfügt dieses nicht über die Ortungsfunktion des iPhone 13 mini mit U1 Chip, weshalb ich mit dem iPad konstant den Find My Button drücke, um auf dem Case einen Ton abzuspielen …

… während ich auf dem iPhone die Lokalisierungsfunktion aktiviert habe, welche mir — bei Verbindungsaufbau — mit einem Pfeil zeigen sollte, wo sich das Case befindet (getestet zu Hause, mit meinem Ersatz AirPods Pro Case mit USB-C, welches den U1 Chip verbaut hat):

Schlussendlich gebe ich auf, und fahre nach Hause. Der Verlust lässt mich aber einfach nicht los, weil der Beacon mir sagt, dass das Case irgendwo bei der Welle im Bahnhof

Überlegungen

  • Das Case bewegt sich nicht. Es wird in der Find My App seit Freitag am selben Ort angezeigt. Ich gehe deshalb davon aus, dass es niemand gefunden hat. Könnte es irgendwo im Kiesbett liegen? Doch wieso konnte sich meine Geräte nicht mit den Headphones verbinden?
  • Das Case meldet sich gemäss Find My App nur sporadisch — manchmal stundenlang nicht. Dies kann entweder vom Case selber gesteuert werden (bspw. um Batterien zu sparen), oder aber das Case befindet sich zwar im Bahnhof Bern, aber es kommen für einen hochfrequentierten Bahnhof erstaunlicherweise nicht so viele iPhones an ihm vorbei, dass das Signal andauernd empfangen und an Apples Server weitergeleitet wird. Könnte es sein, dass sich das Case absichtlich oder unabsichtlich an einem Ort befindet, wo meistens nur Android-basierte Smartphones vorbeikommen, und selten bis nie iPhones?
  • Wie exakt ist die Find My Lokalisierung von Apple wirklich? Man beachte den Radius, der um das Case gezeichnet wird. Ist das Case wirklich im Zentrum, respektive irgendwo in diesem Kreis, oder interpoliert Apple hier und verwendet die nächstgelegene Adresse?
  • Auf der Welle gibt es zwei Shops — den Brezelkönig, und den Kiosk. Ich kann mir nicht vorstellen, dass sich das AirPods Case dort befindet, denn dann müsste es meiner Meinung nach fast konstant von iOS-Geräten „gesehen“ werden.
  • Wäre das Case im Abfall gelandet, müsste es den Perimeter längst verlassen haben — ich kann mir nicht vorstellen, dass die SBB Abfallkübel fünf Tage lang nicht leeren.

Tags: , , , , , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Samstag, 8. Juni 2024

Im Mai 2024 entdecktes Liedgut

Nach fast 30 Tagen bin ich wieder zu Hause in der Schweiz — zuerst gab’s ein Städtetrip nach Venedig, dann ging es auf die Azamara Pursuit, auf welcher wir von Venedig nach Barcelona durch das Mittelmeer schipperten, und schlussendlich hängten wir gleich noch eine Reise zur Verwandschaft in der Bay Area an.

Hier einiges an Liedgut, welches ich in den letzten 30 Tagen (wieder)entdeckt habe:

Tags:
Labels: Musik

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 9. Mai 2024

Sony XAV-AX5550D Firmware Update

Gestern funktionierte Apple CarPlay mit dem Sony XAV-AX5550D (siehe Toyota Verso-S mit Apple CarPlay aufrüsten) meinem iPhone 13 mini aus irgendeinem Grund nicht mehr. Bei der Fahrt von Neuenegg nach Bern–Bethlehem funktionierte es reibungslos, doch bei der Rückfahrt ging nichts mehr: Auto neu starten — nix. iPhone neu starten — nix. Us Da das iPhone meiner Frau einige Stunden später am Autoradio mit CarPlay funktionierte, vermutete ich ein ein Problem mit meinem iPhone.

Nichtsdestotrotz entschied ich mich heute, ein Firmware-Update durchzuführen. Den Radio hatte ich 2020 gekauft und einbauen lassen, und die Firmware wies Version 1 auf: CPU 1.0.0, MCU: 1.0.0. Gemäss Treiber und Software-Updates für XAV-AX5550D ist nun Version 1.13 aktuell.

Ich lud das Firmware-Update herunter, kopierte es auf einen mit FAT32-formatierten USB-Stick, ging in die Tiefgarage, startete die Stromversorgung des Autos und folgte der exzellenten Anleitung Sonys. Nach fünft Minuten und dem einmaligen Wechsel des USB-Sticks vom USB 1-Anschluss auf den USB 2-Anschluss auf Anweisung hin war die Firmware auf dem neuesten Stand.

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

Keine Kommentare | neuen Kommentar verfassen

Montag, 29. April 2024

Schön: anamē & Lydmor: Peaceful Avenues

Je mehr man dieses Lied hört, desto besser wird es:

Erschienen auf Anjunabeats.

A propos: Anjunadeep ist nächste Woche (am 8. Mai 2024) in Basel zu Gast.

Unterschied zwischen Anjunabeats und Anjunadeep: Ersteres veröffentlicht „Progressive House“/Trance, letzteres Label „Deep House“/Ambiance/Chill Out Musik (Reddit-Diskussion). Der letzte Kommentar auf Reddit hat es etwas anders ausgedrückt: Ersteres Alkohol und Ecstasy, letzteres Cannabis und psychedelische Drogen.

Tags: , , , , ,
Labels: Musik

Keine Kommentare | neuen Kommentar verfassen

Montag, 29. April 2024

Hammer: The Kolors: Italodisco

Hammertrack!

Tags: , , ,
Labels: Musik

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 28. März 2024

Debian Bookworm: scp meldet „Connection closed“

Ich plane, hier einige Blog-Artikel zum Upgrade meiner Debian Bullseye-Server auf Bookworm und dabei aufgetretenen Problemen zu veröffentlichen.

Erstes Problem: Ein Cron Job, der jede Stunde ein bash-Script aufruft, lief nach dem Upgrade nicht mehr durch.

Die Fehlermeldung:

...
/usr/bin/scp: Connection closed

Auf dem Server (dem Zielsystem) wurde folgendes geloggt:

Mar 26 01:00:15 SERVER sshd[1090765]: Connection from 10.10.10.19 port 33968 on 10.10.10.102 port 22 rdomain ""
Mar 26 01:00:15 SERVER sshd[1090765]: Accepted key RSA SHA256:X found at /home/cronbackup/.ssh/authorized_keys:1
Mar 26 01:00:15 SERVER sshd[1090765]: Postponed publickey for cronbackup from 10.10.10.19 port 33968 ssh2 [preauth]
Mar 26 01:00:16 SERVER sshd[1090765]: Accepted key RSA SHA256:X found at /home/cronbackup/.ssh/authorized_keys:1
Mar 26 01:00:16 SERVER sshd[1090765]: Accepted publickey for cronbackup from 10.10.10.19 port 33968 ssh2: RSA SHA256:X
Mar 26 01:00:16 SERVER sshd[1090765]: pam_unix(sshd:session): session opened for user cronbackup(uid=1001) by (uid=0)
Mar 26 01:00:16 SERVER systemd-logind[630]: New session 1240768 of user cronbackup.
Mar 26 01:00:16 SERVER systemd: pam_unix(systemd-user:session): session opened for user cronbackup(uid=1001) by (uid=0)
Mar 26 01:00:16 SERVER sshd[1090765]: pam_tty_audit(sshd:session): changed status from 0 to 1
Mar 26 01:00:16 SERVER sshd[1090765]: User child is on pid 1090789
Mar 26 01:00:16 SERVER sshd[1090789]: Starting session: subsystem 'sftp' for cronbackup from 10.10.10.19 port 33968 id 0
Mar 26 01:00:16 SERVER sshd[1090789]: Close session: user cronbackup from 10.10.10.19 port 33968 id 0
Mar 26 01:00:16 SERVER sshd[1090789]: Received disconnect from 10.10.10.19 port 33968:11: disconnected by user
Mar 26 01:00:16 SERVER sshd[1090789]: Disconnected from user cronbackup 10.10.10.19 port 33968
Mar 26 01:00:16 SERVER sshd[1090765]: pam_unix(sshd:session): session closed for user cronbackup
Mar 26 01:00:16 SERVER sshd[1090765]: pam_tty_audit(sshd:session): restored status to 0
Mar 26 01:00:16 SERVER systemd-logind[630]: Session 1240768 logged out. Waiting for processes to exit.
Mar 26 01:00:16 SERVER systemd-logind[630]: Removed session 1240768.

Nach etwas Googlen dann die Lösung:

Note: Since OpenSSH 8.8 the scp utility uses the SFTP protocol by default. The -O option must be used to use the legacy SCP protocol.

Quelle: ssh working on all devices but scp from some devices gives „Connection closed“ error

Seit ich im bash-Script das Argument -O ergänzt habe, läuft der Cron Job wieder durch.

Tags: , , , , ,
Labels: Uncategorized

2 Kommentare | neuen Kommentar verfassen

Mittwoch, 27. März 2024

Headless Chrome verrät sich über seinen User Agent

Headless Chrome eignet sich wunderbar, wenn man Web-Seiten mittels über Cron Jobs aufgerufenen bash-Scripts automatisiert abrufen möchte.

In meinem Anwendungsfall sende ich mir an Werktagen um 9:00 Uhr jeweils das Mittagsmenu des örtlichen Metzgers per Email zu.

Dies tat ich bis vor einigen Wochen mittels wget, doch serverseitig hat irgendwas geändert, und das CMS und/oder der Serverbetreiber haben nun eine Landeseite vorgeschaltet, die überprüft, ob ein „realer“ Benutzer oder ein Bot auf die Seite zugreift.

Anstelle des gewünschten Seiteninhalts bekam ich so seither nur noch eine HTML-Seite mit viel komprimiertem JavaScript-Code zu sehen, welcher höchstwahrscheinlich für die Erkennung und Weiterleitung verantwortlich ist.

Headless Chrome half hier:

chromium --proxy-auto-detect --temp-profile --disable-gpu --headless --virtual-time-budget=5000 --dump-dom "https://www.mittagsmenu.com/" > "/tmp/mittagsmenu.html"

Die Option --virtual-time-budget=5000 ist super, denn sie gaukelt vor, dass nach dem Laden 5 Sekunden vergangen sind. Genug, um die Landeseite aufzurufen, die Checks durchlaufen zu lassen, und dann den tatsächlichen gewünschten Inhalt anzuzeigen.

Das funktionierte wunderschön bis vor einigen Tagen, als kein Menu mehr via Email eintraf. Irgendwie kam auch Headless Chrome nicht mehr über die Landeseite hinaus. Doch wieso?

Bald einmal kam ich darauf: Wird Headless Chrome wie oben aufgerufen, identifiziert sich der Browser als Headless laufender Chrome (!):

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/96.0.4664.110 Safari/537.36

Kein Wunder entdeckte und blockierte die Bot-Abwehr den Zugriff.

Zum Glück war die Lösung des Problems ganz einfach:

chromium --proxy-auto-detect --temp-profile --disable-gpu --headless --virtual-time-budget=5000 --dump-dom --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36" "https://www.mittagsmenu.com/" > "/tmp/mittagsmenu.html"

… und seither funktioniert das Script wieder wie gewünscht. Das Argument --user-agent="" war alles, was es dazu brauchte.

Selenium headless: How to bypass Cloudflare detection using Selenium half mir dabei auf die Sprünge.

Tags: , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. März 2024

Etwas ist sehr faul im Staate Boeing

Sehr gute Folge von Last Week Tonight with John Oliver, welche einem einen Überblick über die gewaltigen Probleme gibt, mit welchen Boeing jetzt und vermutlich für die nächste Dekade oder so kämpfen wird:

Tags: , , , ,
Labels: Wirtschaft

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. März 2024

Flug MH370: Alle bis heute bekannten Fakten

Dieses Jahr jährte sich das Verschwinden von Flug MH370 zum zehnten Mal.

Im Gegensatz zum Teleportationshype, der vor einigen Monaten auf Twitter und YouTube um sich gegriffen hatte, bemüht sich Mentour Pilot, Fakten zu liefern und stellt kaum irgendwelche Mutmassungen an. Bravo, sehr informatives Video:

Tags: , , , , , ,
Labels: Geschichte

Keine Kommentare | neuen Kommentar verfassen