Ablösung von nuLiga, Handball4all und Sportradar durch iSquad zur Saison 2026/2027

  • Das habe ich auch in der 3. Liga schon gesehen. Beim Ticker sieht man dass sogar bei Toren, die in der 30. erzielt wurden. Wahrscheinlich gibt es solche Tore in Spanien nicht, deshalb ist das nie aufgefallen :irony:

    Wer andern eine Bratwurst brät, der hat ein Bratwurstbratgerät.

  • Ich kann nur sagen Auftakt 3. Liga desaströs, es lebe der gute alte Papierbericht.....

    es kommt alles wieder :wall:

    Es bleibt spannend. Insbesondere wie "kreativ" der DHB versuchen wird diese Probleme in ein positives Bild zu rücken.

    Vorschlag (powered by ChatGPT): "Auch wenn es an der einen oder anderen Stelle noch kleine Anlaufschwierigkeiten gab, konnten alle Spiele mit dem ESB durchgeführt und nach Spielende abgeschlossen werden – einen großen Anteil daran haben die engagierten Ehrenamtlichen in den Vereinen sowie Zeitnehmer, Sekretäre und Schiedsrichter, die vor Ort mit viel Einsatz und Pragmatismus Lösungen gefunden haben. Die ersten Erfahrungen zeigen, dass die grundlegenden Abläufe funktionieren, und gemeinsam mit den Beteiligten arbeitet der DHB daran, die noch bestehenden Herausforderungen weiter zu optimieren und das System für die kommenden Spieltage zu stabilisieren."

  • Es bleibt spannend. Insbesondere wie "kreativ" der DHB versuchen wird diese Probleme in ein positives Bild zu rücken.

    Vorschlag (powered by ChatGPT): "Auch wenn es an der einen oder anderen Stelle noch kleine Anlaufschwierigkeiten gab, konnten alle Spiele mit dem ESB durchgeführt und nach Spielende abgeschlossen werden – einen großen Anteil daran haben die engagierten Ehrenamtlichen in den Vereinen sowie Zeitnehmer, Sekretäre und Schiedsrichter, die vor Ort mit viel Einsatz und Pragmatismus Lösungen gefunden haben. Die ersten Erfahrungen zeigen, dass die grundlegenden Abläufe funktionieren, und gemeinsam mit den Beteiligten arbeitet der DHB daran, die noch bestehenden Herausforderungen weiter zu optimieren und das System für die kommenden Spieltage zu stabilisieren."

    Es wurden aber nicht alle Spiele in der dritten Liga mit dem ESB durchgeführt

  • Immerhin wurde der eine oder andere Endstand ja noch nachgetragen wie bei RNL II - Bittenfeld II. Da müssen wir nicht ganz ahnungslos ins Bett gehen.

    Im Anfang war das Nichts - und das ist dann explodiert." (Terry Pratchett)
    1990 + 1974 - 1954 = 2010  (nur ein kleiner RECHENFEHLER)

  • Die Vereine müssen den ESB öffnen....

    wenn die aber nicht reinkommen gibt´s auch keinen ESB

    Rangekommen scheint man ja zu sein, sonst dürfte es ja im Liveticker auch keine Änderungen in den Aufstellungen zu sehen geben. Aber irgendwas wird die weitere Nutzung verhindert haben. Aber auch schön zu lesen was sich die KI daraus als Spielbericht ausgedacht hat.

    Habe sogar ein Spielbericht gesehen, wo ein Spieler 3 Hinausstellungen bekommen hat, aber keine Disqualifikation.


    Gefunden

    In der Halle wird das hoffentlich anders ausgesehen haben. Aber ja, schon traurig das da der ESB nicht reagiert und direkt rot mit einträgt. Auch komisch das da nix manuell nachgetragen wurde in die Richtung.


    Aber das wird sich der DHB schon schönreden.

  • Stark ist auch dieses Spiel

    Der Liveticker endet nach 53 Minuten beim Stand von 28:21. Im Spiel selbst, den Statistiken und im Bericht wird als Endstand 28:21 angezeigt.

    In der Spielplanübersicht sowie der Tabelle steht der tatsächliche Endstand 33:25. Also Halle ist außerdem ein Ort angegeben, der nicht zu Pfullingen passt.

    Ich bin gerade sehr froh, dass der BWHV ausgestiegen ist und ich mich erstmal nicht weiter damit rumärgern muss...

    Einmal mit Profis arbeiten :rolleyes:

  • Habe sogar ein Spielbericht gesehen, wo ein Spieler 3 Hinausstellungen bekommen hat, aber keine Disqualifikation.

    Gefunden

    In der Halle wird das hoffentlich anders ausgesehen haben. Aber ja, schon traurig das da der ESB nicht reagiert und direkt rot mit einträgt. Auch komisch das da nix manuell nachgetragen wurde in die Richtung.

    Im Spiel gab's natürlich rot. Es ist schon blöd, dass das im Spielbericht nicht deutlich gemacht wird (auch wenn die rote Karte nach der 3. Zeitstrafe natürlich klar ist).

    Der Liveticker verhält sich sogar noch verwirrender: Da taucht eine Disqualifikation nicht einmal auf, wenn es eine direkte rote Karte gibt, sondern der Spieler wird nur mit einer Zeitstrafe angegeben. Das ist in dem von Funkruf genannten Spiel auch zweimal vorgekommen. Wenn man den Liveticker entsprechend filtert, findet man die Einträge gleichwohl als Disqualifikation:

  • Das Problem habe ich auch. Mitten in der Saison war es dann Plötzlich nur noch +1 Unterschied. Erst habe ich mich gewundert, dann dachte ich: "Ach ja. Ende Oktober ist doch die Zeitumstellung."

    Wir müssen also nicht nur die Zeitverschiebung innerhalb der Seite auf dem Schirm haben, sondern auch Sommerzeit "+2" und Normalzeit "+1". Dieser Bug (oder soll ein Feature mit dem Thema Exkurs: koordinierte Weltzeit sein? ;)) erstaunt mich in sofern, da Spanien in der selben Zeitzone ist wie unsereins.

    Einmal editiert, zuletzt von speedylsa (31. August 2026 um 21:07) aus folgendem Grund: Tippfehler berichtigt.

  • Wir müssen also nicht nur die Zeitverschiebung innerhalb der Seite auf dem Schirm haben sondern auch Sommerzeit "+2" und Normalzeit "+1". Dieser Bug (oder soll ein Feature mit dem Thema Exkurs: koordinierte Weltzeit sein? ;)) erstaunt mich in sofern, da Spanien in der selben Zeitzone ist wie unsereins.

    Das ist halt der Klassiker in der Programmierung. Das Betriebssystem hält seine Uhrzeit normalerweise in UTC (Sekunden seit 1970) und dann wird zur Anzeige der aktuellen Uhrzeit diese in die lokale (Browser-)Zeit umgerechnet. Dann gibt es keine Missverständnisse (auch nicht bei Winter-/Sommerzeit). Wenn man jetzt - als Programmierer - dieses Prinzip allerdings nicht versteht und Zeitstempel (bei denen die Zeitzone wie "+0200" fehlt) als UTC interpretiert, kommt so ein Käse bei rum.

    Den Bibliotheken der entsprechenden Programmiersprache (wie PHP) ist das relativ egal, entsprechend muss man Sorgfalt beim Verarbeiten von Zeitstempeln walten lassen. Idealerweise sind die Daten im eindeutigen UNIX-Timestamp (Sekunden seit 1970) gespeichert, aber manchmal kann man das nicht beeinflussen - beispielsweise wenn die Datenbank nur Zeitstempel als Zeichenkette (ohne Zeitzone) zurückgibt.

  • Das ist halt der Klassiker in der Programmierung. Das Betriebssystem hält seine Uhrzeit normalerweise in UTC (Sekunden seit 1970) und dann wird zur Anzeige der aktuellen Uhrzeit diese in die lokale (Browser-)Zeit umgerechnet. Dann gibt es keine Missverständnisse (auch nicht bei Winter-/Sommerzeit). Wenn man jetzt - als Programmierer - dieses Prinzip allerdings nicht versteht und Zeitstempel (bei denen die Zeitzone wie "+0200" fehlt) als UTC interpretiert, kommt so ein Käse bei rum.

    Den Bibliotheken der entsprechenden Programmiersprache (wie PHP) ist das relativ egal, entsprechend muss man Sorgfalt beim Verarbeiten von Zeitstempeln walten lassen. Idealerweise sind die Daten im eindeutigen UNIX-Timestamp (Sekunden seit 1970) gespeichert, aber manchmal kann man das nicht beeinflussen - beispielsweise wenn die Datenbank nur Zeitstempel als Zeichenkette (ohne Zeitzone) zurückgibt.

    Was es nicht besser macht, ist der Umstand, dass der Fehler nicht überall auftaucht. Bei manchen Übersichten stimmt die Zeit, bei anderen muss man wiederum die zwei Stunden abziehen. Es ist einfach verwirrend und peinlich.

  • Was es nicht besser macht, ist der Umstand, dass der Fehler nicht überall auftaucht. Bei manchen Übersichten stimmt die Zeit, bei anderen muss man wiederum die zwei Stunden abziehen. Es ist einfach verwirrend und peinlich.

    Absolut richtig. Deswegen setzen Profis auf automatische Unit/Integration/System Tests. ;)