Wollte ich nur mal hier lassen. 🤪

Ein Blick in die gekoppelten Geräte bestätigte es, der Sensor war nicht mehr eingebunden.

Dieses Mal habe ich für die Demontage und die anschließende Montage mit neuer Batterie das Laufrad ausgebaut und die Bremsscheibe demontiert, sodass die Befestigung des Sensors sehr einfach war. Beim ersten Mal nach Kauf hatte ich bemängelt, dass die Montage sehr fummelig war.

Ich bin gespannt, wie lange die Batterie dieses Mal hält. Direkt nach dem Kauf wurden bereits nur noch 3 von 4 Balken des Batteriestands angezeigt, wie auch für die jetzt getauschte Batterie, die auch schon länger herum lag.

Hier war es eine Datei mit einer Größe von circa 220 MiB.

Leider konnte die App damals nicht schneller abspielen und so wechselte ich zur App AntennaPod. Diese konnte bis zu 4-facher Geschwindigkeit beschleunigen, war aber eigentlich für Podcasts gedacht.

Heute habe ich die App Voice mal wieder installiert und erfreut festgestellt, dass man die Geschwindigkeit nun bis 3,5-fach einstellen kann. Das reicht mir locker, noch schneller verstehe ich aktuell eh nichts.

Jetzt verwende ich wieder Voice für Hörbücher. Zudem kann man in Voice eine einstellbare Zeit zurück springen, falls man was nicht versteht und es gibt auch einen Volume-Boost um bis zu 9 dB und Voice ist wesentlich einfacher in der Bedienung.

Die App gibt es bei F-Droid und bei GooglePlay.

Und so siehts aus:

Meine erst Vermutung war, dass es unter anderem daran liegt, dass es im Blog um die 2600 Beiträge gibt, während es im Wiki “nur” 578 Seiten sind. Daraus ergibt sich für den Blog eine Dateigröße für die index.json-Datei von über 3,8 MiB, während es im Wiki 0,87 MiB sind.

Die genannte json-Datei muss der Client-Browser herunterladen, um darin dann per JavaScript lokal die Suche anzuwenden. Und bei einer Datei um 3,8 MiB dauert das dann sehr lange.

Erst später stellte ich fest, dass es weit mehr Optimierungspotential durch die Konfiguration der Suche via FuseJS gibt.

Es gibt also zwei Ansätze für die Optimierung der Suchfunktion im Blog.

• FuseJS Einstellungen optimieren
• Suchindex verkleinern durch Auschließen von Beiträgen

Letzteres kann man auch umsetzen, wenn man bestimmte Inhalte generell aus der Suche ausschließen möchte.

FuseJS optimieren (das größte Potential)

Es gibt viele Einstellungen für FuseJS. Die Wirkung der meisten Einstellungen verstehe ich nicht wirklich. Ich habe also erst einmal im Blog das selbe eingestellt wie auch in der Suche im Wiki:

shouldSort: true,
includeMatches: true,
threshold: 0.0,
tokenize:true,
location: 0,
distance: 100,
maxPatternLength: 32,
minMatchCharLength: 3,

(Die Syntax für die Einstellungen im Wiki ist eine andere als im Blog. Denn dort sind die Einstellunen nicht im Front Matter hinterlegt, sondern direkt im JavaScript, da ich die Originalsuchfunktion im Wiki selbst durch FuseJS ersetzt hatte)

Im Blog wird daraus in der Datein config.toml im Bereich params:

search.fuse.threshold = 0.0
search.fuse.location = 0
search.fuse.distance = 100
search.fuse.minMatchCharLength = 3

Hier die Hilfeseite zu FuseJS, wie es im Blog verwendet wird.

Hier die vollständige Liste der Einstellungen für FuseJS gibt es hier.

Ergebnis der vom Wiki übernommenen Einstellungen

Vor den Änderungen hatte eine Suche nach z. B. “ettlingen und zurück” im Chromium-Browser 20 Sekunden gedauert und es wurden 1741 Ergebnisse gefunden, von denen nur das erste Ergebnis alle Begriffe beinhaltete.

Die vielen weiteren Ergebnise sind vermutlich dem Fuzzy-Search geschuldet. Aber damit kann ich persönlich eh nichts anfangen, das konnte also eh weg.

Nach der Änderung der Sucheinstellungen dauert die Suche weniger als 1 Sekunde und es wird nur das einzig passende Ergebnis angezeigt:

Bei anderen Suchbegriffen, wie z. B. “Staatsanwaltschaft”, wurden wegen Fuzzy-Search Ergebnisse gefunden, die den Begriff “Staatsanwaltschaft” gar nicht beinhalteten sondern nur eine Teilmenge der selben Buchstaben in anderen Konstellationen und Wörtern. So war ein Ergebnis z. B. der Blogbeitrag mit dem Titel “Fotografie: Landschaft”, der nur Fotos und gar keinen Text beinhaltete.

Erweiterte Suche aktiviert

Ich habe im Blog für FuseJS auch gleich die erweiterte Suche aktiviert, denn damit kann man tolle Dinge machen, wie man hier nachlesen kann.

So findet man z. B. alle Blogbeiträge, die mit dem String “Fotos” beginnen:

^Fotos

Oder mit dem String “werfen” enden:

werfen$

Mit den alten Einstellungen für die Suche findet diese für “werfen” 2216 Ergebnisse und die meisten beinhalten den Begriff nicht einmal.

Leerzeichen werden als AND verwendet und für OR nutzt man Pipe-Zeichen (|).

Zur Aktivierung der erweiterten Suche fügt man in die Datei config.toml im Bereich [params] ein:

search.fuse.useExtendedSearch = true

Man findet zusätzlich noch ein paar mehr relevante Ergebnisse auch ohne explizite Verwendung der erweiterten Möglichkeiten.

Ergebnis der Optimierung der FuseJS-Einstellungen

Jetzt bin ich auch im Blog mit der Suchfunktion sehr zufrieden. Ich habe bisher alles gefunden, wonach ich testweise gesucht habe, und das ohne viele, viele weitere unnötige Suchergebnisse.

