Mopidy: Masalah Penyangga saat memutar aliran audio

saya dapat mengkonfirmasi memiliki masalah yang sama menggunakan mopidy versi 1.1.1.

Begitu juga aku

Bermain-main dengan waktu buffer alsasink mungkin tidak akan banyak membantu untuk ini. Anda mungkin perlu mengubah buffer di dalam playbin2 , atau mungkin queue yang kita miliki pada output. Sudah ada TODO dalam kode untuk membuat pengaturan antrian ini lebih dapat diubah, yang kemungkinan dapat membantu untuk kasus seperti ini.

Ada juga bug yang saya buka beberapa waktu lalu untuk meninjau penanganan buffer untuk memastikan kami melakukan hal-hal dengan benar sesuai rekomendasi GStreamers.

dapat mengonfirmasi memiliki masalah ini menggunakan mopidy 2 pada banana pi dengan banana 16.04 saat ini.

Saya masih mengalami masalah yang sama persis di Mopidy 2.0.1 dengan setiap aliran radio. Adakah yang akan menjelaskan kepada saya, bagaimana bug yang menghancurkan seperti itu mungkin tidak diperbaiki di server musik sialan?

@karlmuuga Saya kira ini belum diatasi karena (1) sebagian besar pengguna tidak menggunakan Mopidy untuk mengalirkan aliran musik HTTP lainnya, melainkan memutar musik dari misalnya Spotify atau sistem file lokal (jika tidak demikian, lebih banyak pengguna akan mengalami masalah ini); dan (2) masalahnya kemungkinan ada di GStreamer, komponen pihak ketiga yang tidak dapat langsung diperbaiki oleh Mopidy.

Saya berani bertaruh bahwa jika Anda melakukan peluncuran gst (klien baris perintah GStreamer) dengan playbin dan URI streaming Anda, Anda akan menemukan masalah yang sama di sana. Jadi kita perlu mencari tahu apakah kita dapat menyetel parameter tersebut agar lebih pintar tentang buffering data dari souphttpsrc, yang kemungkinan merupakan elemen yang menyinggung ( https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins- good-plugins/html/gst-plugins-good-plugins-souphttpsrc.html ). Masalahnya adalah itu terkubur di dalam playbin.

Bersumpah tentang hal itu dan mengungkapkan penghinaan Anda bahwa kasus penggunaan khusus Anda belum diuji secara ekstensif tidak membawa kita lebih dekat ke solusi.

@allquixotic : Yah, saya menggunakan streaming _exclusively_ (aliran radio M3U biasa, podcast, internetarchive, dleyna) dan belum melihat ada masalah besar dengan versi Mopidy terbaru. Performa streaming sebagian besar dipengaruhi oleh faktor eksternal, terutama kualitas koneksi jaringan Anda, dan hanya ada begitu banyak pengaturan buffering tweaker yang dapat dilakukan tentang hal itu.

Mungkin berguna untuk mengetahui apakah ada yang mengalami masalah ini pada sistem selain papan lengan bertenaga rendah yaitu mesin desktop mereka.

@allquixotic Saya minta maaf untuk memberi tahu Anda bahwa Anda benar-benar salah tentang gstreamer. Gst-launch memutar streaming sehingga dimulai beberapa milidetik setelah klik enter dan streaming berjalan tanpa cegukan (tidak seperti mopidy). Jadi, bertentangan dengan apa yang Anda katakan, saya TIDAK mengalami masalah yang sama saat streaming URI langsung dari gst.

Dan apa lagi, saya menyelam jauh ke dalam log mopidy -v. Dari sana saya dapat melihat, bahwa pada saat yang benar-benar acak gstreamer mulai buffering (yang sebagian normal). Segala sesuatu yang terjadi setelah itu adalah total bs. Beberapa milidetik kemudian buffer terisi (Pesan selesai ASYNC + buffered 100%) dan kemudian dengan bodohnya mopidy menunggu selama 5 detik atau lebih hingga pemutaran dilanjutkan (dan sepanjang waktu, waktu terus berdetak di depan pada jam Now Playing, dan hening memenuhi ruangan). Ini jelas bukan yang Anda bicarakan di sini.

