Wenn ein Hörbuch beendet wurde, lässt es sich nicht erneut mit einem Tag starten. Erst beim Anlegen eines anderen Tags startet es weider.
Mit der neuen Software-revision 20260719-DEV scheint die Funktion „Denselben RFID-Tag nicht erneut akzeptieren“ aktiviert zu sein, obwohl der Menüpunkt nicht ausgewählt ist. Dieser lässt sich aber auch nicht umschalten.
Übrigens: die neue Gliederung des Einstellungsbereichs finde ich toll
@joker War das nicht ein kürzlicher Change von dir?
Ich bin demletzt auch über den Punkt gestolpert - nicht funktionell, aber beim Anhaken. Für mich ist das aktuelle Verhalten auch nicht intuitiv.
Das Feature DONT_ACCEPT_SAME_RFID_TWICE ist nicht von mir…
Von mir ist der Wechsel von Pause auf play wenn die gleiche Karte aufgelegt wird. Das hat nur Einfluss, wenn vorher pause gedrückt wurde und DONT_ACCEPT_SAME_RFID_TWICE aktiviert ist.
Der Gedanke dahinter ist. Das Gerät steht vor mir mit Pause.
Wenn ich eine Karte auflegen, dann erwarte ich eine Reaktion.
Bei einer neuen Karte wird der neue Inhalt abgespielt.
Bei der gleichen Karte wird die Wiedergabe fortgesetzt mehr nicht. (Mein Festure)
Ohne den Punkt von mir blieb der espuino einfach auf Pause und nix passierte.
So wie ich die Beschreibung verstanden habe funktioniert DONT_ACCEPT_SAME_RFID_TWICE nicht richtig. Wenn die Wiedergabe beendet wurde, egal ob stopp oder Ende der Playlist, dann müsste der Tag wieder akzeptiert werden.
Falls das der Fehler ist, dann ist das neu hinzugekommen. Die Box meiner Kids ist auf dem Stand 20260625-1-DEV und die Features Verhalten sich wie beschrieben. Auch kann ich nach einem beendeten Hörbuch dieses wieder erneut auflegen.
@Ziege
Hmm, also ich habe das gerade mal ausprobiert. Also ein Hörspiel zu Ende laufen lassen und dann die Karte neu aufgelegt. War kein Problem. Hatte keine der Abspieloptionen gesetzt. Entspricht das deinem Fall oder ist da was gesezt?
Nach längerem Spielen mit verschiedenen Einstellungen und vorkompilierten FW-Ständen ist das Verhalten bei mir bis in die Version von Anfang des Jahres sichtbar (Speicherdatum auf Festplatte: 27.03.2026)
Weiter zurück habe ich nicht getestet.
Das interessante ist, dass die selber erstellte Version (siehe Screenshot unten) wegen dem Versuch mit `rxGain=1` am 04.04.2026 wie erwartet funktioniert.
Sowohl alte Version vom Server als auch die eigen erstellte haben folgende Einstellungen:
Etwas Off-topic, aber mir ist beim Vergleichen der verschiedenen Versionen mit der aktuellen aufgefallen, dass Tastenkommandos (Pause/Stopp/Spulen) bei der aktuellen Version erst beim Loslassen der Taster wirksam werden. Ist das beabsichtigt?
@Ziege Vielleicht liegt das an falscher Vorinitialisierung oder so. Ich habe das die Tage nochmal bisschen korrigiert. Teste nochmal mit aktueller Firmware. Da kam u.a. auch ein Autosave dazu für Hörspiele.
Das ist ein Beieffekt der neuen Features mit dem Drehencoder (Taste gedrückt halten und am Drehencoder drehen). Wir haben jetzt quasi drei Dinge:
kurz
lang
gedrückt halten
Wenn du „lang“ nach dem Ablauf der Zeit auslöst, kannst du „gedrückt halten“ nicht erreichen. Ja, das ist leider bisschen doof, wenn man eine lange Aktion auslösen will und man dann aber nicht weiß, wie lange man gedrückt halten muss. Man kriegt’s aber hin.
@Ziege Ich muss mich nochmal korrigieren, obgleich ich es zugegebenermaßen noch nicht getestet habe. Das aktuelle Verhalten, dass LongPress nicht mehr automatisch feuert, ist zum alten Verhalten „konfigurierbar“, wenn alle neuen Drehencoder-Zuweisungen entfernt werden. Oder halt zumindest mal für die Taste, um die es (dir) geht.
Button.cpp => isRotaryModifier
Ich finde, dass das eine ziemlich gute Umsetzung ist. Man könnte es alternativ noch darauf ändern, dass man das weiterhin immer feuert - nur nicht, wenn man innerhalb von longPressInterval (700 ms) gedreht hat. Aber das halte ich für zu kurz.
Ich konnte keinen Unterschied beim obrigen Verhalten feststellen, egal ob mit aktiviertem Autosave oder nicht. Getestete FW von gestern Abend (Commit: 5f7b341e1b)
Tag entfernen ► Tag anlegen ► springt zurück auf Position der letzten Pause oder Start (nicht mit langer Wartezeit getestet)
Stopp mit Taster ► Tag entfernen ► Tag anlegen ► akzeptiert Tag wieder und spielt bei gestoppter Position weiter. ABER auch hier: wird pausiert (z.B. bei 10:15) ► weitergespielt oder -gespult (z.B. 20 Sekunden auf 10:35) ► Tag entfernen ► Tag anlegen ► startet die Audiodatei an der zuvor pausierten Stelle (10:15)
Wird pausiert ► Tag entfernen ► Tag anlegen ► wird nicht weitergespielt (OK)
Stopp mit Taster ► Tag entfernen ► Tag anlegen ► akzeptieren Tag wieder und spielt bei gestoppter Position weiter (mMn nicht OK?) ABER auch hier: wird pausiert (z.B. bei 10:15), dann Weitergespielt oder -gespult (z.B. 20 Sekunden auf 10:35) ► gestoppt ► Tag entfernen ► Tag anlegen ► startet die Audiodatei an der zuvor pausierten Stelle (10:15)
Einstellungen Denselben RFID-Tag nicht erneut akzeptieren und Wechsel von Pause zu Play bei erneutem Auflegen
Meiner Meinung nach widerspricht sich diese Kombination. Müsste das nicht besser die Kombination von Pause wenn RFID-Tag entferntund Wechsel von Pause zu Play bei erneutem Auflegen sein?
Wird pausiert ► Tag entfernen ► Tag anlegen ► wird weitergespielt
Stopp mit Taster ► Tag entfernen ► Tag anlegen ► akzeptieren Tag wieder und spielt bei gestoppter Position weiter. ABER auch hier: wird pausiert (z.B. bei 10:15), dann Weitergespielt oder -gespult (z.B. 20 Sekunden auf 10:35) ► gestoppt ► Tag entfernen ► Tag anlegen ► startet die Audiodatei an der zuvor pausierten Stelle (10:15)
Ich hoffe, ich kann mit meinen Tests und Gedanken etwas weiterhelfen. Auch wenn es am Schluss nur eine Erklärung gibt, dass ich was nicht richtig verstanden habe
Ich habe eben für den PN5180 und RC522 was gemergt. Für den RC522 kann ich es nicht so beurteilen, aber für den PN5180 hat es die Erkennung erheblich verbessert und ggf. können wir uns den Mist jetzt sparen, dass man dieselbe Karte nicht direkt wieder auflegen darf.