Dazu gibt es jetzt noch erweiterte Suchfunktionen, wie oben beschrieben. Damit muss ich mich nur erinnern, welche Begriffe ich in einem Beitrag verwendet haben könnte.

Zum Beispiel hatte ich mal den Spruch “rechter Reifen Mittelstreifen” verwendet, den ich jetzt so auch finde. Zusätzlich kann ich Beiträge finden, die genau diesen String enthalten ODER mit dem String “bußgeldstelle” beginnen mit "rechter reifen mittelstreifen"|^bußgeldstelle und das Ergebnis beinhaltet 17 Blogbeiträge:

Sucht man nur nach “bußgeldstelle”, dann werden 26 Blogbeiträge gefunden.

Und die Suche ist jetzt schnell, die Ergebnisse sind immer nach circa einer Sekunde da (in Chromium, in Firefox aus dem selben Rechner nach ca. 3 bis 4 Sekunden..

Und als mir dann noch einfiel, dass die Bußgeldstelle mir gegenüber mal die Kombination “scharf rechts” verwendete, kann ich auch danach noch suchen mit dem Suchbegriff bußgeldstelle "scharf rechts" und das Ergebnis ist:

Kurz: Die neue Suche rockt 👍 😄

Bestimmte Dinge aus der Suche ausschließen (wenig Potenzial)

Mein erster Ansatz war es, bestimmte Dinge aus dem Suchindex auszuschließen. Erst danach probierte ich die Optimierung der Einstellungen von FuseJS aus, das letzlich zum erhofften Performanceschub führte.

Ich will das hier aber trotzdem stehen lassen, da es vielleicht je nach Website nützlich sein kann, bestimmte Kategorien oder alte Blogbeiträge vom Suchindex auszuschließen.

Kategorien ausschließen

Man kann Kategorien ausschließen, die sowieso wenig gesucht werden, weil sie z. B. fast nur Fotos enthalten oder auch Kategorien, zu denen es schon lange keine Inhalte mehr gab, wie hier im Blog z. B. “Spiele”.

Alte Beiträge ausschließen

Genau. Siehe unten. 😊

Inhalt (teilweise) aus der Suche entfernen

Derzeit beinhaltet die json-Datei noch den kompletten Inhalt eines Blogbeitrags. Das könnte man ändern und nur noch z. B. Tags, Kategorien, Daten aus dem Front Matter und vielleicht noch die ersten 250 Zeichen des Inhalts jedes Blogbeitrags in die json-Datei einfügen.

Das gefällt mir aber nicht, da man dann auch nur Dinge findet, die in diesen ersten 250 Zeichen enthalten sind.

Umsetzung an einem Beispiel

Hier beispielhaft eine Erläuterung, wie man Blogbeiträge von der Suche (bzw. von der Eintragung in die index.json) ausschließt, die die folgenden Bedingungen erfüllen.

• Beiträge, die älter sind als 5 Jahre.
• Beiträge, die zu den folgenden Kategorien gehören:
  • Fotografie
  • Mumble
  • Musik
  • Spiele

Zur Umsetzung muss man die Datei themes/hugo-theme-bootstrap/layouts/index.json nach layouts/index.json kopieren und wie folgt anpassen:

{{- $.Scratch.Add "index" slice -}}
{{- range .Site.RegularPages -}}
    {{- if ge (sub now.Year .Date.Year) 4 -}}
    {{- else if or (in .Params.categories "Musik") (in .Params.categories "Fotografie") (in .Params.categories "Mumble") (in .Params.categories "Spiele") -}}
    {{- else -}}
        {{- $date := .Date.Format $.Site.Params.dateFormat -}}
        {{- $title := .Title }}
        {{- if $.Site.Params.titleCase -}}
            {{- $title = title $title -}}
        {{- end -}}
        {{- $img := "" -}}
        {{- if .Params.Images -}}
        {{- $img = index .Params.Images 0 | absURL -}}
        {{- else -}}
        {{- $images := .Resources.ByType "image" -}}
        {{- $featured := $images.GetMatch "*feature*" -}}
        {{- if not $featured }}{{ $featured = $images.GetMatch "{*cover*,*thumbnail*}" }}{{ end -}}
        {{- with $featured -}}
            {{- $img = $featured.Permalink -}}
        {{- end -}}
        {{- end -}}
        {{- $item := (dict "title" $title "tags" .Params.tags "categories" .Params.categories "series" .Params.series "content" .Plain "permalink" .Permalink "date" $date "img" $img) -}}
        {{- $.Scratch.Add "index" $item -}}
    {{ end }}
{{- end -}}
{{- $.Scratch.Get "index" | uniq | jsonify -}}

Um einen Hinweis auf der Suchseite einfügen zu können, kopiert man die Datei themes/hugo-theme-bootstrap/layouts/_default/search.html nach layouts/_default/search.html und trägt z. B. ein:

<p><a href="/ueber/suche/">Hinweis: Einige Blogbeiträge sind von der Suche ausgeschlossen. Für Details hier klicken.</a></p>

Ergebnis der Optimierung via Weglassen

Im Ergebnis wurde die index.json statt 3,8 MiB nur noch ca. 1,4 MiB groß. Ohne Optimierung der Sucheinstellungen von FuseJS wurde das aber nur etwas schneller.

Statistiken für den Bau des Blogs

Mit der folgenden Befehlszeile habe ich mir ein paar Statistiken zum Bau der Website ausgeben lassen (Details zur Befehlszeile hier):

hugo --templateMetrics --templateMetricsHints --gc --minify > hugo-metric_0.txt

Interessant dort sind die ersten Zeilen, da dort die meiste Zeit benötigt wird:

      cache     cumulative       average       maximum
  potential       duration      duration      duration  count  template
      -----     ----------      --------      --------  -----  --------
         96 4m19.969432968s   50.785198ms   110.86782ms   5119  partials/sidebar.html
         96 4m19.100400102s   50.615432ms  110.836695ms   5119  partials/sidebar/main.html
        [...]
        100 2m3.753700269s   24.175366ms   63.874341ms   5119  partials/sidebar/featured-posts.html
        100 1m15.906580979s     14.8284ms   69.562651ms   5119  partials/sidebar/recent-posts.html
        100  56.22054184s   10.982719ms   45.487529ms   5119  partials/sidebar/taxonomies.html
        [...]

Optimierungen

Ich habe daraufhin in layouts/partials/sidebar geschaut, was dort so an Aufrufen drin ist und habe schließlich die Datei layouts/partials/sidebar/main.html bearbeitet.

Aus:

{{- partial "sidebar/profile" . -}}
{{- partial "post/toc" . -}}
{{- partial "sidebar/featured-posts" . -}}
{{- partial "sidebar/recent-posts" . -}}
{{- partial "sidebar/taxonomies" . -}}

wurde:

{{- partialCached "sidebar/profile" . -}}
{{- partial "post/toc" . -}}
{{- partialCached "sidebar/featured-posts" . -}}
{{- partialCached "sidebar/recent-posts" . -}}
{{- partialCached "sidebar/taxonomies" . -}}

Statistiken nach der Änderung

Danach habe ich Hugo erneut bauen und Statistiken erzeugen lassen. Und der Unterschied war gravierend.

So haben sich die Werte für die gelisteten Dateien nach der Optimierung verändert:

      cache     cumulative       average       maximum
  potential       duration      duration      duration  count  template
      -----     ----------      --------      --------  -----  --------
         12  2.621892242s     512.188µs   71.285726ms   5119  partials/sidebar.html
         96  1.313718468s     256.635µs    71.26333ms   5119  partials/sidebar/main.html
        [...]
        100  155.703685ms   22.243383ms   23.092028ms      7  partials/sidebar/featured-posts.html
        100   207.69076ms   29.670108ms   37.265719ms      7  partials/sidebar/recent-posts.html
        100   98.810821ms   14.115831ms   16.986037ms      7  partials/sidebar/taxonomies.html
        [...]

      cache     cumulative       average       maximum
  potential       duration      duration      duration  count  template
      -----     ----------      --------      --------  -----  --------
         96 4m19.969432968s   50.785198ms   110.86782ms   5119  partials/sidebar.html
         96 4m19.100400102s   50.615432ms  110.836695ms   5119  partials/sidebar/main.html
        [...]
        100 2m3.753700269s   24.175366ms   63.874341ms   5119  partials/sidebar/featured-posts.html
        100 1m15.906580979s     14.8284ms   69.562651ms   5119  partials/sidebar/recent-posts.html
        100  56.22054184s   10.982719ms   45.487529ms   5119  partials/sidebar/taxonomies.html
        [...]

Voller Erfolg

Das Bauen (rendern) des gesamten Blogs dauert jetzt nicht mehr 71 Sekunden sondern nur noch 13 Sekunden. Beim ersten Durchlauf nach der Optimierung dachte ich erst an einen Fehler, der das Rendern verhindert, da normalerweise der Lüfter des Rechners anspringt, wenn Hugo den Blog baut, was jetzt immer ausbleibt.

Nicht im Theme-Repo rumpfuschen

Damit nicht irgendwelche geänderten Dateien im Repo des Themes liegen, habe ich die angepasste Datei main.html in das Hauptverzeichnis von Hugo gepackt, in den selben Pfad wie auch im Theme, sodass die neue Datei eine höhere Priorität bekommt. Genauer gesagt in hugo-hauptverzeichnis/layouts/partials/sidebar/main.html.

Ich nehme an, dass diese Datei nur relativ selten im Theme geändert wird und falls doch, muss ich die Anpassungen erneut manuell vornehmen. Das passt.

Hoffentlich ist nichts kaputt

Ich kannst noch nicht so recht fassen und glaube noch immer, dass irgendwo irgendwas kaputt gegangen ist.

Ich wäre aber sehr froh, wenn es so funktioniert, denn ich hatte schon die Überlegung, ein anderes, etwas leichtgewichtigeres Theme für meinen Blog zu suchen.

Wenn jemandem etwas auffällt, das so nicht sein sollte, freue ich mich über eine Rückmeldung. Danke :)

