@sunatomo
The information is now being cutoff at the bottom after applying your form.html file.
-
webui-plus開発/サポート(webui-plus development/support)
-
@Castle
The last row "---" was footer string, to stop loading the message file function.
(If you click the button whitch has any string result, load the ".aoe.out" file every 300msec until the file end with "---".)
So, please ignore it.
(I may respond with this issue ? if i motivated)AoEプラグインでのメッセージを伴うボタン操作時に最下行に表示される"---"については、
プラグインの内部的にメッセージが全て受信出来た際のサインとしてのみ使っていますので、無視してください。
実は、これを受信するまで300ミリ秒毎に".aoe.out"ファイルを読み込みし、更新する仕様で制作されています。(やる気が起きれば余計な"---"を消す対応するかもしれません。)
-
この投稿が削除されました!
-
Webui-plusのアップデート、ありがとうございます。どんどん使いやすくなっていきますね。感謝しております。
2021-03-13 版のアップデートでインターネットラジオの曲名の表示に不具合があり、ご報告いたします。
登録されているインターネットラジオ曲を複数、キューリスト(表現が間違っていたらゴメンナサイ)に追加し、キューリストの画面に切り替えて、再生ボタンを押すかラジオ局をクリックすると、選んだラジオ局が再生されるのですが、画面の上部に表示される現在再生中の曲名は、常にキューリストの1番の曲名が表示されてしまいます。
2番目のラジオ曲、3番目ラジオ局をクリックしても、一瞬、選んだラジオ局の曲名が表示されかけますが、1番目の曲名表示に戻ってしまうようです。
NASの音楽ファイルの再生では、不具合なく表示されています。急ぎませんので、何かのついでにでも修正いただければ幸いです。
-
@akibon3 さま
ご報告ありがとうございます。
普段ConsumeをOnにしていたため、全然気づきませんでした。
よく考えたらそうですよね。
トップ位置と異なるラジオでキューから楽曲探すとしたら、「ストリームURL文字列の一致」しか無いかもしれません。
ちょっと検討してみます。 -
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.
-
キューから再生中のラジオストリームを探して、タイトルを変更する件ですが
よくよく考えたら現在再生中のキュー内の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. -
らじる★らじる(NHKのインターネットラジオ配信)への対応調査
現状の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関係でインターネットラジオストリームが聞きたいニーズってありますか?
もしありそうでしたらかなり大掛かりになりますが、ちょっと検討して見るかもしれません。 -
-
2020-03-20 版のWebUI配信について
変更点は以下の通り。
※注意
下記の変更に伴い、DASHBOARDのARM・COREグラフが表示されない場合は、ブラウザのキャッシュが残っていることが原因であると想定されます。
この場合は一旦キャッシュを消去の上でWebUI再度起動してみてください(次回リリース時には上記対応します)。-
ラジオ再生中の楽曲情報更新に関するバグ修正
@akibon3 さまご指摘の件、当方での検証不足が原因でした。
(通常Consume On かつキューのトップに配置したラジオを再生していたため気づかなかった。申し訳ありません。) -
AoEプラグインの修正
@Castle さまご指摘の通り、文字列で結果を返すコマンドの表示領域高さを広げました。
また、同コマンド動作ではコマンド実行結果の完了をプラグインに伝えるため、
最下行に"---"をわざと追加していたのですが、これを表示させないように改良しています。 -
ファイルサイズの縮小化(ライブラリの置換)
従来はDASHBOARDのARM・CORE周波数を表示するドーナツ型のグラフ領域(タブレットサイズ以上で表示)は
Chart.jsというグラフ描画のライブラリを使用していましたが、
今回これを使わずに描画処理を自力で行うようにしました。
(今後何らかのグラフ表示を必要とした場合は復活する可能性はありますが、当面は上記にしか使っていないため)
これにより、実行ファイルサイズで130kBほど縮小することが出来ました。 -
通知の一部設定変更について
従来の通知Off設定は「一般的な通知のみ」対象としていましたが、
プラグイン実行成功時の「Success」など「失敗したら通知すれば分かる」
ようなものも表示させないようにカテゴリ設定しています。
(ファイルアップロード時や、NAS設定変更後など「Successが表示されないと状況把握が難しいものはそのままにしています。)
-
-
@sunatomo さま
複数のインターネットラジオ局をキューリストに入れたときの再生中の曲名表示の不具合の件、早速、修正いただきまして、ありがとうございました。無事、再生中の曲目が表示されるようになりました。「らじる★らじる」でのNHKネット配信ですが、私の環境(Win10+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+最適化がメインになります。