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

    SSLサポートなのですが、自分で色々書いておいて各端末・ブラウザでの一通りの検証が足りないことに気づきました。
    (具体的に言うと、Chromeは結構設定がザル・Firefoxなどそれ以外のブラウザはルート証明書が正しくないと接続させてくれない)

    というわけで「手持ちの全デバイスでこれでイケる」という設定が確認できるまで少々時間をください。
    (もし有識者で「openssl の使い方、誤っているよ」というアドバイスは大歓迎です。)

    確認予定の環境は以下の通りとします。
    Windows:Chrome・Firefox・Edge・ie11(ie11はそもそも動きませんでした...)
    ちなみにWindows10・11の場合、https://smpd.localの動き(mDNSによる名前解決)がLinux/Macに比べて異常に重いため固定IP推奨ですね...
    これはこれで、非常に問題あり。

    Linux:Chrome・Firefox
    Android:Chrome・Lightning・DuckDuckGo
    (LightiningとDuckDuckGoは動作せず。代わりと言っては難ですが、Firefoxの動作を確認したので勘弁していただきたく)
    ipad:Chrome・Safari

    ちなみに参考情報ですが、PWAは手元では動きました。

  • さて、MacOS だけは手元になく動作確認出来ませんでしたが、それ以外の環境でほぼ https での動作確認が出来ましたので、
    改めて本スレッドに纏めます。

    1.CA証明書とサーバ証明書のympdルートディレクトリに複写
    cert.zip にCA証明書、サーバ証明書の必要ファイルを全て纏めました。
    当該ファイルを smpd のSDカードに解答し、そのまま同梱の証明書を使用する場合は以下の通りsshでコマンドを入力して下さい。

    cp smpd.local.pem /var/lib/mpd/music/ssl.pem
    cp localCA/localCA.crt /var/lib/mpd/music/
    cp localCA/localCA.der.crt /var/lib/mpd/music
    

    2.CA証明書・サーバ証明書を自分で作成したい場合
    cert.zipの解凍先で、CA証明書の場合は localCA/genRootCA.sh を、サーバ証明書の場合は genSVcert.sh を実行して下さい。
    (smpd を固定IPアドレス運用している場合、openssl の subjectAltName に当該アドレスを自動追加します)。

    3.CA証明書をお使いの端末にインストール
    httpsでのセキュアな通信を行うためには、
    サーバ側にサーバ証明書と秘密鍵を、
    端末側にサーバ証明書を署名するために使用したCA証明書をインストールする必要があります。
    CA証明書のファイルをサーバから転送する方法は以下の3種類あります。
    ・http://smpd.local/localCA.crt へブラウザでアクセスし、ファイルダウンロード
    (この方法はipad・iosではSafariで必ず行う必要あり。
    またAndroidの場合はlocalCA.der.crtをダウンロードする必要あり)
    ・cert.zipを解凍しlocalCA.crt・localCA.der.crtを端末のストレージに複写(そのまま使用する場合)
    ・Filezilla経由でFTPによるダウンロード

    以下、各OSとブラウザ毎にインストール方法を解説します
    OS | ブラウザ | インストール方法
    ----|----|----|----
    Windows | Chrome | ブラウザの場所でchrome://settings と入力してブラウザの設定画面を表示し、「プライバシーとセキュリティ」を選択。
    次に「セキュリテイ」項目内に「証明書の管理」がありますのでこれを選択。
    OSの証明書管理が開きますので、認証局で「インポート」を選んでダウンロード済みのCA証明書をファイル選択してインポート。
    Windows | Edge | 上に同じ
    Windows | Firefox | 設定画面の構成はChromeなどと同じですが、Firefoxの場合はCA証明書の格納場所が独立(OSとは別)のため、個別にインストール処理が必要
    (操作方法はOSの証明書管理とほぼ同等)。
    Linux | Chrome | Windows と画面構成はほぼ同じですが、Windows 版のFirefox と同様、CA証明書の格納場所は各ブラウザで独立しているため、
    smpdでhttps接続したいブラウザ全てでインストールが必要。
    Linux | Firefox | Chromeと同様
    Android | Chrome | 以下、私の手元にあるAndroid v13のOnePlus8を例に説明。
    「設定」の「パスワードとセキュリティ」画面から「システムセキュリティ」を選択し、「認証情報ストレージ」から「ストレージから証明書をインストール」を選択してストレージに保存したder形式の証明書をインストール。
    Android | Firefox | CA証明書のインストールはChromeのやり方でOKですが、さらにOSのユーザ追加したCA証明書を認識するようもうひと手間必要。
    Firefoxを起動し、「設定」から「Firefoxについて」を選択し「Firefox Browser」の画像を領域を5回タップすると「設定」内に「Secret Settings」の項目が追加される。「Secret Settings」の「Use third party CA certificates」をOnにするとこのCA証明書が有効になる。
    ipad | Safari | まず、Safari で http://smpd.local/localCA.crt にアクセスし、証明書をプロファイルとしてダウンロード。
    次に「設定」→「一般」→「VPNとデバイス管理」を表示させ、「構成プロファイル」に今回ダウンロードしたCA証明書が表示されるので、これをクリックして「インストール」を押す。
    次に、「設定」→「一般」→「情報」→「証明書信頼設定」画面でインストールしたルート証明書をOnにする。
    4.systemdのsocket・serviceでhttpsを有効化
    /lib/systemd/system/ympd.socket
    従来のhttpでの80番ポート待受を443番ポート待受に変更します

    #ListenStream=80
    ListenStream=443
    

    /lib/systemd/system/ympd.service

    #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
    

    どちらも従来の記述の先頭に”#"をつけてコメント化し、httpsを有効化しています。
    ファイル修正後 systemctl daemon-reload とコマンドを入れて、smpdを再起動して下さい。

    5.各端末のブラウザでの初期動作について
    既にhttpでアクセスしていた場合、"https://smpd.local" と場所に明示しないと正常動作しない場合があります。
    また、ブラウザによってはキャッシュが残っていて接続に失敗する場合があります。

    6.サーバ証明書の有効期限について
    ipadOSの機能制限により、サーバ証明書の有効期限は「作成後13ヶ月以内」となっています(恐らくiphone・MacOSも同じ成約あり)。
    このため、httpsを継続して使用する場合、1年後に再度サーバ証明書を作り直しをしてインストールし直す必要があります。
    (CA証明書は2036年まで有効にしてありますので、本システムのライフスパン中は再作成は不要だと思います。)

    7.CA証明書について
    強制はしませんが、自宅以外にも様々な環境で複数のsmpdでhttpsを有効化する場合、
    いちいち個別のCA証明書を各サーバで作るのではなく、単一の証明書で済ませたほうが便利です(基本、そのためのCA証明書ですから)。
    というわけで、公式配布するCA証明書を使用することをおすすめします。
    (今回はパッケージ作成が間に合いませんでしたが、今後パッケージ作成後はcert.zipの機能を同梱します。)

    8.現時点で動作非サポート環境
    AndroidでのLightningとDuckDuckGo
    (恐らくAndroid OSのユーザCA証明書ストレージを使用していないため、
    サーバ証明書の証明が出来ずに https でのセキュアな接続が不可)

  • 新パッケージ提供の予告
    久しぶりにパッケージ化を行うため、作業手順を思い出しながらになるので少々時間はかかりますが、
    以下の更新を実装した新パッケージをリリースします。
    1)httpsサポート関連ファイルの追加
    2)Firefoxでのスタイルシートズレ対応
      (PC版・Android版共に発生しているリスト表示領域の右側がはみ出ている件、
    Android版でハンバーガーメニュー表示時にボリウム調整のスライダーが消える件に対応します)

    あと、先日のhttpsサポート関連で Windows のブラウザを触っていて気づいたのですが、
    ブラウザの場所で smpd.local を指定した場合、通常は mDNS (Bonjour・avahi)でIPアドレスに解決してアクセスするのですが、
    Windows の場合は名前解決が遅い(もしくは失敗する)挙動が見られるため、
    技術的に押さえておきたいと思っています。
    (残念ながらAndroid は OS レベルで mDNS 未サポートのため、ブラウザでのIPアドレス解決は不可能です。
    ただし後述しますが、Playストアで mDNS をサポートするアプリをインストールした場合、
    ローカルネットワーク上でどのような端末がどのサービスを提供しているか確認可能です。)

    現在の知見で言うと、以下の通り。
    Apple系の(当方手元ではiPad):Bonjour の開発元なので当然のように名前解決可能
    Linux :avahi が動作する環境ならば当然のように名前解決可能
    Windows:Windows10/11 問わず、待たされることが大。場合によってはタイムアウトも発生。

    参考:Android のmDNS情報閲覧用のアプリ(Service Browser・mDNS Discovery)で当方宅内の情報を確認したところ、
    smpdは"_raop._tcp"のサービス名しか返していないことが判明しました。
    (本当ならば"_http._tcp"も返してほしいところ)
    smpdではShairport-Sync(AirPlay用のアプリケーション)がmDNSのサーバとしても動作し"_raop._tcp"のサービス名を返しているため、
    これの改造もしくは_http._tcpを返す他のデーモンが必要かもしれません。

    なお、Linux で mDNS のサービスとホスト名を確認する際は avahi-browse -alrとコマンドを入れてみて下さい。

  • mDNS周りの規格について
    もう少し補足を記載します。

    1.mDNSの基本プロトコル
    RFC 6762という規格で日本語訳参考資料はこちら、
    従来のDNSを補完する目的で同一ネットワーク内にマルチキャストで問い合わせを送信することで、
    ホスト名からIPアドレスを解決することが可能な仕組みになっています。
    symphonic-mpd ではインストールイメージはsmpd.localという名前が最初から付けられていますので、
    この機能が正常に動作すれば「例え DHCP により当該RaspberryPiに動的に IP アドレスが付与された場合でも」これを特定することが可能になるというわけです。
    mDNS の実装はソフトウェア開発者により名称が異なり、Appleの場合はBonjour、Linux 等では Avahi というふうに名乗っています。
    mDNSによるホスト名からIPアドレスを特定するだけの通信についてはワンショット(1回のみ)となっています。
    この時、リクエストを送る側は 224.0.0.251:5353 (IPアドレス 224.0.0.251 ポート5353)に対して送信します。
    mDNSサーバでこのリクエストが受信されそれが自分のホスト名と一致すると、自分のIPアドレスを返すので、IPアドレスの特定がされるという訳です。

    2.サービス問い合わせ
    RFC6762 に追加し、RFC6763 では5353ポートでのマルチキャストの継続的な通信を行った場合は実際に動作しているサービスの問い合わせが可能になります。
    先の投稿で _raop._tcp と記載していたものは、Shairport-Sync が RFC6763 に基づきクライアントに返していた自分の動作サービス(AirPlay)についての情報になります。
    本来ならばsmpd.localでは httpd のサービスも存在するため、_http._tcp も合わせて返してほしいところです。

    3.他の同様パッケージでの対応方法
    Volumio についてちょっとググってみました。
    Linux 系の Avahi を内部でインストール済みであるため、これで mDNS は賄っているとのことです。
    Avahi では設定ディレクトリ内に存在するサービスの設定ファイルを配置することにより、 RFC6763 で実現しているサービスを全部返すことができるようです。

    4.Windows での mDNS サポート状況について
    Window10以降でOS標準でサポートされたとのことですが、どうやらトラブル事例はそれなりにあるようです(うまく解決しないとのこと)。
    解決方法としては3つほどありそうです。
    (1)OS標準のmDNSを停止し、Apple の Bonjour をインストール
    OSのmDNS停止にはレジストリ操作が必要。更に普通はインストール不要のBonjourインストールが必須

    (2)mDNS以外の名前解決方法を使用する。
    実はWindowsではLLMNRというIPv6対応の名前解決方法があり、smpdではsystemd-resolvedのデーモンでこれ用のポート(5355)が既に開いていました。
    うまく使えれば、アドレスを返してくれるかもしれません。

    (3)IPv6アドレスを付与しておく
    こちらの情報によると、WindowsでのmDNS実装ではIPアドレスの問い合わせ時にIPv6パケットも要求しており、IPv6 アドレスがないと1秒待たさせるとのこと。←これが原因?!

    ※symphonic-mpdの v1 系では ipv6 サポートがカーネルレベルで無効化されているため、
    (2)・(3)の方法ではどうしようもないことが明らかとなりました。
    やはり Windows の場合は「(1)の通りOS標準のmDNSからBonjourに変更」もしくは「固定IP前提運用」しかないですね。

    という訳で後ほど、「(1)の具体的なやり方」と
    「LLMNRのポートを閉じる」設定方法を記載します。

  • WindowsのWiFi環境下でのmDNSレスポンスパケットロスについて

    今まで2回程度記述してきましたが、やっと現象が把握出来ましたので以下に纏めます。
    本件は後程FAQにも纏めておきます。
    (今まで記述してきた内容は課題解決のためのプロセスに関する「読み物」だと思って下さい。)

    現象:

    Windows10・11機にてブラウザの場所に http://smpd.local もしくは https://smpd.local でsmpd機に問い合わせした際、
    名前解決に失敗して表示されない(もしくは成功しても正常に接続出来ない)。

    原因:

    Windowsのブラウザで場所を入力後、ホスト名→IPアドレス変換するために mDNS(UDPマルチキャストを用いたホスト名→IPアドレス変換)のパケットが端末から伝送されるが、
    WiFi環境下では smpd サーバからの応答のUDPマルチキャストによるレスポンスが消えることがあるため。

    解決方法:

    以下のどれかを試してみて下さい。
    1)Windows 機では有線接続とする (smpd.local継続使用時)
    2)smpd.local での運用を止め、固定IPアドレス下で直接IPアドレスを入力する。
    3)WiFiルータ・アクセスポイントの設定見直し・機種変更を検討する。

    おまけ:smpd で systemd-resolvd でのLLMNR向けポートを閉じる方法

    mDNSのsmpdサーバでの挙動を調査していたところ、現状使用できないLLMNRによる名前解決向けポートの5355がTCP・UDP共に開いた状態であることが判明しました。
    当該ポートを閉じるためには /etc/systemd/resolvd.conf をエディタで開き、LLMNR=no という記述を追加して下さい。
    入力する場所としては MulticastDNS=no の一つ前が分かりやすくて良いと思います。
    (smpd v1ではipv6が無効化されているため仮に外部からパケットを受信しても無害ではあると思いますが、
    不要ポートを閉じていたほうが良いと思われるので、設定を推奨します。)
    設定変更後、再起動するか systemctl restart systemd-resolvd.service でsystemd-resolvd を再立ち上げして下さい。

    また、ss コマンドで以下の通り、開いているポートは53(DNS), 5353(mDNS), 22(SSH),80(HTTP)もしくは443(HTTPS), 5000(AirPlay)以外のポートが閉じられていることを確認して下さい。
    (spotifydを使用している場合、ほかも開いているかも)

    root [ ~ ]# ss -nltup
    Netid   State     Recv-Q    Send-Q       Local Address:Port       Peer Address:Port   Process                                                  
    udp     UNCONN    0         0               127.0.0.53:53              0.0.0.0:*       users:(("systemd-resolve",pid=164,fd=12))               
    udp     UNCONN    0         0                  0.0.0.0:5353            0.0.0.0:*       users:(("shairport-sync",pid=689,fd=6))                 
    tcp     LISTEN    0         0               127.0.0.53:53              0.0.0.0:*       users:(("systemd-resolve",pid=164,fd=13))               
    tcp     LISTEN    0         0                  0.0.0.0:22              0.0.0.0:*       users:(("sshd",pid=170,fd=3))                           
    tcp     LISTEN    0         0                  0.0.0.0:443             0.0.0.0:*       users:(("ympd",pid=956,fd=3),("systemd",pid=1,fd=56))   
    tcp     LISTEN    0         0                  0.0.0.0:5000            0.0.0.0:*       users:(("shairport-sync",pid=689,fd=3))   
    

    おまけ2:mDNSレスポンスパケットロス発見の経緯

    最後にWiresharkでパケットを取り直してみたところ、
    LLMNR・DNS・mDNSによるブラウザからsmpd.localの名前解決請求は確認したが、そのレスポンスがないことに気づきました。

    Shairport-Sync のログモードをデバッグにすると正常にmDNSの要求は受信されてそのレスポンスは返している模様でした。

    ここで我が家のPCやAndroidスマホはWiFi経由であったことを思い出し、
    PCをsmpdサーバと同じL2-SWに有線LANで接続してパケットキャプチャーを行ったところ、mDNSの応答がsmpdから返って正常にブラウザの表示がされたことから、
    WiFiに環境下による応答パケットロスであると断定出来たという訳です。

  • アンケート インターネット経由でのカバーアート取得について

    しばらくご無沙汰していたら、閑古鳥が鳴いているようでなかなかレスが付きませんが、一つお聞きしたい事項があります。

    実はインターネット経由でカバーアートを取得する際、「先方のサイトで想定しているアルバム名と実際にライブラリに収録されているライブラリ名が完全一致しないため」にカバーアートがヒットしない場合があります。
    (例えば末尾に[Deluxe Edition]がついている場合など)

    ヒット率を向上するため、以下のどちらかの機能を追加してみようと思いますがどちらがお望みですか?

    1. 辞書式で問い合わせ前にアルバム名末尾の余計な文字列を削除して問い合わせ

    2. 人間系で修正して再問い合わせ可能なダイアログを提供

  • @sunatomo さま
    シマネコと申します。
    投稿いただき有難うございます。
    ずっとSMPDを使わせていただいております。
    "smpd.local" に反応しないことが多く、ずっと前からなんでだろう?と思っておりました。
    Windows-PCやAndoroid,i-OSで反応が違うのでいろいろ試して接続しておりました。
    (Network Scanner等でipアドレスのあたりをつけて、http:// ipアドレスの入力でつないでいます。)
    今回説明いただいたことは、能力不足で理解できていないのですが、さっそく試してみたいと思います。
    技術知識がなくて、なかなか反応することができないのですが、ほとんど毎日 "Symphonic-mpd"の投稿は見ておりますので、これからもよろしくお願いいたします。
    ありがとうございました。

  • @sunatomo
    I think option "2 - Provides human-modifiable ..." would be best as it would provide flexibility.

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

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

    1年ぶりになりますが、ある程度の成果が見込まれましたのでアップデートを提供します。
    ログは以下の通り。

    1. https のサポートについて
       標準ではOFFにしておりますが、httpsを今回からサポートすることにしました。
       有効化したい方は次の投稿で詳細を記載しますので、そちらの手順に基づき実行して下さい。

    2. インターネット経由のカバーアート再取得サポートについて
       Castle 様の提案通り、まずは手動でカバーアートに必要な文字列を変更可能なダイアログを提供します(試作段階のため、今後UIが変更の恐れあり)。
      2023-01-02_001.png
      カバーモードのカバーアート表示域をクリックすると、上のダイアログが表示されます。各コンポーネントの説明は下記のとおりです。

    名前 詳細
    Current URL 当該カバーアート領域で現在先頭に指定されているURLを表示(編集不可)
    Album Name 楽曲から取得したアルバム名を表示
    Album Artist 楽曲から取得したアルバムアーティスト名を表示
    Song Name 楽曲から取得した楽曲名を表示
    Song Artist 楽曲から取得したアーティスト名を表示
    Spin ボタン カバーアート表示領域で指定されたカバーアートのURL候補の順番を変更
    (これにより、希望のカバーアートを優先表示可)
    recover ボタン Album Name 〜 Song Artist の文字列を楽曲から取得したものに復元
    ReGet ボタン Album Name 〜 Song Artist に記載の文字列で再度インターネットからのカバーアート再検索を実施
    各サービスにより必要なパラメータが異なるのですが、最小公倍数で以上4つの項目が必要になります。
    Album Name, Album Artist は同一アルバム再生中は変更しないように実装しましたが、もしかしたら想定外の動作がある可能性があること、
    現状の仕様では Current URL が見えにくい、
    また、スマホ向けには本機能はOFFになっていることから
    もう少しブラッシュアップが必要と考えています。
    1. 表示上のバグFixについて
       ・アルバムモードで楽曲リストまで絞り込み表示した際に通常はrootのトップページに表示される項目(Album・Genre...)が表示されていた件
       ・searchプラグインの結果表示時にパンくずリストの「search」を押すと動作がおかしくなる件の修正
       また、主にFireFox向けにいくつかバグがありましたので修正しております。
       ・リストビューのリスト上にマウスを配置した際に選択領域の右端が枠から飛び出す件。
       ・Android向けのハンバーガーメニュー表示の際、ボリウム調整用のスライダーが表示されない件。
  • @シマネコ さま
    「技術的についていけない」というのは全然構わないと思います。
    ただ、「こういう環境下でこういう事象が発生している」という事実だけで構いませんので、今後もお教えいただければと思います。

    @Castle
    Thank you for your advance.
    I'd made human-modifirable dialog in 2023-01-02 version.
    Please try it!

  • 2023-01-02 バージョンでの https 有効化方法について

    1. こちらの用意した証明書で実装する場合
      原則、本手法が基本になります。

    a) 動作させる端末にルート証明書を予めインストールしておく
    http://smpd.local/ 直下においたルート証明書をダウンロードして各ブラウザの証明書保管場所に保存して下さい。

    OS ブラウザ ファイル名 備考
    Windows edge
    chrome
    localCA.crt OSの証明書ストレージ
    WIndows FireFox localCA.crt FireFox独自の証明書ストレージ
    Linux
    FreeBSD等
    chrome
    FireFox
    localCA.crt 各ブラウザの証明書ストレージ
    Android chrome
    FireFox
    localCA.der.crt OSの証明書ストレージ内※1
    iphone
    ipad
    chrome
    safari
    localCA.crt OSの証明書ストレージ※2

    ※1 Android の場合、「設定 > パスワードとセキュリティ > システムセキュリティ > 認証情報ストレージ > ストレージから証明書をインストール」(手元のOneplus8 Android V13の場合)、
    「設定 > セキュリティ > 暗号化と認証情報 > SDカードからインストール」(手元のXperia XZ2 Android V11の場合)
    等の操作でサーバ証明書をインストールできます。

    ※2 Apple 社製品の場合、ルート証明書は 「Safari からのダウンロード」か「メールでの添付ファイルによる送付」以外はインストールできません。
    また、ダウンロード後 「設定 > 一般 > VPNとデバイス管理 >ダウンロード済みプロファイルのインストール作業」と「設定 > 情報 > 証明書信頼設定」の2つの設定が必要になります。

    ちなみにChrome・FireFoxともに証明書の設定画面は「設定>プライバシーとセキュリティ」からアクセス可能です。

    b) /opt/cert ディレクトリの systemd 関連ファイルを複写
    remakeCert.service, remakeCert.timer を /etc/systemd/system に複写します。
    最近のセキュリティ強化により smpd サーバで使用するサーバ証明書は有効期限が13ヶ月以下にしないとブラウザ側で弾かれる現象が発生しています。
    このため、smpd で使用するサーバ証明書も有効期限が13ヶ月以内となっていますが、証明書の再発行+ympdの再起動をsystemdのタイマーで処理させるための設定ファイルを複写するという訳です。
    ちなみにremakeCert.timerのタイマー設定は毎年1月1日の4:00となっているため、変更したい方は当該ファイルを編集して下さい。

    c) systemd のタイマー設定を有効化
    まず systemctl daemon-reload で設定ファイルをsystemdに反映させます。
    次に systemctl enable remakeCert.timer で remakeCert.timer を有効化します。
    さらに systemctl start remakeCert.timer で remakeCert.timer を開始させればOKです。
    一応動作を確認する際は systemctl list-timers と入力し、以下の状況であることを確認して下さい。

    NEXT                        LEFT                   LAST                        PASSED       UNIT                         ACTIVATES                     
    Mon 2023-01-02 10:23:30 JST 14min left             Sun 2023-01-01 10:23:30 JST 23h ago      systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
    Mon 2024-01-01 04:00:00 JST 11 months 28 days left Sun 2023-01-01 04:00:04 JST 1 day 6h ago remakeCert.timer             remakeCert.service            
    
    2 timers listed.
    Pass --all to see loaded but inactive timers, too.
    
    

    d) ympdのhttps 関連設定を有効化
    まず、ympd.socketを書き換えます。

    [Socket]
    #ListenStream=80
    ListenStream=443
    KeepAlive=true
    PassCredentials=true
    
    [Install]
    WantedBy=sockets.target
    

    もともとは ListenStream=443 の行は記載なしだったと思いますが、本行を ListenStream=80 の真下に追加し、ListenStream=80 の先頭に#を付けてコメントアウト化して下さい。
    次に今回添付のympd.serviceを書き換えします。

    [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
    

    ExecStart の --webport 80 と書かれている行をコメントアウトし、その下の行を有効化して下さい。

    両方のファイル編集後、以下のコマンドでympdをhttpsで起動させます。

    systemctl daemon-reload
    systemctl stop ympd.service
    systemctl stop ympd.socket
    systemctl start ympd.socket
    systemctl start ympd.service 
    
    1. ルート証明書を自分で作る場合
      /opt/cert/localCA にて genRootCA.sh を実行してルート証明書を作成後、
      /opt/cert にて genSVcert.sh を実行してサーバ証明書を作り直して下さい。
      生成したサーバ証明書は以下のコマンドで /var/lib/mpd/music に複写します(/opt/cert のファイル名と /var/lib/mpd/music のファイルが名が異なります。
    cp /opt/cert/smpd.loca.pem /var/lib/mpd/music/ssl.pem
    

    ルート証明書も/var/lib/mpd/musicに複写し直し、前項の通り使用する端末に配布して下さい。

    1. ルート証明書はそのまま使うが、サーバ証明書だけは作り直したい。
      2項の「/opt/cert にて genSVcert.sh を実行してサーバ証明書を作り直して下さい。」以降だけを実施して下さい。
      現在保存されているルート証明書でサーバ証明書を作り直しします。
  • パッケージ再リリース予告について

    昨日アップしたばかりですが、カバーアート再取得関係での課題を解決した目処が付きましたので、今週末に再リリースします。

    ・携帯電話向けの設定画面
     レイアウトを調整の上、対応できましたのでデスクトップ版と同じく機能を提供します。

    ・埋め込みカバーアートの対応改善
     従来は埋め込みカバーアートの取得設定が有効な場合はその有無を確認せずにURLを生成していたのですが、
    埋め込みカバーアートの抽出に失敗した場合はURL生成しないように設定を変更しました。

    ・インターネットからのカバーアートの取得方法改善
     従来はインターネットへのカバーアート取得がOnの場合は、楽曲変更時に毎回問い合わせを行っていましたが、
    今回から「同一アルバムでの再生が継続していた場合」は最初の1回だけ取得しその後は取得しない処理に変更しました。
     ↑
    これについてはアルバム名を修正後にインターネットへ問い合わせた場合も適用させます。

    特に3番目の拡張に関する動作の検証のため、少し時間を頂きたくよろしくおねがいします。

  • 作業遅延のご連絡

    当初目的のカバーアートについてはほぼ達成出来たのですが、
    最近になって真面目にいろいろな機器で動作を確認したところ、
    以下の気になる挙動が見受けられましたので併せて対応したいと思っています。

    • 一部ブラウザ(主にモバイル機器向け)で input タグ+ datalist タグを使用してコンボボックス化する際に、datalistに指定されたリストが表示されない。

    • 上記の代替としてselectタグを使用した場合、ipadOS(恐らくiphoneも?)の Safari と Chrome ではオリジナルのスタイルになってしまう。
      このスタイルを解除すると、selectタグ右横の矢印が非表示になる。

    また、昨年末から復帰し始めて開発機のSDカードにエラーが出始めて怪しくなってきたのですが、
    ここに来てビルドが通らない現象が発生したため、急遽開発環境の再構築が必要でした。
    (改めて、インストールし直しでインストール関連ドキュメントの不足や拡充が必要なことがわかったので合わせて修正しました。)

    という訳で、リリースまでもう少し時間がかかりそうです。ご了承下さい。

    余談ですが、さんざん触っておいて今頃気づきましたが、google-closure-compiler って linux のバイナリネイティブ版なら一瞬でJavaScript の最適化終わるんですね。
    メイン PC の VSCode でソースコードいじったら、そのままこの端末で最適化やってしまったほうが効率良いですね。

  • 2023-01-08版のwebui-plusのリリースについて

    リリースノートはこちらより

    • インターネット向けのカバーアートを再取得するモードを拡充しました。
      予告通り、同じアルバムでインターネット上のカバーアート取得を最初にそのアルバムの楽曲を再生した場合(+手動で再取得した場合)のみに限定します。
      また、同一アルバム再生が継続している際は、手動アルバムアート取得のためのパラメータは引き続き使用できます(アルバム名・アルバムアーティスト名は書き換えされません)。

    • 各種設定画面のうち、リスト項目が変更されない場合は select タグを使用するように変更。
      (これにより、モバイル系のブラウザでもリスト項目が非表示になるバグが解消されたと思われます。)

    • 上記に関連し、当方で編集したプラグインを全てレイアウトを統一修正しました。

    以下の項目は個人的に利便性を考慮し修正しましたが、もし従来のものがお好みの場合は元に戻す予定です。

    • 歯車でメニュー項目を表示した際の項目をスクロール可能にしました。
      有効化したプラグイン数により「画面領域よりメニューの数が増えた場合はスクロールが可能」です。

    • PC向け横画面で使用時、メインメニュー領域のアイテムの左右余白をモード切替矢印幅と揃えました。

    • DASHBOARD の LATENCY グラフ表示前にプログレスバーが表示されると思いますが、これが1秒単位で進捗するようにした。
      (個人的に LATENCY グラフが表示されるまで待つのが苦手だったので...)

    余談:fanart.tv でのアルバムアート取得について

    もしかしたら実装時からそうなのかもしれませんが、webui-plus (JavaScript) で取得した場合、URLが正常でも途中でエラーが返されることが判明しました。
    (webui-plus で生成するURLをそのままブラウザの場所で貼り付けした場合、想定したデータが返ってくるのですが...)
    ↑
    という訳で、ちょっと調査してみます。

  • fanart.tv のアルバムアート取得方法について

    2023-01-10追記:昨日の記述に誤りがあったので取り消し線と訂正を行います。
    仕様を完全に誤解していました...
    こちら に記載のドキュメント+テストケースに基づき実装したはずなのですが、
    そもそもこの API で指定する mbid (musicbrainz のID)はアーティストの ID であり アルバムの ID ではない(サンプルの Evanesence のケースをもっとよく見るべきだった)。

    という訳で、どれだけの方がFanart.tvを使いたいかはわかりませんが、以下の通り実装します。
    1) album-artist の mbid を取得(Musicbrainz の API から)
    2) album の release-groupのid を取得(これも Musicbrainz の API から)
     2023-01-10追記:Fanart.tv でアルバムを特定するためのMusicbrainz の ID は release-group id (アルバムの総称に対して付与されるID)でした。
    CoverArtArchive では release の id (アルバムの特定版)を使用しています。
    ここで解釈の違いがあったという...
    3) album-artist の release-group id から当該アルバムの情報を取得(ここから Fanart.tv の API を使用)
    4) 取得した JSON を解析して、albumsオブジェクト から release-group idでキーが一致したデータオブジェクト内の albumcover[0].url に当該カバーのURLが入っているはずなので、
    これを表示する。

    ちなみに上記の手順の途中で失敗した場合は当然取得不可です。
    ただし、当該URLを叩いた際に CORS(オリジン管理ソース共有)のエラーも同時表示されているので、
    ちゃんと返ってきてくれるかは別の問題として残っています...

    2023-01-10追記:CORS対応は結局として「 ブラウザがFanart.tvのAPIサーバに対してhttp GET メソッドで問い合わせを送る前に OPTIONS(プリフライトリクエスト)を送っていた」ため、
    これのレスポンスでCORSの規則違反がありエラーとなっていました。
    結局はワンレスポンス化(GETメソッド+contentTypeをtext/plainにする)ことで回避できました。

    という訳で、Fanart.tv も攻略出来ました。
    もう少し手元で動作確認し安定化させたら再リリースします。

  • 2023-01-21 版の webui-plus アップデートについて

    リリースノートはこちら

    • インターネットからカバーアートを取り込む方法のうち Fanart.tv の機能を修正
      前の投稿の通り Fanart.tv の API では Musicbrainz のアルバム (release) の ID をパラメータとしてカバーアートの URL を返す仕様なのですが、
      この時指定する ID は release-group (一般的にメジャーなアーティストの場合、各国版を Musicbrainz は認識しますが、当該アルバムの総称が release-group) でした。
      (Fanart.tv にカバーを問い合わせる前に、Musicbrainz のAPIに対してアルバム情報を問い合わせて ID をもらうのだが、今回からは release-group ID を取り込んで Fanart.tv 向けのパラメータとして使用する)

    • プラグイン向けの HTML タグの統合
      トップページの HTML にはプラグイン表示用タグの集合体が非表示のまま埋め込みされています。
      (「DASHBOARD」・「SETTINGS」・「パラメータ設定向けプラグイン表示」、「処理結果出力向けプラグイン表示」・「アップデート処理表示」・「カバーアート再取得」)。
      今回から、「処理結果出力向けプラグイン表示出力」の使用を止めて「パラメータ設定向けプラグイン表示」に統合し、僅かに省メモリ化(使用上は全くわからないかと思います)。
      また、大変今更で申し訳ありませんが、当方でメンテナンスをしているプラグインについては全て表示を統合し、同一の外観になるように再調整を行いました(内部仕様の変更は行っていません)。

    • 楽曲再生中の局情報の一部項目追加
      Search やトップページの検索機能でサポートしている genre(ジャンル)・composer(作曲者)・performer(演奏者)も楽曲タグにある場合は埋め込む仕様に変更

    • 一部のライブラリの差替
      jquery をv3.6.3へアップデート + 通知のポップアップアニメーションに使用している animation.js で不使用効果を廃止してフットプリントの縮小

    さて、個人的な次のネタとしては ADD STREAM プラグインの動作チェックでよく聞いている「Jazz Sakura」についてググって見つけた こちら です。
    何かというと、現状の webui-plus ではかなりヒット率が低い「インターネットラジオでの現在演奏中のカバーアート表示」についてです。
    ま、良い方法が見つかったら対応したいなぁとは思います。

  • 2023-01-22 版の webui-plus アップデートについて

    すいません。昨日アップデートしたばかりですが、1点気になった事項がありますので早速差し替えします。

    • CoverArtArchive においての挙動を修正
      CoverArtArchive のパラメータで MusicBrainz のリリース(アルバム)IDを指定するのですが、これを導出するために MusicBrainz のAPI に問い合わせ(アルバム名+アーティスト名をパラメータとして)を行います。
      当該APIでアルバムを問い合わせしヒットした場合、スコア付きで複数候補が出力されるのですが、アーティスト名を指定した場合でも全く違うアーティストが上位スコアになる可能性があったため、
      問い合わせ結果とアーティストが一致した場合のみ抽出としました。
      (また、複数候補出力時は従来スコアが95点以上の候補のみで判断していたのですが、今回から80点以上としました。)
      ↑
      もう少し補足すると、各リストのアーティスト名と検索パラメータのアーティスト名は双方とも大文字化したもの同士で一致を確認(リストのアーティスト名が検索パラメータのアーティスト名で始まるかどうか)しています。
      現状、以下の場合は一致するアーティストは検知出来ません。
      ①アーティスト名内にスペースがある場合とない場合の比較
      (例えば姓と名の間とか)
      ②ローマ数字などの特殊数字の表記が異なる場合(片方のⅠがIの場合等)
      ③途中で改名をしたアーティストや複数の呼称を持つアーティスト
       (例えば 綾戸智絵 → 綾戸智恵)

    • インターネット経由でのCoverArt検索時のエラー表示
      notifyをOnにしていた場合、インターネットでCoverArt取得に失敗した際はwarning(背景黄色)の通知を行う仕様にしました。
      (本通知はインターネット経由のCoverArt取得のバグがある程度取れた場合はもう一度出力しない仕様に変更する可能性はあります。)

    • symphonic-mpd左隣のヘッドフォンアイコンの挙動修正
      すいません。以前に再生・停止・一時停止の挙動について整理した際に不動にしてしていました。
      今回から再生中に本アイコンが振動する元々の挙動に戻しました。

  • Radio 周りのインターネット経由でのカバーアート取得について

    今回は、インターネット経由のカバーアート取得方法についてちょっと解説を書いてみたいと思います。

    1.ライブラリ上の楽曲での検索方法
     カバーアートを各APIに問い合わせる際のパラメータは「アルバム名」+「アルバムアーティスト名」が基本になります。
    (Webui-plus では アルバムアーティスト名が取得できない場合、楽曲のアーティスト名を使用して問い合わせます。)
     CoverArtArchive と Fanart.tv はちょっと特殊で当該アルバムの release-group MBID(musicbrainz が提供するアルバム固有ID)で指定する必要があります。
    ↑
    以前 CoverArtArchive と Fanart.tv では同じMBIDでも異なる旨説明していましたが、
    改めてAPIのドキュメントを見たところ、どちらも release-group id で抽出可能なため、近日リリース版では仕様を統一します。
    という訳で、これらのサービス向けには一旦 MusicBrainzのAPIを使用して release-group MBID を解決してから 各サービスを呼び出す2段階検索が必要になります。

    2.MusicBrainzの検索サービス
    検索パラメータを指定しても完全一致しない場合もありますが、複数ヒットした場合は各候補のスコア値とともに値が返ります。
    ただし、アルバムアーティストやアルバム名は内部的にあいまい検索なようで完全一致しない場合も返ってくるため、
    次のリリースアルゴリズムでは「検索対象文字列をスペースで分割し、その配列の最初のデータを大文字化したものが、候補の文字列の先頭に一致するか?」を条件とする予定です。
    (これをアルバム名とアルバムアーティストの両方で実施)

    3.ラジオでのカバーアート検索方法
    ラジオで検索用パラメータとして使用できそうなものは「楽曲名」+「アーティスト名」であり、アルバム関連の情報は通常取得できません。
    このため、MusicBrainzの検索APIのうち「recording(楽曲検索)」を使用して、上記パラメータから「release-group」を抽出する方法で実現しています。
    このため、ラジオでのカバーアート検索は現状は CoverArtArchive のみとなっています(将来的に Fanart.tv との切替対応は検討します)。

    4.カバーアート検索後の結果について
    PCでカバーアート表示部にマウスカーソルを重ねると、ツールチップが表示され現在のカバーアート表示候補を確認できます。
    CoverArtArchive や Fanart.tv の場合は MusicBrainz の API で release-group の検索が成功すると表示候補としてURLが抽出されますが、
    実際に当該URLで先方サイトに画像があるかどうかは運次第となります(画像がない場合は、その後ろのno-image*.jpgが透けて表示される)。

    という訳で、明日アップデート版をリリースします。

  • 2023-01-29 版の webui-plus アップデートについて

    • インターネット経由でのカバーアート取得の改良(CoverArtArchive・Fanart.tv)
      昨日の投稿の通り、これらのサービスでは事前にMusicBrainzの APIでの問い合わせによりMBIDの特定が必要になりますが、
      その際のアルバム特定方法を改良しました。
      また、CoverArtArchive・Fanart.tv共にrelease-groupでアルバムを特定するようにしました。

    • webuiの通常使用時の使用タグ・スクリプトを削減
      従来はDashboard・Settings・CoverArtRegetプラグインはメニュー選択の有無に関わらず常時読み込み(+非表示)状態でしたが、
      今回よりこれらのプラグインはHTMLファイルを分離し、ブラウザのメモリ使用量を削減しました。

    • アルバムモードでのページ切替不動バグの修正
      最後に動作確認して気づきましたが、先日のアップデートの際にパンくずリストからの遷移を修正したために上記動作がおかしくなっていました。

    • (業務連絡になりますが)やっとGitリポジトリに今までの変更点をコミットしました。

    個人的な次のネタとしては以下の3つを考えています。
    (出来るかどうかは今後の状況次第)

    1. ラジオ再生時のカバーアートヒット率向上
      前に表示したとおり、各ラジオ局の現在再生中リストが上手く取得できればヒット率は向上出来るのですが...

    2. ラジオストリームでのHLS・MPEG-DASH対応
      (Arch Linux AoE では実現していますが、smpd 内蔵の ffmpeg v4.2.2 では不可能なため。)

    3. BBC・NHK等のストリームURL変更時のplsファイル再提供を半自動化
      (今回Arch Linux AoE向けのおまけの方でURL確認しましたが、両方とも変わっていました。
      NHKはXMLファイルが同じURL上のため、これの解析で連続的にPLSファイルが生成されるようにしたい。)

    4. キューの並び替え(テーブルのドラッグによる修正)
       あまり必要性は感じていませんでしたが、そろそろ重い腰を上げようかなぁと。

  • NHKのHLSストリーム形式のラジオリンクをpls形式で出力するスクリプト(試作版)の提供

    昨日からちょっと手を動かしてみて、とりあえず形になったので提供します。
    今回はpythonのスクリプトになります。

    import urllib.request
    import urllib.parse
     
    url = 'https://www.nhk.or.jp/radio/config/config_web.xml' 
    req = urllib.request.Request(url)
     
    with urllib.request.urlopen(req) as response:
        xml_string = response.read()
    
    import xml.etree.ElementTree as ET
    
    root = ET.fromstring(xml_string)
    p1 = ['AM1', 'AM2', 'FM']
    p2 = [4, 5, 6]
    
    cnt = 0
    for child in root.iter('area'):
        for num in range(0, 3):
            title = 'NHK-' + p1[num] + '_' + child.text
            f = open(title + '.pls', 'w')
            print(title + '.pls')
            f.write('[playlist]\n')
            f.write('NumberOfEntries=1\n')
            f.write('File1=' + root[1][cnt][p2[num]].text + '\n')
            f.write('Title1=' + title + '\n')
            f.write('Length1=-1\n')
            f.write('Version=2\n')
            f.close()
        cnt = cnt + 1
    

    場所を決め打ちにしているのはXMLパーサーの使い方がまだまだ甘いためです。

    このスクリプト、動作させると当該スクリプトファイルと同一ディレクトリ上に全国のNHKラジオ局(インターネット上で公開されているもの。札幌・仙台・東京・名古屋・大阪・広島・松山・福岡)のAMラジオ第1・AMラジオ第2・FMのplsファイルが生成されます。