webui-plus開発/サポート（webui-plus development/support)

---

バグ修正版の配信について

AoEのArch Linux版差替対応を行っていて、SYSTEMプラグインでのNAS設定関連の不具合が見つかりましたので、
差替版を配信いたしました。

ご迷惑をおかけし申し訳ございませんでした。

なお、当該版では「SAVE QUEUE」プラグインの最終版（プレイリストのアップロード対応）も同梱しています。

プレイリスト関連はこれで対応完了という形になります。

次のネタについて

全体的に全て手が入るまではちょっと時間がかかりそうですが、
以下の事項を行うことにしました。
「RaspberryPiでのympdデーモンのmpd通信タイミング調整」

現状のympdではｍｐｄとの通信状態確認と各端末へのステータス送信を以下の手順で実行しています。

１）ympdが起動すると無限ループで200ミリ秒（オプションの-iで指定した数値が200のため)でポーリングから覚めます。

２）ポーリングから覚めた際にtimeで現在時刻を取得し、前に処理を行った時間と差がある場合のみ３）の処理を行います（差がない場合はそのままスリープ）
→という訳で「大体1秒単位で以下の処理に進む」。

３）ympdとmpdサーバとの通信状態を確認します。
「切断済」の場合は接続処理を行い、「切断中」と「再接続要」の場合は「切断済」にステータスを変更します。
「接続中」の場合は４）の処理を行います。
「エラー」の場合は何もしません。

４）mpdサーバ内部でのステータスを取得し、ympdに接続中の全端末にその内容を電文で通知します。

電文には以下の項目が含まれています。
　現在のmpdの状態（再生中・停止中・一時停止中）
　音量数値
　Singleモードの状態
　Consumeモードの状態
　Repeatモードの状態
　Randomモードの状態
　再生曲のID（mpd内部ID）
　再生曲の経過時間
　再生曲の総時間
　（その他ビットレート等）

各利用者のWebブラウザではこの電文を受信した際にその情報を元に
カウンターや各モードのフラグの見え方を変化させているというわけです。

ちょっと見では「これで問題ない」ように見えますが（現状このように動いていますし）、
実は以下の改善が必要な事項があります。

①各端末でのカウンター表示が1秒単位では無いことがある
　これは楽曲再生のタイミングとステータス表示のタイミングがズレるためです。
　現状ympdから送信されるステータスはympdが起動して上記のステータス送信のループを回すタイミングに基づきます。
　利用者が再生ボタンを押したタイミングとympdでのステータス送信タイミングは当然同期していませんし、
　何らかの原因で2)の処理タイミングがズレた場合はステータス送信がずれ込みます。

