So, bin mit den Audio-Issues nochmal weitergekommen. War bei mir direkt mit dem aktuellen Dev-wieder so, dass es die Audio-Artefakte gab (super langsame / stotternde Wiedergabe).
Dieses mal waren die Änderungen am loop-Task irrevelvant und auch eine höhere Prio des Audio-Tasks hat nichts gebracht.
Folgende Dinge habe ich festgestellt:
Wenn man die Ques im Audio-Task nur minimal warten lässt, verstärkt sich das Problem um ein vielfaches
der call audio->loop() verträgt scheinbar keine verzögerungen mehr
Nachdem ich den audio->loop() call in einen separaten Task gepackt habe, der nur diesen Call beinhaltet, und den Rest in der Prio reduziert, läuft der Ton bei mir wieder normal. Kann es eventuell sein, dass die audio->loop() immer hungriger und intoleranter gegenüber delay geworden ist?
Bin der Meinung wir müssen hier was tun, weiß nur nicht was die beste Lösung ist…
Muss diese ganze Sache auch noch evaluieren. Das letzte Mal hat es auch nach was anderem ausgesehen, dass es offensichtlich aber nicht war
Update: tatsächlich bringt das nur was in Kombination mit Änderungen in der main-loop, wenn dort die Gesamtlast reduziert wird… Super stange das ganze…
Update2: wenn man den TCP-Async-Task auf Core 0 schiebt, ist das Phänomen ebenfalls deutlich schwächer / die Situation besser…
Nach dem Laden der Weboberfläche ist der Root vorausgewählt um die verwirrende Meldung „Wähle den Ordner für den Upload!“ zu vermeiden
Kritische Batteriespannung für’s Abschalten kann in der Weboberfläche eingestellt werden
Bugfix 1: DONT_ACCEPT_SAME_RFID_TWICE_ENABLE and web frontend
Erweitertes Task-Debugging. /stats enthält jetzt Infos über freien Heapspeicher und die Überschriften der Taskauflistung.
Ein neuer Endpunkt /debug der diese Infos als JSON zurückibt.
Kommando PRINT_TASK_STATS zur Ausgabe im seriellen Monitor
Anzeige der zugewiesenen RFID-Tag ist nicht mehr abgeschnitten nach ca. 60 Einträgen / 8KB
Neuer Endpunkt /rfid/ids-only liefert nur die gespeicherten Tag-Namen zurück ohne Details.
Bei Webstreams wird das Stationslogo angezeigt sofern verfügbar.
Bei Webstreams wird der Füllpuffer angezeugt.
Bei Webstream Dropouts erscheint Toast.Meldung „Langsamer Stream, Aussetzer möglich.“
Auslieferung des Coverbildes: Chunkgröße aus Stabilitätsgründen auf 1024 Bytes beschränkt. Hier gibt es noch einen alternativen Vorschlag
Der gesetzte Wert wird jedoch nicht abgespeichert. D.h. nach dem Neustart ist der alte Wert (2) wieder da.
Hinweis: SHUTDOWN_ON_BAT_CRITICAL habe ich nicht aktiv.
Hat jemand das Problem, dass der Fortschritt nicht gespeichert wird ? Ich wundere mich die ganze Zeit warum ich immer wieder die selbe Folge hören muss
Ja, im Hörbuchmodus wird derzeit keine neue Position mehr gespeichert und folglich immer die alte geladen. Du kannst den Commit mal ausprobieren (aus dem letzten Link von biologist) und bestätigen, ob dann wieder alles funktioniert:
Ich habe es jetzt nur schnell testen können, ob es nach dem Ausschalten geht. Dies kann ich bestätigen. Mit Modifikation konnte ich es jetzt auf die schnelle nicht testen. Vielleicht hilft das aber schon mal ?!
Habe ich gemacht. Es war aber der erste, den ich jemals erstellt habe. Hoffe das passt so. Weitere Bestätigungen, dass das damit läuft und v.a. keine anderen Fehler eingeführt werden wären natürlich hilfreich.
Behebt das auch, dass der endlos-Modus nicht mehr funktioniert? Also z.B. „sortiert endlos“? Der beendet die Wiedergabe aktuell einfach am Ende der Playlist.
Habe das gerade erst auf dem Stand davor festgestellt und noch nicht den neusten dev-brach testen können…
Erst mal schönes neues Jahr und danke für eure Arbeit. Ich habe gerade den aktuellen DEV Branch installiert. Mir ist aufgefallen, das, wenn die Lautstärke im Webinterface über die max. Lautstärke, die über allgemein als Max festgelegt wurde, angehoben wird. Lässt sich die Lautstärke nicht mehr über den Drehencoder regeln. Kann das jemand nachstellen?
Gruß Joachim
Ich habe da mal ein bisschen rumgetestet. Und dabei sind mir zwei Sachen aufgefallen:
getFilePos() liefert an dieser Stelle 0 zurück, was dazu führt, dass im Logging eine 0 steht, die Startposition tatsächlich jedoch eine andere ist. Ich schlage vor, dass wir einfach den Inhalt aus gPlayProperties.startAtFilePos nehmen. Ich weiß wir hatten das damals anders gemacht, weil die tatsächliche Abspielposition eine leicht andere sein könnte. Allerdings müsste die Position, die abspeichert wird, auch immer als Startpunkt taugen. Sie taugt vermutlich nur dann nicht, wenn jemand manuell dort einen Wert in Bytes einträgt, an einer Stelle, wo sich kein syncword befindet. Wenn man das so übernimmt, dann darf das Nullsetzen von gPlayProperties.startAtFilePos aber natürlich erst nach dem Logging erfolgen .
Wenn man ein solches „Recover“ startet, dann steht (nach meinem Fix) die korrekte Abspielposition im Log, der Abspielvorgang startet passend und auch der Fortschrittsbalken im Webinterface ist korrekt. Was jedoch nicht passt: Der Timer, der zum Fortschrittsbalken gehört. Weil der startet immer wieder bei 0.
Die wird jetzt auf jeden Fall ausgeblendet, wenn das Feature nicht aktiviert wurde .
.