Rückmeldung beim Entwickler

Ich werde das mal die Tage so benutzen und wenn ich keine Fehler finde, werde ich das dem Entwickler mal melden, damit er das für sein Theme übernehmen kann. Bei Blogs mit wenigen Seiten mag der Unterschied nicht auffallend sein, aber hier mit um die 2600 Blogbeiträgen durchaus.

Update: Das Theme wurde erweitert, Hugo erstellt Thumbnails jetzt automatisch.

Ich finde es nachwievor schön, dass dieses Theme Artikelbilder einblendet. Jedoch macht es das beim näheren Betrachten nicht optimal. Erwarten würde man, dass von einem eingetragenen Bild eine kleinere Variante automatisch erstellt wird (das ist möglich mit Hugo) und dann diese verwendet wird. Leider wird aber einfach nur die Originaldatei verwendet.

Das führt dazu, dass die Seite unnötig lange lädt. Die Grafiken in der Listenansicht werden mit einer Breite von 180 Pixeln angezeigt. Eine auf so eine Breite verkleinerte Version eines Bildes wäre wohl um wenige Kilobytes klein. Stattdessen werden hier je nach Blogbeitrag Bilder von bis über einem Megabyte geladen.

Deshalb habe ich Artikelbilder im Blog erst einmal deaktiviert und werde mal schauen, ob ich das selbst irgendwie lösen kann.

Dazu habe ich die Datei hugo/themes/hugo-theme-bootstrap/layouts/partial/list-item.html nach hugo/layouts/partial/list-item.html und die Zeilen 16 bis 18 gelöscht, die überprüfen, ob es ein Featured Image im Front Matter gibt. Hier die Datei online.

