1. サポート対象
   v1.0ならびにArch Linux AoE環境となります。
   （今後サポート対象が変更になった場合はこちらに周知）

2. インストール方法
   RaspberryPiにSSHでログインし、以下の通りコマンドを入れて下さい。

stop ympd
app remove webui-base
app install webui-plus
reboot

3. 元に戻すには
   RaspberryPiにSSHでログインし、以下の通りコマンドを入れて下さい。

stop ympd
app remove webui-plus
app install webui-base
reboot

4. 追加された機能について
   　今後、各スレッドの「リリース」で機能追加・修正事項については記載させて頂きます。

5. 動作保証について
   　webui-plusは正常な動作を期待して開発しておりますが、
   何分私の力不足でwebui-base より安定性が劣る場合がありますので
   ご使用の際はその旨をご了承下さい。
   　当然ながらwebui-plusでの不具合については当方で責任を持って修正いたします。
   　コチラのスレッドに続いて記載の方お願いします。
   （webui-base についても私の方でソースコードは見えますが、
   出来ればメインラインと障害を分けたいと思いますので、ご了承下さい。
   ＜メインラインに関連する障害の場合、当該報告をv1.0不具合報告スレッドに付けなおしする可能性あり）

6. 今後の機能追加などについて
   　インキュベータ（保育器）のような形で使いたいと思います。
   将来的にはメインラインに採用されないかもしれませんが、色々やってみて「これは！」と気づく機能を開発できるかもしれません。
   　WebUIという形を取る以上は「Webブラウザで動作する」前提になりますが、ご提案を受けたいと思います。お待ちしております。

7. English notice
   This is WebUI (symphonic-mpd Web browser interface) plus application thread.
   You can change default WebUI(webui-base package) application to incuvator version (webui-plus package).
   If you have any question/issue report/inprovement idea, write this thread.

8. 前のエンジニアリングプレビューをお試しいただいた方へ
   /opt/plugins/04-webui/webui.cfgを上書きしますので、前の設定を消されたくない方はバックアップ、復元して頂けると幸いです。
   （次のアップデート時には上書きしない方法に改良します）

9. 現時点での宿題とその達成状況
   　今後修正や実装を予定している項目ならびにその対応を以下に表示します。

10. ドキュメント整備について
    本スレッドの下部にもありますが、只今当方の在庫切れにより「当方提案による新機能の実装」についてはお休みを頂いております。
    つきましては、当面の対応としてこれまでおろそかになっていた「ドキュメントの整備」をメインに行います。
    記載先は「Support → User Guide（1.0.x）」内の「webui-plusのドキュメント」になります。

webui-plusパッケージの公開、どうもありがとうございます。

デフォルトのwebui-baseパッケージにympd.serviceを同梱して差し替えました。うっかりしていました。ご指摘ありがとうございます。

webui-plus 向け実装済み機能の安定化と新機能を以下の通り検討しています。
下記はあくまで私が立てた構想ですので、「この機能実現できないの？」というご要望もお待ちしています（面白そう、重要度が高そうなら先にご提案のものをやってしまうかも）。

なお、マイルストーンは「あくまで予定」であるため、予定通りに実装出来るかはお約束は出来ません。

1. 機能安定化
   ・webui.cfg設定の安定化
   　ちょっと使っていてわかったのですが、設定された直後は設定値を保持していますが、
   　PCのスリープ復帰直後などにリロードされたタイミングで設定値が消えています。
   　ympdの本体側（Webサーバ側）で設定は内部格納するようにしないとダメですね。
   ・アップデートによる設定ファイル上書防止
   　現状のappコマンドによるパッケージにはwebui.cfgも出荷状態の設定で含まれているため
   　毎回初期化されてしまいます。
   　次回アップデートからはこのファイルは含まず、
   　初めて使う場合に当該ファイルがない場合は自動生成するように改良したいと思います。
   ・現在再生中の楽曲情報表示の見直し
   　カバーアートに注釈という「やる気のない仕様」のため、もう少し見せ方を考えたいと思います。

