Mopidy: オーディオストリームの再生中のバッファリングの問題

mopidyバージョン1.1.1を使用して同じ問題があることを確認できます。

わたしもそう

alsasinkのバッファ時間をいじっても、おそらくこれにはあまり効果がありません。 おそらく、 playbin2内のバッファー、または出力にあるqueueを変更する必要があります。 これらのキュー設定をより調整可能にするためのTODOがコードにすでに含まれています。これは、このような場合に役立つ可能性があります。

また、GStreamersの推奨事項に従って正しく処理されていることを確認するために、バッファー処理を確認するために少し前に開いたバグもあります。

現在のバナナ16.04のバナナパイでmopidy2を使用して、この問題があることを確認できます。

Mopidy 2.0.1でも、すべての無線ストリームでまったく同じ問題が発生します。 誰かが私に説明してくれるだろうか、このような壊滅的なバグが、なんてこった音楽サーバーで修正されない可能性さえあるのだろうか？

@karlmuugaこれは対処されていないと思います。（1）ほとんどのユーザーはMopidyを使用して他のHTTP音楽ストリームをストリーミングするのではなく、Spotifyやローカルファイルシステムなどから音楽を再生します（そうでない場合は、より多くのユーザーがこの問題に苦しむでしょう）; （2）問題は、Mopidyが直接修正できないサードパーティコンポーネントであるGStreamerにある可能性があります。

playbinとストリーミングURIを使用してgst-launch（コマンドラインGStreamerクライアント）を実行すると、同じ問題が発生することは間違いありません。 したがって、これらのパラメータを調整して、問題のある要素である可能性が高いsouphttpsrcからのデータのバッファリングについてよりスマートにできるかどうかを判断する必要があります（https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins- good-plugins / html / gst-plugins-good-plugins-souphttpsrc.html）。 問題は、それがプレイビンの中に埋もれていることです。

それについて宣誓し、特定のユースケースがそれほど広範囲にテストされていないことを憤慨していることを表明しても、解決策に近づくことはできません。

@allquixotic ：ええと、私はストリーミングを_排他的に_（プレーンなM3Uラジオストリーム、ポッドキャスト、internetarchive、dleyna）使用していますが、最近のMopidyバージョンの大きな問題には気づいていません。 ストリーミングのパフォーマンスは、外部要因、特にネットワーク接続の品質に大きく影響されます。これについては、バッファリング設定を微調整するだけで済みます。

低電力のアームボード以外のシステム、つまりデスクトップマシンで、誰かがこの問題を経験しているかどうかを知ることは有用かもしれません。

@allquixoticgstreamerについてあなたが絶対に間違っていると言って申し訳ありません。 Gst-launchはストリームを再生するため、Enterヒットから数ミリ秒後に開始され、ストリームは一時的な中断なしに終了します（mopidyとは異なります）。 したがって、あなたが言ったこととは反対に、gstから直接URIをストリーミングしているときに同じ問題は発生しませんでした。

そして、他に、私はmopidy-vログを深く掘り下げました。 そこから、絶対にランダムな瞬間にgstreamerがバッファリングを開始することがわかります（これは部分的に正常です）。 その後に起こることはすべて合計bsです。 数ミリ秒後、バッファがいっぱいになり（ASYNC完了メッセージを取得+ 100％バッファリング）、その後、再生が再開されるまで5秒以上待機します（そして、その間ずっと、再生中の時計の時刻が進み、沈黙します部屋を埋めます）。 これは間違いなくあなたがここで話していることではありません。

@tkemセットアップ、構成、インターネット速度について教えてください（私のものは5/5 Mbpsケーブル、クリーンなDebian 7ミニマル、Intelデュアルコアです）。 私はすでにバッファリング設定を微調整しようとしましたが、それは何にも影響しません。

@kingosticks私のFujitsuSiemensAmilo laptoは、真剣に低電力のマシンではないと思います。

