Google Translate (Japanese to English) is not always my friend. I couldn't quite follow your explanation.
What I did was increase the height setting from 165px to 200px in the "Information of Audio over Ether" section of the Form.html file. That worked for me.
RaspPi4b x 2 / IanCanada Stack powered by LiFEPo4 & Ultracaps /
Bisek Output Transformers
キューから再生中のラジオストリームを探して、タイトルを変更する件ですが
よくよく考えたら現在再生中のキュー内のsong_idはympdのメインプロセスに記録されていたのでした。
（各クライアントのセッションと現時点の再生中のsong_idを比較し、相違がある場合は再生中の楽曲が更新されたとメッセージを送ります。
このために内部的に保存されているわけです。）
ただし、このsong_idと一致する楽曲を探すためにキューを総ざらいする必要があるのですが、
キューの全体からsong_idで一致する楽曲を見つける内部コマンドはちょっと調べた限りありません。
現状の手段としてはキューから指定範囲を抽出させて順番に確認する方法しか思いつかず、
この指定範囲は常識的に考えるとキューの先頭から500曲が妥当だと
考え付きました。
（このアルゴリズム的にはwebuiでキューを表示する際のものと非常によく似ています。
実際にキューを表示する際は500曲単位でページを区切って表示されます。）
という訳で、キューに書き込みされたラジオのタイトルを更新可能なのは「1ページで表示可能な1曲目〜500曲目の間のみ」とする仕様とさせていただきたいと思います。
（通常の楽曲ならまだしも、ページを跨いでラジオストリームを再生する場合はほぼ無いとの想定です。）
上記の件、やはり諦めきれず libmpdclient のドキュメントを調査した結果、mpd_run_get_queue_song_id 関数で目的の動作を行うことが出来ましたので制限を撤廃します。
↑
上記の仕様で試作しており、今週末には修正版をリリースいたします。
@Castle
In the screenshot you'd shown, I think only the "---" at the bottom seemed to be cut off.
I think plugin height will keep to be small to prevent vertical scroll in mobile devices.
So, I limited to increase the height of pre tag area.
But you tried to change from 165px to 200px and worked fine, I'll change it in next release. Thank you.
現状のWebuiでは らじる★らじる には対応しておりませんが、
以下の方法でとりあえず視聴することは出来ました。
今回の動作確認はArch Linux AoEで実施しました。
（2021−03−20 調査結果）
smpdのMPDではffmpeg周りの仕様によりmpeg-tsファイルのデコードは出来ません。
Failed to decode https://nhkradiobkfm-i.akamaihd.net/hls/live/512070/1-fm/1-fm-20210218T162242-01-124/596.ts;
avformat_open_input() failed: Invalid data found when processing input
インターネットラジオのm3uファイルのURLを調べる
現状、こちら で分かるようです。
CDATA があるURL記載の部分がm3uデータの場所になります。
8地域の放送局毎、第一放送・第二放送・FMの順で記述されている模様ですね。
m3uデータから実際のストリームデータを抽出
当該のm3uファイルをダウンロードし見ると、
1-fm-20210218T162236-01-119/1709.ts
のように書かれています。
実は上記のweb.xmlからm3uファイルのURLを抽出してADD STREAMプラグインで読み込みしても、m3uファイルの中身が相対パス設定のため動作しません。
tsファイルを音声ファイルとして認識させるには上記の相対パスにm3uファイルのパスを頭に追加して記述しなければなりません。
例えば北海道のNHK-FMの場合
m3uファイルは
https://nhkradiobkfm-i.akamaihd.net/hls/live/512070/1-fm/1-fm-01.m3u8
であったので、上記のtsファイルのパスを
https://nhkradioikfm-i.akamaihd.net/hls/live/512100/1-fm/1-fm-20210218T162236-01-119/1709.ts
と書き直す必要があります（ざっと18箇所）。
再生についての問題点
さらに問題があります。このtsファイル、実は10秒分しか記録されていません。
ということは1つのm3uファイルに18本のtsファイル＝最大180秒しか鳴らせないということになります。
tsファイルの在庫が尽きる前にm3uファイルを読み込みして新しいtsファイルをMPDのキューに次々追加する仕組が必要です。
最後に
この仕組、HTTP Live Stream(HLS)というものらしく、
ちょっと調べた限りではJavaScriptのライブラリ(hls.js)が既に動作していますので、
これを組込すれば対応可能かもしれません。
（事前動作確認ではこちらのデモ画面にm3uのURLを入れたところ、端末上のサウンドカードには正常にラジオを復元しています。）
NHK を始めとしてHLS関係でインターネットラジオストリームが聞きたいニーズってありますか?
もしありそうでしたらかなり大掛かりになりますが、ちょっと検討して見るかもしれません。
変更点は以下の通り。
※注意
下記の変更に伴い、DASHBOARDのARM・COREグラフが表示されない場合は、ブラウザのキャッシュが残っていることが原因であると想定されます。
この場合は一旦キャッシュを消去の上でWebUI再度起動してみてください（次回リリース時には上記対応します）。
ラジオ再生中の楽曲情報更新に関するバグ修正
@akibon3 さまご指摘の件、当方での検証不足が原因でした。
（通常Consume On かつキューのトップに配置したラジオを再生していたため気づかなかった。申し訳ありません。）
AoEプラグインの修正
@Castle さまご指摘の通り、文字列で結果を返すコマンドの表示領域高さを広げました。
また、同コマンド動作ではコマンド実行結果の完了をプラグインに伝えるため、
最下行に"---"をわざと追加していたのですが、これを表示させないように改良しています。
ファイルサイズの縮小化（ライブラリの置換）
従来はDASHBOARDのARM・CORE周波数を表示するドーナツ型のグラフ領域（タブレットサイズ以上で表示）は
Chart.jsというグラフ描画のライブラリを使用していましたが、
今回これを使わずに描画処理を自力で行うようにしました。
（今後何らかのグラフ表示を必要とした場合は復活する可能性はありますが、当面は上記にしか使っていないため）
これにより、実行ファイルサイズで130kBほど縮小することが出来ました。
通知の一部設定変更について
従来の通知Off設定は「一般的な通知のみ」対象としていましたが、
プラグイン実行成功時の「Success」など「失敗したら通知すれば分かる」
ようなものも表示させないようにカテゴリ設定しています。
（ファイルアップロード時や、NAS設定変更後など「Successが表示されないと状況把握が難しいものはそのままにしています。）
@sunatomo さま
複数のインターネットラジオ局をキューリストに入れたときの再生中の曲名表示の不具合の件、早速、修正いただきまして、ありがとうございました。無事、再生中の曲目が表示されるようになりました。
「らじる★らじる」でのNHKネット配信ですが、私の環境（Win１０＋Radikool）ではFMチューナーよりも良い音で聞くことができず、使っておりませんが、smpdのプラグインとすることで市販のFMチューナー並かそれ以上の音質で聞くことができるなら、使いたいと思います。
また、他のFM放送のインターネット配信の「Radiko」も、そこそこ良い音で聞けるなら是非使いたいと思います。
無理の無い程度の作業量であれば、ご検討いただければ幸いです。
@akibon3 さま
不具合の件はお手数おかけしました。
らじる★らじるほかHLS対応については以下の問題があります。
そもそも、ビットレートの低いコーデック
らじる★らじるはHE-AACの48kbpsとかなりの低ビットレートのため、
smpdの高音質設計で少しは改善されるかもしれませんが、
どこまで良くなるかは未知数です。
webui以外で手を入れる必要がある
ネットの記述見た限りではプラグインで何とかするというより、
curl, ffmpeg, mpdに手を入れる(調整)必要がありそうです。
(再生に成功した記述を見る限り具体的に何か手を入れたというものがなく、
これらのソフトウェアの組み合わせだけなので）
個人的にはsmpdではwebui以外は触ってはいけないというポリシーで開発していますので、
HLS対応は現状ではArch Linux AoE のみになるかもしれません。
21:00 追伸
と言っている最中、Arch Linux AoEではあっさり対応してしまいましたのでArch Linux AoEをご覧ください。
@sunatomo さん
まだ Arch Linux AoE の導入ができていないので、RasPi4版AoEで聞けないかなと考えていたのですが、iPhone版の「らじる★らじる」をaplayで飛ばして聞けば良いことに気づきました。
地域によっては別回線を挟んだ音質で配信されているなどの情報もあり、東京を選択して聞いてみましたが、まあまあの音質だと思いました。
Arch Linux AoE版でダイレクトに聞くと、違って聞こえるのでしょうか？
@mgroovy さま
aplay ではなくて、 airplay ですよね?
mpd で直接聞きたいっていうのは、私の環境がそうだからです。
（普段使いではApple製品はあまり周りにない）
ま、webuiの改良も兼ねて以前NGだったインターネットラジオの復習をやってみたってところです。
AoEとAirPlayの比較については正直ちゃんと検証していないので「わからない」と言うのが本音です。
ただ、AirPlayのWikipediaの解説を見る限り、あちらは「圧縮されたコーデックをそのまま専用パケットに載せて、受取側でデコード」しているようですね。
それに対してAoEの場合は「デコード済みのPCMデータをCPUを経由せずに伝送する」という仕組ですから、
音質最優先で考えるとスジは良いでしょう。
（LC-AACの48kbpsという点で音質は語りにくいですが）
個人的ですが、仕事の立込具合や現状のソフトウェア開発でのニーズに関して先の見通しが自分的には立たず、
こちらの書込についてはちょっとご無沙汰でした。（フォーラムは毎日確認していましたが）
さて、そうは言いながらも少しづつ手を動かし始めて、気づいたことがありました。
開発の途中でよくよく考えたらスワイプによるモードの切替を動作できなくしていました。
気づきの切っ掛けは、JavaScriptで使用しているライブラリ群の整理をしようとして、
詳細な機能について精査したところ、
現状使ってなさそうな「modernizr.js」と「hammer.js」があるが、
これらは「modernizr.js = タッチデバイスの検知」，「hammer.js = スワイプの検知」という用途であることが判明したためです。
という訳で、ご質問です。
私の気持ちとしては一人でも希望者がいればちゃんと動作するようにfixの上で提供する予定です（手元では修正し動作確認中）。
もし4月17日まで様子を見てみて、希望者がいないようでしたら一旦上記のライブラリを無効化にしてリリースしたいと思います。
（ちなみに無効化すると、ほんの少しだけJavaScriptのライブラリサイズが減る方向になります。）
@sunatomo さん
私も、個人的には残しておいて欲しいなぁと思っています。
普段は選曲などの操作が終わったらすぐにブラウザを閉じる派です。（ympdのプロセスを自動停止させたいので。）
頻繁にスワイプを使うわけではありませんので、機能がなくなったとしてもさほど支障はありません。
スワイプで画面を切り替える機能は、smpd v0.3でWeb UIを作り直したときに実装したものです。
volumioやmoodeのWeb UIで定番になっていた「キュー」「ブラウズ」「カバーアート」の3画面をもっとスマートで直感的なUIにまとめられないものかと思案した末に現在のような形になりました。
iPhoneで左手の親指だけで操作しやすいように配慮しています。
私にとっては手触りがよくてストレスの無いUIに仕上がっています。スワイプもそのUIを形作っている要素の一つなので、それが欠けてしまうのは少し寂しさがあります。
@sunatomo さん
ご配慮ありがとうございます。
元々の設計に囚われずに自由に改良していただくというのがwebui-plusの意義ですので、ご判断はsunatomoさんに一任いたします。
改良の足枷になると思った機能を廃止していくというのは大事なことだと思いますので。
前回からちょっと間が空きましたが、少しだけ進んだので週末にリリースします。
今回は機能追加というより、内部的な動作fix＋最適化がメインになります。
予告通り、新機能はありません。
更新情報は以下の通り。
タッチ対応デバイスでのスワイプによる表示モード対応復活
ソースコードの追跡は行っていませんが、過去にwebui-plusの開発途中で本機能を不動にしていたため、動作を復活させました。
Cookieの動作について見直し
今回、各ブラウザで初期起動した場合を改めて検証し、Cookieに以下のパラメータを格納する仕様に修正しました。
Cookieの特性上、各端末のブラウザに設定は残ります。ですのでその気になれば「同じipadでもSafariでは通知あり、Chromeは通知なし」などの使い分けもアリになります。
なお、今までwebui-plusを使用した方はそのままCookieは残っていますのでご安心下さい。
また、Cookieの各値は当然webuiプラグインで設定を変更した際に変更されます。
| パラメータ名 | 詳細 | 初期値 |
|---|---|---|
| MAX_ELEMENTS_PER_PAGE | グリッド表示時の1ページ上での最大表示数 | 画面大きさにより異なる（後述） |
| gridFlg | ページ読込時にグリッド表示するか、リスト表示するか | false |
| notifyFlg | 状態変更時などに通知を表示するか | true |
| ndelay | 通知表示から自動消去までの時間 | 5000(msec) |
| ilang | カバーモードのlast.fmによるArtistInfo表示言語 | en(English) |
| MAX_ELEMENTS_PER_PAGEのCookieが存在しない場合の初期値は端末の画面解像度により以下の通り自動設定されるよう設計しました。 | ||
| (初期値は見直しの可能性あり） |
| モード名 | 横解像度 | 表示数 |
|---|---|---|
| xs | 768px未満 | 5 |
| sm | 768px以上〜992px未満 | 10 |
| md | 992px以上〜1200px未満 | 16 |
| lg | 12oopx以上 | 25 |
サーバ〜ブラウザ間の一部電文の廃止（統合）
Cookie仕様見直しや、ライブラリ取得の際に使っていた無駄な電文を廃止しました。
その他ソースコードの統合など見直し
@sunatomo さん
WebUI機能のブラッシュアップ、ありがとうございます。
早速スワイプ機能試しました。
直感的な操作感が良いですね！
@ジャイアン さま
試用お疲れ様です。
スワイプについてはキューモードのリスト表示領域は現状対応しておりませんがよろしくおねがいします。
（上記については調査しますが、もしかしたら対応無理かも。
ミニプレーヤ領域ならば間違いなくスワイプ対応しますが...）
ちょっとした予告になります。
前に一回ステータス表示部分と電文処理部分を別スレッドに分け、ステータス（カウンター）表示部分を高精度タイマー駆動にしたことがあったのですが、
その際にクリティカルセッションが衝突することがあり実装を中止していました。
よくよく調べたらmutexでリソースの衝突を防止すれば良いことが分かったので、
GW辺りに実装してみてうまく行ったらリリースまで持っていきたいと思います。
色々やってみましたが、現行の仕組以外に改善しようがないですね
（ステータスとカウンターを一定時間で更新する方法ですが）。
スレッドをタイマー駆動した場合mutexのデッドロックが発生して途中で動作がおかしくなりました。
mutex抜きでステータス取得部分だけタイマー駆動しましたが、MPDから得られる1秒感覚の再生中カウンター（ミリ秒単位）値の差が0.7~
1.5秒と全く揃わないことが判明したため、
libmpdclientの標準関数で正確に再生カウンターを取得することは諦めます。
という訳で、ちょっと大々的に手を入れるのは下記の通り見送りになりますかね。
| 検討項目 | 検討結果 |
|---|---|
| 組込webサーバライブラリの更新 | 現状のライブラリよりファイルサイズが肥大化することが判明（ソースコードレベルで100kb→500kb）また、http/2対応くらいしか旨味が無い。それ以外はほぼ全て実装済み（コンテンツのZIP圧縮含めて） |
| bootstrap4以降へのアップデート | cssの変更があったため工数がかなりかかるため現状難しいと判断（プラグイン含めて修正が必要） |
| 再生カウンタの正確な取得 | 問い合わせを高精度タイマー駆動しても得られるカウンターのゆらぎが大きすぎて対応不可 |
GW中には上記の通り、カウンターの高精度化を試してみましたが残念ながら元に戻すという結果になりました。
他にネタが無いかなぁと思い以下の2つについて実装を行ってみて、形になりそうな感じになりました。
RaspberryPIのympd（webui）〜MPD間はUNIX socketで接続されていますが、
現状の実装ではクライアントの接続が無くなったことを検知した場合は切断され、接続を検知した場合は再接続する仕様でした。
ここを「常時接続をidle状態にして維持し、MPDと通信する際のみidleを解除させる」仕様にしました。
（この実装は1月〜2月に試行したものと同様ですが、前回はMPDとの通信コマンドをキューに格納して順次処理する仕様にしたため、
端末での操作から描画までにワンテンポラグが発生していました。
今回はレスポンス対策として通信コマンドのキューイングをせず従来の処理と同じくコマンド受信後idle解除して即処理するようにしています。）
再生制御にちょっとだけ「おまけ」をつけようと思います。
具体的には（カバーアートモードで）現在再生位置から30秒巻き戻し、30秒早送りをサポートを考えています。
再生アイコンの最左に「巻き戻し」、最右に「早送り」アイコンを追加し、
それぞれクリックすると現在の再生カウンタから30秒巻き戻し・早送り操作をするように設計します。
という訳で、アンケートになります。
1項目のidle対応版のテストリリースを8日中に行います。
「操作性」と「音質の悪化」がないか、人柱上等な方はちょっとお試しいただけると幸いです。
（もし、どちらかでも悪化しているようでしたら、従来通りに動作は戻します。）
また、2項目の「巻き戻し・早送りについて」機能として必要か不要かお答え頂ければと思います。
（なお、現状各ボタン配置は出来ることを確認しましたが、
機能実装はこれからになります。
もし間に合えば8日のテストリリースに暫定機能提供はします。
ボタン押し下げ時、現在のカウンタ値から-30もしくは+30秒ずらしてシークさせる形になるかと思います。
あと、HTTPストリーム再生時はボタンが動作しないようにマスクが必要でしょうね。）