Mir gefällt an Hugo, dass man sämtliche Dateien eines Themes “überladen” kann, wenn man sie in eine Verzeichnishierarchie innerhalb des Hauptverzeichnisses des Blogs packt, die der innerhalb des Theme-Verzeichnisses entspricht.

Denn AntennaPod ermöglicht ein Abspielen mit einer erhöhten Geschwindigkeit bis 4-fach, Voice lediglich bis 2,5-fach.

Ein Hörbuch in 4-facher Geschwindigkeit kann ich natürlich nicht mehr hören, aber 2,5 ist manchmal noch zu langsam. Ein paar Hörbücher oder einen Podcast höre ich z. B. in 3,2-facher Geschwindigkeit.

Um ein Verzeichnis mit mehreren Hörbüchern in AntennaPod abspielen zu können, muss man dieses manuell hinzufügen. Im Menü drückt man auf „Add Podcast“ und wählt dann das Verzeichnis aus, das die Hörbücher beinhaltet. Danach kann man es wie einen Podcast nutzen.

Wie Voice speichert auch AntennaPod die aktuelle Position eines Hörbuchs bzw. Podcasts.

Die App AntennaPod gibt es bei F-Droid, siehe hier, und bei Google Play, siehe hier.

Hier das Video von dem Vorfall:

Hier meine Erlebnisse bei der Polizei, als ich das damals anzeigen wollte. Spoiler: Wurde abgelehnt. Ich hatte es dann selbst direkt an die Staatsanwaltschaft geschickt.

Dass ein Ordnungswidrigkeitenverfahren eingestellt wird, weil der Halter nicht sagt, wer gefahren sei, das kenne ich. Aber in einem Strafverfahren hätte ich das nicht erwartet.

Vermutlich gibt es nicht einmal die Auflage für ein Fahrtenbuch. Wieso auch, der Halter hat das Fahrzeug ja auch nur jemandem zur Verfügung gestellt, der damit mit einer Geschwindigkeit von um 180 km/h auf der Landstraße entlang bretterte und einen Radfahrer mit deutlich unter einem Meter überholte. Das wäre sicher unverhältnismäßig.

Eine Ordnungswidrigkeitenanzeige wegen des geringen Abstands gab es meines Wissens nach auch nicht.

Nachdem ich seit vielen Monaten wegen der schlechten Erfahrungen der letzten Jahre sowohl Strafanzeigen als auch Ordnungswidrigkeiten direkt an die Staatsanwaltschaft oder die Bußgeldstelle schicke, hatte ich es vor ein paar Tagen mal wieder bei der Polizei vor Ort versucht. Zum einen, weil ich mir Hilfe versprochen hatte bei einer Anzeige und auch, weil ich mich nicht damit abgeben wollte, dass es bei motorisierter Gewalt keinen Ansprechpartner bei der Polizei Pforzheim gibt.

Ich bin wieder mal eines Besseren belehrt worden. Es gab keinen Unterschied zu meinen Erlebnissen, die ich hatte, als die Polizei Pforzheim noch zum Polizeipräsidium Karlsruhe gehörte und es das Polizeipräsidium Pforzheim noch nicht gab. Letzteres existiert seit 01. Januar 2020 und vor allem via Twitter hatte das Social-Media-Team der Polizei Pforzheim immer wieder darauf hingewiesen, dass gewisse Dinge jetzt anders seien.

Es geht um diesen Vorfall vom 04. August 2020, bei dem mich ein Fahrzeugführender mit seinem Fahrzeug mit gemessenen 61 cm und potenziellen 180 km/h überholte. Auf die Geschwindigkeit komme ich, wenn ich vom „hinteren“ Video im Original die Frames zähle, die das Fahrzeug von einem Leitpfosten zum nächsten benötigt.

Ich hatte das Video veröffentlicht und auch die Polizei Pforzheim via Twitter gebeten, sich der Sache anzunehmen und mir zu helfen:

Hallo @PolizeiPF. Wenn Sie für die Sicherheit aller Verkehrsteilnehmenden tätig werden möchten, schicke ich per DM Foto/Video in guter Qualität wg Kennzeichen. Möchte jedoch vermeiden, damit bei Dienststelle aufzulaufen und Zeit damit zu verschwenden.

Mein Tweet an die Polizei Pforzheim

Direkt als Antwort gab es von jemandem den folgenden Hinweis:

Tja, theoretisch sogar ein offizialdelik liebe @PolizeiPF (315c 2. b) & d) StGB). […]

Antwort auf Twitter (Direktlink)

Die Antwort der Polizei Pforzheim auf meine Frage:

Wir können das von hier nicht beurteilen. Wenn eine Anzeige erstattet wird, werden sämtliche Beweiserhebungen vorgenommen. Dies erfolgt nach Anzeigenerstattung in Absprache mit der Verfolgungsbehörde, weil Gutachten von dort angeordnet werden müssen.

Antwort der Polizei Pforzheim auf meine Frage (Direktlink)

Solche Antworten habe ich schon öfter bekommen, auch damals noch von der Polizei Karlsruhe. Vor Ort dann immer wieder dasselbe. Keinerlei Interesse und es sei ja nichts passiert. In einem anderen Beispiel 2019 war der Ablauf so. Da wurde ich auch sehr knapp mit sehr hoher Geschwindigkeit überholt und der Fahrer bekam lediglich eine Ordnungswidrigkeitenanzeige wegen zu geringen Abstands in Höhe von 30 €.

Hier das Video des Vorfalls von April 2019 (es ist fast dieselbe Stelle):

Bei der Polizei

Ein paar Tage später ging ich dann zu einer Dienststelle der Polizei Pforzheim und rief zuvor an, um sicherzustellen, dass die Zuständigkeit auch passte und um zu klären, ob ich aktuell einen Termin bräuchte.

Der Polizist sah sich die beiden Videos an. Beim Angucken des vorderen Videos: „Da sind Sie aber nicht gefährdet worden.“, beim Angucken des hinteren Videos: „Da auch nicht.“

Die Geschwindigkeit müsse man messen. Ich habe erklärt, man könne das auch berechnen über die Frames des Videos und die Leitpfosten. Er wüsste nicht, ob StA dafür einen Gutachter bestellen würde.