mopidy / audio / actor.pyファイルにコード行を挿入した後、問題はなくなりました。 https://discuss.mopidy.com/t/streaming-radio-station-pausing-buffering/1251

1. 正確にはどのコード行ですか？ set_live(True)ビット？ それがいくつかの古い未解決のバグに関連していると思うなら、誰かがおそらく再訪すべきライブ処理について私は持っています。 理想的には、コンテンツがライブであるかどうかをオーディオに通知するためのバックエンドへの何らかの方法を考え出します。
2. 5秒間待機するのは、pykkaアクターのメッセージキューを通過する必要があるためである可能性があります。 非同期イベントがすぐに実行されるようにしますが、アクターモデルを使用するスレッドセーフでもうまく機能する必要があります。 その発見を再現するための提案はありますか？

1. はい、そのビット。 問題が発生した場合はお知らせします。
2. 提案は次のようになります-次のコンテンツを含むplaylists.m3u8ファイルを作成します（もちろん、ストリームURIを変更できます）。

#EXTM3U
#EXTINF:0, Classic Rock
http://us2.internet-radio.com:8191

プレイリストを再生します。

@adamcik調査結果の再現に成功しましたか？ on_source_setupを次のように定義することを発見しました

  def _on_source_setup(self, element, source):
        gst_logger.debug(
            'Got source-setup signal: element=%s', source.__class__.__name__)

        if source.get_factory().get_name() == 'appsrc':
            self._appsrc.configure(source)
        else:
            self._appsrc.reset()

        if source.__class__.__name__ == '__main__.GstSoupHTTPSrc':
            gst_logger.debug('HTTP Src - setting live mode')
            source.set_live(True)

        utils.setup_proxy(source, self._config['proxy'])

無線の占有を停止しますが、ストリームのそのミリ秒の数十または2倍をスキップすることがあります。 ただし、ifステートメントを削除すると、すべてのソースがスキップされます。 したがって、この解決策は正しくありませんが、沈黙よりも優れています。

私は何も試す機会がありませんでした。

is_liveを使用したソリューションでは、通常のhttpソース（期間があるソース）で問題が発生します。 たとえば、dlna（mopidy-dleyna）はストリーミングにhttpを使用しますが、問題は、前の曲が終了した後、プレーヤーが次の曲にスキップしないことです。

ソースがシーク可能であるか、ソースがライブストリームではないかどうかを示す期間またはその他のプロパティがあることを、_on_source_setupでチェックインする方法を知っている人はいますか？

ここでちょうど私の2セント:-)私は同じバッファの問題を経験しています-更新されたラズベリーを実行しているラズベリーパイでのみ-すべてが正常にストリーミングされている私の開発者プラットフォームであるPCLinuxOSではありません。

私はこの問題を次の2つの流れに要約しました。
ラズベリーパイのバッファの問題： gst-validate-1.0 playbin uri=http://stream-dc1.radioparadise.com/mp3-128
％単位のバッファ情報が0％から数パーセントの間で点滅しており、ストリームが開始されない

デバッグ情報付き： GST_DEBUG=*:5 gst-validate-1.0 playbin uri=http://stream-uk1.radioparadise.com/mp3-192

ラズベリーパイで遊ぶ： gst-validate-1.0 playbin uri=http://streams.80s80s.de/love/mp3-192/radiosure/

私はPython2.7gstreamer 1.0 Webラジオでコーディングしていますが、piがごく少数のラジオ局しか再生していない状態で立ち往生しています。

Orange Pi PC Plus、Mopidyバージョン：2.1.0-1で同じ「ヒカップ」の問題が発生します
source.set_live（True）を使用したソリューションは、しばらくの間役に立ちました...プレーヤーがGoogleミュージックの本の次の章にスキップしていないことがわかるまで（GstSoupHTTPSrcとしてもストリーミングされます）

何かアドバイス？

どうも

