Naja, ich finde das aktuell schon praktischer, wenn man die Folge da weiter hören kann, wo man Pause gemacht hat. Mein kleiner wird im Dez. 3 Jahre und ich finde er hat aktuell noch nicht so das durchhalte Vermögen, die Folgen in einem Stück durch zu hören.
Kann natürlich auch ganz anders sein und will die Folgen immer von vorne hören. Dann könnte ich z.B. Spezialmodus von-bis Album nutzen!?!
Ja, genau. So ist er gedacht.
Ich Speicher in meinem Fork tatsächlich den Fortschritt auf dem EEPROM.
Auf der Karte ist nur der Speicherplatz hinterlegt.
Sonst müsste die Karte immer aufgelegt bleiben.
Du kannst meinen Fork doch einfach mal testen und hinterher immer noch aufs Original zurück.
Da passiert nix.
Falls es Probleme gibt, bitte melden.
Ein portieren der Funktion ins Original wäre sehr aufwendig.
na ich überlege mir das nochmal. Wie heißt s so schön? Never touch a running system…
Ich arbeite mich auch gerade in das Excel Tool ein zum Erstellen der Karten: Exceltool - Verwaltung MP3s/RFID-Karten für Tonuino: SD-Karte erstellen / Übersicht der MP3s / RFID-Karten automatisiert beschreiben
Das würde dann gar nicht funktionieren mit deinem Fork oder? Oder ich müsste alles z.b. als Album von-bis erstellen und dann im Tool erst den Modus nochmal anpassen?!
Ich glaub ich arbeite erstmal mit dem was ich jetzt habe. Vielleicht findet mein Kleiner das Hörspiel auch nicht so toll und ich mach mir die ganze Arbeit umsonst … !!!
So direkt wird der Spezialmodus nicht unterstützt. Sollte sich aber einfach integrieren lassen, sofern man die Nummer für den Modus kennt(@marco-117 ?) . Alle momentan definierten RFID Karten müssten halt entsprechend überarbeitet werden. Geht dann aber auch sehr schnell (Änderung in der Tabelle). Wenn es soweit sein sollte, dann können wir ja nochmals schreiben.
Wenn @marco-117 ansonsten die Modi nicht geändert hat, dann kannst das Tool weiterhin nutzen. Das alles bezieht sich jetzt nur auf die RFID-Kartenverwaltung.
Die SD-Karte kannst du so oder so erstellen mit dem Exceltool.
Ich weiß die Nummer des Modus gerade nicht Auswendig, muss ich heute Abend mal schauen.
Wenn ihr es aber eilig habt schaut mal in meinen Code. Es gibt ein Enum mit den Modis. Da sind alle Nummern überischtlich hinterlegt.
Wie eilig es ist hängt von @Fletch ab 
aktuell hab ich ich es noch nicht eilig 
Die Kiste wird erst in einem Monat an den kleinen übergeben
Egal 
Habe dir die Datei mal abgeändert. Neuer Modus ist nun drin.
Bekannter Link für das Exceltool, im Ordner „Marcos Fork“.
@Fletch Du kannst dann deine bisherige Exceldatei natürlich in die neue Datei importieren. Bei Fragen einfach melden.
3 „Gefällt mir“
Heißt das dein Exceltool ist kompatibel mit meinem Fork?
DANKE
Ich würde den Link mit in meine Forkbeschreibung aufnehmen wenn das in Ordnung ist.
2 „Gefällt mir“
Ja, die verlinkte ist es. Zumindest was den Hörbuchmodus von bis anbelangt. Du hast ja auch noch andere Modi, oder?
Wenn diese identisch aufgebaut sind, dann können die auch einfach ins Kartenmanagement nachgetragen werden.
Mein offizielles Exceltool hat da noch falsche Grenzen drin, was zu einem Fehler beim Definieren der RFID Karten führt, wenn ein neuer Modus ausgewählt ist. Werde ich aber bei Gelegenheit ändern.
Ja, klar.
Hier ein vorerst unbegrenzter Link:
https://1drv.ms/u/s!Aqg2Q3UHE2kivDJ-cBCyJ6t7y2EY?e=IRJv2l
Bez. des ursprünglichen Problems dieses Themas hätte ich eine Idee:
Dabei wird der Fortschritt weiterhin nur im EEPROM und nicht auf der RFID oder der SD Karte gespeichert.
Bisher ist es (wenn ich es richtig verstanden habe) so:
- für jeden (1-99) Ordner wird ein eigener Fortschritt (1 Titelnummer = 1 Byte) gespeichert (=99Bytes).
Das scheitert, wie geschrieben, für alle Spezialmodi - wobei der Hörbuch Modus der einzige ist, der sich den Fortschritt merkt - die anderen interessiert das ja nicht.
Lösung:
- Nummer für aktuellen Titel zum Speichern des Fortschritts (wie bisher)
- zur Identifikation:
- Nummern für Ordner + Starttitel + Endtitel zur Identifikation
- Alternativ kann man auch die RFID/UUID der Karte nutzen
- Aber das erfordert
- mehr Speicher: 8? Bytes für die UUID statt 3 Bytes (Ordner, Start, Ende)
- das Auflegen der Karte zu Beginn bzw. zusätzliche Speichern der letzten Musikkarten UUID
- Aber das erfordert
Problem:
- Da ein Ordner mehrere Spezial-Modi Konfigurationen enthalten kann, d.h. die Anzahl an Konfigurationen für einen Ordner nicht definiert ist (bisher galt 1 Konfiguration pro Ordner), muss die Ordner-Nummer ebenfalls gespeichert werden (bisher war die Ordner-Nummer = Index-Position des Bytes).
Folgen:
- Statt 1 braucht die neue Variante also 4 Bytes pro Datensatz.
- Mit der UUID Alternative wären es 9 Bytes
- Außerdem sind nicht nur 99, sondern realistisch (10 Titel pro Album) bis zu ~25 * 99 = 2475 Kombinationen zu speichern.
- Mit der UUID Alternative wären es so viele wie Karten im Umlauf sind (i.d.R. <1000?)
- Statt 99 Bytes braucht die neue Variante also 2475 * 4 = 9900 Bytes
- Die UUID Alternative 9 * 1000 = 9000 Bytes
Da ich nicht weiß, wie viel Speicher der EEPROM hergibt, gibt es 2 Varianten:
Variante A
- Man nutzt die o.g. Variante und braucht 9900 bzw. 9000 Bytes im EEPROM
Vairante B
- Man speichert den Fortschritt nicht für alle Ordner (oder alle/1000 UUIDs) sondern nur die letzten 10 oder 20.
- Realistisch betrachtet fängt man doch keine 10 oder 20 Alben gleichzeitig an
- Und erinnert sich obendrein noch für jeden, was bisher passiert ist
- Damit man noch weiß, welches der letzte Datensatz war, braucht es noch 1 Byte für einen Index
- Damit nutzt man 20 * 4 + 1 = 81 Bytes
- Die UUID Alternative wäre bei 20 * 9 + 1 = 181 Bytes
Mir persönlich gefällt Variante B besser, weil
- ich nicht den Fortschritt für jede Konfiguration brauche
- ich habe keine 100+ Hörbücher und würde mich auch nicht an jeden Fortschritt erinnern
- ich nicht für jede Konfiguration den Speicher im EEPROM dafür vorhalten muss
- Es gibt ja auch Ordner die keine Hörbücher enthalten und daher nie einen Fortschritt speichern müssen
just my 2 cents
Genau. Und die Position im EEPROM ist die Ordnernummer. So gibt es eine feste Zuordnung und es ist kein komplexes Management nötig um rauszufinden was wo liegt und ob noch „Slots“ frei sind. Kann man natürlich alles machen, aber aktuell ist der Ansatz eben keep it simple stupid.
Beim Arduino insgesamt 1024 Byte. Beim LGT 1022 Byte (aktuell die Hälfte, weil Bug im Board Support Package). Da gehen noch die Settings runter (was allerdings nur ein paar Byte sind) und ich würde jetzt auch nicht das ganze EEPROM zum speichern vom Hörbuchmodus nutzen…
Du musst ja den Modus gar nicht abspeichern.
Der Modus ergibt sich über die Karte, die du gerade drauf legst.
Der Ordner ergibt sich aus der Adresse.
Auf der Karte ist der Speicherplatz des Ordners abgelegt.
So kann ich bei angegebenen Speicherplatz auf der Karte den entsprechende Slot im EEPROM abfragen und habe den Track.
Man muss für sich nur organisieren welcher der Speicherplätze pro Ordner für was verwendet wird.
So kann man jedem Modifier (ausnahme Party, wegen der Random Queue) einen Speicherplatz geben.
Der Albummodus hat bei mir im Fork auch die Möglichkeit zur Speicherung bekommen.
Mir fällt auf, dass es auch bei keinem anderen Modus mehr Sinn ergibt, eine Speichermöglichkeit zu ergänzen.
Es sind übrigens 8 Speicherplätze pro Ordner möglich bei 1024bytes. Das ist debke ich mehr als ausreichend.
Danke für die Info.
Also könnte man maximal 255x 4 Bytes Datensätze und das nötige Index-Byte speichern. (die Settings-Bytes mal außen vor gelassen).
Das sehe ich auch so.
Daher die Idee, es auf die letzten 10 oder 20 Hörbücher zu beschränken.
Habe ich auch nicht.
Mein präferierter Vorschlag speichert nur die Nummern von Ordner, Start- und Endtitel.
Genau.
Zudem ist er erst beim Abspielen relevant.
Für das Speichern und Auslesen des Fortschritts braucht man ihn ja nicht.
Du meinst immer noch die RFID- und nicht die SD-Karte, richtig?
Meinst du den normalen Musik-Ordner, der ohnehin mit jeder Konfiguration auf der RFID-Karte gespeichert wird oder einen zusätzlich gespeicherten Fortschritt-EEPROM-Speicherslot/Ordner?
Das verstehe ich nicht ganz.
Es wird doch jeder Speicherplatz fest mit dem Ordner der Musikkarte verknüpft.
Ein zu organisierendes Problem habe ich erst / nur dann, wenn ich zwei (Hörbuch-)Karten habe, die den gleichen Ordner verwenden … Dann wird der Fortschritt der ersten (Hörbuch-)Karte durch die zweite (Hörbuch-)Karte überschrieben. Das Problem könnte ich verringern, indem ich meine Hörbücher auf alle Ordner verteile und nicht 2 Hörbücher in einen Ordner packe.
Meintest du das mit organisieren?
- Edit:
Ich glaube du beziehst dich auf deine Special3 und Special4 Daten, die du mit auf die RFID-Karte schreibst, richtig?
Also dass ich beim Konfigurieren der Karte einen Musik-Ordner angebe (wie bisher) und zusätzlich einen Hörbuch-EEPROM-Speicherplatz/Ordner als Special3 bzw. Special4 ?!
Dann müsste ich mir organisieren, dass meine Hörbücher keinen Ordner als Special3/4 doppelt belegen. Meintest du das mit organisieren? - Edit-Ende
Das verstehe ich noch weniger, sry.
Modifier?!
- Edit:
Meinstest du das hier?
Ich habe in deinem Thema gerade gelesen:
- Den Stand deines Forks habe ich noch nicht ganz gelesen, sry.
Edit-Ende
.
Also ist dann: Album = Hörbuch, oder unterscheiden sich die Modi noch in anderen Punkten?
Der aktuelle Ansatz braucht doch 99 Bytes (1 Speicherplatz pro Ordner, bei 99 Ordnern), also wären bei 1024 Bytes doch bis zu 10 Speicherplätze (990 Bytes von 1024) möglich, oder habe ich wieder was übersehen?
Mein Vorschlag ist die o.g. Variante B.
Damit funktioniert der Spezial-Modus für mehrere Hörbücher in einem Ordner mit nur 81 Bytes Speicherbelegung im EEPROM.
Man muss nur die Start- und Endtitel mit denen der aufgelegten Karte vergleichen, um den jeweiligen Fortschritt zu laden.
- Wahrscheinlich würde sogar der Starttitel reichen, was dann nur 20 * 3 + 1 = 61 Bytes bräuchte.
Beim Speichern müsste man die „Fortschritts-Queue“ noch neu sortieren, wenn ein alter Fortschritt für eine Karte durch einen neuen Fortschritt ersetzt wird. Aber das ist auch kein Hexenwerk (zwischen liegende Bytes um 4 Stellen verschieben, neuen Datensatz hinten dran).
- Edit:
Da fällt mir auf, dann braucht man auch kein Index-Byte.
Die Reihenfolge der letzten Hörbücher ergibt sich dann einfach aus der Reihenfolge der Bytes.
FIFO (first in, first out) mäßig.
Ah sorry, ich habe Modifier geschrieben, meinte aber Modus. Also den Abspielmodus.
Ich habe einfach 8 mal 99 Speicherplätze reserviert.
sodass man für jeden Ordner 8 Track speichern kann.
Es gingen auch bestimmt 9 mal 99, aber bei 10 ist kein Platz mehr für die Settings. Ein wenig Puffer ist nie verkehrt.
Auf der RFID Karte gebe ich an welcher dieser 8 Speichereinträge ich benutzen will.
Wie du schon richtig erkannt hast, muss das organisiert werden, damit man einen Stand nicht überschreibt.
Die Idee dahinter ist, dass man eben mehr als 99 Hörbücher haben kann und auch Hörbuchreihen besser strukturieren, indem man sie in einen Ordner speichert. Deshalb habe ich auch den Hörbuch von bis Modus in meinem Fork integriert.
Auch können mit den 8 Speichern mehrere Personen einen eigenen Stand des selben Hörbuchs haben.
Der Albummodus mit Speicher unterscheidet sich darin, dass ich nicht den zuletzt gehörten Track beim wiederaufnehmen des Albums erneut abspiele, sondern den danach. Das war ein Wunsch eines Nutzers, der die Hörbertfunktion nachbauen wollte. Diese spielt bei erneutem Druck auf die Taste für das Album, den nächsten Track.
Ich habe das etwas umständlich gelöst um die Funktion allgemeiner zu halten.
Außerdem endet ein Hörbuch nach dem letzten Track. Erst durch wieder auflegen der Karte startet es neu. Beim Album reicht der Next Button. Es gibt denke ich auch Unterschiede bei next und previous Track.
Grob kann man sagen das ein Album in Schleife gehört werden kann, ein Hörbuch nicht.
Der EEPROM wird doch eigentlich für nichts verwendet außer ein paar Settings.
Also kann man ihn doch auch zu großen Teilen für Hörbücher/Fortschritte reservieren.
Ich gebe dir Recht, dass man nicht 99x8 Hörbücher hört, selbst wenn es mehrere Personen im Haushalt gibt. Ich gehe auch nicht davon aus das jeder Ordner mit Speicher verwendet wird. Aber ich muss annehmen, dass nicht jeder Nutzer bspw. Ordner Nr 10 mit Hörbücher füllt sondern auch Ordner Nr 2 oder Nr 99. Das einfachste war es, jedem Ordner Platz im EEPROM zu geben.
Dein Ansatz ist eleganter und dynamischer. Man muss sich nicht um die Organisation der Speicher pro Ordner kümmern und kann den Kompromiss eingehen nur eine Gesamtzahl Speicherplätze vor zu geben mit dem Effekt den EEPROM nicht bis zum Anschlag zu füllen und man merkt effektiv nichts von den Einschränkungen.
Aber was ist, wenn man doch mehr als 20 Plätze braucht und man versucht Nr 21 zu beschreiben.
Einfach den ältesten Eintrag löschen?
Eine Abfrage einbauen?
Woher weiß man was der Speicher enthält um als Nutzer zu entscheiden, dass der Speicher gelöscht werden kann?
Dann müsste man die Möglichkeit schaffen die Speicherplätze durch zu gehen, um zu Entscheiden welcher überschrieben wird. Wenn die UUIDs abgelegt sind, ist das sinnlos, weil sie keinen Bezug zum Inhalt haben.
Dein Ansatz Ordner, Start- und Endtitel im EEPROM zu speichern hat den Nachteil, dass man nur eine Karte haben kann für den selben Titelbereich. Zwei Personen können dann nicht das selbe Hörbuch mit ihrem eignen Fortschritt hören.
Ein anderes „Problem“ sind die UUIDs. Was ist, wenn eine Karte verloren gegangen ist? Dann habe eine „Leiche“ im Speicher liegen, die erst Überschrieben wird, wenn sie an der Reihe ist. Und ich muss das Hörbuch von vorne beginnen bzw. meinen Stand manuell suchen.
Ein weitere Punkt wäre, das ich ja festhalten muss, wie die Reihenfolge der Einträge ist.
Folgender Fall:
Ich höre mein erstes Hörbuch bis zur Hälfte. Aus Gründen werden, bis ich Hörbuch eins weiter hören kann, 19 weitere Hörbücher angefangen.
Jetzt will ich das erste Hörbuch weiter hören. Hier muss ich doch jetzt festlegen, das diese Hörbuch nicht das älteste, sondern das neueste ist. Wenn ich das nicht mache, wird es mir unter umständen überschrieben, weil jemand Hörbuch 21 anfängt. Das erste Hörbuch ist aber wieder mein aktuell gehörtes.
Das hat doch zur Folge, das ich die Speicher in ihrer Reihenfolge immer wieder umorganisieren muss.
Und jeder Eintrag der dazu kommt oder wieder aufgenommen wird sorgt dafür das die Reihenfolge aller Einträge neu Festgelegt werden muss.
Als prove of concept ist das sicher eine interessante Aufgabe mit Herausforderung, aber ich finde das zu Aufwändig für den TonUINO, vor allem mit dem Aspekt, dass es eigentlich genug Speicher im EEPROM gibt für die statische Lösung. Das handling der Speicherplätze lagre ich auf den Nutzer aus.
@marco-117 wieso speicherst du den aktuellen Stand des Hörbuchs nicht auf der RFID-Karte selbst?
Die Idee hatte ich auch schon.
Das ist aber nur möglich, wenn die Karte auf der Box liegen bleibt. Man müsste also die „stop when card away“ Funktion aktiv haben, damit das sicher funktioniert.
Das will nicht jeder.
Auch wieder wahr.
Bin nur von meinen Kindern ausgegangen. Die lassen die Karten prinzipiell auf den Tonuinos liegen (obwohl es die Funktion bzgl Stop wenn Karte weg nicht vorhanden ist).
Man kann sich überlegen bei aktiver stop when card away Option den Fortschritt auf der Karte zu speichern. In meinem Fork kann man diese Option aber zur Laufzeit ändern. Ich müsste dann EEPROM und Kartenspeicher gleichzeitig implementieren. Außerdem müsste man bei erneuter Deaktivierung der Option, den Speicher auf der Karte wieder in den EEPROM kopieren.
Man könnte aber eine Hybridversion erstellen. Man könnte den Fortschritt auf die Karte speichern, wenn diese aufliegt. Wenn nicht, könnte man den Fortschritt im EEPROM lagern, bis die Karte wieder verfügbar ist. Dann kann man @Bastelmatz Lösung mit den UUID aufgreifen. Leider mit der gleichen Einschränkung bei Verlust der Karte.
Das würde aber das Problem des Überschreiben lösen und man könnte die zeitliche Reihenfolge der Speichereinträge im EEPROM eher außer acht lassen.
Edit: Das würde einen Unendlichen Vorrat an Hörbuchspeichern generieren!!