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

---

2021/10/04 版の webui-plus リリースについて

リリースログは以下の通り

• aoeプラグインの差替について
  arch linux aoe のスレッド通り、lsaoe の出力結果（Macアドレス）を各端末の Cookie に保存する仕様としました。
  (Cookie の Macアドレス保存の有無に関わらず、aoeプラグインを画面上に表示した時点で「＜＜none＞＞」という選択肢が追加されます。
  これを選択した場合、aoeの起動オプションは無指定になります。）

• 楽曲変更時のカバーアート書替アルゴリズムの変更
  @mgroovy さまご指摘で処理を見直した結果、カバーアートの書替を曲変更時に必ず行うように処理を見直ししました。
  （従来は mpd から当該楽曲のURIを受信した場合にのみカバーアート書替を実施していたが、内部的タイミングで URI が空のまま楽曲が変更されたと伝送される可能性が有ったため。）

• PC向け表示（リスト＋カバーアート）の試作版同梱
  お試しになりたい場合は以下の通りURLを入れてみて下さい。

http://(webuiのipアドレス)/index2.html
　もしくは
http://smpd.local/index2.html

とりあえず当方環境では（フルHDの解像度）では左右画面両立していますが、これよりも縦解像度が少ないとカバーアート側の表示が崩れると思います。
（今後開発継続の場合は縦768ピクセルまではちゃんと動作するようサポート予定。）

@sunatomo さん (cc @ゴンザエモン さん)

いつも精力的な対応ありがとうございます。aoe バックエンドの切り替え機能の UI 提供、誠にありがとうございます。パパリウスさんに本機能をお願いした張本人として、rpi4 フロントエンド v1.0 にて試してみたのですが、あいにくうまく動作しませんでした。以下、rpi4 フロントエンドにて実施した作業です。

(1) web-plus のインストール
(2) Web UI の PLUGINS 設定にて AoE CONFIG プラグインの有効化
(3) バックエンド1 (BE1) を起動後、NAS の音源を再生開始 (バックエンドとして BE1 しか起動されていないため、当然 BE1 にて再生される) した上で再生終了。
(4) バックエンド2 (BE2) を起動。
(5) Web UI の AoE CONFIG 設定にて leaoe を実行し、BE1 及び BE2 がどちらも表示されることを確認した上で、BE2 を "Setting the vsound.service" の mac-address にて選択し、"Setup" をクリック。
(6) "vsound.service restart success" のメッセージを確認後、"OK" をクリック。

上記操作の結果、てっきり、”/lib/systemd/system/vsound.service" の ”ExecStart=/usr/bin/aoe” に "-d <BE2 の mac-address>" が追加されているのではないかと想像していたのですが、変更されておらず、また、その後再生しても、前回再生していた BE1 で再生される状況となりました。
書き込み権限の問題もあるかと思い、"chmod 777 /lib/systemd/system/vsound.service" を実施してから (5) (6) の作業を繰り返してみましたが、結果は同じでした。

念のため、vsound.service を手動で変更し、"-d <BE2 の mac-address>" を aoe 起動時のパラメタとして追加してフロントエンドをリブートしたところ、期待通り、BE2 で再生できることは確認しています。

何か見落としている作業などありましたら、ご教授いただけますでしょうか。

@norinori さま
やり方としては上記でOKです。

すいません。同梱のファイルセット、 /usr/local/bin/vsound-setup.sh のパーミッション誤りで動作しないと思います。
パーミッションを以下の通り755に変更いただけませんか?

chmod 755 /usr/local/bin/vsound-setup.sh

（言い訳になりますが、aoeについては私の環境では arch linux aoe で検証を行っているため必要なファイルをそちらから複写していたのですが、
作業手順の忘れが発生したためでした。）

差替版のパッケージはこの後直ちに作成してアップします。

@sunatomo さん

楽曲変更時のカバーアート書替アルゴリズムの変更

こちらですが、同じ結果で直りませんでした。

そこで色々と試行錯誤したのですが、分かりました！
CoverArt Filename の指定のところの一番最後の
"last.fm's API"のチェックボックスを外してみたらちゃんと表示されるようになりました。
もう少し早くここに気づければ良かったのですが。。。
すみません。

@mgroovy さま
検証有難うございます。おかげで絞り込みができました。

"last.fm" のチェックボックスを外した場合動作したということは、
「last.fmからカバーアート URL が正常に受信出来ていない」か
「last.fmからのカバーアート URL が他のカバーアートURLに対してどのような順で内部記載されているか確認する必要がある」ということまでわかりました。

次回のアップデートで恐らく、良い結果が期待できると思います。

@sunatomo さん

同梱のファイルセット、 /usr/local/bin/vsound-setup.sh のパーミッション誤りで動作しないと思います。
パーミッションを以下の通り755に変更いただけませんか?

早速の情報提供ありがとうございます。ご指示に従い、無事期待した通りの動作を確認できました!
今までは-d オプションを切り替えて再起動する snippet を使っていましたが、WEB UI の操作で楽ちんになりました。ありがとうございました。

@mgroovy さま
Last.fmからカバーアートを取得する件、どうやらバグが発見出来たかもしれません。
１．last.fmから正常なURLが返らなかった場合のエラー処理の書き方で直したほうが良い表現があった。

２．正常なURLが返ったとしても、カバーアートのサイズ指定通りの URL が含まれなかった場合、途中で処理落ちする可能性があった。

以下の２点修正してみます。

2021-10-09版のWebui-plus配信について

あまり変更は加えていません。
リリースノートはこちら

• last.fmでのカバーアート取得を以下の通り最適化
  従来、last.fm からのカバーアート URL 取得は last.fm のAPIから返された電文内のカバーアートURL群から最大画像サイズの "mega" (300×300ピクセル)直指定で取得していたのですが、当該カテゴリが含まれない場合その後の処理でエラーになる可能性がありました。
  今回からは取得できたカバーアートURL群の中で最大サイズを取得するように変更しました（例えば "mega" が含まれない時、カバーアートURL群内の最大サイズが "large" の場合はその URL を返す）。

※参考ですが、カバーアートの取得は以下の順で表示されます（仮に全ての項目にチェックを入れ、全て取得可能であった場合。チェックを入れない項目は下記リストから除外されます。）
１．楽曲ファイル組込画像（存在する場合のみ）
２．folder.jpg
３．Folder.jpg
４．cover.jpg
５．（アーティスト名） - （楽曲名）.jpg
６．「last.fmで取得したカバーアートの指定URL」
７．noimage*.jpg ←webui初期起動時などに表示されるお姉さんの画像
1 〜 4 についてはNASやカバーアート格納先の接続状況によって表示順が異なる場合があります。
（例えば、しばらく楽曲再生していない場合はNASの接続が一旦遮断されている可能性があり、その場合は５・６が先に表示されることがある。）

• ツインモード表示の最適化
  ↑左にリスト、右にカバーアートを配置した横画面設定向けモードを勝手に「ツインモード」と称します。
  画面縦の解像度がある程度低い場合にもカバーアート（右）側の下部表示が切れにくいようにスタイルシートを（具体的には解像度によるメディアクエリで）調整しました。
  恐らく、1024×768ピクセルでも表示可能になったと思います。

@sunatomo さん
ご報告が遅くなりました。
残念ながら、まだ直っていないようです。
last.fmからカバーアートを取得するにチェックを入れると、問題は発生してしまいました。
チェックを外せば問題は発生しませんので、またお時間の取れる時にでも検討をお願い致します。

@mgroovy さま
うーん、まだうまくいかないですか...
それではほんの少しだけ時間頂きますが、デバッグ出力可能なものを用意してみます。
お使い頂いて、どういう出力が記録されるか確認させて下さい。

カバーアートテスト用ビルドの試験公開について

中身としては２０２１-10-09版と基本的には変わりありません。
違いは後述しますが、ブラウザで動作するJavaScriptでデバッグ情報をファイル出力するようにしたものになります。

※今後、ブラウザ上でのデバッグ情報を利用者に提供頂きたい場合はこのようなビルドを試験的にリリースします。

ympd-test_2021-10-19.zip

○インストール方法
以下、/root辺りに当該ファイルを複写した場合を想定して記載します。
なお、元々のwebuiは/usr/bin/ympd.orgとしてバックアップします。
（念の為、丸写しではなく自分で内容を確認してから実行して下さい。）

unzip ympd-test_2021-10-19.zip
systemctl stop ympd.service
systemctl stop ympd.socket
cp /usr/bin/ympd /usr/bin/ympd.org
cp ympd.release.out /usr/bin/ympd
systemctl start ympd.socket
systemctl start ympd.service

○このデバッグ用リリースについて
webuiをリロードしてブラウザに表示させて下さい。
楽曲を再生し、曲が切り替わるタイミングでカバーアートが更新しますが、その際のカバーアート周りのパラメータを内部的に文字列に保存し続けます。
カバーアートの不具合現象が発生した状態で何曲か楽曲が切り替わったら、
Settingsプラグインを起動して最下部のDebug Outにある「debug.txt」をクリックしてデバッグ情報をファイルとしてダウンロードして下さい。
ダウンロードしたファイルをエディタなどで開き、そのまま開示頂けると有り難いです（個人的にメールで送信したい場合はチャットなどで事前相談しましょう）。

○元に戻す場合
（念の為、丸写しではなく自分で内容を確認してから実行して下さい。）

systemctl stop ympd.service
systemctl stop ympd.socket
cp /usr/bin/ympd.org /usr/bin/ympd
systemctl start ympd.socket
systemctl start ympd.service

デバッグ情報をブラウザで動作しているJavaScriptの変数内に文字列として格納し続けるため、
長期的に今回のビルドを運用した場合の連続動作の保証はしかねます。
（恐らく通常の楽曲で2〜3時間連続再生くらいでは問題にならないと思いますが．．．）

@sunatomo さん

どうもありがとうございます！
さっそく実施してみました。

最初に、Folder.jpgとlast.fm's APIの2つのチェックを入れ、問題が発生するもののログです。（1曲目は正しいアルバムアートが表示される曲で、2曲目はアルバムアートが上書きされず、ブラウザリフレッシュでデフォルトの女性の絵になってしまうものです。次に3曲目にスキップしたのですが、正しく表示されないアルバム（2曲目と同じ）のためか、ログは表示されていないみたいです。）

songChange!
coverFlg:36
songChange!
coverFlg:36

これに続いて、Folder.jpgのみにチェックを入れ、正しいアルバムアートが表示されるもののログです。（上記ログ取りに続いて実施したため、継続してログが取られていると推察され、5行目以降がログと思われます。再生した曲は上記ログ取得と同じ曲になります。）

songChange!
coverFlg:36
songChange!
coverFlg:36
songChange!
coverFlg:4
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%203%2FFolder.jpg), url(/assets/no-image1.jpg)
songChange!
coverFlg:4
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%2026%2FFolder.jpg), url(/assets/no-image0.jpg)
songChange!
coverFlg:4
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%2026%2FFolder.jpg), url(/assets/no-image0.jpg)