@tkem Tolong beri tahu saya tentang pengaturan, konfigurasi, dan kecepatan internet Anda (milik saya adalah kabel 5/5 Mbps, bersihkan minimal Debian 7 dan Intel dual core). Saya sudah mencoba mengubah pengaturan buffering tetapi itu tidak memengaruhi apa pun.

@kingosticks Saya kira laptop Fujitsu Siemens Amilo saya bukan mesin bertenaga rendah.

Setelah memasukkan sebaris kode ke dalam file mopidy/audio/actor.py, cegukan itu hilang. https://discuss.mopidy.com/t/streaming-radio-station-pausing-buffering/1251

1. Baris kode yang mana tepatnya? Bit set_live(True) ? Jika saya pikir itu terkait dengan beberapa bug terbuka lama yang saya miliki tentang penanganan langsung yang mungkin harus dikunjungi kembali oleh seseorang. Idealnya mencari tahu beberapa cara untuk membuat backend untuk memberi sinyal ke audio bahwa konten itu hidup atau tidak.
2. Hal menunggu selama lima detik bisa jadi karena harus melalui antrian pesan aktor pykka. Kami mencoba memastikan bahwa peristiwa asinkron segera ditindaklanjuti, tetapi juga harus sesuai dengan keamanan utas, di mana kami menggunakan model aktor. Adakah saran untuk mereproduksi temuan itu?

1. Ya, sedikit itu. Saya akan memberi tahu Anda jika saya mengalami masalah dengan yang satu itu.
2. Sarannya adalah - buat file playlists.m3u8 dengan konten berikut (tentu saja Anda dapat mengubah URI streaming):

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

Mainkan daftar putar.

@adamcik apakah Anda berhasil mereproduksi temuan? Saya telah menemukan bahwa mendefinisikan on_source_setup sebagai

  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'])

menghentikan cegukan radio, tetapi terkadang melewatkan selusin atau dua kali milidetik aliran tersebut. Namun, menghapus pernyataan if akan melakukan lompatan untuk semua sumber. Jadi solusi ini tidak benar, tetapi lebih baik daripada diam.

Saya tidak punya kesempatan untuk mencoba apa pun.

solusi dengan is_live menimbulkan masalah dengan sumber http normal (yang memiliki durasi). misalnya dlna (mopidy-dleyna) menggunakan http untuk streaming, masalahnya adalah pemain tidak akan melompat ke lagu berikutnya setelah yang sebelumnya selesai.

adakah yang tahu cara memeriksa _on_source_setup bahwa sumbernya dapat dicari atau memiliki durasi atau properti lain yang memberi tahu jika sumbernya bukan streaming langsung?

Hanya dua sen saya di sini :-) Saya mengalami masalah buffer yang sama - hanya pada raspberry pi yang menjalankan raspian yang diperbarui - bukan pada platform pengembang saya, PCLinuxOS di mana semuanya mengalir dengan baik.

Saya telah merangkum masalah ini menjadi dua aliran ini:
Masalah buffer pada raspberry pi: gst-validate-1.0 playbin uri=http://stream-dc1.radioparadise.com/mp3-128
Info buffer di % berkedip antara 0% dan beberapa persen, dan streaming tidak pernah dimulai

Dengan info debug: GST_DEBUG=*:5 gst-validate-1.0 playbin uri=http://stream-uk1.radioparadise.com/mp3-192

Bermain di raspberry pi: gst-validate-1.0 playbin uri=http://streams.80s80s.de/love/mp3-192/radiosure/

Saya mengkode pada radio web python 2.7 gstreamer 1.0, dan terjebak dengan pi yang hanya memainkan sedikit stasiun radio

