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

    今まで説明していませんでしたがWebuiではキーボード・ショートカットが有効になっています。

    今の所割り当てられているキーは以下のとおりです。

    • "←"(左向き矢印)
      キューの一つ前の楽曲に戻る

    • "→"(右向き矢印)
      キューの次の楽曲に進む

    • ” ”(スペース)
      キューの再生/一時停止+キューモード・カバーアートモードの切替
      (現状の作り込みが悪く、2つの挙動をスペースキーで兼ねていたので
      今後リリースのWebui-plusで修正し、再生/一時停止を"p"キーに変更します。)

    • "c"
      ConsumeのOn/Off切替(プラグイン側のボタン表示をキーと連動させるのはもう少し後までお待ちください)

    • "r"
      リピートのOn/Off切替※

    • "s"
      シャッフルのOn/Off切替※

    ※”r"・"s"はカバーアートモードで表示されるアイコンも連動して切り替わります。

    キーボード・ショートカットで単独のキー割り当てならば容易に出来ますので、
    今後も拡張については考えていきたいと思います。
    (今の所↑↓での音量調節・Grid/リストビュー切替・通知On/Off切替は対応しようかなぁと)


    先に記載したキューモードでの上部カバーアート・楽曲情報表示部分を畳み込みする処理ですが、
    とりあえず動作するものは出来たのですが以下の問題を現状の私の能力では解決しきれないため一旦塩漬けにします。

    • 切替表示が重い
      Bootstrapのアコーディオンを採用したのですが、操作した限りでは現状のWebuiの持つ軽快感が損なわれている。
      また、アコーディオンの動作時に一部スタイルの配置で再計算を行うようで、常時固定位置で動いてほしくない各コンポーネントがブルッと動いてしまう。

    • カバーアートとリスト/グリッド表示部分の重なりが制御できない。
      リスト部分がせり上がる際にカバーアートを隠すようにcss記述したはずなのですが、完全に隠れるまではカバーアートが常に最上部に見えてかっこ悪い。
      (リスト部分が上に上がりきった際にいきなりカバーアートが消える)


    というわけで、機能的な改善はあまり変わりませんが、
    「キーボード・ショートカット」と「アコーディオン対応の際にメインのCSSで見つけたレイアウト設定」の不具合をなおした修正版を早ければ明日、遅くとも今週末にリリースいたします。

  • 11月4日付のテストビルド配信について

    レイアウトはこれからの改善次第となりますが、機能としては個人的にはこれをやっておこうかなと思うものを実装しましたのでテストビルド配信しました。

    • キーボード・ショートカットの改良
       新たに"↑"・"↓"でボリウム上昇・下降(5%づつ)、
      "g"でグリッド/リストの切替
      "n"で通知のOn/Offの切替をサポートしました。
      また、一部のショートカットのキーについて通知がうまく行われていないため修正しています。

    • カバーアートモードでの楽曲追加情報表示に対応
      mpdで現在再生中の楽曲からはその楽曲のタグや楽曲固有の情報についてはWebuiのブラウザには転送されていましたが、
      表示する方法について決まっていませんでした。

    (もう少し詳しく書くと、ビットレート・ビット数・フレームレートなどは再生時のステータスとして毎秒、楽曲名・アルバム名・アーティスト名など楽曲の埋込タグの情報は再生楽曲の切り替わり時に伝送されます。)

    今回、一応試作段階になりますが、カバーアート上部に楽曲再生中に取得される情報を全て表示させることが出来るようにしました。
    (従来のカバーアート情報に表示されているものはそのまま変更なしという考え方です。
    その気になれば今回拡張した表の中に収容することも可能です。)
    Screenshot from 2020-11-04 19-21-42.png
    ↑
    自宅のブラウザで表示させた際の例ですが、フルHDだと横幅的に持て余しますね。

    「SongInfo」ボタンを押すと、従来表示されていない楽曲情報を表示します。
    (もう一度押すと従来のカバーアートモードと同じく情報表示は消えます。)
    なお、楽曲情報はスマホのような画面の小さな端末では現状対応しません。

    • スタイルシートの不整合修正
      開発凍結しましたが、アコーディオンを実装している際にスタイルシートで不整合(具体的には余白の定義や各パーツの高さなどの誤り)があったことを確認したため、これの修正を行っています。

    楽曲情報については、今後インターネットの音楽サービス(last.fm・Spotifyなど)から楽曲・アルバム・アーティスト情報を取得する際の表示方法の土台と考えています。
    当然ながら現在のレイアウトで決まりではありませんし、mpdの楽曲に格納された他のタグの情報も取り出すことは可能ですので、
    色々とご意見・ご提案があればと思います。

  • @sunatomo さま
    @パパリウス さま
    こちらか、v1.0サポートか迷いましたが、こちらに投稿させていただきます。
    UPDATE LIBRARYのBACKUP/RESTOREって正常に機能していますでしょうか?
    BACKUPをクリックしてもNASにバックアップファイルが保存されないようです。

    v1.0.10 + 11/4テストビルド
    Win10 Google Chrome 86.0.4240.183

  • @kens さま
    検証してみました。
    当該のプラグインを開いた際に「Uncaught TypeError: Cannot read property 'trim' of undefined」と言うメッセージが出てスクリプトの処理が止まっていますね。
    メッセージから判断すると、webui-plusでjqueryをv3.5.1までバージョンアップした際に$.trimコマンドが廃止されたのが原因だと思われます。
    詳細調査しますので、もう少しお待ちください。

    当該プラグインの初期化(表示)の際にアップデート対象ディレクトリが現在参照中の場所を基準に自動的に表示されますが、
    webuiを初期化時には当該変数が未定義状態であったためにエラーとなっていました。

    という訳で、webui-plusの差替版でこのエラーは修正いたしますが、
    それまでの間は「webuiを開いたら一旦キュー表示からディレクトリ表示に切替する」ことで対応頂けると幸いです。

  • 2020-11-07版のwebui-plus配信について

    まだ、荒削りな部分はあると思いますが、当面の機能についてはリリース版に近づいたかと思います。
    ※11/08 21:19記載
    予定通りアーティスト情報表示部分の高さがlast.fmから取得した文字列数により高すぎになる現象対策したものを配信しています。

    • UPDATE LIBRARYプラグインでの不具合修正について
      @kens さまご報告の件です。
      前の投稿にも書きましたが、現在参照中のNAS上のディレクトリを保存する変数の初期化漏れでした。

    • カバーアートモードでの情報表示対応
      11/04テストビルドで対応した楽曲情報に続き、last.fmから得られるアーティスト情報の表示に対応しました。
      なお、現状は以下の仕様となります。

    ①楽曲・アーティスト情報ボタンの表示を変更
    「single」・「repeat」・「rundom」などと同じような仕様(ただしサイズは未調整)としました。画面イメージの吹き出しアイコンになります。
    楽曲名と同じ高さのボタンが「楽曲の追加情報」、アーティスト名と同じ高さのボタンが「アーティスト情報」になります。
    ボタンの仕様は「非表示時に押したら、情報表示」し「表示中に押したら、情報欄を隠す」動作となります。
    また、楽曲情報とアーティスト情報はどちらか1個のみが表示されます。
    (楽曲情報表示時にアーティスト情報のボタンを押すと楽曲情報は隠れる)
    なお、キューから楽曲が消された場合は情報表示部分だけではなくボタン自体も表示されません。
    アーティスト情報については高さ制限をしています。
    スクロールバーが隠れていますが、スワイプないしホイールの回転で表示外の文字列をスクロールさせることが出来ます。

    ②現在再生中の楽曲のタグに記録されている「アーティスト名」で検索
    フィーチャーアーティストのようにlast.fmで記録が無いものは取得できません。

    ③抽出対象の言語を指定出来ます
    WEBUIプラグインに「shown lang」という項目を用意しましたので、こちらで言語を指定してください。指定後、情報ボタンを再クリックすれば
    現状はenとjaだけですが、 ISO 639 に基づく2文字コードを記載すればその言語向けに当該アーティストの説明が記載されていれば指定言語で見ることが出来ます(es,de,ruなど確認済み)。

    以下、画面イメージを貼り付けします。
    Screenshot from 2020-11-07 21-13-15.png
    アーティスト情報の表示例
    (「勝手にしやがれ」の右横ボタンをクリック)

    Screenshot from 2020-11-07 21-13-26.png
    WEB UIプラグインの表示例
    (項目数増加につき、レイアウト一部変更。一番下に「Shown Lang」項目を追加)

  • @sunatomo さま
    早速、2020-11-07版のwebui-plus配信を試させていただいております。

    UPDATE LIBRARYのBACKUPが正常に機能することを確認できました。

    last.fmから得られるアーティスト情報は良い感じです。
    但し、曲が変わってアーティスト表示が切り替わっても、アーティスト情報は自動的に更新されないのですね。
    楽曲情報は可変ビットレートのようにFrame Rateが毎秒違った値で更新されると、フォントのプロポーションの関係?で左から2~4列目の表示が横方向にヒクヒク動いてしまうのが気になります。(桁数が変化すると顕著)

    Win10 Google Chrome 86.0.4240.183

  • @kens さま
    お試し、ありがとうございます。
    (UPDATE LIBRARYの件、お手数おかけしました)

    但し、曲が変わってアーティスト表示が切り替わっても、アーティスト情報は自動的に更新されないのですね。

    これについては対応忘れていました。現状楽曲の切り替わりで各文字列が書換されていますので容易に出来るかと思います。

    「フレームレートが都度変わることにより文字がブレる件」については解決方法考えてみます。
    (固定幅フォント、preタグ使用、右揃えでブレを気にしなくするあたりでしょうか)


    さて、カバーアートモードの拡充のつもりで楽曲関係の情報を表示する機能を実装し始めましたが、
    ここで皆さんにアンケートを一旦取り、方向性を練ってみたいと思います。

    楽曲・アーティスト関係の情報を表示する手段としてどれが適していると思いますか?

    ①カバーアートモードに専用領域を作り常時表示
    ②カバーアートモードでユーザがボタンを押したタイミングで表示
     (現状提供したwebui-plusと同等の機能の改良版)
    ③カバーアートモードの楽曲名表示部にボタンはあっても良いが
     表示自体はプラグインと同じモーダルウィンドウ化
    ④完全プラグイン化(プラグインメニューからモーダルウィンドウを開く)
    ⑤その他
     これに限りご自分の考える理想的な表示方法についてご提案ください。

    楽曲情報については使わない場合でもその観点でお答え頂いて構いません(「前とレイアウト変わって使いにくい」も有用な意見ですので)。
    なお、ある程度回答が集まるまでは私の方はScrobbleの実現方法など、他の調査ネタを進めていきます。

  • sunatomoさん        CC.パパリウスさん、皆様

    こんにちは。

    MPDクライアントである「yaMPC」の開発者の方から、アルバムカバーアートの取得に関して、以下の情報をいただきました。

    ----引用開始----

    MPD 0.21でカバーアートを直接取得するコマンド(albumart)が追加され、最近、APIである libmpdclientがバイナリデータの取得をサポートしましたので、yaMPCもHTTPに頼らず、MPDから直接カバーアートを取得できるようになりました。

    必要なもの:
     MPD 0.21以降(初期バージョンはalbumartにデッドロックのバグがあるので0.21.5以降を推奨)

    制約:(albumartコマンドの制約)
     カバーアートのファイル名は cover.jpg のみ対応

    -----引用終わり-----

    Symphonic-MPDにおけるWEB-UIの仕組みとの関連性は当方判っておりませんので、有用性は無いのかも? また既にご存知の事項かもしれませんが、為念ご参考まで。

    ただし、カバーアートファイル名が「cover.jpg」の決め打ちのようなので、folder.jpgを既に使用している方が多いとすれば多少微妙なところがあるかもしれませんね。

  • @ゴンザエモン さま
    有用な情報ありがとうございます。

    これらに対するympdでの状況については以下のとおりになっています。
    libmpdclientからバイナリデータを取得出来る件については
    実は当方で開発しているympdでもコードは実装されています。
    ただし、yaMPCの開発者が言及する通り、有効化したことによりmpdサーバの不具合が発生したことから現状は無効化されています。

    NAS上のカバーアートファイルについてはympd自体がHTTPサーバの機能を有している=「自由にファイル名を指定してHTTPサーバからWebブラウザに直接表示可能」なため、
    mpd経由でバイナリデータを貰って表示させる必要があまりないのが正直な感想です。
    (逆にympdではNAS上のカバーアートファイル名を色々設定可能なのが利点かと。)
    yaMPCのような専用クライアントの場合、HTTPプロトコルのやり取りをできるだけ無くしたほうが良いと思いますので
    上記の構造は有効でしょうね...

  • last.fmでの書込権限が必要なAPIへのアクセスについて

    scrobble対応ですが、原理試作は今日の時点で動作したので、
    どのような要素が必要なのかメモで纏めます。
    (他に対応したいアプリを開発する方へ塩を送るつもりで)
    自分でAPIのドキュメントを確認したい場合はScrobbing 2.0 Documentation
    と、
    Authentication: Desktop Application How-Toが参考になるでしょう。

    ①アプリケーション向けのAPIキーを取得する
     従来のympdにはカバーアート取得用のAPIキーは実装されていますが、
     合わせて共有シークレットというキーも書込の際は必要になります。
     現状のympdにはコレがないため、とりあえず私のアカウントでAPIを再取得しました。
     → APIキー・シークレットは最終的にどれを使うか、 @パパリウス さまと相談します

    ②ユーザとアプリケーションを接続する作業を行う
     last.fmのAPIがlast.fmを使用するユーザのアカウントにアクセスするためには、
     事前に許可された状態かつアクセスのためのセッションが必要になります。
     コレを得るために以下の処理を順に行う必要があります。
     今回の使い方ではlast.fmで提供されている方法のうち、Desktop Applicationを使用しました。
    (Spotifyのアクセス検証時も類似でしたが、Web APIの場合はインターネット上に公開したサーバへのコールバックが必要そうだったため、この方法を選択)

    • APIキーを指定してトークン(アクセスするための一時キー)を取得する
      トークン取得のためのURLは"http://ws.audioscrobbler.com/2.0/?method=auth.gettoken&format=json"になります。
      パラメータとしてapi_key(アプリのAPIキー)が必須となります。
      api_sigが必須とドキュメントには記載されていますが、指定しなくてもトークンは取得できました
      トークンはjsonで返されます(XML返送も可能)。
    • APIキーとトークンを使用してlast.fmのユーザアカウントへの認証許可を得る
      (last.fmへログイン済みのWebブラウザ上で、ユーザアカウントへのアクセスを許可させる)
      許可のURLはhttp://www.last.fm/api/auth/?
      パラメータはapi_keyとtokenを指定します
    • list itemAPIキー・トークン・署名を使用してセッションを取得する
      →ユーザと書込権限の必要なAPI(アプリケーション)を紐付けするものは「セッション文字列」になります。
      セッションと言いますが、アクセス期限は一度設定すると無期限のようです(ユーザ設定画面で紐付けを切ると当然アクセスできなくなる)。
      URLは"http://ws.audioscrobbler.com/2.0/?method=auth.getSession"
      パラメータはapi_key,token,api_sigです。
      このapi_sigがちょっと曲者で、api_key・method・tokenの各キー名とその値をキー名のアルファベット順に並べて最後にAPIのシークレット文字列を連結した文字列をmd5でハッシュを計算した値になります。
      api_sigはこの後のscrobble関連の各APIでも使用します(並べる文字列はAPI毎に指定したパラメータをキーのアルファベット順に並べたものになります)。

    ③scroblleのための書込API対応
     単純にscroblleを再生中に送るだけではだめなようです。

    • 再生開始時に「nowPlaying」リクエストを送ります
      このAPIを送るとlast.fmのユーザアカウントで「Scrobbing now」として表示されます。
    • 実際のscrobbleのタイミングは以下の条件となります。
       楽曲が30秒以上でありかつ上記のどちらかの条件を最短で満たした場合
       a.再生時間が楽曲の時間の半分を超えた
       b.再生時間が4分を超えた
      nowPlaying、scrobble共にアーティスト・トラック名は必須です(nowPlayingの場合はアルバム名必須、scrobbleの場合は再生開始時刻をUNIX時間で必須)。
      ympdではアルバム・アルバムアーティスト名は標準的に取得出来ていますので、こちらもパラメータとして渡すように設計しています。
      認証パラメータとしてはAPIキー・セッションキー・そしてapi_sigの3つです。

    現状の実装状況としては、②の作業をURL直打ちで行い、セッションを作成しました。
    (セッションを作成すると、last.fmのユーザアカウントページのSettng内Applicationにそのアプリの名前が表示されるようになります。)

    また、③のscrobbleのために必要なAPIキー・シークレット・セッションキーについては現状はwebuiのJavascriptファイルにハードコーディングしています。
    (APIキー・シークレットはそのままハードコーディングしますが、セッションキーはユーザ毎に異なるため、/etc/webui.cfgに保存させる予定です。)

    皆さんにwebui-plusの機能として提供するためには以下の3つの実装+検証が必要です。
    ①各ユーザ向けセッション文字列を得るための設定画面
     web-uiプラグイン内で用意するつもりです。
    ②セッション文字列はWebブラウザが変わった場合でも対応するかの確認
    (試作の際はセッション文字列取得とWebuiでのscrobble動作確認を同一のブラウザで実施したため、
    scrobbleを別な端末で先に取得したセッション文字列で行った場合はどういう挙動になるかまだ不明。)
    ③scrobbleが不要な人向けに処理をパスする設定

    早ければ来週末にはscrobble対応版リリースできるかもしれません。

  • webuiでhttpsを使いたい場合の設定について(未完)

    前に実証試験を実施した上記の件ですが、
    私の設定が足りずにympdの内部で使用しているmongoose(組み込みWebサーバ)では対応していない旨を書いていました。
    今回、完全対応ではありませんが判明した事項がありましたので、
    途中報告とします。
    ※最後に補足を書きますが、現状わかっている設定だけでは最新のWebブラウザではhttpsの接続でエラーが出ることがわかっていますが、
    技術的には可能だという話になります。

    • 証明書ファイルの生成
      以下のコマンドで証明書ファイルを生成し、ympdのhttpサーバのドキュメントルートに複写します。
    openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 1000 -nodes
    cat key.pem cert.pem > ssl.pem
    cp ssl.pem /var/lib/mpd/music
    
    • httpsのポート設定
      /lib/systemd/system/ympd.socketを以下のように設定します。
    [Socket]
    #ListenStream=80
    ListenStream=443
    KeepAlive=true
    PassCredentials=true
    
    [Install]
    WantedBy=sockets.target
    

    [Socket]部のListenStreamが通常80と書かれていますが、これを希望のポート番号に替えます(httpsは通常443ポートのため、例では443にしています。)

    • ympdの設定
      /lib/systemd/system/ympd.socketを以下のように設定します。
    [Unit]
    Description=ympd server daemon
    Requires=network.target local-fs.target
    After=mpd.service
    
    [Service]
    EnvironmentFile=/etc/environment
    Type=simple
    ExecStartPre=/usr/bin/ympd-plus.sh
    #ExecStart=/usr/bin/ympd -h /run/mpd/socket --webport 80 -i 200 --documentroot /var/lib/mpd/music
    ExecStart=/usr/bin/ympd -h /run/mpd/socket --webport "ssl://443:/var/lib/mpd/music/ssl.pem" -i 200 --documentroot /var/lib/mpd/music
    
    User=root
    CPUSchedulingPolicy=other
    CPUAffinity=3
    
    [Install]
    WantedBy=multi-user.target
    
    

    ExexStart 行の
    --webport 80 を
    --webport "ssl://443:/var/lib/mpd/music/ssl.pem"
    に書き換えします。
    (前項でympd.socketのポートを443以外にした場合はこの行の443もそれに合わせてください)

    両方のファイルを書換後、
    systemctl daemon-reload
    を実行後に

    systemctl stop ympd.service
    systemctl stop ympd.socket
    systemctl start ympd.socket
    systemctl start ympd.service 
    

    で再起動してください。

    • 最後に
      ここまで説明しましたが、現状の最新のブラウザでは表示させようとした時点でエラーが表示されてhttpsでは動作しません。
      理由は今回作成した証明書が自己署名証明書(公式の認証局から証明されていない)であるため、エラーで弾かれるためのようです。
      解決するためには認証局証明書を自分のブラウザに追加する必要がありますが、果たしてそこまでしてwebuiをhttpsで使いたい方居ますかね...
  • @sunatomo さま
    httpsでアクセスすると、ympdの内部で使用しているmongoose(組み込みWebサーバ)とブラウザとの通信が暗号化されるのですよね。
    IPアドレス直打ちアクセスだとSSLは機能しないか。(自己署名証明書は関係ない?)

    NASのユーザー名、パスワード設定や将来last.fmのユーザーアカウントの設定をする際に気にするかと言われると、
    私は自宅LAN内で使用する想定なので、特にhttpsで暗号化する必要性は感じていません。
    Chromeでは"保護されていない通信"と警告表示されますけど気にしません。

  • @kens さま
    IP直打ちでも暗号化はされます。要は通信経路を暗号化するのがSSL(現状はTLS)の目的です。
    「webui(RaspberryPi4)とそれを制御する各クライアントはローカルネットワークに設置されているため、通信経路を暗号化してもあまり意味が無いんじゃね」ということです。

    「インターネット接続前提ならばもう暗号化は当然」というのが最新Webブラウザの設計になるので、非正規の証明書含めて警告表示という流れでしょうね...


    さて、Scrobbleの件ですが設計変更を行います。
    元々はクライアント側のJavaScriptでScrobbleを送るように開発を行ってきましたが、「複数のクライアントを同時使用していた場合、Scrobbleもlast.fmのサーバに複数ほぼ同時に送る」ということに今さら気づきました。

    というわけで、RaspberryPi4側から送る仕様に変更します。
    curlとmd5sumを使用することで、まずは追加ライブラリなしの方向性にします。
    ついでにAPIのセッションキーを/etc/webui.cfgに保存+取り出しする部分の開発も行います。
    合わせてScrobble要・不要のフラグも/etc/webui.cfgに保存が必要ですので、こちらも対応します。
    なお、Scrobbleは「フラグを立てた場合のみ対応」としますので、不要な方も安心してください。

  • Scrobbleの進捗(と言う名の言い訳)
    この連休に機能を実装できればと思って進めてきましたが、
    残念ながら以上の点で問題がありもう少し時間が必要そうです。

    1.updateNowPlayingは動作したのですが、scrobbleの方でエラー(Invalid method signature supplied)が出る。
     api_sigのハッシュ値が指定したパラメータと合わないためなのはわかるのですが...
     (関連してマルチバイト対応が大丈夫かも調べないとなりませんねぇ)

    2.Webuiプラグイン側でセッションを取得する部分が未完成
     token取得と、ユーザアカウントへの認証許可部分は出来ましたが、
     最後にsessionを得る部分の動作確認が済んでいません。

    という訳で、もう少し時間がかかりそうって報告でした。

  • RaspberryPi4側でのtrack.scrobble、やっと動作いたしました。

    パラメータの仕様では大量のトラックを1回のコマンドで同時scrobble出来るように[*] (アスタリスク内は0〜49の数字)という形でartist・album・track・timestampを配列指定することでバッチ登録出来るのですが、
    結果としてはこれを使用した場合にハッシュ値との相違が出るのが原因でした。
    ドキュメントを再度読み込んだところ、
    「パラメータの単体指定時には[*]は不要」という記載があり、
    消したところ正常動作しました。

    JavaScriptで実装した際はパラメータに[0]を付加しても問題なくCでおかしくなるのは釈然としませんが、
    提供する機能としては1曲毎にscrobbleを送信する予定であるため、この方向で行きます。
    (なお、マルチバイト時の動作については確認の結果OKでした。)

    あとは
    「Webuiプラグイン側でのセッション取得部分の実装」
    「巻き戻し・早送りでのscrobble動作の調整」
    「last.fmからのレスポンス処理」
    が残っていますので、
    28日目処にリリースを目指します。

  • 2020-11-28 版のWebui-plus配信について

    「煮詰めが足りん」と言われる部分が有るかもしれませんが、配信させて頂きます。
    (厳密なエラー処理の未実装+内部動作確認用の情報出力が有効な状態)
    今回の改良点は「last.fm」のScrobble対応、です。


    Scrobbleとは

    自分が現在聞いている楽曲の情報をlast.fmに転送する機能です。
    伝送された楽曲情報はlast.fm上の各自のアカウント単位で集計されたり、同じ楽曲のYoutube動画をサイト内で視聴することが可能になります。
    scrobble-sample.png
    「こういう情報を他人に握られるのは嫌」って方もおられると思いますが、
    私は「自分の趣向などを集計したものが後で確認出来るのは結構面白い」と思います。
    (開発前は「要るかなぁ?」とも思いましたが、開発中にブラウザ上のアカウントにscrobbleの結果が流れて集計されるを見て、
    個人的にはOnにしてしばらく使おうかと考えています。)

    ※last.fmのサービス自体がインターネット上のサービスであるため、
    Scrobbleを有効にする場合は「RaspberryPiからインターネット接続が可能な環境に置く必要があり」ます。
    音質向上などを考えて「閉じたネットワークに置いた場合は当然動作しません」ので、
    ご承知おきください。

    Scrobbleの有効方法

    できればPC等の画面解像度が広く、複数ウィンドウ表示の可能なWebブラウザの使用をお勧めします(スマホ・ipadでの動作確認は未実施)。

    1.last.fmへの加入+ログイン
     Scrobble自体はlast.fmが提供するサービスです。当然加入する必要があります(無料アカウントで結構です)。
     既に加入中の場合は、Webuiに対してScrobbleを設定するブラウザでlast.fmにログイン状態にしておいてください。

    2.Webui-plusの「Webui」プラグインを開く
     ご覧の画面にプラグインが変更されています。
    webui-2020-11-28.png
     Scrobble関連のボタン類は「last.fm」タグにまとめてあります。
     last.fmのAPIを叩いてScrobbleを送るためにはAPIキー・APIシークレット・セッションキーという3つのパスワード文字列が必要になります。
     APIキー・APIシークレットはWebUIにすでに組み込まれています。
     セッションキーは各last.fmユーザアカウント毎に作成される(当然ユーザ毎に異なる)ので、自分専用のセッションキーを取得するための処理が必要です。

    3.トークンの取得
     「Webui」プラグインを開いた瞬間、セッションキーを取得するために必要なトークンという文字列をlast.fmに請求し、これを取得済みの状態になります。
     トークンには有効時間があります。
     ドキュメントを見ましたが、何分まで有効かは明記されていませんでした。
     おおよそ10分以内でセッションキー取得まで終わらせることをお勧めします。
     もし、時間を要した場合はwebuiプラグインを再度開いて新しいトークンを取得してください。

    4.last.fmユーザとympdの紐付け(認証)
     「Get Auth」ボタンを押すと、小さなウィンドウが開き、
    「ympd for symphonic-mpd」が貴方のlast.fm アカウントにアクセスする旨の
    許可が聞かれます。
    lastfm-auth1.png

    セッションキーを取得する場合、この画面で許可をしてあげてください。
    許可を有効にするとこの画面になります。
    lastfm-auth2.png

    (許可後、このウィンドウは閉じても良いです)
    もし、許可の画面が開いておらず、ログイン画面になっている場合はlast.fmに貴方のアカウントでログインしてください。

    5.セッションキーの取得と保存
     「Get Session」ボタンを押してlast.fm側で正常に処理されると、
    内部でセッションキー文字列が取得されてRaspberryPi4の/etc/webui.cfgに保存されます(同時にympdのプログラム内にも保存されます。)

    Scrobbleの実行方法

    Webuiプラグインを開き、「Scrobble」ボタンをOnにします。
    ※Scrobbleボタン右横の文字列が「session-key available」ではない場合は、
    セッションキー未取得のためScrobbleはされません。
    あとは貴方が再生した楽曲が自動的にlast.fmへScrobbleされます。

    last.fmへのデータ伝送は1曲あたり以下の2回実施されます。
    楽曲再生直後:updateNowPlaying(現在再生中の楽曲を通知)
    Scrobble条件成立時:Scrobble
    (条件成立は楽曲が30秒以上かつ「再生時間が楽曲の半分以上もしくは4分異常を超えた」際)

    現時点での仕様ほかについて

    • Webuiプラグインでセッションキーを取得後、Webuiプラグインの「Scrobble」ボタン横の文字列がセッションキー取得済みに変わらない
      (鬱陶しいですが、セッションキー取得時に画面左下に通知がありますのでこれで代用願います)

    • 枚曲再生時にScrobbleされるのは止めて纏めて送る仕様にしてほしい。
      バッチ対応は将来的には考えたいと思います。

    • セッションキーを再取得するには
      一度、ブラウザでlast.fmにログインし、貴方のアカウント設定で「Settings」の「Application」タブで表示される「ympd for symphonic-mpd」を「Disconnect」してください。
      その後、セッションキーの取得を説明したとおり実施すれば/etc/webui.cfgに記録されます。

    • Scrobble時に伝送される情報について
      私の手元のライブラリに問題があり、AlbumArtistを送った場合は正常なアルバムと認識されなかったことがあったので、AlbumArtistは送らない仕様にしています。

    • APIキーとSecret文字列について
      last.fmの無料アカウントを使用中の私が開発用として取得した「ympd for symphonic-mpd」というものを使っています。
      ( @パパリウス さまと相談しますと言ってましたが、まだ行っていません。)
      将来的に別なキーになる場合はアナウンスしますので、再設定をお願いします。
      ※APIキー・セッション文字列が変更されても貴方のアカウントのScrobbleの履歴は消えません。


    その他使ってみて質問や機能改善提案などありましたら、ご所望くださいませ。

  • @sunatomo さま
    last.fmのScrobble機能対応、楽しみにしておりました。
    ところが、

    app install webui-plus

    を実行してreboot後にWEB UIのメニューを表示させてみたのですが、
    last.fmに関する設定項目が表示されません。
    ブラウザのキャッシュクリアも試しましたが、やはり表示されませんでした。

    Chrome/Edge

  • @kens さま
    誠に申し訳ありません。こちらの作業ミスでパッケージサーバ内でのファイル転送失敗していたことがわかりました。
    先程、パッケージを転送し直ししていますので、再度アップデートして頂けると幸いです。

    念の為Webuiのプラグインも以下の通り一部挙動を見直ししています。

    • Scrobbleボタンが「On」の際だけ、他のlast.fm関係のボタンが操作出来るようにした。
    • Scrobbleボタンが「On」になった際と、Webuiプラグイン読み込み時に「On」である場合のみlast.fmに対してtokenを取りに行くようにした
    • ScrobbleOn/Off切替時の通知タイミングの調整
      (従来は切替直後のサーバ側の状態を受信していたため、実際のフラグとは異なる値を返すことがあった)
    • SessionKey有無のメッセージ表示の改善

    (下の2つが正常動作していると判断した場合、通知を取りやめしようかと思います)

  • @sunatomo さま

    早速の対応ありがとうございます。

    色々試しているのですが、Scrobbleがうまくいきません。
    sunatomoさんの説明文の1~4までは記述通り進めることができます。
    4の操作後、WEB UIをOKで抜けた後、

    /etc/webui.cfg

    を確認したところ

    #last.fm Scrobble flg
    Scrobble=1

    #last.fm api session-key
    lstSession=

    となっており、lstSessionには何も保存されていないように見えます。
    Scrobble=はOn(1)/Off(0)が設定通り反映されます。

    4の操作の後、last.fmの「Settings」の「Application」タブには
    ympd for symphonic-mpd が存在していません。

    PC/スマホ両方で試しました。(どちらもChrome)
    当方で何か確認すべきところがあればご指示をお願いします。

  • @kens さま
    デバッグに付き合っていただく形になり申し訳ありません。
    さて、当方でも改めて動作確認しましたが、以下の理由でバグが有りましたので
    修正いたしました。
    大変申し訳ありませんが再度アップデート版をインストール頂けると幸いです。

    当方で確認した不具合:
    「Set Session」ボタンを押し下げ後、セッションは取得できましたが確かに/etc/webui.cfgには反映されていない。

    原因:
    セッション取得部分をブラウザ側の last.fm API処理部分と共有化した際にtypoミスでサーバへの保存部分が動作していなかった。

    なお、上記修正後に一連の動作を行って当方環境では正常にセッションの書込+Scrobbleがされたことを今回提供バージョンでは確認しました。

    ちなみに5の「Set Session」ボタンを押し下げしないと last.fm のSetting -> Applications に 「ympd for symphonic-mpd」の項目は出ません。
    (セッション保存後に当該画面を既に開いていた場合はリロードが必要)