よろしくお願い致します。

@mgroovy さま
早速のログ提供、誠にありがとうございます。
確認中ですが、取り急ぎ気づいたことが1点あります。

songChange!
coverFlg:36

この状態、songChange!で楽曲が変更したことを示します。
その際にcoverFlg（現在のカバーアート取得のフラグ）を確認して36と返しているのですが、last.fmでのタグを取得するようになっているはずなのに

cover_art_url:called
err:
last-fm_url:https://lastfm.freetls.fastly.net/i/u/300x300/b12c846ab82443eebf7edcc54c9bbe3a.png

のように続く項目が見えていないというのがまず気になります。
（この辺りはcoverFlgの値を32（last.fmのカバーアート取得のフラグ）でビット論理積で演算し、
0より大きい場合はlast.fmへカバーアートを取得する(cover_rt_url:calledが記録される)ように記述しています。）

まずは「coverFlg」の36が整数値ではなく文字列で格納されている可能性を疑って見たいと思います。
（webuiプラグインで値を変更したタイミングで一見正常になっているようですので、恐らくwebuiのリロードによる初期化時にRaspberryPiから返されたcoverFlgが文字列で格納されていると想定）。

カバーアートテスト用ビルド（差替版）の提供について

先程も書きましたが、webuiの初期起動時にcoverFlgをRaspberryPiから取得するのですが、
一部の環境で数値ではなく文字列として格納しているようでしたので、
明確に数値化するようにしました。

