Mopidy: ऑडियो स्ट्रीम चलाने के दौरान बफरिंग की समस्या

मैं mopidy संस्करण 1.1.1 का उपयोग करके एक ही समस्या होने की पुष्टि कर सकता हूं।

मैं भी ऐसा करूँ

alsasink बफर समय के साथ खिलवाड़ शायद इसके लिए बहुत कुछ नहीं करेगा। आपको शायद playbin2 , या संभवतः queue के अंदर बफ़र्स को आउटपुट पर बदलना होगा। कोड में पहले से ही एक TODO है जो इन कतारों को और अधिक ट्वीक करने योग्य बनाता है, जो इस तरह के मामलों में मदद कर सकता है।

एक बग भी है जिसे मैंने कुछ समय पहले बफर हैंडलिंग की समीक्षा करने के लिए खोला था ताकि यह सुनिश्चित हो सके कि हम GStreamers अनुशंसाओं के अनुसार सही तरीके से काम कर रहे हैं।

वर्तमान केले 16.04 के साथ केले के पाई पर मोपिडी 2 का उपयोग करके इस समस्या की पुष्टि कर सकते हैं।

मुझे अभी भी हर एक रेडियो स्ट्रीम के साथ Mopidy 2.0.1 पर ठीक वैसी ही समस्या का सामना करना पड़ता है। क्या कोई मुझे समझाएगा, इस तरह के विनाशकारी बग को भगवान के संगीत सर्वर पर ठीक किया जाना कैसे संभव है?

@karlmuuga मुझे लगता है कि इसे संबोधित नहीं किया गया है क्योंकि (1) अधिकांश उपयोगकर्ता अन्य HTTP संगीत धाराओं को स्ट्रीम करने के लिए Mopidy का उपयोग नहीं करते हैं, बल्कि संगीत को बंद कर देते हैं जैसे Spotify या स्थानीय फ़ाइल सिस्टम (यदि यह मामला नहीं था, बहुत अधिक उपयोगकर्ताओं को इस समस्या का सामना करना पड़ेगा); और (2) समस्या GStreamer में होने की संभावना है, एक तृतीय पक्ष घटक जिसे Mopidy सीधे ठीक नहीं कर सकता है।

मैं शर्त लगाने को तैयार हूं कि यदि आप प्लेबिन और अपने स्ट्रीमिंग यूआरआई के साथ जीएसटी-लॉन्च (कमांड लाइन जीस्ट्रीमर क्लाइंट) करते हैं, तो आप वहां एक ही समस्या का सामना करेंगे। इसलिए हमें यह पता लगाने की आवश्यकता है कि क्या हम उन मापदंडों को सूपhttpsrc से बफ़रिंग डेटा के बारे में होशियार होने के लिए ट्यून कर सकते हैं, जो संभवतः आपत्तिजनक तत्व है ( https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins- Good-plugins/html/gst-plugins-good-plugins-souphttpsrc.html)। समस्या यह है कि इसे एक प्लेबिन के अंदर दबा दिया गया है।

इसके बारे में शपथ लेना और अपना आक्रोश व्यक्त करना कि आपके विशिष्ट उपयोग के मामले का व्यापक परीक्षण नहीं किया गया है, हमें समाधान के करीब नहीं लाता है।

@allquixotic : ठीक है, मैं स्ट्रीमिंग _exclusively_ (सादे M3U रेडियो स्ट्रीम, पॉडकास्ट, इंटरनेटआर्काइव, डेलीना) का उपयोग करता हूं और हाल के Mopidy संस्करणों के साथ कोई बड़ा मुद्दा नहीं देखा है। स्ट्रीमिंग का प्रदर्शन काफी हद तक बाहरी कारकों से प्रभावित होता है, विशेष रूप से आपके नेटवर्क कनेक्शन की गुणवत्ता, और इसके बारे में केवल इतनी ही ट्वीकिंग बफ़रिंग सेटिंग्स कर सकती हैं।

यह जानना उपयोगी हो सकता है कि क्या किसी को कम शक्ति वाले आर्म बोर्ड यानी उनकी डेस्कटॉप मशीन के अलावा किसी सिस्टम पर इस समस्या का सामना करना पड़ रहा है।

@allquixotic मुझे आपको यह बताते हुए खेद हो रहा है कि आप gstreamer के बारे में बिल्कुल गलत हैं। जीएसटी-लॉन्च स्ट्रीम चलाता है ताकि एंटर हिट के बाद यह कुछ मिलीसेकंड शुरू हो जाए और स्ट्रीम बिना हिचकी के (मोपिड के विपरीत) हो जाए। तो, आपने जो कहा उसके विपरीत, यूआरआई को सीधे जीएसटी से स्ट्रीमिंग करते समय मुझे एक ही समस्या का सामना नहीं करना पड़ा।