Er schrieb Teile dessen, was ich sagte, auf ein Blatt Papier und ich sollte das unterschreiben. Die CD mit Videos wollte er erst nicht haben, nahm sie dann aber nach meinem Protest trotzdem. Er meinte zuerst, man würde sich schon bei mir melden, wenn man die Videos bräuchte.

Ich frage mich da schon, wie sich die Staatsanwaltschaft zu etwas ein Bild machen soll, wenn sie nicht einmal die Videos sehen kann. Und wenn sie die nicht zu sehen bekommt, wird vielleicht vorschnell entschieden, dass es mal wieder nichts sei, da die Beschreibung des Polizisten doch sehr harmlos klang.

Ich fragte dann, ob das jetzt eine offizielle Strafanzeige sei und machte ihn auch darauf aufmerksam, dass ich bei sowas immer den Nebensatz „und wegen aller in Betracht kommenden Straftatbestände“ einfüge, was er nicht getan hat. Er schrieb lediglich den kurzen Ablauf auf. Dass ich meiner Ansicht nach zu knapp überholt wurde und dass das Fahrzeug meiner Ansicht nach sehr schnell war. Ich fügte an, dass der Sensor 61 cm gemessen hatte.

Er sagte, er müsse sich den Vorfall nochmal ansehen und würde dann entscheiden, welchen Tatbestand er „nehmen“ würde.

Ob das nicht Sache der StA wäre, das zu beurteilen, fragte ich. Anfangsverdacht sei doch bei der Geschwindigkeit bestimmt schon gegeben.

Er wollte die ganze Zeit auf StGB § 315 c hinaus. Ich verneinte, weil das eh eingestellt würde. Was mir vorschwebe, fragte er. Ich nannte 315d.

Polizist: Was ist d?
Natenom: Sie kennen d nicht?
Polizist: Ich schon, aber ich will wissen, mit was für Sachen Sie jetzt ankommen. Haben Sie das irgendwo gelesen?
Natenom: Illegales Autorennen.
[Polizist lacht laut auf]
Polizist: Jetzt kommen Sie aber mit Sachen an.

Ich erkläre, dass ich es nicht weiß aber doch wohl die Staatsanwaltschaft das entscheiden müsse. Und dass ich hier sei, damit er mir helfen könne und dass ich nicht verstehe, dass er das nicht als Gefährdung ansieht.

Er bot irgendwann an, statt einer Anzeige einen Bericht an die Staatsanwaltschaft zu schicken mit Bitte um Beurteilung. Dann müsse die Polizei je nach Entscheidung der Staatsanwaltschaft ermitteln.

Nichts geändert

Nach diesem erneuten Erlebnis kann ich leider sagen, dass sich trotz dem neuen Polizeipräsidium Pforzheim in dieser Richtung nichts verändert hat. Ich werde auch in Zukunft Strafanzeigen direkt an die Staatsanwaltschaft schicken, ohne die Polizei zu bemühen.

Das Aktenzeichen, oder doch nicht

Am nächsten Tag rief ich bei der Polizei an und konnte mit dem Polizisten sprechen, bei dem ich gestern war. Ein Aktenzeichen gab es nicht und aus dem versprochenen Bericht an die Staatsanwaltschaft mit Bitte um Beurteilung wurde auch nichts. Der Polizist sehe keinen Straftatbestand sondern lediglich eine Ordnungswidrigkeit wegen des zu geringen Abstands. Ich fragte zur Sicherheit nochmal, ob er jetzt wirklich 105112 meint (das ist die Tatbestandsnummer für Überholen mit zu wenig Abstand). Mit der Nummer konnte er nichts anfangen, meinte aber diesen Tatbestand.

Direkt zur Staatsanwaltschaft

Ich werde diesen Vorfall also doch wieder direkt an die Staatsanwaltschaft schicken. Es darf nicht sein, dass jemand mit 180 km/h auf der Landstraße fährt, einen Radfahrer mit 61 cm überholt und es letztlich nur 30 € kostet. Vor allem auch deshalb, weil die Szene auf Video ist, das Kennzeichen erkennbar ist und man auch die Geschwindigkeit zumindest in gewissen Grenzen berechnen kann.

Wie auch die Lenkertasche habe ich den Fahrradcomputer schon länger in Benutzung. Bisher hatte ich allerdings aus Faulheit noch nichts dazu geschrieben.

Ich kaufte den Fahrradcomputer ROX GPX 11.0 von Sigma als Bundle. Enthalten waren zusätzlich noch Trittfrequenzsensor und Pulssensor mit Brustgurt.

Besonders interessiert war ich an den Werten des Trittfrequenz-sensors und des Pulssensors, da man daraus und ein paar weiteren Daten zumindest einen theoretischen Wert für die Leistung beim Fahrradfahren berechnen kann. Darüber kann ich dann ganz gut in Auswertungen erkennen, wie fit ich aktuell bin. Natürlich war mir auch die Funktion sehr wichtig, dass gefahrene Strecken automatisch und immer per GPS aufgezeichnet werden.

Es ist keine Verkabelung notwendig, alle Zubehörteile des Fahrradcomputers kommunizieren per Funk miteinander.

Kosten

• Kosten: 170 € für einen „Sigma ROX GPS 11.0“-Fahrradcomputer als Bundle (Black-Set) (online)
• Zeit zum Wechseln: 20 Minuten
• Kilometerstand: 1100 km /2019
• Ausgaben bisher: 1029,55 € /2019

Fotos

Mit der App Onleihe hat man über ein Konto einer lokalen Bibliothek Zugriff auf digitale Medien. Die verfügbare Auswahl bestimmt dabei die lokale Bibliothek. Details siehe hier.

Seit dem letzten Update (schon im September 2019) ist es in der App möglich, Hörbücher in verschiedenen Geschwindigkeiten abzuspielen.