2. 仕様追加について
   　mpcクライントや競合ディストリのWebUIの動向を見ながら、以下の機能を実装を考えました。
   ・「ディレクトリ表示」以外の楽曲の表示方法対応
   　"ジャンル"や"アルバムアーティスト"の一覧からアルバム・楽曲を絞り込み出来るようにします。
   　例えば”ジャンル”を選択すると、あなたのライブラリ内のタグからMPDが抽出した全ジャンル名称がリスト化されます。
   　その中から希望のジャンルを選択すると、当該ジャンルのアルバム名が次にリスト化されるという仕組みです。
   ・「SEARCH」プラグインでの複数タグ同時検索
   　上記の「ディレクトリ表示」以外の楽曲表示方法対応でSEARCHとほぼ同じ機能を実現するため、
   　こちらは機能強化になります。
   　ｍｐｃクライアントを見ると、複数タグで同時検索が可能であることが判明したので、これを実装します。
   　（下の例はmpcクライアントでArtistタグとAlbumタグを同時指定した場合の結果の一部です。）

mpc search Artist 核 Album ビ
NAS/核P-MODEL/ビストロン/01  - 二重展望3.m4a
NAS/核P-MODEL/ビストロン/02  - Big Brother.m4a

なお、明日以降は6/14にリリースしたwebui-plusの各追加機能について画面イメージを交えて1日1本づつくらいのペースで説明します。

Web-UI Plusの構想ですが、タグ情報（ジャンル、アーチスト、アルバム）を使っていく方向であれば、相当強力になりますね。

ジャンル、アーチストからのドリルダウンが可能となれば、現状のスピーディな操作感かつSMPD環境に沿った十全な設定機能とあわせて他のMPDクライアントは全く不要になってしまうかもしれません。

ただこの方向性が、SMPDの基本のWeb-UI(Basse)ではない　というのは何か理由があるのでしょうか。

メンテナンスを含めた将来性を考えてみても、一本化された上での機能拡張が望ましいと思うのですが、、、

baseとplusの2本立てにしているのは、開発をスムーズに進めるための工夫で、 @sunatomo さんと相談の上で運用手順を整備して参りました。

改良版(webui-plus)で動作実績を積み上げて安定動作が確認できた追加機能は、デフォルトのWeb UI(webui-base)に順次取り込んでいきます。

新機能を早く試したい方にはappコマンドでwebui-plusに差し替えてもらい、1〜2ヶ月後の反映でもよいという方にはオンラインアップデートでの配信を待っていただければと思います。

これまで、 @sunatomo さんが改良したソースを私が受け取り、私の方で動作確認した上でオンラインアップデートで配信という開発サイクルでした。

これだと、せっかく新機能を実装していただいても、アップデートで配信するまでに数週間のタイムラグが生じることもありました。
（これはPi4版の開発期間に特に顕著でした。私がWeb UIの機能改善を後回しにしていたからです。）

今後は @sunatomo さんの好きなタイミングで改良版(webui-plus)を公開し、即座にユーザからフィードバックを吸い上げ、さらに改良を進めるという一連のサイクルをご自身のペースで進めていただくことができます。

結果として、デフォルトのWeb UIに機能改善が反映されるのも早くなり、全てのユーザにとって恩恵があるものと思います。

PCのスリープ復帰直後などにリロードされたタイミングで設定値が消えています。

Spotifyから戻ったタイミングでも設定値が消える場合があります。

グリッド表示の表示数制限とキュー表示を切り離せないでしょか？
グリッド表示は50ぐらいでも良いんだけど、同時にキュー表示も50に制限されますので
キュー表示の50は下がスカスカになります。

そういうことなのですね！　　
先行的な公開という趣旨で、全て了解いたしました。

私から実行ファイルをリリースしているものは当方環境では一応動作確認は行っていますが、
v1.0β等で色々ご対応頂いたとおり必ずしも万全とは言えない場合があります。
v1.0正式版も出ましたので、やはりベースとなるものがあってこその、plusだと思います。

また、こういう形でお手伝い（兼個人的趣味も兼ねて）させていただいていますが、最終的なリリース版での取捨選択は主催者であるパパリウス さまに引き続き確認して頂くという気持ちはずっと変わっていません。

@Cresson さま
今の仕様だと「リストビュー」に戻すと数量が制限されるので「なんとかしてほしい」という要望来そうだなぁと想定していましたが、「キュー表示」もそうですよね。
実装方法を検討してみます（まずは「グリッド」・「リスト＋キュー」の2項目になりますかね...）

競合ディストリのWebUIやMPDの専用アプリでは既に実現していましたが、
symphonic-mpdで採用しているympdでは実現していなかった機能です。