ympd-test_2021-10-20.zip

@sunatomo さん
残念ながら同じ結果でした。

上記と同じ3曲を選曲し、今度はブラウザリロード無し、曲のスキップ無しで、最後まで再生させてみました。
まずはFolder.jpgとlast.fm's APIの2つのチェックを入れた場合です。

songChange!
coverFlg:36
cover_art_url:called
err:
last-fm_url:
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%203%2FFolder.jpg), url(/assets/no-image1.jpg)
songChange!
coverFlg:36
songChange!
coverFlg:36

次にFolder.jpgのみにチェックを入れた場合です。

songChange!
coverFlg:36
cover_art_url:called
err:
last-fm_url:
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%203%2FFolder.jpg), url(/assets/no-image1.jpg)
songChange!
coverFlg:36
songChange!
coverFlg:36
songChange!
coverFlg:4
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%203%2FFolder.jpg), url(/assets/no-image0.jpg)
songChange!
coverFlg:4
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%2026%2FFolder.jpg), url(/assets/no-image0.jpg)
songChange!
coverFlg:4
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%2026%2FFolder.jpg), url(/assets/no-image0.jpg)

もう一息っぽい気がします。

カバーアートテスト用ビルド（差替版）の提供について

もう１発、テストリリースさせて下さい。
ympd-test_2021-10-24.zip