Die Einstellung erreicht man über das kleine Play-Icon rechts oben in der Ecke. Dabei sind Geschwindigkeiten bis 2-fach möglich; diese muss man nach jedem Start der App neu einstellen.

Das ist schon wesentlich besser, als die Hörbücher mit normaler Geschwindigkeit anzuhören; aber mir reicht das leider noch nicht aus. Denn aktuell höre ich Hörbücher/Videos/Filme in der Regel mit 2,5-facher Geschwindigkeit, teilweise auch mit 3-facher. Deshalb habe ich eine E-Mail an die Entwickler geschickt mit der Bitte, auch noch höhere Geschwindigkeiten bis 3 oder 4-fach zu ermöglichen.

Für jemanden, der es nicht gewöhnt ist, Ton schneller anzuhören, mag das absolut übertrieben sein. Aber wenn man sich daran gewöhnt hat, dann ist zweifache Geschwindigkeit leider immer noch ziemlich langsam.

Wenn es aber längere Strecken den Berg hoch geht, dann wechsele ich lieber zu Hörbücher, vor allem, weil man langsamer fährt und der Fahrtwind nicht stört.

Schnell, schneller, …

Eine Besonderheit beim Anhören von Hörbüchern ist, dass ich diese schneller abspielen lasse, weil mir die Informationen sonst zu langsam sind. Ich habe vor langer Zeit damit angefangen, Videos in höhrerer Geschwindigkeit anzusehen und wenn man sich erst daran gewöhnt hat, dann kommt einem die Originalgeschwindigkeit wie Zeitlupe vor.

Serien gucke ich z. B. in 2 bis 2,5 facher Geschwindigkeit an. Bei Hörbüchern, je nach Vorlesendem aktuell in bis zu dreifacher Geschwindigkeit.

Kopierschutz ist doof

Nutzt man Hörbücher mit Kopierschutz, dann kann man nur die vom Anbieter erzwungene App zum Anhören nutzen. Und diese haben nicht immer die Möglichkeit, ein Buch schneller abzuspielen, wie z. B. die App von Onleihe.net, auf deren Sammlung man über die Anmeldung bei lokalen Bibliotheken Zugriff bekommt. Dort gibt es seit 2017 einen Wunsch nach dieser Funktion, bisher ohne Ergebnis. Seit dem Update der App im September 2019 ist es möglich, eine bis zu 2-fache Abspielgschwindigkeit einzustellen.

Wenn ich richtig informiert bin, dann bietet z. B. Audible an, ein Hörbuch mit bis zu dreifacher Geschwindigkeit abzuspielen.

Voice für Hörbücher ohne Kopierschutz

Hörbücher ohne Kopierschutz kann die freie App Voice abspielen (bei F-Droid oder bei GooglePlay). Doch auch Voice erlaubt es nur, das Hörbuch mit maximal 2,5 facher Geschwindigkeit abzuspielen. Wenn man es jedoch gewohnt ist, Audio schneller zu hören, dann kann selbst das zu langsam sein, dann möchte man eher etwas mit Faktor 3 oder noch etwas schneller.

Ich hatte deshalb vor einiger Zeit beim Entwickler der App einen Issue erstellt und darum gebeten, mehr als 2,5 fach zu ermöglichen. Dies wurde abgelehnt; schon in der Vergangenheit in einem anderen Issue.

ffmpeg als Helfer

Mit Hilfe von ffmpeg kann man ein Hörbuch in die zweifache Geschwindigkeit konvertieren.

Dazu der folgende Befehl:

ffmpeg -i buch.ogg -filter:a "atempo=2.0" buch-zweifach.opus

Die Datei buch.ogg wird konvertiert und es entsteht die neue Datei buch-zweifach.opus.

Ergebnis in Voice

Spielt man buch-zweifach.opus mit Voice ab, dann ist die echte Geschwindigkeit von nun an der in Voice eingestellte Faktor mal zwei.

Stellt man in Voice 1-fach ein, dann hört man das Buch in zweifacher Geschwindigkeit.

Bei 0,5 in Voice hört man das Buch in normaler Geschwindigkeit und bei 2,5 in 5-facher Geschwindigkeit.

So passt es für mich.

Von Pforzheim aus gab es weder offiziell noch inoffiziell eine Tour nach Stuttgart, sodass ich zuerst, natürlich mit dem Fahrrad, nach „Weil der Stadt“ gefahren bin.

Auf nach Weil der Stadt

Ich war trotz Planung zu spät losgefahren, weil ich kurz vorher meinen Fahrradcomputer verlegt hatte.

Um 09:50 Uhr sollte es in Weil der Stadt am Marktplatz losgehen und ich konnte erst um 09:10 Uhr losfahren. Es sind zwar nur ca. 17km, aber zwischendrin geht es doch etwas den Berg hoch. Trotzdem habe ich es geschafft und war nach 34 Minuten dort und konnte gerade noch die Ansage der Polizei zum Verhalten in der Gruppe mitverfolgen.

Dabei wurde erklärt, dass man nicht die Gegenspur nutzen solle, dass man nicht abrupt bremsen solle, Abstand halten und einiges andere mehr.

Los gehts

Die Masse setzte sich bei schönem Sonnenwetter in Bewegung. Ich fuhr als Vorletzter los und bekam von einem Menschen, der durchgezählt hatte, die Information, dass bereits 72 Menschen dabei waren.

Wie auch bei „meiner“ letzten Sternfahrt 2016, die im Jahr 2017 habe ich nicht mitbekommen, habe ich mich schnell nach vorne „durchgearbeitet“, da ich lieber dort fahre. Denn vorne ist meist weniger los und man sieht besser, wo es hingeht.

Hier ein Bild nachdem die meisten schon losgefahren waren:

Polizeiarbeit

Ein Polizeiauto fuhr immer mit Blaulicht vor den Radfahrenden, während die Motorräder schon ein ganzes Stück vorne fuhren, um Zufahrten abzusperren. Hinter der Masse fuhren ein weiteres Polizeiauto und ein Krankenwagen.