②ympdとmpd間の通信の維持方法について
　今までは約1秒に1度ステータス通信のためにmpdに状態取得コマンドを送って通信を維持させる仕様でした(ちなみにタイムアウトは10秒）が、
　他の類似プロジェクトやドキュメントを見る限り、
「idleコマンドを送って常時は何もしないが接続を維持させ、状態変化を受けた際にidleを解除させて処理させる」のが本来の処理方法だと判明しました。
（この方法だともしかしたらympdのCPU使用率を軽減出来ないかという皮算用もあります）
　
という訳で、今後の改良としては以下の事項を実施します

①各端末での再生中楽曲のカウンター表示タイミング変更
　従来の電文によるステータスでカウンターを変更するのではなく、
　楽曲変更時（再生開始時）にカウンターを初期化させる。
　あとは端末内のタイマー処理でカウンターが変化

②各端末へのステータス送信のタイミング変更
　（「定時送信」→「イベント単位で非同期化」）
　これに伴い、各スイッチ操作後のレスポンスも改善出来る可能性があります。
③ympd〜mpd間通信のidleによる接続維持

②・③は恐らく一緒に書換えしないとダメでしょう。
次のリリース目標としては①は新年の早い段階で、②・③はちょっと時間を頂くかもしれません。
（先行で③の試作を行ったところ、コマンドを受け付けなくなった。）

カラーテーマ機能拡充について

先に次のネタと書いてあるmpdのidle対応についてですが、
手は動かし始めましたが結構難航しそうなので、
現実逃避でドキュメントを整備しようと考えていました。

その中で、「カラーテーマ」のプラグインについてまとまった文章を作ろうと思ったのですが、もしかしたら機能拡充の必要があるかとおもい、今回やってみようかなと思った次第です。

• カラーテーマのドキュメント構成（案）
  ①カラーテーマのスタイルファイル構成の説明
  ②新たなカラーテーマの作成方法
  ③プラグインへの反映方法

上記のうち、①・②は具体的なドキュメントを纏めれば良いのですが、
③については現状ちょっと面倒くさい手順
（スタイルシートを作成・編集してプラグインディレクトリに複写＋プラグインhtmlファイルのリスト部分を書換）
を踏む必要があるため、機能拡充が必要と判断したわけです。

• 追加予定の機能について
  最低限以下の機能を追加します。
  ①カラーテーマ用のスタイルシートを規定ディレクトリにファイルアップロード
  ②規定ディレクトリからカラーテーマ用のスタイルシートファイルを抽出してプラグインのリストに表示
  これにより、新しいカラーテーマのスタイルシートをwebuiからの操作だけで追加・選択まで一元的に管理出来るようになります。

• 実装後の展開について
  上記「カラーテーマ」用プラグインのドキュメントをほぼ同時に公開します（早ければ3日までには機能実装前の現状で先にドキュメントを纏めるかも）ので、
  その後に当該スレッドの下に「私の作ったカラーテーマ」を投稿頂けると良いのかなぁと思います。

@sunatomo さん

カラーテーマの機能が拡充されると楽しみがふえそうですね。好みのカラーテーマを作れるということでしょうか。

話は変わりますが、ライブラリの管理方法がはSMPDとArch Linuxでは異なるのでしょうか？
SMPDではtag_cacheだったと思うのですが、Arch Linuxの方はこれが見当たらないのでmpd.dbになったのかなと。
ライブラリのバックアップとレストアがArch Linuxでは反映されていないようなので、調べていて？？？になっています。

@hiroget9 さん

mpdのデータベース名は/etc/mpd.confで変更できます。

db_file                 "/var/lib/mpd/mpd.db"

これを以下のように編集していただけば、tag_cacheというファイル名にすることができます。

db_file                 "/var/lib/mpd/tag_cache"

smpd v1.0.xのmpd(0.22)とArch Linuxのmpd(0.22.3)はバージョンも近いのでデータベースも互換性があるはずです。

@hiroget9 さま
前から自由に作ることは出来ましたが、
現状の仕組だとちょっと面倒な部分があるため、
これを簡略化して使って頂ければと思いました。
（というか、今までドキュメント用意できていなかったのはこちらの手落ちですね。）

@パパリウス さま
レスありがとうございます。
Arch側の内部構造を解析できる余裕まだなかったので、
これから調べてみようと思っていました。

@パパリウス さん、さっそくありがとうございます。
謎が解けました(^_-)-☆

@sunatomo さん

私も複雑な方法より簡略な方が使いやすいと思います。

@パパリウス さん

mpdのデータベース名を変更してみました。
webuiのリストアでsmpdのmpdのデータベースを使えるようになりました。互換性ありますね。
これでsnpdとArch Linuxでデータベースを共用できますね。
ありがとうございました。
少し前にcantataでライブラリのアップができないという件がありましたが、原因はここだったのでしょうね。

現状の進捗について
「ympdデーモンのmpd通信タイミング調整」を先週末にちょっと集中的に行っていました。
現状はデバッグメッセージてんこ盛りですがｗｅｂブラウザからの操作電文に基づいて応答を返すところまでは進みました。

解析の結果として、既存のympd内部では以下の処理が行われていることがわかりました。

• メインループでmongoose（組込webサーバ）のポーリング制御（スリープ解除後にwebサーバで受信したhttpプロトコルのリクエスト処理を行い、またスリープに移行）を行っています。
  ポーリング間隔は標準では200ミリ秒（これはympd.serviceのパラメータで指定された値）です。

• webブラウザからwebsocketプロトコル経由で送信される電文はmongooseのコールバック関数より呼ばれ、
  処理後にwebsocketプロトコルで返信します。

• mpdとの通信状態はメインループで1秒以上の時間差があった場合のみ確認します。
  このときに通信が切れていた場合は再接続、致命的なエラーが発生していた場合は接続しません。
  また、確認の際にｍｐｄに接続状態ならば、mpdの状態を接続中の全クライアント（webブラウザ）に通知します。

ympdサーバがmpdとの接続を維持するためには、以下のどちらかで運用する必要があります。

• 常にタイムアウト時間より短い間隔で通信を継続する
  （現状のympdがこのやり方。約1秒単位でステータスを問い合わせする）

• mpdに対してidle命令を送って通信状態はサーバに維持させ、必要に応じてクライアントからidle解除の命令を送って電文処理を行い、処理終了後にまたidle命令でidle状態に戻す。

後者の場合、idle解除の命令のキックは以下の3つになります。

• webブラウザからwebcoketでmpd関連の命令が届いた場合
  実はidle状態の場合、mpdに対して「idle解除」以外の電文を送信しても処理はされません。
  このため、webブラウザから受信したmpd関連の電文は一度FIFOバッファに保存し、バッファにデータがあることを検知した段階でidle解除を行って電文を処理させる必要がありました。

• ympdサーバから各端末のwebブラウザにステータスを送る場合
  webブラウザ側でステータスを受信しないと、再生ボタンなどは機能しません。
  また、ステータスにはカウンターなどの情報があるため、再生中にプログレスバーが動作しません

• mpdから何らかのステータス変更を検知した場合
  idle状態にした際にフラグを立てることにより、そのフラグ条件に一致した際には通知するようになっています。
  現状のフラグ条件では「データベースの更新」・「キューの状態変更」・「再生状況の変更」・「リピート・コンシューム・ランダムなどのオプションの状態変更」などが受信できるようです。
  このときの通知があるかどうかはpoll関数で受けるため、ポーリングをループ処理する必要があります。
  ということはidleを使う場合はmpd処理部分を別スレッド化してループを回す必要があるということでした。

とりあえず手元のバージョンではmpd処理部分を50ミリ秒のpoll関数でループさせ、カウントが20回になった際はステータスをwebブラウザに送るように仕立てました。
ただし、カウンタについては前より値のバラツキ（2秒単位で更新する確立が高くなった）があること、
webブラウザからの電文を一旦FIFOバッファ格納するためにブラウザ操作→表示完了までのラグ（僅かな遅延）が見られるのが気になります。

カウンタのバラツキについては「ステータスを送るタイミングを従来の１秒間隔から0.5秒程度に増やす」か、「カウンタ値をミリ秒単位で取得して誤差を吸収させる」方法のどちらかで対応してみようと思います。

表示のラグについてはもう少し何とかしたいと思います。

最終的には今回開発したidle対応版で「ympd〜mpd間の通信の安定性」と「ympdの低負荷化により音質に優位性が確認出来た」かを皆さんにもお試しいただきたいと思いますので、もう少しお待ちくださいませ。

本日時点までの進捗について

①idleによるmpdの接続の改良（ペンディング）

UIのラグは私の実力では解消出来ませんでしたので元に戻すという結論に至りました。

利用しているクライアント端末の性能によって変化はあるかもしれませんが、
私のメイン使用環境であるPCベースの場合、既存のympdでは「ボタンクリックに対してラグがなく結果を返してくれます」。
これに対し試作版（mpd_idleを有効にするためにmpd対応処理を別スレッドにした場合）は、
「ボタンクリック後にその応答が返るまでにわずかにラグが出ます」。

恐らく、「元々idle版でずっと使用していた場合は違和感にを覚えない程度」だと思うくらいなのですが、webuiを今までお使い頂いた方にとっては恐らく違和感が顕著に感じると想定されますので、「現状でのリリースは難しい」と判断しました。

②再生カウンターのバラツキ解消

以下の点で改良を行っています。

• カウンター取得関数の変更
  現行では同カウンタ値をmpd_status_get_elapsed_time()関数で秒単位取得しています。
  この関数は現在のlibmpdclientのドキュメントでは「deplicated」扱いであることがわかったので、
  mpd_status_get_elapsed_ms()関数でミリ秒単位で取得するようにしました。

• カウンター取得タイミングの適切化
  従来はwhile無限ループ内で毎回time関数で現在時刻を取って前回のステータス取得時と1秒以上のラグがある場合にステータス取得を行う様に記述されていました。
  今回、pthreadのタイマーでステータス取得の関数を呼び出す仕様に変更しました。

正直、ここまでやっても端末側で得られるカウンター数値はバラツキがあるのが現状です。
特に通常のカウンター間隔を確認したのですが、何故か約740ミリ秒、
たまにその2倍が計測されるのため「なぜ？」というのが正直な感想ですね...

ちなみにpthreadのタイマー実装後に「ステータス取得関数の処理終了時にstderrにログ書込をさせ」、
jounalでタイムスタンプを確認した限りでは1秒間隔（誤差おおよそ1ミリ秒以下）で当該関数が間違いなく動作しているのですが...

個人的には最終手段になりますが「再生中に取得したカウンタ値が前回の値と同じならば＋１する」という処理を追加するしか無いかもしれません。
（これで問題ないかのテストは必要ですが）

再生カウンタの対応を行っていて、一つ大事なことに気づきました。
カウンタ左横の「プログレスバー」に関する問題です。

現状プログレスバーでは最小値0〜最大値100の間を表示＋取得可能な仕様のため、
楽曲のトータル時間が60秒を超えた場合、毎秒更新されなくなります。
（例えば10分=600秒の曲だと6秒に1回しかプログレスバーが動かない）。
また、上記のせいでドラッグ時の値が1%単位しか調整出来ません。
（10分の曲だと6秒単位のシークしか出来ない。）

プログレスバーの追加ライブラリ（bootstrap-slider)の最新仕様では
最大値に100以外の値を定義することが可能になっていますので、
ライブラリの差替後は毎秒更新＋シークの秒単位実現を可能にしたいと思います。

