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

---

@mgroovy さま
最近 foobar2000 ちゃんと触っていないのでイメージが沸かないんでちょっと解説いただけませんか？

Youtube の検索はプラグインや何らかの方法で提供し、
Youtube上のリンクのURLをクリックしたら smpd で当該リンクの楽曲を再生出来るってことでしょうか？

@sunatomo さん

私も foobar2000 の使い方を良く把握できているわけではありませんが、
View -> Youtube Source -> Search on Site とクリックすると、
別 window が開き、検索する文字を入力できます。
その後、下の部分に検索結果が表示され、どれかをダブルクリックすると、再生が始まります。

結構大変な気もしますので、YouTube の検索は YouTube内で行ってもらい、
気に入った曲の URL を smpd の webui に入力し、再生できれば良いと思います。

@mgroovy さま
本機能、遅くなりましたが今日実際にfoobar2000起動してみて確認しました。
こちらで紹介されている「Youtube component for foobar2000」ですよね？
（標準では当該メニュー表示されなかったので、ちょっと一緒に調べてみました）
コンポーネントのダウンロード先はこちら
確かにアーティスト名を指定すると楽曲のリストがずらっと並んで、音声再生だけfoobar2000経由でできますね（カバーアートはおそらくサムネールが表示される）。

私のようなライト系ユーザには面白い機能ですが、実現するには以下の確認が必要ですね。

• 検索の実現方法
  ご呈示の通り、Youtubeサイトで検索してURL指定するってのもありだと思いますが...

• YoutubeのURLを音声デコード可能なのか
  smpdの現状のffmpeg実装ではサポートが不足しているため再生できない可能性が高いかもしれません。
  Arch Linux AoEならもしかしたらOKかもしれません。

どちらにせよ、後者のYoutubeのURLをsmpdから再生できるかちょっと試してみたいと思います。

@sunatomo さん
すみません、標準のコンポーネントではなかったのですね。。。
いつの間にか自分でインストールしていたようです。。。

検索についてなのですが、検索文字を入れるすぐ下に、"youtube.web: Ordered by relevance" と表示されていると思います。
それで、youtube.web と relevance にアンダーラインが表示されていて、クリックできるようになっています。
そこをクリックすると検索方法のようなものが表示され、Provider とか type とか各種情報が表示されます。
なにかヒントになれば。

まぁ大変そうなので、Youtube の URL 入力だけで良くって、とにかく再生ができたら万々歳です！

2023-02-26 版の webui-plus アップデートについて

本日も新機能はほぼ無く、バグフィックスになります。

1. DASHBOARD プラグインのグラフ表示がある程度の画面解像度の場合正常に表示されない（その下の表領域の内側に指定される）バグ修正。
2. 同じくDASHBOADR でスマートフォン向けのarm_freq・core_freq の表示がされない件のバグ修正。
3. カバーアートモードでカバーアートをクリックした際のカバーアート用プラグインの動作修正。
   （ReGetボタンを動かなくしていました。また、当該プラグインでは現在再生中楽曲のカバーアートを表示するように修正し、Spin・ReGetボタンを押した際もプラグインは閉じない仕様に変更しました。）
4. html内部のstyle属性並びにJavaScriptでの.cssメソッドを極力使用しないように内蔵のCSSファイルにクラスとして事前定義済みに変更。

---

インターネット向けのカバーアートに関する現状の実装についてちょっと解説します。

• ライブラリ上の楽曲はwebuiプラグインで指定した方法で検索しますが、ラジオの場合は現状は必ず CoverArtArchive (musicbrainz) で問い合わせを行います。
  これは、Musicbrainz の検索 API 以外では「楽曲名とアーティスト名からアルバム名を特定」出来ないためです。
  （正確に言うと Fanart.tv でも Musicbrainz の API を使用してアルバムを特定しているため、こちらとの切替運用は可能でしょうが、今の実装は上記のとおりです。）