Saya memiliki masalah "cegukan" yang sama, pada Orange Pi PC Plus, versi Mopidy: 2.1.0-1
solusi dengan source.set_live(True) membantu sejenak ... sampai saya menemukan bahwa pemain tidak melompat ke bab berikutnya dalam sebuah buku dari Google Music (streamed sebagai GstSoupHTTPSrc juga)

Ada saran?

Terima kasih

tambahan juga dapat mengkonfirmasi masalah ini untuk komputer desktop berbasis baik haswell menjalankan "saat ini" debian jessie, gstreamer 1 dan mopidy 2 dan juga sebagai mixer.
Mopidy pada dasarnya tidak dapat digunakan untuk mendengarkan stasiun radio dalam kondisi saat ini. mopidy-youtube, mopidy-spotify dan memutar dari filestore lokal bekerja dengan baik selama berjam-jam.
Apakah ada solusi atau perbaikan bug yang tersedia untuk ini?
Tidak ada entri log yang terkait dengan masalah buffering itu.

Saya dapat menawarkan solusi saya, ini adalah tambalan terhadap versi 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 bisakah Anda membuat permintaan tarik untuk ini dan menautkannya ke masalah ini? Terima kasih!

atau di UAudioDecorder_FFmpeg baris 1020 setel LIBAVCODEC_VERSION ke sekitar 60 alih-alih 57 dan coba lagi dengan ffmpeg 2.8

Sayangnya perbaikan yang diusulkan hanyalah solusi. Kami tidak dapat membuat hardcode bahwa semua aliran http harus ditayangkan karena tidak demikian halnya. Apa yang perlu terjadi adalah mopidy.audio membutuhkan cara baru bagi backend untuk memberitahunya bahwa sebuah sumber aktif. Kemudian backend streaming dan backend lain yang kemungkinan besar memiliki streaming langsung dapat menyebutnya di backend pemutaran mereka.

Untuk membuat ini lebih mudah bagi orang-orang, akan lebih baik jika ini dienkapsulasi dalam BaseStreamingBackend yang dapat digunakan kembali untuk backend semacam itu.

@adamcik solusi saya tidak mengasumsikan bahwa semua aliran http hidup. Saya memeriksa apakah track.length adalah None untuk membedakan antara streaming langsung dan tidak langsung. track.length diatur dalam mopidy.stream.actor oleh metode StreamLibraryProvider.lookup yang pada gilirannya menggunakan mopidy.audio.scan. Ada juga atribut 'seekable' yang tersedia tetapi dibuang di StreamLibraryProvider.lookup. Saya pikir trek yang tidak memiliki panjang dan tidak dapat dicari selalu dapat diperlakukan sebagai streaming langsung.

@basisbit Saya akan membuat permintaan tarik ketika saya sampai di rumah.

@mczerski maaf agak terlalu pagi untuk saya, jadi bacalah sedikit untuk berpuasa. Saya melihat sekarang Anda telah mengubah set_uri menjadi pass in live. Dua saran untuk ini:

1. Mungkin gunakan cek seperti https://github.com/mopidy/mopidy/blob/develop/mopidy/audio/utils.py#L67 untuk is-live yang ada alih-alih hardcoding jenis sumber?
2. Pastikan untuk membuatnya set_uri(uri, is_live=False) (atau mungkin hanya live=False , tapi itu lebih dari sebuah gudang sepeda). Kami tidak ingin merusak API set_uri . Dan jika kita perlu memecahkannya, kita hanya dapat melakukannya dalam rilis besar, dan ada banyak backend yang perlu diperbarui.

Saya juga terbuka untuk tidak mendukung ini ke set_uri , tetapi memiliki metode terpisah. Meskipun saya belum memikirkan pro/kontra dari pilihan seperti itu.

@adamcik terima kasih atas sarannya. Saya tidak terbiasa dengan kode mopidy dan perbaikan saya hanyalah perbaikan jelek yang cepat :) Jika Anda setuju dengan ide di balik perbaikan saya, saya dapat mencoba menulis solusi produksi jika saya akan menemukan waktu untuk ini.

