Hallo zusammen,
Ich habe bei mir eingestellt, dass die Musikwiedergabe pausiert wird, wenn die Karte weggenommen wird. Das funktioniert. Nun geht aber folgender „hack“:
Kate auflegen > Pause Taste drücken und Wiedergabe pausieren > Karte entfernen > nochmal Pause Taste drücken und die Wiedergabe geht weiter, obwohl keine Karte aufliegt.
Ist das so gewollt?
Für mich würde es mehr Sinn machen, wenn dann einfach nichts passieren würde, da ja keine Karte aufliegt?
Im Moment ist das Ereignis-gesteuert implementiert. Pause Taste wechselt die States Play ↔ Pause ohne auf den Kartenstaus zu schauen. Könnte man natürlich noch einbauen, dass nur gewechselt wird, wenn der Status der Karte stimmt. Aber halt, wenn das in der einen Richtung so sein soll, dann müsste es konsequent auch in der anderen Richtung so sein: wenn Pause gedrückt wird und es liegt die Karte noch drauf, dann sollte auch nichts geschehen. Aber dann ist die Pause Taste eigentlich ohne Funktion in dem Modus.
Ich weiß jetzt nicht, ob das alle so wollen?
Ich finde schon, dass die Pausetaste dann noch Sinn machen würde. Für mich käme das der Logik eines Kassettenrecorders nahe: wenn die Karte aufliegt (=Kassette eingelegt ist) kann ich Pause machen und wieder aufheben. Wenn ich die Karte weg tue (=Kassette auswerfe) dann macht sich die Pause Taste keinen Sinn.
PS: meine Box sieht so aus, das man einen Taler mit RFID chip „einlegen“ kann. Deswegen habe ich irgendwie diese Assoziation.
Dann würde Pause drücken zum Starten der Wiedergabe und dann Karte auflegen für ein neues Hörspiel im Hörspielmodus nicht mehr funktionieren, richtig?
Klingt total logisch, besonders bei deiner Box mit den Talern.
Mir war allerdings das Verhalten auch schon aufgefallen, da meine Box(en) mit der Einstellung „Pause, wenn Karte weg“ laufen. Gestört hat es mich allerdings überhaupt nicht, vielmehr bin ich mir nicht schlüssig, ob ich das Verhalten als Bug oder Feature einstufen soll. Aus meiner ganz persönlichen Sicht (und auch der, der Nutzer meiner Boxen) besteht da kein Änderungsbedarf.
Bei der Funktionsvielfalt, die „unser TonUINO“ inzwischen hat, ist es bestimmt nicht leicht, für alle Anwendungsbereiche und Designs immer ein 100% logisches Verhalten bei allen Betriebs- und Bedienungsmodi zu erreichen. Dies zu durchdenken und zu bestimmen scheint mir fast schwieriger als den Code dafür zu schreiben… Ich fand es schon herausfordernd, allein die Funktionen (aktiv / nicht aktiv) der Vor- und Zurücktasten in den unterschiedlichen Wiedergabemodi in einer Bedienungsanleitung für Eltern zu beschreiben.
@Boerge1
Bei aufliegender Karte, würde ich es für zwingend logisch halten, das der Status Play - Pause mit jedem Druck der Pause-Taste gewechselt wird. Nur, wenn keine Karte aufliegt, bleibt der TonUINO im Pause Status und wechselt nur in den Play Status, wenn dieselbe Karte wieder aufgelegt wird.
Das ist jetzt nur mein spontaner Kommentar, ohne das umfangreiche Wissen wie @Gute_Laune zu haben, mit dem ich sagen will, dass derartige Änderungen in gewisser Tiefe analysiert werden müssen, um nicht anderenorts neue „Baustellen“ zu errichten.
Hmm, aus Sicht der kleinen Nutzerin meiner Box würde es glaub schon Sinn machen, wenn ich sie bei der Bedienung beobachte. Aber ich lass jetzt mal die großen Antworten 
Keine weiteren Meinungen?
Dann würde ich also noch einbauen, dass die Pausentaste nur dann wieder in Play geht, wenn die Karte (noch) aufliegt.
Ich habe das auf dem Branch issue_188 implementiert.
@Martin1 und/oder @NoBl: Könnt ihr das bitte testen?
Ja, das funktioniert dann nicht mehr. Hat irgendwer das Feature benutzt. Wir können immer noch entscheiden, ob diese Änderung wirklich gemacht werden soll.
@Boerge1
Ich habe Issue 188 geladen und mit den Tests begonnen.
Spontan sind mir einige Unplausibilitäten mit der Pause-Taste (auch an anderen Stellen) aufgefallen, die ich aber gern in einer besser verifizierten Testreihe beschreiben will. Das benötigt noch etwas Zeit, da mir noch nicht einmal eine klare Darstellung dazu eingefallen ist.
Demnächst also hoffentlich mehr und in verständlichen Details / Beschreibungen
@Boerge1
Der DF-Player meines Test-TonUINOs ist mit dem Chip MH2024K24SS bestückt.
Mit der Standardeinstellung (define DFMiniMp3_T_CHIP_Mp3ChipIncongruousNoAck) und einer Anpassung von „dfPlayer_timeUntilStarts“ auf 3000 ms schien für meine Anwendung zunächst alles OK.
Mit Beginn der Testreihe zu Issue 188 haben sich Fehlverhalten gezeigt, die m. M. eher auf eine Ansteuerungsproblematik des Players denn auf Programmängel hinweisen.
Die bisherige Testsequenz ist ziehmlich simpel:
verfügbar sind zunächst 3 Karten in den Abspielmodi „Einzel“, „Party“ und „Hörspiel“
jeweils nach Auflegen einer Karte erfolgt folgende Bedienungssequenz:
Mit define = DFMiniMp3_T_CHIP_Mp3ChipIncongruousNoAck:
Bei Einzelkarte:
press pause toggelt korrekt zwischen pause und play
long press pause führt zur Ansage der Tracknummer, nach der Ansage wird der Track korrekt weiter gespielt, der TonUINO meldet aber „enter idle“ und nimmt keine Tasteneingaben mehr an, obwohl sie lt. Konsole erkannt werden. Auflegen einer anderen Karte funktioniert dann wieder.
Bei Party-Modus:
press pause toggelt korrekt zwischen pause und play
long press pause führt zur Ansage der Tracknummer, nach der Ansage der Tracknummer wird der Track korrekt weiter gespielt, der TonUINO meldet aber „play X+1“, was der nächste Track in der Suffle-Queue wäre.
(weiter long press pause führen dann zur falschen Ansage von Trach X+1 und erhöhen die Meldung des TonUINO auf „play X+2“). Abgespielt wird weiterhin der korrekte Track X.
Am Ende des Tracks oder bei Tastendruck „next“ wird dann folgerichtig Track X+2 abgespielt, Track X+1 also fälschlicherweise übersprungen.
Bei Hörspiel-Modus:
Verhalten wie bei Einzel-Modus.
Mit Define = DFMiniMp3_T_CHIP_MH2024K16SS:
Diese Einstellung wurde wegen mehrerer Fehlermeldungen bei der Initialisierung des DF-Players verworfen und nicht weiter getestet.
Mit Define = DFMiniMp3_T_CHIP_GD3200B:
Verhalten, wie mit Define = DFMiniMp3_T_CHIP_Mp3ChipIncongruousNoAck
Mit Define = DFMiniMp3_T_CHIP_LISP3:
Für press pause und auch long press pause korrektes Verhalten, wie erwartet.
Vereinzeltes Auftreten von „missingOnPlayFinished“, deshalb „dfPlayer_timeUntilStarts“ auf 3500 ms erhöht.
Damit scheint mir die Einstellung „Define = DFMiniMp3_T_CHIP_LISP3“ am besten zu dem Chip MH2024K24SS des DF-Players zu passen und ich werde alle weiteren Tests mit dieser Einstellung vornehmen.
Könntest du da bitte mal schauen, ob es ev. Sinn macht ein spezielles „Define“ für den Chip einzuführen? (oder einfach eine Ergänzung als Kommentar bei LISP3)
Hi Boerge1,
vielen Dank für das schnelle implementieren!
Ich habe leider bei mir nur das updaten via Browser (Chrome) zum laufen bekommen, aber NoBI ist ja schon voll dabei wie ich sehe 
Mit dem Fehlerbild oben hatte ich erwartet (schon bevor ich von dem DFMiniMp3_T_CHIP_LISP3 gelesen hatte), dass dieser Player fälschlicherweise ein OnPlayFinished auch nach den advertise Tracks sendet. Und ja, deine weiteren Tests haben das dann auch bestätigt. Der Lisp3 Player macht nämlich auch genau das und dafür gibt es den Workaround mit DFMiniMp3_T_CHIP_LISP3.
Ich mache da mal einen Kommentar ran.
Und wie sieht es mit dem Test bzgl. des eigentlichen Fehlers aus?
@Boerge1 , @Martin1 , @Gute_Laune
Nachdem nun mein DF-Player glaubhaft das tut, was er soll, habe ich eine kleine Testreihe gemacht. Ich erspare uns die Listen hier zu posten, sondern lade ein entsprechendes PDF mit den Details hoch.
TonUINO issue 188 - Test.pdf (33,8 KB)
Für mich sieht die Umsetzung so völlig OK aus!
Wie schon von @Gute_Laune angemerkt, wird es schwierig, durch erneutes Auflegen der Hörspielkarte zu einem anderen Hörspiel zu gelangen, da ja das Auflegen nur den Pause-Status beendet.
Beim Testen ist mir auf-/eingefallen, dass der TonUINO durch „long press pause“ abgeschaltet wird. Das ist prima, wenn nichts abgespielt wird, wie in der Anleitung steht. Befindet sich der TonUINO allerdings im Pause-Status, wird ja eigentlich etwas abgespielt, z. Zt. eben nur gerade pausiert.
Da bei der Einstellung „Pause, wenn Karte weg“ die Pause-Taste (press pause) jetzt ohne Funktion ist, war es für mich nicht mehr ganz logisch, dass long press pause dann dennoch zum Shutdown führt.
Sinnvoll erscheint mir, den TonUINO aus dem Pause-Status über ein long press pause zunächst in den Idle-Status zu schalten.
Dann würde sogar ein erneutes Auflegen der Hörspielkarte dazu führen, dass ein anderes Hörspiel gewählt wird.
Erst ein zweites long press pause würde dann (wie gewohnt) den Shutdown einleiten.
Will damit folgende simple Logik vorschlagen:
long press pause im Pause-Status → wechsel zu Idle-Status
long press pause im Idle-Status → Shutdown
Was haltet ihr von der Ergänzung oder erkennt ihr Wiedersprüche mit anderen Funktionen / Betriebsarten?
Schönen Dank fürs Testen.
Ich glaube aber nicht, dass es sinnvoll ist, die Tastenbelegung noch komplizierter zu machen.
Die Regel ist: wenn nichts abgespielt wird (egal ob Pause oder Idle) fängt der Shutdown Timer an zu laufen und man kann ausschalten. Da der Tonuino kein Display hat, ist es auch schwer zu unterscheiden, ob er in Pause oder Idle ist. Kinder können das noch weniger.
Gibt es denn sonst noch Meinungen zu dem Hörspiel-Problem?
Ich bin durchaus deiner Meinung, dass die Bedienung möglichst einfach, aber dennoch logisch schlüssig gehalten werden sollte. Ich hatte gehofft, dass die Bedienung dadurch nicht verkompliziert würde, sondern eher sogar logischer wird. Schließlich kommen wir ja aus einer Programmvariante, in der durch „press pause“ die Wiedergabe ohne aufliegende Karte fortgesetzt wurde.
Deshalb bin ich ebenso an Meinungen aus der Community interessiert.
In diesem Zusammenhang möchte ich aber eine neue „Baustelle“ oder Frage aufmachen:
Tastendrücke, die (sinnvollerweise) zu keiner Aktion führen (das ist ja nicht nur die Pause-Taste, wie hier, sondern an anderen Stellen auch die Vor- / Zurück-Tasten) sollten m. M. nach zumindest mit einem Quittungs- / Misserfolgston bestätigt werden. Könnte mir dazu ganz gut 260.mp3 aus dem Advert-Ordner vorstellen.
Was meinen die anderen dazu und @Boerge1 wäre das ggf. mit vertretbarem Aufwand machbar?
Danke für den „Stups“ an @Gute_Laune , für die Vor- / Zurück-Tasten ist das schon seit einem Dezember-Release eingebaut (peinlich: auch noch auf meine eigene Anregung hin 
)
Es war eine Idee, ich glaube aber es wurde nicht umgesetzt.
Ich werde das mal versuchen. Ich weiß auch noch nicht, ob das wirklich sinnvoll ist. Mal sehen, wie sich das dann anfühlt. Auf jeden Fall wird das ein optionales Feature.
@NoBl Ok, dann versucht mal den Branch issue_195. Da ist der negative Quittungs-Ton (und natürlich obige Änderung) implementiert.
Nicht vergessen: es ist eine neue Datei im advert Ordner dazugekommen.
Das Feature muss in der Datei constants.hpp aktiviert werden (#define NEGATIVE_NOTIFICATION)
Wenn der letzte Track erreicht ist und man drückt die Vor-Taste, kommt kein Quittungs-Ton (obwohl nichts passiert). Das würde zu viel Aufwand und Änderung im Code erfordern. Ist vielleicht auch gar nicht erwünscht.
@Boerge1 , Ich habe gerade issue_195 geladen und angetestet.
Da funktioniert (bei mir) einiges nicht mehr, was schon in issue_188 ganz OK war:
Falls erforderlich, hier ein Log der Konsolenausgabe:
_____ _____ _____ _____ _____
|_ _|___ ___| | | | | | |
| | | . | | | |- -| | | | | |
|_| |___|_|_|_____|_____|_|___|_____|
TonUINO Version 3.1 - refactored by Boerge1
created by Thorsten Voß and licensed under GNU/GPL.
Information and contribution at https://tonuino.de.
V3.1.7 12.04.24
Ver:2
Vol:25 1 10 25 5 15
EQ:6
ST:0
IB:1
AL:0
AP:1111
PCR:1
MFRC522:146
Volume: 10
enter Idle
Command: 6
enqueue mp3 262 0
play mp3 262
Card Inserted
CardData: 31 73 3b 74 02 05 03 00 00
enter StartPlay
enqueue mp3 262 0
play mp3 262
153 tr in folder 5
enqueue 5-1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153
shuffled 57 45 12 92 126 99 73 121 76 33 31 36 5 139 23 10 105 134 53 78 147 104 20 79 41 77 145 93 89 94 64 111 124 11 85 128 40 1 87 16 44 127 47 152 146 106 80 68 82 30 54 37 34 67 91 97 137 3 143 69 83 123 22 150 24 112 29 144 125 75 65 96 109 43 15 38 50 90 19 52 118 48 141 132 122 28 103 110 58 98 131 42 107 149 9 62 114 153 108 26 115 140 151 136 113 35 66 81 27 84 13 116 59 7 102 56 133 71 55 51 130 119 4 17 95 18 32 70 117 25 129 138 74 49 63 60 86 2 46 21 135 148 8 14 6 39 72 88 142 100 120 101 61
play 5-57
enter Play
Command: 7
enter Pause
Command: 11
play adv: 263
Command: 11
play adv: 263
Command: 7
enter Play
Command: 14
play 5-45
Command: 7
enter Pause
Command: 11
play adv: 263
Command: 11
play adv: 263
Command: 7
enter Play
Command: 9
Volume: 11
Command: 10
Volume: 10
Command: 10
Volume: 9
Card Removed
enter Pause
Command: 7
play adv: 263
Command: 11
play adv: 263
Command: 11
play adv: 263
Command: 7
play adv: 263
Card Inserted
CardData: 31 73 3b 74 02 05 03 00 00
enter Play
Command: 7
enter Pause
Command: 7
enter Play
Command: 9
Volume: 10
Command: 14
play 5-12
Command: 7
enter Pause
Du hast den langsamen Player? Dann liegt es daran. Es ist nämlich nicht so einfach einen Advertise Track abzuspielen, wenn gerade nichts läuft. Du kannst dir ja mal den Code in mp3.cpp anschauen. Da muss zuerst ein Track gestartet werden, wenn der dann auch läuft, kann der Adv Track gestartet werden. Wenn der dann fertig ist, muss noch gewartet werden, bis der oben gestartete Track wieder läuft um dann wieder in Pause zu gehen. Wenn der Player da zu lange braucht, kommt der Algorithmus aus dem Tritt. Außerdem macht ein Quittungston keinen Sinn, wenn er 4 Sekunden später erst kommt.
Du brauchst also einen anderen Player dazu.