@sunatomo さん
同梱のファイルセット、 /usr/local/bin/vsound-setup.sh のパーミッション誤りで動作しないと思います。
パーミッションを以下の通り755に変更いただけませんか?
早速の情報提供ありがとうございます。ご指示に従い、無事期待した通りの動作を確認できました!
今までは-d オプションを切り替えて再起動する snippet を使っていましたが、WEB UI の操作で楽ちんになりました。ありがとうございました。
webui-plus開発/サポート(webui-plus development/support)
@sunatomo さん
同梱のファイルセット、 /usr/local/bin/vsound-setup.sh のパーミッション誤りで動作しないと思います。
パーミッションを以下の通り755に変更いただけませんか?
早速の情報提供ありがとうございます。ご指示に従い、無事期待した通りの動作を確認できました!
今までは-d オプションを切り替えて再起動する snippet を使っていましたが、WEB UI の操作で楽ちんになりました。ありがとうございました。
@mgroovy さま
Last.fmからカバーアートを取得する件、どうやらバグが発見出来たかもしれません。
1.last.fmから正常なURLが返らなかった場合のエラー処理の書き方で直したほうが良い表現があった。
2.正常なURLが返ったとしても、カバーアートのサイズ指定通りの URL が含まれなかった場合、途中で処理落ちする可能性があった。
以下の2点修正してみます。
あまり変更は加えていません。
リリースノートはこちら
※参考ですが、カバーアートの取得は以下の順で表示されます(仮に全ての項目にチェックを入れ、全て取得可能であった場合。チェックを入れない項目は下記リストから除外されます。)
1.楽曲ファイル組込画像(存在する場合のみ)
2.folder.jpg
3.Folder.jpg
4.cover.jpg
5.(アーティスト名) - (楽曲名).jpg
6.「last.fmで取得したカバーアートの指定URL」
7.noimage*.jpg ←webui初期起動時などに表示されるお姉さんの画像
1 〜 4 についてはNASやカバーアート格納先の接続状況によって表示順が異なる場合があります。
(例えば、しばらく楽曲再生していない場合はNASの接続が一旦遮断されている可能性があり、その場合は5・6が先に表示されることがある。)
@sunatomo さん
ご報告が遅くなりました。
残念ながら、まだ直っていないようです。
last.fmからカバーアートを取得するにチェックを入れると、問題は発生してしまいました。
チェックを外せば問題は発生しませんので、またお時間の取れる時にでも検討をお願い致します。
@mgroovy さま
うーん、まだうまくいかないですか...
それではほんの少しだけ時間頂きますが、デバッグ出力可能なものを用意してみます。
お使い頂いて、どういう出力が記録されるか確認させて下さい。
中身としては2021-10-09版と基本的には変わりありません。
違いは後述しますが、ブラウザで動作するJavaScriptでデバッグ情報をファイル出力するようにしたものになります。
※今後、ブラウザ上でのデバッグ情報を利用者に提供頂きたい場合はこのようなビルドを試験的にリリースします。
○インストール方法
以下、/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から取得するのですが、
一部の環境で数値ではなく文字列として格納しているようでしたので、
明確に数値化するようにしました。
@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)
もう一息っぽい気がします。
もう1発、テストリリースさせて下さい。
ympd-test_2021-10-24.zip
今までの状況から coverFlg が32以上の場合は 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にチェックが入っているとそちらが優先されるようなインプリになっているのですね。
そのような仕様になっているということで、理解致しました。
いろいろと調査いただき、どうもありがとうございました!
@mgroovy さまのご協力でいくつかカバーアート取得関連のバグfixしましたので、配信いたします。
ブラウザでのリロード時(リンククリック直後も)、RaspberryPiからカバーアート取得のフラグ数字を受信するが、これが一部の環境で文字列であったバグのfix
last.fm経由でのカバーアート取得時の内部処理見直し
前にちょっと調べてからかなり間が空いてしまいましたが、
MusicBrainz からアルバム(MusicBrainz では release と呼びます)のユニークなID (mbid) を取得することが出来ましたので、
これを元にCover Art Archive に対応させてみることにしました。
MusicBrainzからの mbid さえ分かれば、
http://coverartarchive.org/release/${mbid}/front
のURLで直接カバーアートそのものが返ります
(実際には別なURLへのリダイレクトのようですが、どちらにせよカバーアートが表示されました)。
あとは、将来的なものになりますが、mp3等の楽曲内タグに Musicbrainz のアルバム mbid が格納されていれば、
これを MPD から取得して直接カバーアートのURLが生成出来るということになります。
(libmpdclient では MPD_TAG_MUSICBRAINZ_ALBUMID という形で埋め込みされたタグを認識できるようになっているため、あとは楽曲へのタグ埋め込み方法を調査して実証して見たいと思います。)
あとは、webuiにこの仕組を組み入れて試作版を提供しようと思います。
ただし、2点ほど注意事項があります。
インターネット経由(last.fm・CoverartArchive)でのカバーアート取得の場合、どちらも一旦インターネット経由での情報取得による「非同期」実行となるため、両方共有効にした場合の動作を保証出来ません。
(非同期動作でどちらが先に結果が返ってくるか予想が出来ないため。)
当面は「どちらか選択」で使用する方向になるかと思います。
MusicBrainzでのAPI経由での mbid 取得時は単一の検索結果ではなく、類似結果を含む複数で返されます。
各検索結果での類似率が score キーの値として返されると共に検索結果がスコアの高い順で格納されていますので、
「最上位項目で score が 95 を超える場合のみ当該アルバムの mbid として信用する」という形で実装予定です。
現状ラジオでプリセット登録されているLinn RadioのURLですが、
どうやら使用できなくなっています。
以下の通り書き換えすることを推奨します。
Linn Radio
Linn Classical
Linn Jazz
何故気づいたかと言うと、「ラジオストリーム再生中にアルバムアート表示が切替出来ないかなぁ」と思ったからでした。
ま、これはちょっと検討してみます。
@sunatomo さん
Linn Radio の件、助かりました!
Linn のホームページを見ると、何か問題が発生し、その後直ったとの記載がありましたが、相変わらず再生できず困っていたところでした。
それから、5つ上の件ですが、もう一度良く読み返したら、
結論としては「指定のパラメータ(artist, album)で返される結果にはカバーアートのURLは存在しない」ということでした。
こちらは一曲目についてのことで、ちゃんとFolder.jpgが表示されているものになります。ですので、last.fmに問い合わせたけど存在しなかったので、NASのFolder.jpgを持ってきて表示したのだと推察しています。
それで、二曲目、三曲目の方がlast.fmに問い合わせしていないのが問題なのでは?と思いました。
もしお時間がありましたら、もう一度見直していただけるとありがたいです。
よろしくお願い致します。
今まで食指があまり動いていなかった部分でしたが、
やっとやる気になりまして一気に拡張できそうかなぁと思っています。
現状の取り組みについて、ご紹介します。
※参考情報webuiでのMusicBrainzID対応について
各楽曲のタグにアルバムのmbidタグが保存されており、mpdで本タグの認識がサポートされている場合はwebuiで活用可能なようにwebui側のプログラムを拡張しました(具体的には楽曲変更時に当該楽曲のアーティスト名・アルバム名・総再生時間などの情報と共にmbidを各端末に返すので、mbidを使用した問い合わせが可能になります)。
ただし、私の手元ではまだ動作確認中です。
(MusicBrainzPicardでタグの書替した楽曲をsmpdのライブラリに転送し、楽曲情報を更新しましたが、smpd は mbid を返してくれませんでした。
後程 Arch Linux AoE の mpd での動作確認と「他のタグエディタ」でそもそもmbidが格納されているのかの確認を行います。)
補足:MusicBrainzPicardでMusicBrainzサーバから情報を取得して書込した楽曲ファイルのうち、mp3ファイルについては以下のタグが追加されることが判明しました(それ以外のフォーマットの楽曲については追って解析)。
名称 | 解説 |
---|---|
MusicBrainz Album Artist id | アルバムアーティストのid |
MusicBrainz Album id | アルバム(リリース)のid |
MusicBranz Album Release Country | リリースされた国(2文字コード) |
MusicBrainz Album Status | 不明(手元ではofficialと記載) |
MusicBrainz Album Type | 不明(手元ではalbumと記載) |
MusicBrainz Artist id | アーティストのid |
MusicBrainz Release Group id | 不明 |
MusicBrainz Release Track id | 不明(恐らく個別トラック(楽曲)のid) |
※webui-plusでのカバーアート表示優先度について
カバーアートは css の background-image 属性を使用しており、当該属性内の url文 書込順序に基づき表示されます。
(以下のリスト昇順に表示される。
当然1〜5はフラグが有効な場合はbackground-image属性内にurl文が存在しますが、無効時は存在しません。)
順位 | 画像名 |
---|---|
1. | folder.jpg |
2. | Folder.jpg |
3. | cover.jpg |
4. | (アーティスト名) - (楽曲名).jpg |
5. | 楽曲ファイル組込画像(/RAM/cover-art.jpg) |
6. | インターネットサービス経由で取得したカバーアートのURL |
7. | noimage*.jpg ←webui初期起動時などに表示されるお姉さんの画像 |
また、各インターネットサービスは最終的には5種類のサービスから選択可能ですが、そのうち1個のみ使用できます(インターネットサービスを全く使用しない選択肢もあり)
※インターネットサービスでのアルバム特定用パラメータについて
どのサービスでも「アーティスト名」+「アルバム名」の2つが必要ですが、今回より「アーティスト名」は「アルバムアーティスト名」が存在する場合は、こちらを使用するアルゴリズムを試験採用しています。
last.fm
従来よりサポートしていましたが、追加で解説します。
アルバム情報を取得する album.getinfo で返った結果より カバーアートの URL を抽出して表示します。
当該 API の必須パラメータは「アーティスト名+アルバム名」(従来より継続サポート)と「MusicBrainzのID (mbid) 単独指定」の2種類があります。
今回より、mbidもサポートすることとしました(mbidが正確ならば、間違いないカバーアートが取得可能)。
CoverArtArchive
Musicbrainz と internet archive の合同作業成果です。
一旦MusicBrainzのAPIでアルバム情報を取得してmbidを抽出してから、CoverArtArchiveのURLにmbidを埋め込みすればカバーアートは表示されます。
Discogs
インディレーベルの販売等で実績がありますが、実はカバーアートが取得できます。
アルバムの指定・カバーアートの抽出方法は last.fm とほぼ同等(アルバム情報をクエリすると、返された結果にカバーアートのURLがふくまれるため、これを抽出)です。Discogs はmbid には対応しません。
fanart.tv
内部的には mbid でアーティスト・アルバムを管理しています。
ただし、fanart.tv 単独では last.fm のようなクエリ(検索)のAPIがないため若干の工夫が必要です。
(現在検討中ですが、MusicBrainzで情報検索 → 得たmbidでfanart.tvからカバーアート取得でしょうか?)
Spotify
独自IDでアーティスト・アルバムを管理しています。
IDクエリ用のAPI + 指定IDを使用したアルバム情報取得方法は判明しましたが、認証の都合で「トークン」が必要です(アプリのIDとパスワードから一時的にアクセスを許可する別パスワードを生成)。
トークンには有効期限(3600秒=1時間)があるため、切れる前に再取得の手続きをするなどちょっとだけハードルが高そうです。
という訳で、今の実装では Spotify を除くインターネットサービスは実装し、利用者に希望のものを選んでもらう方向性でリリースしたいと思います。
上記の仕様に対応するため、web-uiのプラグインを上図のように拡張いたします(fanart.tvがグレーアウトしているのは開発中のため)。