Saya agak bertanya-tanya bagaimana pemain lain (yang, menurut komentar pengguna tampaknya benar) menangani ini. Apakah mereka memperlakukan semua sumber jaringan sebagai aliran "langsung"? Atau apakah ada keajaiban yang terlibat, yang dapat ditransplantasikan ke backend stream , membuat ekstensi tidak menyadari perbedaan itu?

@tkem Saya gagal menemukan apa pun di Rhythmbox yang melakukan ini, tetapi saya memang menemukan: https://github.com/GNOME/totem/blob/80709b95f16258c68d47a0a8587c41f93d291e54/src/backend/bacon-video-widget.c#L2570 (yang apa yang kami sarankan sebagai perubahan di sini)

EDIT: dan yang ini https://github.com/xfce-mirror/parole/blob/1a952fe9b632969f5ecbdc4f783ae285959c435c/src/misc/parole-stream.c#L169

Saya tidak mengerti mengapa ini tidak lebih eksplisit dalam dokumentasi gstreamer.

@kingosticks : Bagus!
Jadi, apakah ada kemungkinan "solusi" serupa berdasarkan proposal @mczerski akan membuatnya menjadi Mopidy jangka pendek? Meskipun saya menyukai gagasan tentang backend yang menentukan secara eksplisit apakah suatu streaming ditayangkan atau tidak, saya kira ini tidak akan terjadi dalam waktu dekat...

Saya tidak melihat kerugian dari ini, jika kita menanganinya dalam set_uri dengan nilai default, kita dapat memilikinya di rilis minor berikutnya. Dengan mengingat dua komentar @adamcik , apakah Anda ingin mengirimkan PR @mczerski? Gagal bahwa saya akan.

@kingosticks Saya tidak keberatan jika Anda melakukan itu. Aku hanya tidak punya waktu untuk itu.

sayangnya solusi saya tidak sepenuhnya baik ... masalahnya adalah dengan baris kode ini di backend.py (baris 251):
self.audio.set_uri(uri, track.length adalah None).get()

terkadang track.lengthnya Tidak Ada meskipun faktanya trek tersebut bukan streaming langsung :/ ini terjadi dengan trek spotify dan youtube. Perilaku ini acak, terkadang track.length adalah None dan terkadang tidak None. Di web gui trek selalu ditampilkan panjangnya.

apa kerugian dari perubahan untuk lagu-lagu di mana gstreamer atau kode mopidy kami berpikir bahwa panjangnya adalah 0? (kecuali untuk seseorang yang tidak bisa melompat ke dalam trek) Tolong seseorang lakukan saja solusi ajaib yang bagus... XD

Jeda akhirnya membuang data alih-alih menjeda. Jadi memiliki sesuatu seperti set_uri(uri, live=False) (atau set_live(live) ) mungkin masih layak, Anda hanya perlu backend untuk mengetahui apakah mereka menyetelnya ke true, atau mendasarkannya pada panjang trek.

Adapun panjangnya terkadang tidak ada, itu mungkin perlombaan data, tapi saya tidak yakin.

@basisbit kelemahan terbesar adalah kenyataan bahwa trek dengan atribut is-live yang disetel ke true tidak akan berakhir, jadi jika Anda memiliki trek lain di daftar putar setelahnya, trek itu tidak akan diputar kecuali Anda secara manual melewati trek yang sedang diputar. Saya percaya bahwa solusi yang tepat adalah mengatur is-live di tempat kode yang berbeda, di mana panjang trek dijamin diatur dengan benar, tetapi saya memiliki sedikit pengetahuan tentang kode mopidy dan saat ini tidak ada waktu untuk mempelajarinya sehingga saya bisa 'tidak menemukan solusi yang tepat :(

Halo semua,

Saya mengalami masalah yang sama dengan mereproduksi aliran web radio. Saya bertanya-tanya apakah ini akhirnya diperbaiki dalam rilis mopidy terbaru?

Terima kasih

Hai,

Saya mengalami masalah ini dan perbaikan yang disebutkan di atas tidak berfungsi untuk saya.