何よりも、私自身がアルバムアートがズラッと並ぶのを見てみたい一心で実装しました。
もう一つ実装した理由としてv1.0βの開発の中で「MPDが埋め込みカバーアートの出力に対応した」というのがあります（埋め込みカバーアートの対応は今は実行停止していますが...）

「キュー」と「ディレクトリ」切替ボタン/Titleの横に◯のボタンが追加されています（このボタンは「ディレクトリ」選択時のみ表示）。
このボタンをクリックすると、従来の一覧（リスト）型楽曲表示と、カバーアートを表にした楽曲表示（グリッド）に切り替えられます。

• カバーアートが表示されます
• カバーアートの下にディレクトリ名が表記されます（ただし文字数制限あり）
  また、カバーアートにマウスカーソルを重ねると、ディレクトリ名がフルで表示されます
• カバーアートをクリックすると、当該ディレクトリ内部に表示が遷移します。
• カバーアート右上の「＋」アイコンをクリックすると、当該ディレクトリ内の全楽曲をキューに追加します。

ディレクトリ内部の楽曲表示の際は従来のリストと全く同じ描画プログラムとしています。
仮にディレクトリの内部には楽曲と子フォルダがある場合は下に画像例があるとおり
ハイブリッド表示となるようにしています。

（この画面例では上3行分のリストが楽曲、その下のカバーアートはディレクトリ（アルバム）表示）

また、Title横の「search」部分を使った簡易検索機能、リスト/グリッド表示どちらも有効です。
この欄に文字列を入力すると、現在表示中のディレクトリ内のアイテム情報から条件に合致したもののみを抽出する「簡易検索」機能となります。
ちょっとだけ技術説明をすると、グリッド表示はul・liタグを使ったリストが実体で検索条件に合致しない場合は当該liタグを丸ごと隠す処理を行っています
（リスト表示部はtableタグで条件に合致しないtrタグ行を丸ごと隠す）。

webui-plusインストールさせていただきました。
タイル表示にはなるのですが、cover-artが表示されずdefaultの女性のままです。
cover-artはFolder.jpgで保存しているのですが、どのように指定すればよいのでしょうか？
お教えください。宜しくお願い致します。

Folder.jpgは各ディレクトリに保存されていますか？

また、フォルダリストの最初のNAS・RADIO・RAMの3つが表示される状態の場合、
グリッド表示にした場合はどの画像が表示されますでしょうか？

多分、デフォルトで、CoverArt Filenameの項目、全てにチェックが入ってるんじゃないでしょか？
folder.jpg,Folder.jpgのみに絞ると表示されると思います。

「カバーアートのグリッド表示」は対応出来ましたが、
従来の設定をそのまま使った場合は1画面分のカバーアートを取得するために
ネットワークアクセスが増加してしまいました。
さらにWebUIの開発でリスト表示部分の最下部に「PREV」・「NEXT」ボタンが表示されること、
このボタンを表示するためのしきい値が500アイテムであることが判明したことから、
カバーアートの取得方法を改良しなければと気づきました。

従来のWebUIでのカバーアート取得方法は以下のとおりです。
１） 楽曲変更時に1回、URLを書換えする。
2) カバーアートのURLは以下のルールで複数記載されている。
①楽曲ファイルと同一ディレクトリのfolder.jpg
②楽曲ファイルと同一ディレクトリのFolder.jpg
③楽曲ファイルと同一ディレクトリのcover.jpg
④楽曲ファイルと同一ディレクトリの(artist)-(album).jpg
　（楽曲再生中のカバーアートのみ対応）
⑤last.fmのAPIに楽曲について問い合わせし、その結果返されたURL
　（楽曲再生中のカバーアートのみ対応)
⑥デフォルトの女性のjpg（ランダムに2枚のどちらか）
この6つをほぼ同時に取得（実際にはlast.fmのURLはその性質上ちょっとラグあり）し、返されたものがカバーアート領域に積み重ねされている。
積み重ねの順番は上記のリストの通り。
（仮にfolder.jpgとFolder.jpgの両方見つかった場合は、folder.jpgのみ表に見えます）。

というわけで、グリッドで500アイテムのカバーアートを問い合わせすると、3000件の画像問い合わせアクセスが発生するということになります。