और क्या है, मैंने mopidy -v लॉग में गहराई से गोता लगाया। वहां से मैं देख सकता हूं, कि बिल्कुल यादृच्छिक क्षण पर gstreamer बफरिंग शुरू करता है (जो आंशिक रूप से सामान्य है)। उसके बाद जो कुछ भी होता है वह कुल bs है। युगल मिलीसेकंड बाद में बफर भर जाता है (ASYNC किया गया संदेश + 100% बफ़र किया गया) और फिर मूर्खतापूर्ण तरीके से 5 या अधिक सेकंड तक प्रतीक्षा करता है जब तक कि प्लेबैक फिर से शुरू नहीं हो जाता (और पूरे समय, समय नाउ प्लेइंग घड़ी पर आगे टिक जाता है, और मौन कमरा भरता है)। यह निश्चित रूप से वह नहीं है जिसके बारे में आप यहाँ बात कर रहे हैं।

@tkem क्या आप कृपया मुझे अपने सेटअप, कॉन्फ़िगरेशन और इंटरनेट स्पीड (मेरा 5/5 एमबीपीएस केबल, क्लीन डेबियन 7 न्यूनतम और इंटेल डुअल कोर) के बारे में बताएं। मैंने पहले ही बफरिंग सेटिंग्स को बदलने की कोशिश की है, लेकिन यह कुछ भी प्रभावित नहीं करता है।

@kingosticks मुझे लगता है कि मेरा फुजित्सु सीमेंस एमिलो लैपटॉप गंभीर रूप से कम शक्ति वाली मशीन नहीं है।

mopidy/audio/actor.py फ़ाइल में कोड की एक पंक्ति डालने के बाद, हिचकी चली गई थी। https://discuss.mopidy.com/t/streaming-radio-station-pausing-buffering/1251

1. कोड की कौन सी पंक्ति बिल्कुल? set_live(True) बिट? अगर मुझे लगता है कि यह कुछ पुरानी खुली बगों से जुड़ा हुआ है तो मेरे पास लाइव हैंडलिंग के बारे में है जिसे किसी को शायद फिर से देखना चाहिए। आदर्श रूप से ऑडियो को संकेत देने के लिए बैकएंड का कोई तरीका निकालना कि सामग्री लाइव है या नहीं।
2. पांच सेकंड की प्रतीक्षा की वजह पायक्का अभिनेता संदेश कतार के माध्यम से जाना हो सकता है। हम यह सुनिश्चित करने की कोशिश करते हैं कि एसिंक्स इवेंट्स पर तुरंत कार्रवाई हो, लेकिन इसे थ्रेड सेफ्टी के साथ भी अच्छा खेलना होगा, जहां हम एक अभिनेता मॉडल का उपयोग करते हैं। उस खोज को पुन: प्रस्तुत करने के लिए कोई सुझाव?

1. हाँ, वह बिट। अगर मुझे इसमें कोई समस्या आती है तो मैं आपको बता दूंगा।
2. निम्नलिखित सामग्री के साथ प्लेलिस्ट.m3u8 फ़ाइल बनाएं (बेशक आप स्ट्रीम यूआरआई बदल सकते हैं):

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

रेडियो हिचकी बंद कर देता है, लेकिन कभी-कभी धारा के उस मिलीसेकंड को दर्जन या दोगुना छोड़ देता है। हालांकि, अगर कथन को हटाने से सभी स्रोतों के लिए छोड़ दिया जाएगा। तो यह उपाय सही नहीं है, बल्कि मौन से बेहतर है।

मुझे कुछ भी आजमाने का मौका नहीं मिला है।

is_live के साथ समाधान सामान्य http स्रोतों (जिनकी अवधि है) के साथ समस्याएं पैदा करता है। उदाहरण के लिए dlna (mopidy-dleyna) स्ट्रीमिंग के लिए http का उपयोग करता है, समस्या यह है कि खिलाड़ी पिछले समाप्त होने के बाद अगले गीत पर नहीं जाएगा।

क्या किसी को इस बात का अंदाजा है कि _on_source_setup में कैसे जांचा जाए कि वह स्रोत तलाशने योग्य है या उसके पास अवधि या अन्य संपत्ति है जो बताती है कि स्रोत लाइव स्ट्रीम नहीं है या नहीं?

बस मेरे दो सेंट यहाँ :-) मैं एक ही बफर समस्या का सामना कर रहा हूँ - केवल एक रास्पबेरी पाई पर अद्यतन रास्पियन चल रहा है - मेरे डेवलपर प्लेटफॉर्म पर नहीं, पीसीलिनक्सओएस जहां सब कुछ ठीक चल रहा है।