今までの状況から coverFlg が３２以上の場合は cover_art_url 関数が動作するように修正出来ましたが、
当該関数の呼び出し時のパラメータ(artist, album)が楽曲（アルバム）によってどのように変化するか確認する必要があるという判断です。

ちょっとした補足説明：
元々 cover_art_url 関数では album が null の場合は last.fm API の getinfo で artist 情報を、 null 以外では album を取得するようになっていましたが、
今回 album が空文字列の場合も artist を指定するように修正をしています。
これでNGの場合、artistは自動指定しないようにしてみようかと思います。

@sunatomo さん
いつもありがとうございます。
残念ながら同じ結果でした。
ログは一つにまとめ、前半がlast.fmのチェック付き、後半がチェック無しとなります。

------------------------ with last.fm --------------
songChange!
coverFlg:36
artist:The Hottest New Group
album:HD Jazz Volume 3
cover_art_url:called
err:
last-fm_url:
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%203%2FFolder.jpg), url(/assets/no-image0.jpg)
songChange!
coverFlg:36
artist:Ramsey Lewis
album:HD Jazz Volume 26
songChange!
coverFlg:36
artist:Joe Williams
album:HD Jazz Volume 26
---------------------- without last.fm -------------
songChange!
coverFlg:4
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%203%2FFolder.jpg), url(/assets/no-image1.jpg)
songChange!
coverFlg:4
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%2026%2FFolder.jpg), url(/assets/no-image0.jpg)
songChange!
coverFlg:4
url:url(%2FNAS%2FJazz%2FVarious%2FHD%20Jazz%20Volume%2026%2FFolder.jpg), url(/assets/no-image1.jpg)

よろしくお願い致します。

@mgroovy さま
結論としては「指定のパラメータ（artist, album）で返される結果にはカバーアートのURLは存在しない」ということでした。

お教えいただいたパラメータからlast.fmのアルバム情報を問い合わせURLを作成したものが下の文字列になります。

ws.audioscrobbler.com/2.0/format=json&api_key=ae1603978a00f0e398f1a7ae39fc6e57&method=album.getinfo&artist=The Hottest New Group&album=HD Jazz Volume 3

上記のURLをエンコードしたもの
をブラウザの場所に入れると以下の結果（json形式）が返ってきました。
(実際にはわかりやすいように改行とスペースによるインデント追加済みです）

{
  "album":{
    "artist":"The Hottest New Group",
    "listeners":"4",
    "image":[
      {"size":"small","#text":""},
      {"size":"medium","#text":""}, 
      {"size":"large","#text":""},
      {"size":"extralarge","#text":""}, 
      {"size":"mega","#text":""}, 
      {"size":"","#text":""}
    ],
    "mbid":"",
    "tags":"",
    "name":"HD Jazz Volume 3",
    "playcount":"10",
    "url":"https:\/\/www.last.fm\/music\/The+Hottest+New+Group\/HD+Jazz+Volume+3"
  }
}

この中でご覧頂きたいのが"image"の後ろで[]に囲まれた部分です。
"#text" の値が全て "" と空白文字列で返されています。
(コロンを挟んで左がキー文字列、右が値と思って下さい）
本来はココにURL文字列が入るはずなのですが...

うーん、いろいろバグfixにお付き合い頂いて非常に当方としては感謝なのですが、
結論としては残念な結果になってしまいました。

@sunatomo さん

チェックボックスに複数チェックしていたら、ローカルというか近い方にあるものから優先して調べていって、あったら画像表示するというふうになっているものと勝手に思い込んでいましたが、last.fmにチェックが入っているとそちらが優先されるようなインプリになっているのですね。
そのような仕様になっているということで、理解致しました。

いろいろと調査いただき、どうもありがとうございました！

webui-plusアップデート版の配信について

@mgroovy さまのご協力でいくつかカバーアート取得関連のバグfixしましたので、配信いたします。

• ブラウザでのリロード時（リンククリック直後も）、RaspberryPiからカバーアート取得のフラグ数字を受信するが、これが一部の環境で文字列であったバグのfix

• last.fm経由でのカバーアート取得時の内部処理見直し