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

---

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

@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が開きます。

sunatomoさん

「iOSでのホーム画面追加」の件、早速やってみました！

これ、iPAD/IPhoneユーザーの当方としては何ともありがたい情報です。

なお、アイコンの名前も任意に変更できるようですので、
「Raspi 3 SMPD」
「Raspi 4 SMPD」
とかやれば、複数のSymphonic-MPD（個別のStatic Address設定前提ですが）をアイコン管理できます。

@ゴンザエモン さま
お試し、お疲れ様です。
自分は基本的には１台運用のため、ご提示のような状況は想定していなかったので有り難いです。

ちなみにまだ中途ですが、AndroidでもChromeを使った場合は同じように「ホーム画面に追加」が可能にあります。
（ちゃんと対応するとProgressive Web Applicationになり、
コンテンツのキャッシュコントロールなども実現しますが、まだ調整中です。）

2021-02-28版のwebui-plus配信について

ほぼ1週間ですが、一部先に進めましたので配信します。

変更点

• 再生カウンター部分のプログレスバーを実秒に対応させました。
  従来は0〜100%で返されていたプログレスバーの現在値を
  今回は0〜楽曲の総秒数に変更しています。
  これにより、お使いの端末のピクセル幅にもよりますが、
  普通の（10分以下）の楽曲で、PCやipadなどの解像度ならば1秒単位で
  シーク＋プログレスバーの視覚変化が可能となります。

• 実行ファイル等の若干のスリム化
  2/20版ではPWA一部対応のため実は512×512ピクセルのpng画像ファイルをアイコン用として追加しており、
  これのサイズが結構大きかったため実行ファイルが200kbほど肥大化していました。
  今回同ファイルをもう少しサイズ縮小しています。
  また、内部の精査に伴い、webuiを最初に呼び出しするhtmlファイルで以前のプラグインで使用していた未使用のタグがあったため、
  これらのコメントアウトを実施しています。

• Audio over Ether 向けのプラグイン追加
  あちらのスレッドに先にプラグインだけアップロードしましたが、
  webui-plusのパッケージにも同じものを同梱しています。

スマホなど小画面でのミニプレーヤ表示の試作に関するアンケートについて

これは実機ではなく、Chrome（Vivaldi）でのDevelopper Modeで
デバイスにiphone6-8を指定した際の画面例になります。

以前 @toshi300 さまからご相談を頂いた件、とりあえずミニプレーヤ側ではカバーアートを表示させないという方法で試作してみましたが、
正直どのように感じますでしょうか？

1. このままで良い
2. 方向性はこれで良いが、タイトルなどを調整してほしい
3. 今までのほうが良い
4. 別の方法が良い

ご意見、お待ちしております。

ちなみに私としては 2) になりますね。
現状の楽曲タイトルはsmallタグなので文字大きさを他の文字と合わせる調整は行いたいと思っています。
(スマホ向けのカバーアートはカバーアートモードで見て頂くのでアリかなと)

@sunatomo さん

もし時間をかけて取り組めるのであれば、カバーアートに透明度を設定して背景に表示するというのはどうでしょうか。
カバーアートの華やかさと表示領域を両立させられるのではないかと思います。

@パパリウス さま
早速お申し出、ありがとうございます。
ちょっとcssいじってみました。

背景の opacity は仮に0.6設定にしています。
また、現状のcssでは画面サイズ問わず opacity が有効になっているので、この部分は修正要ですね。