मैंने इस मुद्दे को इन दो धाराओं में उबाला है:
रास्पबेरी पाई पर बफर मुद्दा: 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/

मैं एक अजगर 2.7 gstreamer 1.0 वेब रेडियो पर कोडिंग कर रहा हूं, और केवल बहुत कम रेडियो स्टेशनों को चलाने वाले पाई के साथ फंस गया हूं

ऑरेंज पीआई पीसी प्लस, मोपिडी संस्करण पर मुझे वही "हिचकी" समस्या है: 2.1.0-1
source.set_live(True) के साथ समाधान ने एक पल के लिए मदद की... जब तक मुझे पता नहीं चला कि खिलाड़ी Google Music की किसी पुस्तक के अगले अध्याय पर नहीं जा रहा है (GstSoupHTTPSrc के रूप में भी स्ट्रीम किया गया)

कोई सलाह?

धन्यवाद

अतिरिक्त रूप से "करंट" डेबियन जेसी, जीस्ट्रीमर 1 और मोपिडी 2 और मिक्सर के रूप में चलने वाले एक सभ्य हैसवेल आधारित डेस्कटॉप कंप्यूटर के लिए भी इस समस्या की पुष्टि कर सकता है।
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 पर सेट करें और ffmpeg 2.8 के साथ पुनः प्रयास करें

अफसोस की बात है कि प्रस्तावित फिक्स सिर्फ एक समाधान है। हम हार्डकोड नहीं कर सकते हैं कि सभी http स्ट्रीम लाइव होनी चाहिए क्योंकि ऐसा नहीं है। क्या होना चाहिए कि mopidy.audio को बैकएंड को यह बताने के लिए एक नया तरीका चाहिए कि एक स्रोत लाइव है। फिर स्ट्रीम बैकएंड और अन्य बैकएंड जिनमें लाइव स्ट्रीम होने की अत्यधिक संभावना है, इसे अपने प्लेबैक बैकएंड में कॉल कर सकते हैं।

लोगों के लिए इसे आसान बनाने के लिए यह भी अच्छा होगा यदि इसे BaseStreamingBackend में इनकैप्सुलेट किया गया था जिसे ऐसे बैकएंड के लिए पुन: उपयोग किया जा सकता है।

@adamcik मेरा समाधान यह नहीं मानता कि सभी http धाराएँ लाइव हैं। मैं जांचता हूं कि लाइव और गैर-लाइव स्ट्रीम के बीच अंतर करने के लिए ट्रैक.लेंथ कोई नहीं है। track.length को mopidy.stream.actor में StreamLibraryProvider.lookup विधि द्वारा सेट किया गया है जो बदले में mopidy.audio.scan का उपयोग करता है। 'तलाश करने योग्य' विशेषता भी उपलब्ध है लेकिन इसे StreamLibraryProvider.lookup में फेंक दिया जाता है। मुझे लगता है कि वह ट्रैक जिसकी कोई लंबाई नहीं है और जिसे खोजा नहीं जा सकता है, उसे एक लाइव स्ट्रीम के रूप में माना जा सकता है।

जब मैं घर पहुंचूंगा तो @basisbit मैं पुल अनुरोध करूंगा।

@mczerski मेरे लिए सुबह-सुबह थोड़ा क्षमा करें, इसलिए थोड़ा उपवास करने के लिए स्किम्ड किया। मैं देख रहा हूं कि अब आपने set_uri को लाइव इन पास करने के लिए बदल दिया है। इसके लिए दो सुझाव:

1. शायद स्रोत प्रकार को हार्डकोड करने के बजाय मौजूदा is-live के लिए https://github.com/mopidy/mopidy/blob/develop/mopidy/audio/utils.py#L67 जैसे चेक का उपयोग करें?
2. इसे set_uri(uri, is_live=False) बनाना सुनिश्चित करें (या शायद live=False , लेकिन यह एक बाइकशेड से अधिक है)। हम set_uri के एपीआई को तोड़ना नहीं चाहते हैं। और अगर हमें इसे तोड़ने की जरूरत है तो हम केवल एक प्रमुख रिलीज में ही ऐसा कर सकते हैं, और बैकएंड का एक गुच्छा है जिसे अद्यतन करने की आवश्यकता होगी।

मैं set_uri में इसका समर्थन नहीं करने के लिए भी तैयार हूं, लेकिन एक अलग विधि है। हालांकि मैंने इस तरह के विकल्प के पेशेवरों/विपक्षों के बारे में नहीं सोचा है।