• CoverArtArchive では楽曲からアルバムを特定するために「アルバム名」・「楽曲名」・「アーティスト名」の3つを指定出来ます。
  アーティスト名は「アルバムアーティスト名」が存在する場合はそれを、存在しない場合は楽曲のアーティスト名を使用しています。
  一般的には「アルバム名」と「アーティスト名」からアルバムは特定できますが、特定できなかった場合は、アルバム名を消して「楽曲名」＋「アーティスト名」で検索してみるとヒットする場合があります（指定したアルバム名が Musicbrainz の DB 内部記述と異なる場合）。

• CoverArtArchive でのアルバム特定に失敗した場合、以下の2つのエラー出力が通知として表示されます。
  「No Release in result」検索 API のレスポンスに候補が無い（空）の場合
  「Can't specify Release」検索 API のレスポンスをすべて確認したが、アーティスト名が一致しなかった場合
  （通知をOffにした場合は表示されません）

• Musicbrainz の検索APIではアーティスト名の厳格な検索は行われずにレーティングと共に複数のアルバムを返す仕様のため、
  当該リストから再度アーティスト名でふるいにかけていますが、
  その際のアーティスト名は半角スペースで区切った最初の文字列部分の一致を検出しているため、まれに希望外のアーティストを特定する場合があります。
  例えば、指定したいアーティスト名が John Doe だった場合、Musicbrainz から返されたリストの候補で John Robinson が先に記載されていたら John Robinson のほうがヒットしてしまいます。
  （アーティスト名でのふるいをかける方法に工夫が必要かも知れません。）

• CoverArtArchive では、事前に Musicbrainz の API でアルバムを特定出来た（Musicbrainz のアルバムIDを取得出来た）場合でも、
  必ずしもアルバム画像を取得出来ない場合があります（当該カバーアートが CoverArtArchive に非登録の場合）。
  この場合、その後ろの no-image*.jpg が透けて見えます。

• 欧州文字列の半角中丸？とASCIIでの半角ピリオドの相違により Musicbrainz で同一アルバムと認識してくれない例がありました（下例が Metallica なのは個人的な趣味です）。
  特殊文字の読み替え辞書を作る必要があるかも知れませんね...

Musicbranz 登録
…And Justice for All

当方ライブラリ登録
...And Justice for All

---

youtube の URLを smpd・Arch Linux AoE 両方にライブラリの追加をした場合の挙動ですが、 どちらも楽曲（動画）URLのデコードに失敗しました。

前から考えていたのですが、youtube の楽曲を本システムで聞きたい場合は shareport-sync のように chrome-cast 互換のクライアントプログラムを起動したほうが良い気がしてきました。
（以前調べた際はその用途に使えるアプリケーションは存在しませんでしたが、再調査してみようと思います。）

アップデート提供の予告について

機能上は正直頭打ちなのですが、不具合が見受けられましたので明日を目処にアップデート版を提供します。

1. PC向けより小さい解像度での表示の際にレイアウト崩れを起こしていた（当方でHTMLファイルのDOMツリー削減のために手を入れた際の検証不足でした）。

2. CoverArtArchive（Musicbrainz）でアルバム検索をする際、パラメータを多めに指定したためにヒットしなくなっていた。
   （欲張りすぎて「アルバム名」・「トラック名」・「アーティスト名」の3つがあれば全部パラメータにしたところ、逆に返される結果は 0ヒットになるケースが非常に多いことに気づきました。
   楽曲から渡される情報にアルバム名が存在する場合は「アルバム名」＋「アーティスト名」で、
   存在しない場合は「トラック名」＋「アーティスト名」からアルバムを検索するように仕様修正します）

