neues modul sonosBookmarker

[justme1968]

leider merken sich die sonos player die aktuelle wiedergabe postion nicht wenn man zwischen titeln wechselt. das ist besonders bei hörbüchern oder podcasts ziemlich nervig.

anbei eine erste version eines moduls das versucht dieses problem zu beheben...

die idee dahinter ist sich für titel die bestimmte kriterien erfüllen die aktuelle position zu merken und sobald dieser titel wieder abgespielt wird diese position direkt anzuspringen. das ganze funktioniert auch player übergeifend. d.h. man kann auf einem player anfangen und zu einem anderen zeitpunkt auf einem ganz anderen player weiter hören.

das modul merkt sich zur zeit die position für einzeltitel mit einer länge von mehr als 10 minuten oder für alben mit mehr als 25 titeln.

wenn das modul auf titel ebene arbeitet wie z.b. bei TuneIn podcasts gelten die bookmarks titelweise, bei alben gelten die bookmarks jewils für das komplette album. d.h. es wird auch der aktuelle track wieder angesprungen.

beide grenzen lassen sich über ein attribut ändern.

zur zeit ist nur ein einziges sonosBookmarker im system möglich.

Code Auswählen Erweitern

define sb sonosBookmarker TYPE=SONOSPLAYER

ideen für weiteren ausbau:
- nicht direkt an die gemerkte stelle springen sondern ein paar sekunden davor
- automatisches aufräumen zu ende gehörter titel
- automatisches aufräumen alter bookmarks
- ... ?

es gibt bestimmt noch eine reihe von fällen bei denen das modul noch nicht sinnvoll funktioniert oder bei dem es sogar misst macht. wenn man sich aber erst mal drann gewöhnt hat ist es sehr komfortabel nicht mehr zu suchen wo man zuletzt aufgehört hat zu hören sondern es einfach automatisch stimmt.

eventuell wäre eine 'engere' integration in das sonos modul für die performance besser? die heuristik zum merken und wieder herstellen wäre dann vielleicht auch etwas einfacher?

gruss
  andre

[Reinerlein]

Hi Andre,

schöne Idee. Das gehört ja eigentlich in die Sonos-Firmware

Zu einer engeren Verzahnung mit dem Sonos-Modul:
Der SubProzess ist so aufgebaut, dass er nur wenige Informationen über einen Neustart hinweg benötigt, die dann vom Fhem-Teil beim Start geliefert werden.
Wieviele Elemente speicherst du denn so?

Man könnte natürlich relativ einfach eine Speicherdatei konfigurieren, in der dann diese Positionen in Textform gespeichert würden. Dann könnte man tatsächlich deutlich effizienter damit umgehen, da Fhem dann gar nicht damit belästigt werden würde (das bliebe dann ja alles im SubProzess).
Man könnte sich dann auch ein paar neue Befehle vorstellen, mit denen man solche "Bookmarks" benennen und zur Laufzeit anlegen lassen könnte. Diese könnte man dann mit anderen Befehlen auf einem (anderen) Player auch wiederherstellen...

Wie genau läuft denn deine Mechanik für das Erkennen, wann ein Position gespeichert werden muss? Beim Liedwechsel ist ja oben in Fhem etwas schwerer. Das ginge ja nur bei Stop o.ä... Im SubProzess könnte ich das vermitlich sogar beim Liedwechsel bewerkstelligen...
Und wann wird das wiederhergestellt? Beim Starten eines so gespeicherten Titels?
Tut mir leid, wenn ich hier Dinge Frage, die ja in deinem Code stehen... ich konnte diesen nur gerade nicht runterladen und lesen...

Ich könnte mir also eine integration gut vorstellen... allerdings wäre dann dein schönes Modul ja irgendwie überflüssig, was ja auch nicht mein Ziel ist...

Grüße
Reiner

[Loredo]

Sehr schöne Idee! Damit wäre ich einen Schritt näher Podcasts tatsächlich nativ über Sonos zu hören, statt es über eine iOS App per Airplay an Sonos zu streamen.
Allerdings bleibt noch ein wichtiges Kriterium, wo ich aber glaube, dass man/ihr das vermutlich nicht lösen könnt: Nämlich innerhalb einer Podcastfolge zu bestimmten Bookmarks zu springen, die dort enthalten sind. Denke das geht ohne dass dies in der Sonos App direkt unterstützt wird nicht, richtig?


Ich wollte es nur erwähnen für den Fall, dass ihr da gerade drüber nachdenkt und doch eine Lösung seht 




Gruß
Julian

[justme1968]

die logik schaut so aus:

das modul merkt sich für jedem player einen md5 hash des aktuellen titels.

- dieser hash ist index in die bookmarks. ein bookmark besteht aus titel im klartext (nur zum anzeigen) und position
  oder album track und position. es gibt ein get komamndo zum listen der vorhandenen bookmarks.

- wenn ein neuer titel auftaucht wird geschaut ob er länger als die eingestellte minimal dauer ist oder das album mehr als die eingestellte anzahl an titeln hat. wenn nein passiert nichts weiter, wenn ja wird ein bookmark erzeugt falls es noch keines gibt.