さらに、「現在の」debian jessie、gstreamer 1、mopidy 2、およびalsaをミキサーとして実行している適切なhaswellベースのデスクトップコンピューターでこの問題を確認することもできます。
Mopidyは基本的に、現在の状態のラジオ局を聴くためには使用できません。 mopidy-youtube、mopidy-spotify、ローカルファイルストアからの再生は何時間でも問題なく動作します。
これに利用できる回避策またはバグ修正はありますか？
そのバッファリングの問題に関連するログエントリはありません。

私は自分の解決策を提供できます。これは2.1.0バージョンに対するパッチです。

diff --git a/mopidy/audio/actor.py b/mopidy/audio/actor.py
index 6020bc1..6020d2f 100644
--- a/mopidy/audio/actor.py
+++ b/mopidy/audio/actor.py
@@ -415,6 +415,7 @@ class Audio(pykka.ThreadingActor):
         self._buffering = False
         self._tags = {}
         self._pending_uri = None
+        self._is_live = False
         self._pending_tags = None
         self._pending_metadata = None

@@ -547,9 +548,12 @@ class Audio(pykka.ThreadingActor):
         else:
             self._appsrc.reset()

+        if source.get_factory().get_name() == 'souphttpsrc':
+            source.set_property('is-live', self._is_live)
+
         utils.setup_proxy(source, self._config['proxy'])

-    def set_uri(self, uri):
+    def set_uri(self, uri, is_live):
         """
         Set URI of audio to be played.

@@ -558,7 +562,7 @@ class Audio(pykka.ThreadingActor):
         :param uri: the URI to play
         :type uri: string
         """
-
+        self._is_live = is_live
         # XXX: Hack to workaround issue on Mac OS X where volume level
         # does not persist between track changes. mopidy/mopidy#886
         if self.mixer is not None:
diff --git a/mopidy/backend.py b/mopidy/backend.py
index 7412ccc..f15b616 100644
--- a/mopidy/backend.py
+++ b/mopidy/backend.py
@@ -248,7 +248,7 @@ class PlaybackProvider(object):
                 'Backend translated URI from %s to %s', track.uri, uri)
         if not uri:
             return False
-        self.audio.set_uri(uri).get()
+        self.audio.set_uri(uri, track.length is None).get()
         return True
     def resume(self):

@mczerskiは、これに対するプルリクエストを作成して、この問題にリンクできますか？ ありがとう！

またはUAudioDecorder_FFmpeg行1020で、LIBAVCODEC_VERSIONを57ではなく60のようなものに設定し、ffmpeg2.8で再試行します

残念ながら、提案された修正は単なる回避策です。 すべてのhttpストリームがライブである必要があることをハードコーディングすることはできません。これは、単にそうではないためです。 発生する必要があるのは、 mopidy.audioには、ソースがライブであることをバックエンドが通知するための新しい方法が必要なことです。 次に、ライブストリームを持っている可能性が高いストリームバックエンドおよびその他のバックエンドは、再生バックエンドでこれを呼び出すことができます。

これを人々にとってより簡単にするために、これがそのようなバックエンドに再利用できるBaseStreamingBackendにカプセル化されているとよいでしょう。

@adamcik私のソリューションは、すべてのhttpストリームがライブであるとは想定していません。 ライブストリームと非ライブストリームを区別するために、track.lengthがNoneであるかどうかを確認します。 track.lengthは、mopidy.audio.scanを使用するStreamLibraryProvider.lookupメソッドによってmopidy.stream.actorに設定されます。 利用可能な属性「seekable」もありますが、StreamLibraryProvider.lookupに破棄されます。 長さがなく、シークできないトラックは、ライブストリームとして扱うことができると思います。

@basisbit帰宅したらプルリクエストをします。

@mczerskiは私にとって早朝に少し申し訳ありませんでした、それで少し速くスキミングしました。 set_uriを変更してパスインがライブになっているようです。 これに関する2つの提案：