3. MP3 コーデック以外の楽曲で再生時に埋め込みカバーアートを抽出しようとした際に内部的に異常終了するバグの修正
   (先日aacコーデックの楽曲の埋め込みカバーアート抽出をしようとしてwebuiの処理がタイムアウトになることが判明し、
   「抽出出来ない」場合の処理にバグがあることがわかりましたので、それの修正になります）
   当時手持ちの楽曲で埋め込みカバーアートがあるものは MP3 ばかりでしたので「これで埋め込みカバーアートの抽出は fix した」と思い込んでいましたが、見通しが甘かったです。
   （smpd で採用している mpd では、FLAC は不明ですが AAC は抽出出来ないようです）

4. CSSファイルへの SCSS（SASS）の採用について
   webuiを構成するため、ブラウザへ表示されるページのスタイルをcssファイルで指定しているのですが、
   これを scss に変更します。
   scss ファイルは開発時のみ使用し、ビルド時にこれをコンパイルして生成されるcssファイルをパッケージには同梱するので、実際の表示方法は従来と同じ仕組みで変わりません。
   要はスタイルシートの開発の際に html の階層構造に即した記述か可能な scss 形式を採用することで、バグや不使用定義の発生しにくくするのが目的になります。

2023-03-12 版の Webui-plus アップデートについて
リリースノートの基本は先の投稿にあるとおりですが、一部補足を書きます。

5. CSS Containment の採用について
   メインの ブラウザ上の画面に対し、頻繁に書換が発生する部分を別ツリーとして管理することにより、描画の際の css 解析を極小化する技術になります。
   実測はしていませんが、体感的には高速化を見込めたので試験導入しています（おそらく、キューやディレクトリ構成を表示する部分の書換が前より素早くなった）

6. 埋め込みカバーアートについて
   埋め込みカバーアート取得のタイミングは現状「再生中の楽曲が変更した場合」かつ、その楽曲のURLが「NAS上もしくはRAM上」の場合のみとなります。
   今回処理の見直しにより、「楽曲のトラック名・アーティスト名他の情報をmpdから取得し終わった」あとで「mpdからカバーアートのバイナリデータ取得をする」ように修正しました。
   （従来は「トラック名他取得のセッションリソースが残った」状態で「カバーアートを取得するためのセッションを開く」処理であったため、異常終了していた模様）

※今回の埋め込みカバーアートの修正に伴い、「楽曲ファイルに埋め込みカバーアートが無い場合」や、
aac 等 「mpd のバージョン違い等の理由でカバーアート非サポートの楽曲」での処理時はjounalctlにエラー表示がされるようにしています（今のところは）。

今週のアップデート予定について

「しばらくリリースネタは無いかもなぁ」と勝手に思っていましたが、
手を動かしたら個人的には「なかなかの成果」がありましたので、週末予定でリリースします。

1. ページ表示の高速化
   今までもHTML内でCSSを先に読み込んでから JavaScript を読み込んで走らせるという高速化は実施していましたが、
   script タグ（JavaScript ファイルの指定）に defer オプションを追加し HTML ＋ CSS 解析とは非同期読込対応することで
   URL呼び出しから描画完了がほぼ一瞬で書き換わるようになります。
   
   なお、従来はスキン対応のために必要ファイル全読込後に再描画がかかっていた模様でした。
   今回からはスキン用の css 読込を head タグの先頭で行うように調整しました。

2. CSS 上の旧版 Opera 向けベンダープレフィックス消去
   現状の Opera はWebkit ベースのレンダリングエンジンですが、2013 年までの旧版は 独自エンジンを採用しておりました。
   ただし、もう 10年も前のソフトウェアのため、今回整理したいと思います。
   もう一つサポートとして消したいところとして ie 向けのベンダープレフィックス設定がありますが、こちらは edge （旧版）でも使われている可能性があるため、ちょっと慎重に作業を行います。
   
   ※ベンダープレフィックスとはブラウザが正式なcssに対応する前に定義することで同様の動作を期待出来る記述で、主に css での動的効果に使用されています。

3. 埋め込みカバーアートの表示機能について
   ＊＊＊本項目については「今後の構想」だと思ってください。＊＊＊
   RaspberryPi4 上の ympd でカバーアート抽出を動作させた場合はそれほど待たされませんが、
   Pi3 の場合、「楽曲再生開始から書き出し完了」まで数秒待たされる現象が発生しています。
   
   現状の実装ではキューの最上位が書き換わった（次の楽曲再生開始時）場合、以下のように動作しています。
   ①現在の最上位の楽曲の情報を抽出し文字列化
   　↓
   ②当該の楽曲のURLからNAS/RAM上にある場合は当該楽曲の埋め込みカバーアートを抽出してRAM上にファイル出力
   　↓
   ③先の楽曲情報文字列にカバーアートの抽出結果（成功or失敗）を追加付与してブラウザに送る
   　↓
   ④ブラウザで楽曲情報を受け取ったら、その情報で楽曲表示を書き換え
   
   ②の処理完了まで③・④が待たされるというわけです。
   という訳で、②の処理を非同期化（別スレッド or 別プロセス）する必要があるかも知れません。
   （従来のようにカバーアートの抽出をしない場合は②の処理は飛ばされるので全く影響はありません）
   ②の処理も mpd での埋め込みカバーアート読込時、コマンド1回あたりの 8192バイト単位でしかバイト列が読み込めず、
   数百kバイトクラスの読込だと何度もループ内で処理を回す必要があります。

追伸：ここに書くのもどうかと思いますが、手持ちの ArchLinuxAoE で pacman -Syu を全パッケージにかけてしまい
ブートはするのですがネットワークへのIPアドレス設定が出来ない状況になってしまいました。
復旧まで少々時間がかかりますので、その間は ArchLinux 向けのパッケージ提供はお休みする可能性があります。ご了承ください。

webui-plusで埋め込みカバーアートの抽出設定をOnにしている方へ

本日内部の処理を確認したところ、以下の不具合を見つけましたので「取り急ぎの対応」に記載の通りアップデート版を提供するまでは使用制限を行っていただければと思います。

• 不具合内容
  ympd に対して同時に複数のウィンドウ・タブ・端末から同時アクセスしている場合、埋め込みカバーアートの抽出が複数回動作するために楽曲変更時の楽曲情報が表示されるまでに非常に時間がかかる場合がある。

• 発生原因
  ympdでは内部のhttpレベルの各接続セッションに対してwebsocket（ympdとブラウザ間の専用通信プロトコル）接続セッション毎に内部ステータスメッセージの生成→送信を行います。
  楽曲変更時は「メッセージの生成＋（設定有効時は）埋め込みカバーアートの抽出」を行いますが、
  複数の端末でアクセスを受けている際、websocketの接続セッション数分上記の動作を行うために「埋め込みカバーアートの抽出」に時間を要する環境では一番最後に処理されるwebsocketから楽曲変更のメッセージが帰ってくるのが非常に遅くなる可能性が高くなります。
  （例えば1回あたりの抽出に5秒かかる場合、それを10セッション実施したとすると、最後のセッションの場合は最大50秒以上要する）

• 対策
  現在webui-plus内部のympdの処理を「埋め込みカバーアートの抽出は最初のwebsocketでのみ実施」するように書き換えして動作検証しています。
  （これ以降のwebsocketでは「抽出処理の結果をフラグで受信」するようにし、重複実行を防止）
  次のアップデートで、対策版を配布します。

• 取り急ぎの対応について
  上記の不具合を防止するには、以下の2つの対応が可能です。
  ①埋め込みカバーアートの使用は今のところ行わない。
  ②どうしても埋め込みカバーアートを使用する場合、1端末の1ウィンドウ（タブ）からしか webui にアクセスしない。

という訳で、ご不便おかけしますがご了承頂きたくお願いします。

2023-03-19 版の webui-plus アップデートについて

すでに前のスレッドで書いたとおりの内容の fix と scrobble 送信前のnowplaying の送信が多重で行われていた可能性のある件の対応をしました。
（Scrobble 自体は別でタイムカウンター処理を行っている関数で送信しているため、多重送信は行われていない模様）
↑
どちらにせよ、もう一度このあたりは時間をかけて精査はしたいとは思います。

という訳で、今回のバージョンから埋め込みカバーアート取得でも複数端末・ウィンドウ・タブからのアクセスは可能です。