- wenn sich der aktuelle titel (bzw der md5 hash) ändert wird der bookmark aktualisiert.
   es gibt noch einen timer der mitläuft um die zeit seit dem starten zu bekommen auch wenn zwischendurch keine position
   vom sonos player gemeldet wurde. da ich mir den hash des letzten titels merke kann ich den bookmark auch setzen
   nach dem sich das currentTitle readingGeändert hat und ich eigentlich nicht mehr weiss wie der titel hieß.

- wenn sich der transportState auf pause bzw. stop ändert wird der bookmark aktualisiert

- wenn ein titel gestartet wird schaut das modul ob es eine bookmark gibt und springt die gespeicherte position an.
  entweder nur die position oder bei einem album titel und position.

- das ganze ist nicht an einen bestimmten player gebunden. d.h. du kannst auf einem player starten und anhalten und einfach den gleichen titel an einem anderen tag auf einem anderen player wieder starten. der bookmark wird gefunden und dann an die zuvor gemerkte stelle gesprungen.

zusätzlich oder statt des automatismus könnte man auch auf klick oder eine taste am player reagieren.

die anzahl der bookmarks ist zur zeit noch nicht beschränkt und es werden auch noch keine bookmarks automaitsch gelöscht. das sollte auf jedne fall passieren wenn ein titel 'normal' zu ende gespielt wird. also x sekunden vor gesamtspielzeit erreicht ist. eventuell auch konfigurierbar nach alter.

das speichern und wieder laden passiert einfach über serialisieren mir Data::Dumper und beim schreiben und eval bein zurück lesen. das ist völlig unabhänig von der fhem infrastruktur und kann auch direkt im subprozess passieren.

das ganze in das sonos modul zu integrieren hätte den vorteil den ganzen umweg durch zwei prozesse und drei module und den fhem event mechanismus zu vermeiden. zur zeit braucht es etwa 2-3 sekunden vom starten eines titels mit der sonos app bis zum setzen der bookmark position aus fhem. das ist zwar ok ober schneller wäre natürlich besser.

es auf fhem ebene zu haben hat den vorteil das alles was userinterface angeht natürlich einfacher ist. auch mehrere bookmark devices für unterschiedliche player wären so möglich. z.b. einer für die kinder hörbücher getrennt von allem anderen.

alles in allem denke ich es wäre näher integriert besser und auf dauer einfacher und stabiler.

module habe ich schon genug. wenn du es besser integrieren kannst nur zu. ich habe es ja extra schon unvollständig gepostet.

gruss
  andre

[justme1968]

@Loredo: das problem hatte ich noch nie da ich eigentlich immer von anfang an höre.

falls du die files lokal liegen hast könnte man das in den griff bekommen in dem man noch einen vorverarbeitungsschritt einbaut der die kapitel extrahiert und man dann in fhem darauf zugreifen kann.

ich weiss aber nicht wie handlich das wird. irgendwie muss du ja dann auch auswählen wohin du springen willst.

das merken der position und wieder herstellen ist völlig automatisch und braucht keine manuelle bedienung. sobald ein titel oder album startet wird an die bookmark position gesprungen. it's magic

gruss
andre

[Loredo]

Nee, ich spreche ja von Chapters, um ggf. eines überspringen zu können oder - falls man mal eingeschlafen sein sollte    - zum Anfang eines Kapitels zurück springen zu können, an das man sich noch nicht (oder nicht mehr) erinnert.
Sowas macht halt normal die Podcast Player App (Instacast, Podcat, u name it).


Ich wähle gar meine Podcasts danach aus, ob sie Chapters haben. Wer keine hat, muss schon sehr gute Gründe vorweisen können 

[Reinerlein]

Hi Andre,

danke für die Infos...

Ich könnte mir einen gemeinsame Verwaltung von diesen automatischen und manuellen Bookmarks mit demselben Mechanismus vorstellen.
Damit gäbe es dann Bokmarks die bei Erkennung des Titels dann automatisch angehüpft würden, und welche, die ich als Anwender per Befehl anspringen kann...
Und wenn es direkt im SubProzess abgehandelt würde, reden wir von Reaktionszeiten weit unter einer Sekunde beim Titelwechsel oder Transportstatewechsel.
Das kann man ja momentan schon bei der einstellbaren Maximallautstärke sehen. Das wird ja auch im SubProzess abgehandelt, und enthält kaum eine Verzögerung, wenn ich eine zu laute Lautstärke korrigieren lasse. Meistens ist der Verstärker des Players noch gar nicht lauter geworden, wenn das Modul schon wieder leiser gedreht hat...