2020-01-17版のWebui-plus配信について

現状対応した内容について配信させて頂きます。

①変更点

• COLORプラグインの機能拡張
  従来からカラーテーマは自由に利用者が作ることが可能な仕組になっていましたが結構煩雑な手順が必要でした。
  今回、当該プラグインを拡張し、PC上などでダウンロード済みのスキンファイルをアップロードすることで選択可能な仕組を備えました。
  今後、みなさんがスキンを開発頂いてこちらのサイトなどに公開頂ければと思います。
• プラグインの一部UI変更
  　SAVE QUEUE・COLORでファイルアップロードの機能に関するUIを一部変更しましたので「FILE UPLOAD」もこれに合わせました。
  　（ファイル選択ボタンの配置を変えたのみ。機能は変更されておりません。）
• 再生カウンタ表示の最適化
  今までは再生カウンタの秒数が稀に毎秒更新されないことがありましたが、今回の対応でほぼ事例がなくなると想定されます。
  昨日の投稿の対応に加えて、以下の挙動をブラウザ側で行うように処理追加しました。
  ①RaspberryPiから転送されたミリ秒単位の再生カウンターを秒に切り捨て
  ②再生中の場合、前回伝送された再生カウンタ値と比較して同一値の場合は現在の値に+1秒追加
  ③補正した再生カウンタ値を表示