@adamcik सलाह के लिए धन्यवाद। मैं mopidy कोड से परिचित नहीं हूँ और मेरा फिक्स सिर्फ एक तेज़ बदसूरत फिक्स था :) यदि आप मेरे फिक्स के पीछे के विचार से सहमत हैं तो मैं एक उत्पादन समाधान लिखने का प्रयास कर सकता हूं यदि मुझे इसके लिए समय मिल जाए।

मैं सोच रहा हूं कि अन्य खिलाड़ी (जो, उपयोगकर्ता टिप्पणियों के मुताबिक स्पष्ट रूप से यह अधिकार प्राप्त करते हैं) इसे कैसे संभालते हैं। क्या वे सभी नेटवर्क स्रोतों को "लाइव" स्ट्रीम मानते हैं? या क्या इसमें कुछ जादू शामिल है, जिसे stream बैकएंड में ट्रांसप्लांट किया जा सकता है, जिससे एक्सटेंशन उस भेद से अनजान हो जाते हैं?

@tkem मैं रिदमबॉक्स में ऐसा कुछ भी खोजने में विफल रहा जो ऐसा करता है, लेकिन मैंने पाया: 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 की दो टिप्पणियों को ध्यान में रखते हुए, क्या आप एक PR @mczerski सबमिट करना चाहते हैं? असफल होने पर मैं करूंगा।

@kingosticks अगर आप ऐसा करते हैं तो मुझे कोई आपत्ति नहीं है। मेरे पास इसके लिए बस समय नहीं है।

दुर्भाग्य से मेरा समाधान पूरी तरह से अच्छा नहीं है ... समस्या backend.py (पंक्ति 251) में कोड की इस पंक्ति के साथ है:
self.audio.set_uri(uri, track.length is कोई नहीं).get()

कभी-कभी ट्रैक.लेंथ इस तथ्य के बावजूद कोई नहीं है कि ट्रैक एक लाइव स्ट्रीम नहीं है: / स्पॉटिफाई और यूट्यूब ट्रैक के साथ ऐसा हुआ। यह व्यवहार यादृच्छिक है, कभी-कभी ट्रैक। लंबाई कोई नहीं है और कभी-कभी यह कोई नहीं है। वेब गुई में ट्रैक की लंबाई हमेशा प्रदर्शित होती है।

उन गानों के लिए बदलाव का नकारात्मक पहलू क्या होगा जहां gstreamer या हमारा mopidy कोड सोचता है कि लंबाई 0 है? (एक को छोड़कर जो ट्रैक के भीतर कूदने में सक्षम नहीं है) कृपया कोई बस कुछ जादुई रूप से अच्छा समाधान करें ... XD

रोकें, रुकने के बजाय डेटा को समाप्त करता है। तो set_uri(uri, live=False) (या set_live(live) ) जैसा कुछ होना शायद अभी भी संभव है, आपको स्मार्ट होने के लिए बैकएंड की आवश्यकता है कि क्या वे इसे सत्य पर सेट करते हैं, या इसे ट्रैक की लंबाई पर आधारित करते हैं।

लंबाई के लिए कभी-कभी कोई नहीं होता है, यह डेटा दौड़ हो सकती है, लेकिन मुझे पूरा यकीन नहीं है।

@basisbit सबसे बड़ा नकारात्मक पहलू यह है कि is-live विशेषता के साथ ट्रैक सत्य पर सेट समाप्त नहीं होगा, इसलिए यदि आपके पास प्लेलिस्ट में अन्य ट्रैक हैं, तो वे तब तक नहीं खेले जाएंगे जब तक कि आप मैन्युअल रूप से वर्तमान में चलाए गए ट्रैक को मैन्युअल रूप से छोड़ नहीं देते। मेरा मानना ​​​​है कि सही समाधान कोड के अलग-अलग स्थान पर सेट करना होगा, जहां ट्रैक की लंबाई सही ढंग से सेट होने की गारंटी है, लेकिन मुझे mopidy कोड का बहुत कम ज्ञान है और वर्तमान में इसे सीखने का समय नहीं है इसलिए मैं कर सकता हूं सही समाधान नहीं मिला :(

नमस्ते,

मैं रेडियो वेब स्ट्रीम को पुन: प्रस्तुत करने के साथ एक ही समस्या का सामना कर रहा हूं। मैं सोच रहा था कि क्या यह अंततः नवीनतम मोपीडी रिलीज में तय हो गया है?

धन्यवाद

नमस्ते,

मुझे यह समस्या आ रही है और ऊपर बताए गए सुधार मेरे लिए काम नहीं कर रहे हैं।