कोडी के साथ बफरिंग के मुद्दे (ओपनीलेक पर)

Question

हर बार जब मैं भारी (अधिकतर 1080p) वीडियो नेटवर्क (वेबडाव, sftp ...) को स्ट्रीम करने की कोशिश करता हूं, तो यह या तो विफल हो जाता है या मुझे संदेश "कैश भरा हुआ है" आदि मिलते हैं। वीडियो खेलना शुरू हो जाता है, लेकिन बेतरतीब ढंग से बंद (फिर से बफर करने के लिए) , मेरा अनुमान)।

मुझे पता है कि यह एक सामान्य मुद्दा है और मुझे पता है कि मैं जो ट्विक्स कर सकता हूं ( कर्ल भी कर सकता हूं )।

पर्यावरण:

मैं एक आरपीआई मॉडल बी का उपयोग करता हूं और मेरे पास 100 एम / बी इंटरनेट कनेक्शन है। मैं कोडी 14.2 और कोडी 15 (openelec 5.0.7, openelec 5.95.2) के साथ परीक्षण कर रहा हूं।

जाँच:

अब तक, कई अतिरिक्त विकल्पों में से, यही मैंने कोशिश की है:

Cache\Protocol | Webdav      | SFTP (local and internet)
--------------------------------------------------------------------------
No cache       | not loading | loads quickly, no error, stops frequently
--------------------------------------------------------------------------
(5mb cache)    | not loading | slow to load, cache error, stops randomly
--------------------------------------------------------------------------
(25mb cache)   | not loading | very slow to load, cache error, stops randomly
--------------------------------------------------------------------------
sdcard cache   | not loading | incredibly slow to load, no error, fine
--------------------------------------------------------------------------

वीडियो की समस्या?

नहीं। अगर एसडी कार्ड पर कॉपी किया जाता है, तो यह आसानी से चलता है।

रैम की समस्या?

मैं हार्डवेयर सीमा को समझ सकता हूं यदि रैम भरा हुआ था, लेकिन, वीडियो देखते समय, free -mमुझे यह देता है:

             total         used         free       shared      buffers
Mem:           373          236          137            4           34
-/+ buffers:                202          171
Swap:            0            0            0

ऐसा लगता है कि बहुत सारे उपलब्ध हैं ...

दिलचस्प तथ्य, जैसा कि @goldilocks ने देखा, बफ़र्स असामान्य रूप से कम हैं।

नेटवर्क की समस्या?

अगर मैं SFTP के साथ मैन्युअल रूप से एक वीडियो फ़ाइल डाउनलोड कर रहा हूं , जबकि एक ही समय में एक ही फ़ाइल खेल रहा है, तो यह काम करता है। डाउनलोड गति: ~ 1.5MB / s। इसलिए, न तो नेटवर्क, न ही डिक्रिप्शन एक अड़चन है।

अन्य समस्या?

लॉगगाइल में त्रुटियां (वीडियो डिबग, ffmpeg डिबग के साथ), डिबग और नोटिस को छोड़कर:

ERROR: CCurlFile::FillBuffer - Failed: Timeout was reached
ERROR: OMXPlayerVideo: Got MSGQ_IS_ERROR(-1) Aborting

ठीक है, इसलिए कर्ल वीडियो स्ट्रीमिंग के लिए अनुकूलित नहीं है। लेकिन SFTP का क्या? यह केक का एक टुकड़ा होना चाहिए।

कॉन्फ़िगरेशन समस्या?

ऊपर अंतिम परीक्षण (sdcard कैश) दिलचस्प है। यह sdcard ( .kodi/temp/filecache000.cache) पर लगभग 150M (!) को लोड करने के बाद, वीडियो खेलना शुरू करता है । हालांकि यह अच्छी तरह से चलता है, यह एक व्यवहार्य समाधान नहीं है क्योंकि यह शुरू करने के लिए बहुत धीमा है।

ऐसा लगता है कि रैम की एक ही राशि को डाउनलोड करने की कोशिश की जा रही है, जिसमें कॉन्फ़िगरेशन को अनदेखा किया गया है advancedsettings.xml। मैंने जाँच की, फ़ाइल बिना किसी समस्या के भरी हुई है। यह मेरे द्वारा परीक्षण की गई कुछ चीज़ों का एक उदाहरण है ( .kodi/userdata/advancedsettings.xml):

<advancedsettings>
    <network>
        <buffermode>1</buffermode>
        <cachemembuffersize>5242880</cachemembuffersize>
        <readbufferfactor>4.0</readbufferfactor>
        <curlclienttimeout>60</curlclienttimeout>
        <curllowspeedtime>20</curllowspeedtime>
    </network>
</advancedsettings>

नोट: इन विकल्पों में से कुछ अब कोडी 17 में सही नहीं हैं, अपडेट के लिए @ZacWolf जवाब देखें

तो, किसी को कोई विचार है? यहां क्या गलत हो सकता है? जो भी समाधान है, मैं यह भी जानना चाहता हूं कि इस मामले में सामान्य उपयोग (रैम बफर) विफल क्यों है।