1. おそらく、ソースタイプをハードコーディングする代わりに、 https：//github.com/mopidy/mopidy/blob/develop/mopidy/audio/utils.py#L67のようなチェックを使用してis-liveが存在しますか？
2. 必ずset_uri(uri, is_live=False)にします（またはおそらくlive=Falseですが、それはもっと自転車小屋です）。 set_uriのAPIを壊したくありません。 そして、それを破る必要がある場合は、メジャーリリースでしか破ることができず、更新が必要なバックエンドがたくさんあります。

また、これをset_uriに戻すのではなく、別の方法を使用することもできます。 私はそのような選択の賛否両論を考えていませんが。

@adamcikアドバイスありがとうございます。 私はモピディコードに精通しておらず、私の修正はただの醜い修正でした:)私の修正の背後にある考えに同意するなら、私がこれのための時間を見つければ、私は本番ソリューションを書こうとするかもしれません。

他のプレイヤー（ユーザーのコメントによると、これは明らかにこれを正しく理解している）がこれをどのように処理するのか疑問に思っています。 すべてのネットワークソースを「ライブ」ストリームとして扱いますか？ または、 streamバックエンドに移植して、拡張機能がその区別に気付かないままにする可能性のある魔​​法が含まれていますか？

@tkemこれを行うRhythmboxで何かを見つけることができませんでしたが、見つけました： https ://github.com/GNOME/totem/blob/80709b95f16258c68d47a0a8587c41f93d291e54/src/backend/bacon-video-widget.c#L2570（これはここでの変更として提案したもの）

編集：そしてこれはhttps://github.com/xfce-mirror/parole/blob/1a952fe9b632969f5ecbdc4f783ae285959c435c/src/misc/parole-stream.c#L169

これがgstreamerのドキュメントでより明確になっていない理由がわかりません。

@kingosticks ：いいね！
それで、 @ mczerskiの提案に基づく同様の「回避策」が短期的にMopidyになる可能性はありますか？ ストリームがライブであるかどうかを明示的に指定するバックエンドのアイデアは好きですが、これはすぐには起こらないと思います...

これの欠点はわかりません。デフォルト値を使用してset_uriで処理すると、次のマイナーリリースでこれを使用できます。 @adamcikの2つのコメントを念頭に置いて、PR @mczerskiを送信しますか？ 失敗します。

@kingosticksあなたがそうしてもかまいません。 その時間はありません。

残念ながら、私の解決策は完全には良くありません...問題はbackend.pyのこのコード行（251行目）にあります：
self.audio.set_uri（uri、track.lengthはNone）.get（）

トラックがライブストリームではないにもかかわらず、track.lengthがNoneになる場合があります：/これはspotifyおよびyoutubeトラックで発生しました。 この動作はランダムであり、track.lengthがNoneである場合と、Noneではない場合があります。 Web GUIでは、トラックには常にその長さが表示されます。

gstreamerまたはmopidyコードが長さが0であると考える曲の変更の欠点は何でしょうか？ （トラック内にジャンプできないものを除いて）誰かが魔法のように良い解決策をコミットしてください... XD

一時停止すると、一時停止する代わりにデータが破棄されます。 したがって、 set_uri(uri, live=False) （またはset_live(live) ）のようなものを使用することはおそらくまだ可能です。バックエンドがそれをtrueに設定するか、トラックの長さに基づいて設定するかについて賢くする必要があります。

長さがゼロになることもありますが、それはデータの競争かもしれませんが、よくわかりません。

@basisbitの最大の欠点は、is-live属性がtrueに設定されているトラックが終了しないため、後でプレイリストに他のトラックがある場合、現在再生されているトラックを手動でスキップしない限り、それらは再生されないことです。 正しい解決策は次のように設定することだと思います-トラックの長さが正しく設定されることが保証されているコードの別の場所に住んでいますが、私はモピディコードの知識がほとんどなく、現在それを学ぶ時間がないので、正しい解決策が見つかりません:(

こんにちは、みんな、

ラジオウェブストリームの再生でも同じ問題が発生しています。 これが最終的に最新のmopidyリリースで修正されたかどうか疑問に思いましたか？

ありがとう

やあ、

この問題が発生していますが、上記の修正が機能していません。