PC上のブラウザのようにリソース（CPUパワーとメモリ）が豊富な環境ではあまりストレスがなかったのですが、ipad等で表示した場合はやはり重いということで以下の改良を加えてみました。

1. 画像取得のサーバ変更設定
   　従来はRaspberryPiの/var/lib/mpd/music下のディレクトリをRaspberryPiのWebサーバがサーチしてカバーアート向け画像を取得していました。
   　この方法だとWebUIでのカバーアート取得の度にRaspberryPiにアクセスするため、
   　NAS上でWebサーバが建てられる環境の方向けに問い合わせ先サーバを変更する機能を実装してみました。
   　設定方法は以下のとおりです。
   　・Access method を規定の「Raspberry Pi」から「NAS(httpd)」に変更する。
   　・NAS IP-addr に NASの楽曲フォルダまでのパスを記載する。
   　なお、後述のCoverart Filenameの設定を含めて動作確認出来るよう「test」ボタンを用意しています。
   　「test」ボタンを押すと、MPDのあなたのライブラリから最初の”a"を含むアルバムを探し、そのカバーアートが指定した方法で正常に取得できるか視覚的に確認することが可能です。
   　（内部的に指定した取得方法を元にカバーアートのURLを生成し、実際にそのカバーアートを直接読み込みしようとします。カバーアートが表示されれば正しい設定である可能性が高いです。）

2. ファイル名取得方法の選択
   　先に示した通り従来は1枚のカバーアートを表示するために6つの相手に問い合わせを行っていたため、
   　これを減らすためにCoverArt Filenameの項目を作りました。
   　予め全てのフォルダに自分で決めたファイル名（folder.jpg・Folder.jpg・cover.jpgのどれか）を保存しておき、
   　当該ファイル名のみにチェックを入れれば他のカバーアート名を問い合わせしないよう設計しました。

3. カバーアート取得数の制限
   　先述の通り従来は1ページあたり最大500件取得しますので、グリッド表示の場合はこれでは多すぎると判断しました。
   　そこでユーザーが設定を変更出来るようにしています。

これらの１）〜3）を併用することにより、RaspberryPiへのカバーアート問い合わせアクセスが最大効果ではデフォルトの女性の画像のみ（NASのHTTPで全て処理させた場合）に抑えることが可能になります。

20:25追記：原因分かりました。
(artist)-(album).jpgが有効になっている場合、この形式でカバーアートのURLが生成できない場合は文字列が空になってしまうためでした。

今週末を目処に修正版お送りしたいと思いますが、
取り敢えずは @Cresson さまご提示の通り、CoverArt Filename の項目を減らして動作を確認頂けれると幸いです。

cd /opt/plugins/attach 
ln -s ../04-webui/ 04-webui

上記のコマンド入力後、WebUIをリロードすると出ると思います。
（porgでのパッケージ作成時、当該ファイルの手当考慮していませんでした。
色々考えなければいけませんね...）

私もカバーアートが表示されなかったので、webui.cfgをのぞいてみました。

#coverFlg=62
の６２は＃１から＃３２の数値の合計で機能を選択するというロジックでしょうか。

これを
coverFlg=2
とすることで、folder.jpgのみを表示させるようになるという理解であっていますでしょうか？
実際、これでfolder.jpgが表示されるようになりました。

以下、folder.jpgだけにする場合

opt/plugins/04-webui/webui.cfg　の内容、および変更点

#this file is configuration for WebUI(ympd)

#setting for NASurl
#if you don't have NAS HTTPd this feed must be "RaspberryPi"
nasUri=RaspberryPi

#coverFlg CoverArt fetch mechanism

1 SongEmbeded

2 folder.jpg

4 Folder.jpg

8 cover.jpg

16 (artist) - (album).jpg

32 last.fm fetch

#coverFlg=62
coverFlg=2

#max columns(elements) per page
MAX_ELEMENTS_PER_PAGE=500

@kkumax さま
お疲れ様です。
若干下世話な話ですが、皆さんのカバーアートを見せて頂ける機会がなかなかおもしろいです。

さて、グリッドお試し頂いた方々、カバーサイズはもう少し小さくしてたくさん並べたい希望はありますか？
（今の仕様ではキューモードのカバーアートサイズと揃えて170×170pxにしています。）

カバーサイズは私的には、このサイズがちょうど良いのではないかと思います。