Dieselbe „Konfiguration“ konnte ich später in Stuttgart auch bei den anderen Gruppen ausmachen, die von weiteren Städten nach Stuttgart fuhren.

Polizei corkt vor und Radfahrende übernehmen

Ich konnte etwas beobachten, was mir neu war und was gut zu funktionieren scheint.

An jeder Kreuzung/Einfahrt positionierte (corkte) sich zuerst ein Polizist mit seinem Motorrad, um je eine Zufahrt zu sperren. Kurz danach löste einer der vielen „Ordner“ jeden Polizisten ab, sodass dieser zur nächsten Stelle fahren konnten. Man sagte mir, das hätte man von der CriticalMass in Stuttgart so übernommen.

Strecken

Von „Weil der Stadt“ ging es nicht über Radwege sondern über die Hauptstraßen nach Malmsheim und Renningen nach Leonberg zum Marktplatz in der Altstadt. In jedem Ort schlossen sich weitere Radfahrende der Gruppe an.

In Leonberg gab es eine Pause und als die Masse losfuhr waren es dann ca. 300 Radfahrende laut Zählung eines der „Ordner“.

Dann ging es weiter nach Gerlingen, Giebel, Feuerbach, Pragsattel und Stuttgart.

Alle offiziellen Touren, die bei der Radsternfahrt am 10. Juni 2018 nach Stuttgart führten, kann man hier nachlesen.

Ankunft und meine Rückfahrt

Um 12:55 Uhr kamen wir in Stuttgart in der Nähe der Liederhalle an. In Stuttgart war dann noch eine Rundfahrt geplant.

Im Jahr 2016 bin ich diese Rundfahrt mitgefahren, doch gestern war vorher schon für mich Schluss, da für mich – wie erwartet – zu viele Menschen dort waren und ich mich unwohl fühlte.

Also beschloss ich nach kurzer Wartezeit, zum Hauptbahnhof in Stuttgart zu fahren, und von dort aus zurück nach „Weil der Stadt“ zu fahren, noch bevor die Rundfahrt zu Ende ging und alle Bahnen voll werden würden.

Und am Bahnhof waren auch sooo viele Menschen…

Wie es aus meiner Sicht war

Ich habe mich mehrmals zurückfallen lassen und bin dann wieder an den anderen Radfahrenden vorbei nach vorne gefahren. Dabei habe ich mir wieder ganz viele interessante Fahrräder angesehen, einige Leute mit Fragen zugetextet und auch einiges von der Organisation und dem Ablauf der Sternfahrt erfahren.

Alter

Es waren Menschen verschiedenen Alters vertreten. Von ganz jungen Menschen von geschätzt fünf Jahren zu etwas älteren Menschen um die 70 oder älter.

Die kleinen Menschen fuhren, auch auf Aufforderung des „Tourenleiters“, vorne mit, damit sie das Tempo vorgeben konnten.

Vielfahrer, Seltenfahrer, Alltagsfahrer, E-Bikes, …

Es waren Menschen dabei, die sehr viel Fahrrad fahren, als auch solche, die es eher selten tun. Beides erkennt man bei einem Radfahrenden ziemlich gut an der Wadenmuskulatur. Auch hört man bei leichten Anstiegen ganz gut, wer trainiert ist und wer direkt einen oder mehrere Gänge herunterschaltet.

Bei einem der Mitfahrenden konnte ich an verschiedenen Teilen des Fahrrads Spinnweben ausmachen.

Ich hatte den Eindruck, dass der Anteil der E-Bikes geringer war als bei den Radfahrenden, denen ich sonst im Alltag begegne.

Ich habe mehrere Tandems gesehen, Klappräder, ein Riesenrad, und vieles mehr.

Landschaft

Landschaftlich war die Strecke von Weil der Stadt bis Leonberg sehr interessant für mich. Ich war zwar schon in allen diesen Orten, aber die gefahrene Strecke und die entsprechenden Aussichten waren mir neu.

Geschwindikeit

Die Durchschnittsgeschwindigkeit in der Masse betrug so ca. 15 bis 17km/h.

Je näher wir dem Ziel kamen, desto mehr Radfahrende wurden es und desto langsamer wurde die Geschwindikeit. Kurz vor dem Ziel wurde immer wieder getoppt. Einmal wurde auf eine Gruppe aus einer anderen Stadt gewartet und einmal mussten wir an einer Kreuzung sechs Minuten warten, bis eine andere Gruppe durchgefahren war.

Es war schon krass, so viele Radfahrende zu sehen.

Ausrüstung der Teilnehmenden

Interessant fand ich auch, dass bis auf die „Ordner“ fast niemand eine Sicherheitsweste trug. Das fand ich ansich gut, denn man wird zwar besser wahrgenommen mit einer Weste, man ist aber nicht davor geschützt, trotzdem „übersehen“ zu werden. Und wenn jeder mit einer solchen Weste unterwegs wäre, würde sie letztlich auch nichts mehr bringen.

Ich trage deshalb eine Weste, weil ich auch im Dunkeln auf Landstraßen unterwegs bin und da ist jede Reflektion aus meiner Sicht besser.

Die meisten Mitfahrenden trugen einen Helm. Auch hier soll jeder für sich selbst entscheiden, ob er einen haben möchte. Aber ohne Helm wüsste ich gar nicht, wo ich meine Kamera und mein Rück-Blinklicht befestigen sollte :)

Stimmung

Ab und zu heulte mal das Megafon des „Tourenleiters“ auf, vor allem, wenn er in jeder Stadt die ein oder andere Ansage machte. Es wurde gesprochen, war aber sonst ziemlich ruhig. Von anderen Teilnehmenden habe ich keine Musik gehört.

Einmal habe ich irgendwo weit hintermir gehört, wie jemand kurz zu sowas rief wie „das muss doch nicht sein“. Sonst habe ich keine Zwischenfälle mitbekommen.

Es ist eine interessante Erfahrung, dass man sich, bis auf die anderen Radfahrenden, um den umgebenenden Verkehr gar nicht kümmern muss.