昨日の書き込みに記載したプログレスバーの修正は次回に対応します。
（差替予定の新バージョンのライブラリと現バージョンのライブラリの相違が多く、簡単な入換が無理だったため。）

また、AoE向けのArchの実行ファイル生成はこれからの作業となります。
まだ、Arch向けのパッケージ作成方法はわからないので、とりあえずZIPで実行ファイルとプラグインの差替ファイル提供となります。）

@sunatomo さま、UIの開発をありがとうございます。
今年中にアラフィフを卒業する私(>o<)は、普段使いのAndroidスマホでSMPDを操作する事が多いです。
言葉では上手く伝わらないと思い、YouTubeにアップしました。

https://youtu.be/TqsYgj9wBwI

内容は曲のタイトルが長い時、RAMの上のNASを選択したいのですが、上へタップすると最上部になってしまいます。

が、たった今解決しました！
(^o^)
元々スマホの設定で文字サイズを大きくしていたためにこのような現象になっており、文字サイズをデフォルトにしたらこのような現象は全く発生しなくなりました。
もしかしたら私と同様な現象でお困りの方がいたらと思い、謹んでお伝えいたしました。
これからも宜しくお願いいたします。
m(__)m

@toshi300 さま

現象確認しました。
クラシック等の比較的長い楽曲名の場合、
カバーアート領域が大幅に領域を取っているためにこの現象が顕著になりますよね。
次回の更新時には「スマホ向けのミニプレーヤーではカバーアートは表示しない」というのも選択肢として考えてみたいと思います。
（カバーアート見るならば、スワイプしてカバーアートモードを使って頂くとか）