Des Weiteren könnte man bei lokaler Verfügbarkeit von Dateien mittels einem externen Prozess/Systemaufruf sowas wie die Kapitel ermitteln lassen, und als manuelle Bookmarks eintragen lassen. Damit wäre vielleicht die Sache von Loredo mit möglich (sofern die PodCasts von lokal erreichbar sollten).
Man könnte eine Bookmarkfolge ja auch z.B. aufsteigend nummerieren (und vielleicht als Kapitel definieren) und dann der Oberfläche entsprechend als Kapitel anbieten (mit einem entsprechenden Befehl von Fhem aus verwendbar)...
Mal schauen, was mir da nettes einfällt

Ich würde mich da jetzt mal ranwagen, und die automatischen Bookmarks unter Berücksichtigung der manuellen umsetzen...
Wäre das für dich so OK?

Grüße
Reiner

[justme1968]

wie gesagt: nur zu

es ist im sonos modul sicher besser aufgehoben. meine version ist schon sehr hilfreich und man gewöhnt sich sehr schnell an den komfort.. die eingebaute wird sicher noch besser

gruß
  andre

[justme1968]

hallo reiner,

hast du schon etwas in richtung der automatischen bookmarks weiter gemacht?

gruss
  andre

ps: reine neugier und ungeduld. kein drängeln

[Reinerlein]

Hallo Andre,

ich bin tatsächlich leider noch gar nicht weit, da ich es schlichtweg auf meiner Liste übersehen habe. Danke für die Erinnerung

Aber ein paar Gedanken habe ich mir natürlich schon gemacht, und ich werde das jetzt auch angehen. Die anderen Themen sind ja jetzt erstmal durch...

Eine Frage is bei meinen Gedanken aufgekommen:
Stichwort: Bookmarks für Alben
Wie erkennst du ein Album, und wie soll ein Bookmark dazu gehandhabt werden?

Eine aktuelle Abspielliste hat ja leider keinerlei eindeutiges Kennzeichen. Man könnte jetzt die Titelanzahl verwenden, aber die ist ja nun wirklich nicht eindeutig.
Und das bei dem Abspiellistenkonzept jemand ein Album reintut, von dem er gar nicht alle Titel hören will gibt es ja auch nicht... (das ist ja sooo CD )
Das bedeutet ich kann auch nicht einfach die Albumangabe des (ersten oder aktuellen) Titels verwenden, da ja die restlichen Titel dieses Albums gar nicht in der Abspielliste sein müssen...

Kannst du mir da mal kurz auf die Sprünge helfen?
Danke schon mal...

Grüße
Reiner

[justme1968]

schau mal ganz oben da hatte ich das schon kurz beschrieben.

die entscheidung ob ein bookmark automatisch erzeugt bzw. wieder hergestellt werden soll hängt bei mir zur zeit an zwei kriterien:
- der titel ist länger als 10 minuten oder das album hat mehr als 25 titel. beide werte sind konfigurierbar.
- für fall 1 ist ein hash über den namen des titels der key für das bookmark und es wird sich die aktuelle position gemerkt
- für fall 2 ist es ein hash über den namen des albums und es wird sich der aktuelle titel und und die aktuelle Position gemerkt

fall 1 greift sehr gut für podcasts (auch über TuneIn) und hörbücher die als wenige grosse files vorliegen
fall 2 greift sehr gut für hörbücher die aus vielen kleinen files bestehen. das funktioniert auch wenn das album teil einer playlist ist

ob man den von dir angesprochenen fall auch voll automatisch abdecken will weiss ich nicht. beim musik hören höre ich eigentlich lieber von anfang an.

aber wenn du die komplette playlist kennst kannst du ja auch den hash über alle titel in der playlist erstellen. z.b. dann wenn die aktuelle liste titel aus unterschiedlichen alben enthält. ich hatte nicht rausgefunden wie ich an das genre des aktuellen titels komme. wenn man das hat kann man das natürlich in die entscheidung mit einfliessen lassen.

ein anderer ansatz wäre es in diesem fall mit dem laden der playlist zu verknüpfen. und dann das bookmark mit titel/position anzuspringen.

die automatisch bookmarks sollten so automatisch wie möglich arbeiten und 'einfach funktionieren'. ob es schlimmer ist das ein bookmark zu viel als zu wenig erstellt und verwendet wird hängt vermutlich von der verwendung und vom geschmack ab.  um das verhalten für musik festzulegen wäre es vielleicht gut sich das ganze ein paar szenarien durchzuspielen:

- hörbücher und podcasts -> ich denke da ist es relativ klar. immer am bookmark weiter spielen. zur not manuell auf anfang
- starten einer playlist -> ich würde sie von anfang an hören wollen
- ein album oder eine playlist läuft und wird pausiert, der radio wecker kommt dazwischen, irgendwie mit so wenig aufwand wie möglich an der alten stelle weiter hören
- in manchen fällen ist vielleicht auch das automatisch erzeugen aber nur manuell wieder herstellen das richtige
- ...


gruss
  andre

[justme1968]

willkommen zurück

ist dir inzwischen schon etwas dazu eingefallen?

leider passt deine variante noch nicht ganz auf meinen anwendungsfall. da sie aber sehr viel schneller reagiert als meine version würde ich sie ja gerne benutzen

gruss
  andre