Zwischendurch war es für mich so, auch dank der leisen Musik aus meinem Lautsprecher, als ob ich alleine fahren würde. Das war sehr entspannend.

Die Autofahrendenden, die uns entgegenkamen, fuhren fast ausschließlich sehr langsam an uns vorbei. Mir ist nicht bekannt, ob sie das von sich aus taten oder ob sie von den vorausfahrenden Polizisten dazu angewiesen wurden.

Mein Fazit

Ich werde auch bei der nächsten Radsternfahrt nach Stuttgart wieder mitfahren.

Vielleicht traue ich mich nächstes Mal, bei der Rundfahrt in Stuttgart mitzufahren.

Ja, ich spule auch immer hin und her in einem Video/Film, um langweilige Sequenzen zu überspringen oder interessante Szenen mehrmals anzusehen.

Bei Youtube-Videos z. B. habe ich diese dafür immer mit MPV geöffnet; die in Youtube integrierten Geschwindigkeiten 1,25, 1,5 und 2,0 sind nicht fein genug auf das Video abstimmbar.

Heute hat mir jemand den tollen Tipp gegeben, dass es auch entsprechende Browser-Plugins gibt, die genau das realisieren.

Z. B. „Video Speed Controller“.

• Das AddOn für Firefox, siehe hier.
• Für Chrome gibt es die Extension, siehe hier.

Auch kann man mit den Tasten X und Y vor- bzw. zurückspulen und dafür sogar in den Einstellungen des Plugins/Addons bwz. der Erweiterung die Zeitspanne einstellen. Fünf Sekunden finde ich hier sinnvoll.

Im Video selbst gibt es links oben ein Overlay, das man aber auch ausblenden lassen kann:

Vielen Dank Mister R. :)

Der km-Stand des defekten Tachos lies sich per Docking-Station in einem Fahrradgeschäft noch auslesen.

Deshalb habe ich mir den BC 16.16 von Sigma gekauft. Die letzte Zahl steht bei dieser Reihe für das Jahr, die erste für die Anzahl der Funktionen.

Erst war ich etwas verwundert, weil es statt vier Tasten nur zwei hat, d. h. die Ersteinrichtung ist etwas umständlich. Aber letztlich hat man beim alten Tachometer nach der Einrichtung auch nur zwei Tasten benutzt, daher ist das nur logisch, dass zwei weggefallen sind. Ausserdem kann man den BC 16.16 mittels NFC und der Sigma Link App konfigurieren.

Dann war ich aber sehr überrascht von den netten Funktionen.

Zum Beispiel kann man einstellen, dass bei Drücken eines Knopfes das Licht nur angeht, wenn es innerhalb einer bestimmten Uhrzeit ist. Aktuell bei mir zwischen 21 und 05 Uhr. Beim alten Modell war das Licht entweder immer oder gar nicht.

Dann gibt es neben den Gesamtkilometern zusätzlich noch die Möglichkeit, die Gesamtkilometer für jeden Monat anzuzeigen; dies habe ich bisher in einer OpenOffice-Tabelle manuell gemacht.

Wie auch die alte Version des Tachometers kann man diesen auf zwei Fahrrädern nutzen und dabei das Rad manuell einstellen.

Für mich ist es praktisch, dass auch ein Temperatursensor verbaut ist.

Leider ist der BC 16.16 nicht kompatibel mit den alten Halterungen vom BC 16.12.

Seit gestern gibt es bei F-Droid eine App namens DataStats, die lediglich die aktuell genutzte Bandbreite in kleinen Overlay am oberen Bildschirmrand anzeigt.

Das Overlay lässt sich in den Einstellungen auf der x-Achse verschieben und man kann die maximale Bandbreite und wenige Dinge mehr einstellen.

Da ich die Statistiken von „Internet Speed Meter Lite“ nicht benötige, weil Android selbst schon solche Statistiken zur Verfügung stellt, reicht mir die Funktionalität von DataStats aus.

Die App gibt es bei F-Droid und bei GooglePlay, den Quelltext findet man auf GitHub und sie steht unter der Apache v2 Lizenz.

Dazu fügt man die Option ConstantDeceleration in die entsprechende Konfigurationsdatei für die Maus ein, z. B. bei mir:

Section "InputClass"
    Identifier "Mouse"
    MatchIsPointer "on"
    MatchDevicePath "/dev/input/event*"
    Option "ConstantDeceleration" "2.55"
EndSection

Damit passt die Geschwindigkeit wieder.

Siehe auch hier.

Benötigt man mehr Informationen und möchte dabei OpenSource Software nutzen, gibt es aktuell in F-Droid zwei Apps…

Speedmeter

Zeigt die aktuelle Geschwindigkeit in groß, darunter die maximale und die Durchschnittsgeschwindigkeit. Dazu die bisher zurückgelegte Distanz und die Zeit. Ganz unten werden die GPS-Genauigkeit und die Anzahl der Satelliten angezeigt.

• Projektseite von SpeedMeter
• SpeedMeter auf F-Droid

AndroidRun

Ganz oben in groß werden gefahrene Kilometer und die Gesamtzeit angezeigt, dann erst folgen die aktuelle Geschwindigkeit und die Durchschnittgeschwindigkeit.

Bei jedem „Run“ speichert diese App im Verzeichnis „RUN-Data“ jeweils eine CSV-Datei, die alle angezeigten Information im Verlauf und zusätzlich die Positionsdaten enthält. Das Format innerhalb der Datei entspricht:

CSV format : OLC; Distance; Delta Dist; Accuracy; Inst Speed; deltaTSeconds; altitude; bearing; latitude; longitude; lastAltitude; ascent; descent; SatNumber; UpdateNumber; State;

Um die Daten auszuwerten, müsste man sich jedoch selbst etwas scripten; interessant wäre es schon…

• Projektseite von AndroidRun
• AndroidRun auf F-Droid

Fazit

Mir gefällt Speedmeter besser, da die aktuelle Geschwindigkeit größer dargestellt wird als der Rest; und darum geht es ja auch.