という訳で、webuiについては私が使い始めた時点で「ある程度完成したUIである」こと、「私個人的にはデザインのセンスが無いこと」から
今後は皆さんの利用上のアイデアを元にした機能・デザイン改良がメインになっていくと思いますので、
ふとした疑問でも構いませんので、お申し出ください。

（ライブラリの更新としては組込webサーバのmongooseのバージョンアップかcivetwebへの切替、Bootstrapのバージョンアップが考えられますが、
どちらも一筋縄では行かない予感．．．）

@sunatomo さま、ご覧頂きありがとうございます。
悲しいかなLow-Ganにより、過去に大きくしていたのを忘れていました。
ブラウザやLINEなどアプリ毎に拡大出来ますし、私はこのままで大丈夫です。

現在の状況について
今の所、宿題は以下の2つが残っているのかなぁと思っています。
①楽曲再生プログレスバーでの楽曲秒数値への整合（現在は0〜100）
②ミニプレーヤでのスマートフォン等の低ピクセルサイズ端末でのカバーアート表示の取扱

「速やかに機能実装する必要のある項目が今のところはなさそう」というのと、
「ソースコードが建て増し旅館化してきた」ことから
リファクタリング＋内部の構造的な把握が更にしやすいような改良が必要と
判断して手を動かしています。

具体的には「元々のソースコードにも存在していなかったが、
今後を考えて関数他のコメントをdoxgen相当で埋め込む」という作業をまずは行っております。

コメントを入れると当然ながらソースコードのファイル容量は増えますが、実行プログラムのパフォーマンスの低下はありません。
（Cにせよ、JavaScriptにせよ、リリース時にはコンパイル・最小化によりコメント部分は実動作プログラムから消去されます。）

何より、コメントを記載している最中に「どのような挙動だったのかすぐには説明できない」関数がいくつか見つかっているという形で成果が見えています。
↑
本当は「あってはいけない」んですが

現在の状況について
doxygen（C向け)、JSDoc（JavaScript向け）に各関数にはコメントを入れ終わりましたが、
やはり諦めきれずにympdのidle化に関する再検証を行っていました。