EDIT: आर्कलिनक्स पर टेस्ट

मैंने यह निर्धारित करने के लिए कि यह एक कोड़ी या ओपेनलेक मुद्दा है, मैंने आर्कलिनक्स पर कोड़ी स्थापित की। यह वही है: HD वीडियो तड़का हुआ है, इसलिए यह कोड़ी में एक बग लगता है। यह एक प्रोटोकॉल समस्या (SFTP और WebDAV: http) की तरह अधिक है क्योंकि SSHFS के साथ मेरा परीक्षण बहुत अच्छा काम करता है। दुर्भाग्य से, यह openelec पर SSHFS स्थापित करने के लिए तुच्छ नहीं है।

संपादित 2: एक वैकल्पिक हल

मैं इसे यहाँ लिखता हूँ, क्योंकि यह सीधे बफ़रिंग समस्या को संबोधित नहीं करता है, लेकिन मैंने अब एक साल से अधिक समय तक आर्कलिनक्स पर कोड़ी स्थापित की है, और यह पूरी तरह से अच्छी तरह से काम करती है। यह openelec की तुलना में कम noob-friendly है, लेकिन उन लोगों के लिए जो रुचि रखते हैं:

• ARM के लिए Archlinux स्थापित करें (बहुत आसान है, बस गाइड का पालन करें - यह rpi1 के लिए है, हाल ही में एक के लिए, बस प्लेटफ़ॉर्म को बदल दें);
• कोडी स्थापित करें ( आर्कलिनक्स विकी गाइड का पालन करें - मूल रूप से, kodi-rbpपैकेज स्थापित करें );
• कोड़ी सेवा को स्वतः स्टार्टअप पर चलाने के लिए सक्षम करें # systemctl enable kodi.service:;
• SSHFS स्थापित करें pacman -Suy sshfs:;
• बहुत उपयोगी प्रयोग करें automounting sshfs साथ /etc/fstabअपने दूर के शेयर माउंट करने के लिए।

किया हुआ। उन्मादी तरीके से अपडेट करना न भूलें ( pacman -Suy)।

Comments

150 एमबी उच्च पक्ष पर हो सकता है, लेकिन 5 एमबी शायद ~ 1 एमबी / एस बिटरेट सामग्री के लिए बहुत कम है, अगर आप अतिसुरक्षा से बचना चाहते हैं। मैं एसडी कार्ड के बारे में व्यामोह को खोदूंगा। आपने इसे सही उपयोग करने के लिए खरीदा है? यदि नहीं, तो यह एक शांत, शुष्क अलमारी में कहीं सुरक्षित होगा।

— गोल्डीलॉक्स

आपकी चिंता के लिए धन्यवाद। लेकिन, ध्यान रहे मेरा सवाल अकेले sdcard बफर के बारे में नहीं है। दूसरा, 150M, ~ 1MB / s पर ... हां, 150s। यह आईएस बेतुका है। क्या एसडीकार्ड का उपयोग करते समय बफर के आकार को बदलने का विकल्प है? यह एक समाधान हो सकता है। फिर, जो भी कैश का आकार है, वह एसडीकार्ड पर पूरे वीडियो (कभी-कभी कई जीबी) को लोड करेगा, न कि केवल बफर। मुझे पता है, एसडीकार्ड सस्ते हैं। यह एक बड़ा सौदा नहीं है। मुझे पता है। लेकिन मुझे sdcard के बारे में परेशान क्यों होना चाहिए जबकि RAM को काम करना चाहिए?

— गुई-डॉन

क्षमा करें - मैं उस पर वापस glancing के बाद थोड़ा नीचे toned। मैंने कोडी का उपयोग नहीं किया है इसलिए मैं यहाँ बहुत मदद नहीं कर सकता, यह सिर्फ एक सामान्य अवलोकन था। IMO, डिस्क से बफरिंग रैम की बफ़रिंग से बेहतर रणनीति है क्योंकि यदि आप RAM को 100% भरते हैं, तो सिस्टम में कोई डिस्क कैश नहीं बचता है जो ऑपरेशन के सभी पहलुओं पर ध्यान देगा । हालाँकि, यदि आप RAM नहीं भरते हैं और कुछ नहीं करता है, तो आप जो भी लिख रहे हैं (और साथ ही साथ पढ़ रहे हैं) डिस्क निश्चित रूप से डिस्क कैश में डाल दी जाएगी - यानी, RAM, लेकिन कर्नेल द्वारा गतिशील रूप से प्रबंधित, जो है क्या यह एक बेहतर रणनीति बनाता है।

— गोल्डीलॉक्स

यदि यह स्पष्ट नहीं है तो: ओएस कैशिंग के लिए जितना संभव हो उतने रैम का उपयोग करता है (मैंने इसे ऊपर "डिस्क कैश" के रूप में संदर्भित किया है, जो कि एक मामूली मिथ्या नाम है, लेकिन इस तथ्य पर जोर दिया गया है कि आमतौर पर यह ज्यादातर डिस्क से पढ़ा जाने वाला सामान है। )। पीआई पर यह असामान्य नहीं होगा कि सभी रैम रहित हों, यह "बफ़र्स" का आंकड़ा है free- इसलिए आपके पोस्ट में कुछ रोचक तथ्य यह है कि यह संख्या अपेक्षाकृत कम है। यदि आप कोडी के डिस्क कैश को बढ़ाते हैं, तो उस संख्या को मैच के दौरान कार्रवाई के दौरान बढ़ा सकता है / चाहिए।

