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

    カバーアートモードでの楽曲情報表記に関するアンケートについて

    webui-2021-03-02_sample.png

    とりあえず、PCで表示させたものを貼り付けしています。
    (現バージョンからの改変あり)

    先にお聞きした、ミニプレーヤでのタイトル表示の変更と合わせて、
    カバーアートモードでもスマートホン向けの表示の修正を行おうとしていますが、
    その際にPC側のレイアウトも含めて見直しが必要なことがわかりました。

    ---- 以下見直し理由です。興味のある方はお読みください ----
    具体的には現状カバーアート上部の楽曲文字列情報については「アルバム名」・「トラック名」・「アーティスト名」の3段登録されていますが、
    下の図の通り、「トラック名」ではアルバム名との隙間を作るために上部に余白設定されています。
    (丁度オレンジの部分が上部余白)
    webui-2021-03-02_sample2.png
    この部分がスマホ向けでもスタイル的には余白として認識されるため、
    スマホ画面では余白が広すぎてカッコ悪いため調整予定です。
    webui-2021-03-02_sample3.png

    ---- 見直し理由おわり ----

    で、本題です。
    今回、カバーアートモードの方も表示を整えようと思いますが、
    その際の方向性をお聞きしたいと思います。
    (1行に収まり切らない場合を想定しています)

    質問1:
     PC・タブレット向けの高解像度向けの文字列表示の仕様はどちらを希望しますか?
    ①marquee (1行に収まらない場合はスクロールさせる
          ミニプレーヤで実績あり)
    ②複数行表示(基本的には全文字列表示するまで改行の予定)

    質問2:
     スマートフォン向けの文字列表示はどちらを希望しますか?
    ①marquee
    ②複数行表示(ただし2行までの制限付きになる可能性あり)

    他に「こんな良い方法あるんだが」というアイデアもありましたら、ご提案頂ければと思います。
    (もちろん「見た目の提案」で結構です。実現方法は調査してみます。)

  • @sunatomo さま

    私の好みは
    質問1:①marquee
    質問2:①marquee
    です。

    理由
    アートワーク、制御ボタン、シークバーの表示位置が楽曲情報の表示行数で変化してしまうので。
    そういう意味ではInfomation Areaを開くとアートワークから下の表示が下側にずれてしまうのも気になります。

    逆にこれらの楽曲情報がシークバーの下側に表示されているとアートワークの位置が固定されて気にならないかも知れません。
    ただし、レイアウトの関係でスクロールしないと楽曲情報が見られないような場合はかえって不便かもしれません。
    両立は難しそうですね。

  • @sunatomoさん

    ちなみにラジオの楽曲通知の場合、タイトルにそのまま残りませんか?

    すみません。私の思い違いだったようです。
    ただカバーアートモードの時に、入りきれない文字が右端で切れてしまっていて、それが思い違いの原因だったかもです。

    それから、私の好みも、
    質問1:①marquee
    質問2:①marquee
    です。

    できたら、Spotifyと同じように、左スクロールして端まで行ったら、右スクロールしてを何度も繰り返すのが、良いかと思います。

  • @sunatomo さま
    質問 1→①marquee
    質問 2→①marquee
    私も他の方と同様です。

  • @kens さま、 @mgroovy さま、 @toshi300 さま
    アンケートにご回答頂き、ありがとうございます。

    とりあえず、他の方からは回答がありませんでしたので 双方 marquee で仕上げてみました。
    実際の動作を見て「やはり変更したほうがよい」 というのもアリだと思いますので、
    その際は調整しますね。


    2021ー03ー05 版のWebui-plus 配信について

    改変/改良点 は以下のとおりです。

    • AoEプラグインを開いた際に dreq・recv の現在値を取得

    • アーティスト情報取得のバグ修正
      last.fmから情報取得の際に言語を指定(デフォルトではen=英語)するのですが、
      その言語設定を調節後にCookieにセットする前の「空の状態」では取得に失敗する仕様でしたので、修正しています。

    *※上記アーティスト情報の言語設定はWEB UIプラグインからlast.fmプラグインに今回移動していますのでご注意ください。

    • ミニプレーヤでのスマホ向け楽曲名表示の修正
      従来はカバーアート右横のスキマに表示される仕様でしたが、
      今回からはスマホ向けにはカバーアートを若干暗めにして透過状態にし、
      その上に楽曲が表示される仕様に変更しました。
      (透過の明るさや楽曲文字列の表示方法等は今後改良の可能性はあります。)

    • カバーアートモードでのアルバム名・楽曲名・アーティスト名表示の改良
      今までPC・タブレット向け解像度ではmarquee(スクロール)が有効でしたが、
      今回スマホ向けもmarqueeを有効にしました(PC向けの表示領域をスマホ向けに再利用し、解像度に合わせて文字サイズや領域高さを変更させた。
      おまけですが、楽曲情報・アーティスト情報のボタン位置も再調整しています。)

    • 通知の表示時間調節機能追加
      WEBUIプラグインのnotifyボタン隣に通知の表示時間を指定出来るようにしました。
      (ちなみに通知をOffにした場合は数値調整が出来なくなります。)
      表示時間の指定はミリ秒単位で、既定値は5000ミリ秒 = 5秒になります。
      0を指定すると、通知の☓ボタンを押すまで消えなくなります。


    現時点の宿題についてですが、HTTPS対応の3件は調査の結果では自己署名証明書を使っていることによることがほぼ明らかとなりました。
    無料の認証局を使えばクリアするのでしょうが、
    「有効期限が短いため、毎月更新版を配る必要がある」ことや
    「家庭内で使う分にはHTTPSによる暗号化利用のメリットは少ない」
    と判断し「HTTPS対応は当面は中止」の方向を考えています。
    ↑
    ブラウザに警告されずに自己署名証明書を作る手段が見つかれば別ですが...

    という訳で、今回対応済みではありますが次のネタとしては
    「ミニプレーヤのスマホ向け画面対応」と「カバーアートモードの文字列表示改良」のさらなる煮詰めが先になります。

  • marquee の挙動(スクロール)について

    今までもPC版のミニプレーヤでは対応していましたが、今回改めて動作確認していますので解説します。
    設計的には「メディアプレーヤでタイトル表示される場合」を想定しています。

    • 表示領域と文字列のはみ出し検知について
      実は非表示で文字列幅を検知するためのだけの領域が存在します。
      楽曲・アルバム・アーティスト名の文字列をこの領域に複写し、
      同時に領域の文字列サイズを表示するサイズに合わせて文字列の横幅を計測します(これをaと称する)。
      元々の文字列表示領域の横幅(これをbと称する)は固定であるため、
      a>b ならば表示領域を超えたと判断してスクロールさせるというわけです。

    • スクロール不要時の表示位置について
      領域によって異なります。
      ①ミニプレーヤの楽曲名、アルバム名
       左寄せ
      ②ミニプレーヤのアーティスト名
       右寄せ
      ③カバーアートモードの各情報
       中央寄せ

    • スクロール時の初期状態について
      左寄せで文字列が表示されます。
      (当然右端に文字列がはみ出る状態です)
      2秒間静止状態になります。

    • スクロールの挙動について
      左方向に文字列がスクロールします。
      文字列が領域外に出る前に、若干の空白のあとで右から先頭文字列が表示されます。
      右からの文字列が左端に到着して、スクロールの1動作完了になります。
      (事前の2秒静止と左スクロールを合わせて20秒で1動作になります)

    ※おまけ
    marqueeの動作上、左端から消えた文字列を右端から見せるのはちょっと難しいため、
    実はスクロールさせている文字列は以下のようにして実現しました。
    「表示対象文字列」+「全角スペース3個」+「表示対象文字列」+「全角スペース3個」
    20秒後の1動作完了時は上記で作成した文字列の丁度ど真ん中(50%)まで表示した状態になります。
    (ただしスクロールの初期動作時と同一なため、見分けがつかない)

  • @sunatomo さん

    アップデートありがとうございます!
    といっても、私は今回初めてwebui-plusをインストールしてみたのですけれども。。。(お役に立てておらずすみません)
    インストールはこのスレの一番上に記載のあった方法で実施しました。

    それで気づいた点が何点かありますので、記載致します。

    ・iPhone, Safariを使用していて、カバーアート切り替え直後には、スクロールされず2行で表示されます。
     その後、iPhoneを横に向けてから立てにすると、スクロール表示になります。あるいは、Safariでリロードするとスクロール表示になります。

    ・通知(Notify)をオフにすると一切の通知が表示されませんが、オンにすると、曲を削除する際の通知が無くなり、他の通知は表示されますが、設定秒数が、効いているのかいないのか、ちょっと良く分からなかったです。一気に50msとかしたのが不味かったのかも。。。

    ・RasPi4B版ですが、AoEプラグインが無い気がします。
    (どこかにインスト方法の記載があったらごめんなさい)

    ・ボリュームコントロールですが、MsberryDacの方は効くのですが、dtoverlay=rpi-dacのFifoPi経由の場合にはボリュームが効きません。
    (もしかするとハード的にサポートされていないかもしれませんが)

    このスレとか関係ないかも知れませんが、、、
    ・MPDのプラグインの項目ですが、例えばボリュームコントロールでHardware, none とか設定し、もう一度開いてみると、何も表示されておらず、保存されていないように見える。

    長々と書いてしまいましたが、よろしくお願い致します。

  • @mgroovy さま
    お試し、ありがとうございます。
    状況確認いたしますのでお付き合いください。

    ・iPhone, Safariを使用していて、カバーアート切り替え直後には、スクロールされず2行で表示されます。

    一応iPhoneの機種、お教えください。
    marqueeのために表示領域に対して当該の文字列幅が超過しているかを判別させているのですが、
    恐らくそこの処理に問題があるかもしれません。調査/調整いたします。
    (今回当該部分は今までの設定を流用していたため、もしかしたら過去からのバグが顕在化したかもしれません)

    ・通知(Notify)をオフにすると一切の通知が表示されませんが、オンにすると、曲を削除する際の通知が無くなり、他の通知は表示されますが、設定秒数が、効いているのかいないのか、ちょっと良く分からなかったです。一気に50msとかしたのが不味かったのかも。。。

    とりあえず、1000msecくらいにして様子見て頂けると有り難いです。
    通知についてはOn/Offを追加した時点で「Off時には致命的なエラー以外は表示しない」という処理にしています。
    このため今のロジックでは恐らくすべて表示されるはずですが...
    ちなみに、今回の通知の表示時間変更については設定後に規定値を再設定するように実装しています(当該プロパティだけ書換の方法が分からなかったため)。

    ・RasPi4B版ですが、AoEプラグインが無い気がします。
    (どこかにインスト方法の記載があったらごめんなさい)

    標準ではリンクが漏れているかもしれません。
    以下の通りお試し頂けると幸いです。
    ①sshでRaspberry Piのフロントエンドにログインし、以下の通りコマンド入力

    cd /opt/plugins/detach
    ln -s ../82-aoe 82-aoe
    

    ②webuiにてPLUGINコマンドを開き、AoE CONFIGプラグインをONにする。

    ・ボリュームコントロールですが、MsberryDacの方は効くのですが、dtoverlay=rpi-dacのFifoPi経由の場合にはボリュームが効きません。

    ボリウムコントロールについては手を入れていませんので、特定デバイスで対応しない場合はその設定が正しいか確認する必要があります。
    (もしくはそもそもボリウム調整に対応しないデバイスかもしれません。)

    ・MPDのプラグインの項目ですが、例えばボリュームコントロールでHardware, none とか設定し、もう一度開いてみると、何も表示されておらず、保存されていないように見える。

    MPDのプラグインについてはwebui-plusでは改変していません。
    設定変更後、「OK」ボタンを押しましたか?
    (OK押し下げ後、一旦「mpdとの接続が切れた旨」と「接続した」との通知が表示された場合、
    当該設定を書換えるために裏でmpdが再起動した状態となります。
    このとき、設定変更に成功したと確認出来るかと思います。)

  • @sunatomo さん

    リプライありがとうございます。

    まずiPhoneの機種ですが、昨年発売された第二世代のSEです。

    1000msにして様子見致します。
    ちなみに、On時の操作方法ですが、アルバム一枚追加して再生を行い、再生中にアルバム内の曲を削除する際に、秒数設定に関わらず通知されないです。

    AoEプラグイン、記載いただいた方法で表示され、選べるようになりました!
    ただし、lsaoe, aoestatも表示されないし、動きがおかしいようです。
    journalctl -f 取っていたら、以下のようなメッセージが表示されていました。

    Mar 07 15:29:12 smpd ympd[5819]: /opt/plugins/./attach/82-aoe/run.sh: line 19: unexpected EOF while looking for matching ``'
    Mar 07 15:29:12 smpd ympd[5819]: /opt/plugins/./attach/82-aoe/run.sh: line 54: syntax error: unexpected end of file
    Mar 07 15:29:42 smpd ympd[5835]: /opt/plugins/./attach/82-aoe/run.sh: line 19: unexpected EOF while looking for matching ``'
    Mar 07 15:29:42 smpd ympd[5835]: /opt/plugins/./attach/82-aoe/run.sh: line 54: syntax error: unexpected end of file
    

    MPDプラグインは保存された設定は表示されないのですね?
    おっしゃる通り接続が切れて、接続したメッセージは確認していますので、保存されているので、表示もされるものと思っておりました。

  • @mgroovy さま
    引き続きの確認、誠にありがとうございます。

    • marqueeの動作について
      こちらで動作確認したところ、marqueeの条件確認のための「表示領域と文字列の比較」についてバグがあったことを確認しました。

    • 通知について
      キュー内部の楽曲削除については現状「全楽曲削除」以外は通知しない仕様となっています。
      「通知したほうが良い」という要望でしたら、今後実装方法を検討します。

    • AoEのプラグインについて
      裏で動作するrun.shの記述に誤りがあるようです。
      (すいません。同じファイルを使っているはずなのですが、当方環境でAoEはArch LinuxのRaspberryPi3側のため、
      RaspberryPi4 側へ非正規のファイルが渡った可能性があります。)

    • プラグインのOKボタン押し下げ後の挙動について
      MPDプラグイン含めてプラグインでOKボタンを押し下げした後の挙動ですが、
      RaspberryPi側でプラグインの対応コマンドを実行してその戻り値でsuccessとerrorを返すことは出来るのですが、
      「何をしてどうなった」までは現状は対応していません。

    marqueeとAoEプラグインの件はお手数おかけしますが、今日中に差替版作ってリリースいたします。

  • @sunatomo さん

    どうもありがとうございます。
    修正についてお待ちしておりますが、そんなに急がなくても大丈夫ですよ。
    それからキュー内部の楽曲削除の仕様は、このままの「通知しない」方が良いです。
    よろしくお願い致します。

  • 2021-03-07版のWebui-plus 配信について

    @mgroovy さまご報告の不具合修正になります。
    ご協力ありがとうございました。

    • 再生中楽曲・アルバム・アーティスト名のスクロールに関するバグ修正
      実は前からバグがあったようです。申し訳ありません。
      スクロールを開始するタイミングとしては「楽曲変更時」・「左右端のクリックでモードを切り替えた際」・「ウィンドウサイズを変えた際」の3つがありますが、
      「モード切替時」のスクロールが正常に動作していませんでした。

    • AoEプラグインのsmpd版での不具合修正
      すいません。実際にコマンドを投入するrun.shについて、
      開発途中のものを配布していました。
      (当方AoEについてはArch Linux で動作確認していたため)

  • @sunatomo さん

    不具合修正ありがとうございました!
    とても快適に使わせていただいております。

    五月雨のようになってしまいすみませんが、もう一つ見つけてしまいました。。。

    ラジオを選択して開始すると、最初は曲情報を取得できないためかミニプレイヤーの上の部分、下の部分共にラジオ局名が表示されています。その後曲名が取得できると下の部分には表示されますが、上の
    部分の表示が書き換わらずラジオ局名表示のままになっています。
    カバーアートモードにしてもラジオ局名表示のままになっています。
    この時に、ブラウザをリフレッシュすると現在流れている曲の情報が表示されるようになり、次の曲になると次の曲が表示されます。

    以上はiPhone+Safariでの現象ですが、Windows10+Chromeで同じことをやってみると、ブラウザをリフレッシュするまでは同じ動作なのですが、こちらはリフレッシュ後、次の曲になっても前の曲情報のままになってしまいます。さらにリフレッシュすると現在の曲情報になりますが、次の曲になっても前の曲情報のままです。

    それで修正いただく際の、追加の要望なのですが、もし可能でしたら、二行表示にしていただき、ラジオ局名と現在流れている曲の表示をお願いしたいです。

    急ぎませんので、よろしくお願い致します。

  • @mgroovy さま
    しばらく radio はご無沙汰でこの挙動について失念していました。
    radio にせよ、nasにせよ、mpdから楽曲情報の変更を受けて通知を行っていることは変わりありませんので調査してみます。

  • インターネットラジオに関する調査(その1)

    帰宅後、ちょっとだけ試してみました。

    • エラーメッセージに対する返信のバグについて
      Websocketの仕様について実装誤りがあり、ステータス取得時にエラーを同時に検知した場合はステータスの電文が正常に受信できないことがわかりました。
      (エラー電文とステータス電文を改行コードで繋いだ場合、受け取り側のクライアントで電文解析時にエラーになる)
      次回のアップデートで修正します。

    • インターネットラジオでの解析エラー時のメッセージについて
      AudiophileでURLエラーが発生していますね。
      その際にステータスでエラーが発生すると、他の楽曲再生を行うまでエラーメッセージを連続で吐き続けてかなり鬱陶しくなりますね。
      (ちょっと見ではエラーメッセージの表示を1回だけに留める方法が思い付きませんでした。)

    • 楽曲名の書換について
      一般的なNASの場合楽曲が変わった時点で検知できるのですが、
      インターネットラジオの場合はキューが更新された際にキュー側の最上位リストの楽曲名しか変わらない場合が多いので、
      これをどうやって楽曲名として表示させるのかがちょっと悩ましいところです。

  • インターネットラジオに関する調査(その2)

    • メッセージのバグ
      送信予定の文字列バッファ内の区切り文字(\n)で電文を分けて2回送信する仕様にしてバグ修正は終わりました。

    • ステータス系のエラー対応について
      libmpdclientのドキュメントをググったところ、mpd_run_clearerror関数でエラーメッセージを消せることがわかり、
      1回だけ送信することが可能になりました。

    さて、あとはキューの先頭から再生中の楽曲名称を取得するところ考えてみたいと思います。

  • @sunatomo
    I upgraded to webui-plus 2021-03-07 (Arch Linux AoE) very nice interface with very convenient AoE Config plugin. Thanks very much . 👍

    alt text

  • @linh0983
    Thank you for your using webui-plus.
    If you have any suggestion, wish, or claims, please send me message.
    (I'm going to support and fix feature if mpd server team or @パパリウス provides).

  • インターネットラジオに関する調査(その3)

    ラジオから返される楽曲名について
    完全に調べられた訳ではありませんが、以下の3パターンありそうです。

    1. 楽曲が切り替わるパターン
      Linn Radioがこのパターンです。現状この場合のみ、トラック名を表示可能です。
      (NASの場合と同じく、楽曲ファイルが次々変わっていくのをmpdが検知してその都度新しい楽曲の情報を返すやり方です。)

    2. キューのバージョンが変わるパターン
      Radio Swissがこのパターンです。
      現状はキュー上のタイトルしか変化しませんが、
      キューのバージョンアップを検知してRaspberryPiが「Queue Change」のメッセージをクライアント送っているのですから、
      このときに再生中の楽曲(キューのトップの楽曲のみ)を返す仕様にして楽曲情報をプレーヤ側にも表示できるように実装中です。

    3. 何も返してくれないパターン
      BBC がこのパターンです。
      mpdに問題があるのか、先方のラジオストリームに原因があるのか不明ですが、この場合は楽曲情報がmpdでは取得できません。
      ただし、このパターンのみ楽曲情報としてラジオステーション名が表示されます。
      (恐らく、plsファイルの名称をそのまま表記しただけと想定される)

    というわけで、現状の調査結果では以下の通りの結果です。
    「ラジオ局から現在再生中の楽曲を返してくれる場合は、ラジオ局名は取得できない」
    「ラジオ局が現在再生中のラジオ局を返さない場合、plsファイルのラジオ局名を楽曲名として表示」

  • @sunatomo
    I like the addition of the AoE Config plugin, it is very helpful. I do not that there may be a display issue with the parameter values. They seem to be cutting off the second number in both of the values.
    77f42f99-39c4-4a7b-b750-ed1dcc45293d-image.png

    RaspPi4b x 2 / IanCanada Stack powered by LiFEPo4 & Ultracaps /
    Bisek Output Transformers