結果としては「従来版よりパフォーマンスが低下するのは否めないため、変えないほうがよい」となりました。

前にも書きましたが、従来版とidle版の内部動作についてもう少し解説します。

従来版の挙動について

• ympdのメインループ内でmongoose（組込webサーバ）が200ミリ秒毎にポーリングでクライアントからのメッセージを受ける。
  （ポーリングのため、メッセージがなければただ待つだけです。
  メッセージがあればhttpならばコンテンツを返し、websocketの場合はmpd関連の処理をしてwebsocketでその結果を返します。）

• 同一ループ内で現在時刻を取り、前に処理した時刻と差がある場合のみmpd関連のポーリング処理を行います。
  ポーリングではmpdサーバとympdの接続状態に合わせて以下の処理を行います。
  　接続されていない場合は再接続処理を行って終了。
  　接続状態の場合は以下の2つを行います
  　　① 現在のmpdの通常ステータスを送信
  　　② ①で取得した通常ステータスと保存済みのステータスを比較し、
  　　　mpdでの状態変更を検知して送信
  　　　（検知する状態変更は「楽曲変更時にその楽曲の情報」もしくは「キューが改変された場合はその周知」の2つ）

「mpdのステータス」に含まれる情報

前項①で伝送される「mpdのステータス」には以下の情報が今までは含まれており、おおよそ1秒間隔で伝送されていました。

• 現在演奏中の楽曲のキュー内でのID
  これを元にプログレスバーのドラッグで当該楽曲のシークを提供

• データベース更新ID
  この値が正の場合、現在データベースは更新中であることを検知
  （ボリウムの左横のスピンアイコン）

• 再生楽曲の経過時間
  カウンター値やプログレスバーの表示

• 現在の状況（再生中・一時停止中・停止中）
  再生ボタンの状況を変更

• 再生楽曲の総時間
  これもカウンター値・プログレスバーの表示で使用

• ボリウム値
  ボリウムスライダでの現在値表示

• シングル＋リピート＋ランダム＋コンシューム
  纏めて記載しましたが、これら再生時の各モードの現状値

idle版対応開発の理由

以下の2つあります。
①現状の仕組だと通常ステータスの受信タイミング（1秒単位）でしか
　状態変更が検知できない。
　→idle対応した場合、idleマスクを設定することで条件が揃った場合は即検知出来る仕組があります。
　　しかも、libmpdclientの標準関数であるため、mpdから状態変更を取得するのに必要な情報は全て含まれています。
②mpdとの接続を継続させるには「通信しない場合はidleとする」仕様である。
　→結果としてmpdとの通信に関する不具合を減らすことが期待出来る。
（ympdのフォークであるmympdではlibmpdclientの開発も行っている経緯もあり、このidle対応が既にされています）

idle版の動作について

idle化するためにはおおよそ以下の対応が必要になります。

• mpd処理部分を別スレッド化する

• ympdのメインスレッドで受信したmpd関連の電文は一時的にキューに保存する。

• 別スレッドのmpd処理部分で従来の「mpd通信状態のポーリング」関数を以下の通り拡張する
  ①mpdとの再接続を行った場合、その後idleに移行
  ②mpdと接続状態の場合、「idleマスクによる状態変更検知」もしくは「キューにクライアントからの電文が存在」した場合はidleを解除して処理を行う。
  処理終了後、再度idleに移行

idle版の問題点について

普通に読んだ限りでは「idle版のほうが良さそうでない？」と思います（現にそう思って手を動かしました）が、以下の問題があり再度断念となりました。
①従来版とidle版を比較すると、ディレクトリ表示でラグが発生する。
　実はmpd通信状態のポーリング関数は50ミリ秒間隔で動作するように設定しています。
　しかしながら、このラグ50ミリ秒でもディレクトリ表示を行った場合に一瞬書換が見えるという結果になりました。
②idleマスクによる状態変更を使いこなせなかった。
　状態変更による通知量が増えたが対応の取捨選択がうまく行きませんでした。
③mpd関連を別スレッド化したことによる影響が不明であった。
（最後のこれはちょっと言い訳ぽいですね。
topコマンドではcpu使用率は増えていませんが...）