— गोल्डीलॉक्स

मैंने देखा;) ठीक है, मैं समझता हूं कि डिस्क का उपयोग रैम भरने से बेहतर है। यह काम करने के लिए एक अच्छा समाधान है, अगर मैं वीडियो को चलाने के लिए आवश्यक बफर आकार को कम कर सकता हूं। BTW, यह एक पूर्ण राशि के बजाय एक प्रतिशत लगता है। फिर भी, मैं उत्सुक हूं कि यहां क्या होता है। यह अजीब है कि मैं इतना RAM अप्रयुक्त हो गया, भले ही वीडियो बफरिंग कर रहा हो।

— गुइ-डॉन

Answer 1

EDIT (12/2017)

कोडी v17 का नाम बदला गया और उन्नतसेटिंग में टैग हटाए गए। xml

<cachemembuffersize> का नाम बदलकर <memorysize> करें

<readbufferfactor> का नाम बदलकर <readfactor> कर दिया गया

और उन्हें <network> से हटा दिया गया है और <cache> में जोड़ दिया गया है

मेरे advancesettings.xml अब जैसा दिखता है:

<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <cache>
                <memorysize>524288000</memorysize>
                <buffermode>1</buffermode>
                <readfactor>6</readfactor>
        </cache>
</advancedsettings>

Comments

यह विशेष रूप से एक वेरो 4 के डिवाइस के लिए है, जिसमें अधिक मेमोरी है जो एक पाई है, इसलिए आपको इन सेटिंग्स को अपनी उपलब्ध मेमोरी के लिए विशिष्ट रूप से ट्विक करने की आवश्यकता होगी।

— ZacWolf

Answer 2

मैं इस पर OpenElec के साथ Pi 3 चला रहा हूं और मैं बहुत सारे बफ़रिंग मुद्दों पर भी भाग गया।

मैं इसे वाई-फाई पर देख रहा था क्योंकि मुझे लगा कि यह राउटर के ठीक बगल में है और इसमें कोई समस्या नहीं होनी चाहिए। अच्छी तरह से ईथरनेट के माध्यम से प्लग करने के बाद मुझे बफ़रिंग समस्याओं को रोकने के साथ-साथ उन्नत xml फ़ाइल को एक साथ निकालने के लिए मिला।

मेरा लैपटॉप और फोन दोनों वाई-फाई के माध्यम से बिना बफ़र किए ठीक से चलते हैं, इसलिए पीआई 3 के ओपन-एलेक पर निर्मित वाई-फाई के साथ कुछ समस्या पैदा कर रहा है।

Comments

मुझे खुशी है कि आपने अपना मुद्दा ठीक कर लिया है और मुझे यकीन है कि यह बहुत सारे लोगों की मदद करेगा जो इस समस्या में भाग गए। मेरे मामले में मैंने शुरुआत से ही ईथरनेट का इस्तेमाल किया। Rpi1 के लिए मुझे नहीं लगता कि यह समाधान है। कहा जा रहा है, यह अजीब है कि आपको rpi3 पर एक समान समस्या थी, क्योंकि इसमें rpi1 की तुलना में दोगुना RAM है ... मैं गलत हो सकता हूं, लेकिन ऐसा लगता है कि कोडी पर कैश हैंडलिंग केवल भद्दा है।

— गुई-डॉन

Answer 3

मुझे भी यही समस्या थी और मैंने इस 'हैक' का इस्तेमाल किया , चीजें अब आसानी से चलती हैं।

--- संपादित करें --- @Simulant सुझाव का पालन करें:

• Xunity रखरखाव उपकरण स्थापित करें।
• कार्यक्रम में गया (सेटिंग्स नहीं), xunity - tweaks।
• 'Add 0 Cache Advanced XML' चुनें

Comments

कृपया अपने लिंक किए गए स्रोत से मुख्य फ़ैक को लाइन करें। अन्यथा यदि लिंक किया हुआ स्रोत ऑफ़लाइन हो जाएगा तो आपकी पोस्ट बेकार हो जाएगी।

— सिमुलंत

क्या Xunity उस उद्देश्य के लिए सिर्फ GUI नहीं है? मेरा मतलब है, यह कैसे उन्नत से खुद को अलग करना है। Xml फ़ाइल खुद? वास्तव में, मैंने नो कैश सेटिंग की, यह SFTP या वेबडाव वीडियो के लिए लोड करने के लिए धीमा है।

— गुई-डॉन

यह एक गुई है। लेकिन मेरे अनुभव से सीधा संपादन मुश्किल (अनुमति आदि के कारण) हो सकता है। एडऑन अच्छी तरह से काम करता है, मैंने इसका इस्तेमाल किया :-)

— मीर