長くなったので、分けます。
後半は「今日まででどこまで進んだのか」です。

今日までの進捗について

という訳で、裏でidle版の方を試作していたのですが、
一旦ソースコードを戻して現状のsmpd向けに協力出来ることについて考えてみました。
そこで思いついたのが「毎秒送っているmpdのステータス」って本当に全部必要なのかということでした。
下記項目については「状態が変更した場合」もしくは「クライアントが自発的に必要な場合」のみ送る仕様に変更しました。
（バイト数では微々たるものでしょうが、もしかしたら少しでも音質向上に寄与できるかもしれませんしね）

• 再生楽曲の総時間
  →「楽曲変更時の楽曲情報」と共に1回だけ送る

• 現在演奏中の楽曲のキュー内でのID
  →上と同じく

• ボリウム値
  →ボリウム変更時、接続中の全クライアントに周知、個別に値が必要な場合は取得するように調整

• シングル＋リピート＋ランダム＋コンシューム
  →どれか値が変更した場合は、ボリウム値と同様に接続中の全クライアントに周知、個別に値が必要な場合も取得可能に調整

良い意味の副作用として「ボリウム値のスライダーを表示してから値が現在値を示すまでのラグが無く」なりました。
（当該スライダーを開く操作をした際にボリウム値を毎回取得する処理を追加したため）

あともう1点、scrobbleの挙動を見直ししています。
具体的には以下の2つを行いました。

• scrobble条件のチェック
  楽曲変更直後にscrobbleに条件達成時間を計算し、経過時間が当該時間を超えた際にscrobbleをする仕様に変更
  （従来は毎秒経過時間が条件を満たすか都度確認）

• scrobble送信について
  従来popen関数でcurlを別プロセス呼び出ししていたのを今回はlibcurlで内部処理化しました。

という訳で、動作の確認が終了次第（早ければ明日）リリースしたいと思います。
（ごめんなさい。
宿題はプログレスバーの改良から次回進めていきます。）

2020-02-20版のwebui-plus配信について

長らくご無沙汰でした。
ちょっと手を入れる部分を前回の投稿から増やしたりしていまして
ちょっと時間がかかりましたが配信させて頂きます。

変更点は以下の通り

• 1秒間隔で行っている定時状態通知を縮小
  先の投稿通り、
  「ボリウム値」，
  「シングル＋リピート＋シャッフル＋コンシューム」，
  「再生中楽曲の総時間」，
  「再生中楽曲のキュー内ID」
  以上4項目は1秒単位で状態検知し、変更があった時点でそのステータスを送信する仕様に変更しました。
  「データベースの更新情報」も外出しできる可能性はありますが、
  それは次回実施いたします。

• scrobbleの挙動修正
  楽曲変更時に条件達成時間を計算し、「経過時間がこれを上回り」かつ「前に再生した楽曲と異なる」場合のみscrobbleを送信します。
  また、libcurlを使用し、ympdのプロセス内部でscrobble処理を完結させました（以前は別プロセスを内部的に呼び出し）。

• 当方で修正・拡張したプラグイン類のスマホ向けレイアウトの修正
  PCベースで開発を行っている都合上、レイアウトを改めて見て崩れているのがわかったので修正を行いました。

• DASHBOARDでのスマホ向けARM・COREクロック表示対応
  スマホのように小画面ではドーナツグラフが非表示にされているため、これらのクロックは確認出来ませんでしたが、
  今回小画面デバイス向けに表の領域で対応するように拡張しました。

• httpsのサポート（実験的）
  昨年試してみて「出来ない」と話していましたが、今回実験したところあっさり動作したため、
  実験的ですがサポートを開始します。（詳細は後述）

• 微修正
  停止時に毎回「mpdの再生停止」をクライントがサーバに送る仕様を一時的に止めました
  （恐らくwebsocketのセッションを維持させるためにあった?)
  また、html文で使用していないタグをコメントアウトしています。

HTTPSのサポートについて

本日時点では、以下の条件（不具合？）があります。
①今回提供する状況では自己署名（オレオレ）証明書であるため、通信経路の暗号化はされますが「信頼性の無いサイト」としてエラーが表示されます。
このエラーで「詳細」ボタンを押して強制接続する操作が必要になりますので、「なにそれ、怖い」とか「何言っているかわからない」という方は止めておいたほうが良いと思います。

②safariではwss（websocketのSSL対応）が現状動作しないため使えません（正確にはトップページが開きますが、操作出来ません）。

③Android向けのPWA（Progressive Web Application）はまだ完全ではありません。
インストーラの画面が開かないため、Chromeで自発的に「ホーム画面に追加」して頂くことになります。
また、キャッシュコントロールも「とりあえず実装した」というレベルです。

④wssのセッションエラーにより、スリープ状態などで一旦RaspberryPiのサーバと接続が切れた場合は、
ページリロードが必要になる可能性が高いようです。

HTTPS接続を試したい方は以下の通り実行してみてください。
①/lib/systemd/system/ympd.socketを以下の通り書換

[Socket]
#ListenStream=80
ListenStream=443
KeepAlive=true
PassCredentials=true

[Install]
WantedBy=sockets.target

要は、443ポートで接続させるという意味になります。

②/lib/systemd/system/ympd.serviceを以下の通り書換

[Unit]
Description=ympd server daemon
Requires=network.target local-fs.target
After=mpd.service

[Service]
EnvironmentFile=/etc/environment
Type=simple
ExecStartPre=/usr/bin/ympd-plus.sh
#ExecStart=/usr/bin/ympd -h /run/mpd/socket --webport 80 -i 200 --documentroot /var/lib/mpd/music
ExecStart=/usr/bin/ympd -h /run/mpd/socket --webport "ssl://443:/var/lib/mpd/music/ssl.pem" -i 200 --documentroot /var/lib/mpd/music

User=root
CPUSchedulingPolicy=other
CPUAffinity=3

[Install]
WantedBy=multi-user.target

長々全記述付けていますが、中盤の「ExecStart行」だけ書換すれば良いです。
見たとおり、443ポートを使用し、
証明書は/var/lib/mpd/music/ssl.pemを使用するように書換します。

③ympdデーモンの再起動

systemctl daemon-reload
systemctl stop ympd.socket
systemctl stop ympd.service
sleep 1
systemctl start ympd.socket
systemctl start ympd.service

systemctl の stop と start 間は少しだけ間を開けたほうが良いと思います。

何か不明な点、バグなどございましたらご連絡くださいませ

おまけ：
宿題のプログレスバーは手は動かしていますが、まだこれからです。

iosでのホーム画面に追加について

今回PWA対応のために色々ドキュメントを調べていたところ、
そういえばindex.htmlに見慣れない記述があったなぁと思い
改めて確認したらあっさりと出来ましたので一応ご紹介です。

出来ること

iosデバイスのデスクトップ上にwebuiのアイコンを置き、ここから直接webuiにアクセス可能になります。

設定方法

• safariでwebuiを表示します。

• webui表示状態のまま、□に↑のアイコンをクリックします。

• ３段のウィンドウが表示されますが、一番下の段をスワイプでスクロールさせ「ホーム画面に追加」（□に＋のアイコン）をクリックします。

実行方法

デスクトップに出来たSymphonic-mpdのアイコンをクリックすると、
webuiが開きます。