טוב פתרתי את כל בעיות הBuffer אצלי :D

itzikg · שליחה #41 21/01/2015 18:03

moshebit
אני הוצאתי לך את זה מהקובץ advencedsettings.xml שנוצר מהסרטון.

tzahi · שליחה #42 21/01/2015 21:08

אני עם NUC2820 4GB RAM ו openELEC מותקן על DOK 16GB, האם זה יעבוד אצלי ?

maya1 · שליחה #43 22/01/2015 0:06

איציק - אל תתן המלצה גורפת לשים ערך/ערכים מסויימים לכל אחד - זה פשוט לא הדרך הנכונה במקרה הזה.

כדי לעשות טיפה סדר בבלאגן - צריך לשים לב לשני משתנים עקריים שיש אפשרות לשחק איתם בעניין הBUFFER :

הראשון זה הcachemembuffersize (גודל הCACHE) שאותו כמו שנאמר צריך לקבוע ללא יותר משליש מהזכרון הפנוי במערכת.
למשל NUC 4GB שעובד רק עם OPENELEC ומותק בו 4GB RAM אפשר להניח ש1GB ( שזה 1024*1024*1024= 1073741824) לא יהווה בעיה ולא יגרום לקריסה. במערכות עם WINDOWS הסיפור מעט שונה מכיוון שWIN7 ומעלה משתמש בזכרון כמשאב ולמעשה לא משאיר הרבה זכרון חופשי (מבחינתו זה בזבוז לא לנצל את הזכרון..) - אך זה לא אומר שהקצאת הזכרון הדינאמית שלו לא תוכל להתמודד עם CACHE גבוהה גם אם זה על חשבון דברים אחרים - עד גבול מסויים שם המערכת כבר לא גמישה כל כך... אין כאן מספר אחד נכון לכולם , זה תלוי בזכרון המותקן ובמה שעובד במחשב ומשתמש במשאבי RAM - צריך לנסות ולראות . אפשר לנחש שבמערכת ממוצעת שלא מריצה תוכנות כבדות נוספות במקביל עם WINDOWS 8 כדאי להשאיר מעל 1GB "חופשי" לפחות - ז.א שאם יש 4GB מותקן לא לשים יותר מ 1GB לCACHE (זה מוכפל ב3..) - אפילו מעט פחות מזה לדעתי.
בכל אופן לכל מי שחושב לשים 0 כאן - שיזכור שזה בעצם מסיט את הCACHE מהRAM ל HDD , עם כל מה שזה אומר... לכל מי שיש מספיק RAM במערכת עדיף שימנע מזה ! (לSSD ודומיו זה מקצר את החיים )

המשתנה השני שאפשר/רצוי לשנות זה הreadbufferfactor - זה למעשה המשתנה שמגביל את קצב המילוי של הCACHE (שכנראה נוצר כדי להקל על מכשירים חלשים יחסית כמו RPI למינהם וכן לא "להתחזר" על הרשת שלא לצורך) - הערך הוא כפולות של ברירת המחדדל 10 - אמור להיות פי 10 מהיר וכו' - כל עוד השרת / מקור ממנו "יונקים" מאפשר זאת ... ערך מקובל במכשירים סבירים ומעלה יהיה 10 או אפילו 20..
* את ה buffermode היתי משאיר בברירת המחדל שלו שהיא 0 (אין טעם לעשות CACHE גם לתוכן מקומי או להגביל )

דוגמא לXML עם ההגדרות האלה (שוב שכל אחד יעשה את החישובים למערכת שלו..)

advancedsettings.xml

advancedsettings>
network>
buffermode>0
cachemembuffersize>1073741824
readbufferfactor>20
/network>
/advancedsettings>
* החסרתי את ה< מתחילת השורה כדי שיוצג ולא "יעלם" כפי שקורה אם משאירים את הטקסט המלא .

אתם יכולים להוריד את זה כקובץ : כאן
*ורק בשמירה בשם תורידו את ה.TXT. ותשאירו את זה כXML - וכמובן לשמור את זה במקום הנכון (לפי המערכת שלכם) ולערוך את שני הנתונים בהתאם למה שנכון לכם.

Android>>> Android/data/org.xbmc.kodi/files/.kodi/userdata/
iOS>>>>> /private/var/mobile/Library/Preferences/kodi/userdata/
Linux >>>>~/.kodi/userdata/
Mac OS X >>>> /Users/<your_user_name>/Library/Application Support/kodi/userdata/
OpenELEC>>>> /storage/.kodi/userdata/
(Windows>>>> Start - type %APPDATA%\kodi\userdata -( press <Enter>
*בגרסאות לפני ה 14.0 זה יופיע ב XBMC במקום KODI..
בהצלחה !

tzahi · שליחה #44 22/01/2015 16:10

@maya1
·
יש לי 2 שאלות :
1. האם עניין ה buffer משפיע גם על הזרמה מקומית ברשת הבייתית ?
2. איך בודקים כמה RAM נשארים לי פנויים ב OPENELEC ?

maya1 · שליחה #45 22/01/2015 18:58

1 . כדי לקבל BUFFER גם לרשת מקומית תשנה ל1 במקום ה0 ב buffermode. אבל תראה אם יש בזה צורך בכלל ? (ברוב המקרים זה לא אמור לשנות מכיוון שהזרימה מספיק מהירה ולא היא זאת שגורמת לבעיות אם ישנם)
2. למערכת כזאת היתי מתחיל עם חצי גיגה (512*1024*1024=536870912) ובכל מקרה לא עובר את 1GB

itt8 · שליחה #46 22/01/2015 19:14

אני מתחיל לחשוב שה buffering אצלי בכלל לא קשור ל KODI אלא לתשתית המקרטעת של האינטרנט של הוט,
הנימוק: כל הזמן ניתוקים בתקשורת ב WAN , תקשורת לא יציבה, אני נאלץ לרסט את המודם לפחות פעמיים ביום , פניתי להוט החליפו לי מודם - לא נתן פתרון הניתוקים ממשיכים.
שוקל מעבר לתשתית בזק מחוסר ברירה

iChrist · שליחה #47 22/01/2015 22:32

itt8 כתב:אני מתחיל לחשוב שה buffering אצלי בכלל לא קשור ל KODI אלא לתשתית המקרטעת של האינטרנט של הוט,
הנימוק: כל הזמן ניתוקים בתקשורת ב WAN , תקשורת לא יציבה, אני נאלץ לרסט את המודם לפחות פעמיים ביום , פניתי להוט החליפו לי מודם - לא נתן פתרון הניתוקים ממשיכים.
שוקל מעבר לתשתית בזק מחוסר ברירה
...

צר לי לבשר לך אבל אני עשיתי את התהליך ההפוך (בזק>הוט) והמצב השתפר פלאות.
אצלי באזור התשתית של הוט מעולה וגם ב2 בלילה אפשר להנות מתוכן HD, מה שבבזק היה זוועה, קיבלתי 40 מגה בשיא והתוכן היה מקרטע ברוב שעות היום.
אבל זה אינדיבידואלי, יכול להיות שאצלך הכל ירוץ מעולה בבזק ובהוט לא.
בכל מקרה בהצלחה, מקווה שתסדר.
·

moshebit · שליחה #48 22/01/2015 23:36

אם יש לי CUBOXI2 ו I4 , איזה הגדרות צריך לכל אחד ? ואם אני משתמש בתוכנה שהבאת היא יוצרת אוטומטית בהתאם למערכת שהיא עליה ולמכשיר?

maya1 · שליחה #49 23/01/2015 7:12

שים לב למה שכתבתי בעמוד הקודם !
כמו שאני רואה (לא ניסיתי בעצמי ואני גםם לא מתכוון לנסות) ממה שאיציק העלה ה"תוכנה" העבירה את הCACHE מהזכרון לאחסון (הצבת 0 ב הcachemembuffersize) במקרה של HDD עמיד זה פחות נורא (אם כי מיותר כשיש מספיק RAM לביצוע ה CACHE), אבל במקרה של מערכת שיושבת על כרטיסי SD למינהם - זה אומר נזק וודאי !!!
אל תשתמשו בתוכנה כזאת בלי לדעת מה היא בדיוק עושה אצלכם במערכת ! תכוונו ידנית את הפרמטרים.

Idpo · שליחה #50 23/01/2015 9:34

maya1
בוא נרגע.
ל SSD יש המון מחזורי חיים. אני לדוגמה משתמש ב SSD כבר כמה שנים טובות. עושה BUFFER לסרטי HD מלאים לדיסק תמיד (מה שאגב, קורה בהרחבות טורנטים בכל מקרה). הדבר עדיף כמעט בכל המקרים על שימוש בזכרון, כי הזכרון (גם 16GB) לא יספיק לסרט FULLHD ששוקל מעל 6GB.
ה SSD שלי - שעובר התעללות יום יומית כבר 4 שנים - במצב מעולה. מצב "הבריאות" שלו הוא 80%.

בכרטיסי SD הבעיה קצת קשה יותר מאחר ויש להם פחות מחזורי חיים מ SSD, אבל עדיין. התוצאה המכשירים שמשתמשים בכונני SD בדרך כלל שווה את זה.

maya1 · שליחה #51 23/01/2015 11:02

כרטיס SD (ובכוונה לא רשמתי SSD !) לא ישרוד הרבה בעבודה שוטפת כBUFFER לוידאו. (הרבה זה עניין יחסי כמובן..)
שכל אחד יעשה את השיקולים שלו , רק כדאי להיות מודעים למה שעושים ולא לעשות בלי לדעת...

As I mentioned in the video in the first post caching to your storage device will cause lots of wear and tear, on a mechanical HDD I don't really see a massive problem - yes it will probably lessen the life expectancy by a few years but they are sturdy units so if it's a decent HDD it shouldn't be a problem. However caching to an SD card is not something I would suggest, a good quality class10 you can probably get away with it working for a while but I don't think it would take long for that card to become corrupt - once corrupt you've lost everything and the card has to be binned (I've corrupted plenty over the years with the r-pi!).
...

Note that using flash (or sdcard) as a video cache is more or less guaranteed to kill it rather fast.
AFAIK, a sector on those is only guaranteed for ~10000 writes before dying.
Furthermore, performances are poor, especially when writing, so I'm pretty sure it's not worth
...

אחד מהמפתחים של KODI בפורום KODI ^

אבל שוב אני לא אומר שזה פסול (בעיקר למכשירים נמוכי RAM שממ צריכים את זה..) - רק לדעת את המשמעות .

kalda01 · שליחה #52 23/01/2015 11:09

חברים, מהבדיקות שאני עשיתי עם באפרינג לסרטים וסדרות בHD, אז הגדלת הבאפר רק עוזרת אם יש
האטה רגעית במהירות ההורדה מהאינטרנט ואז יש מספיק תוכן בבאפר כדי שלא תהיה תקיעה
עד שהמהירות של ההורדה מתאוששת למצב נורמלי.

אף באפר בכל גודל שהוא לא יעזור אם מהירות ההורדה היא באופן קבוע יותר איטית מקצב צריכת הנתונים של הנגן.

הנה נתוני המהירות המינימלית הדרושה כדי שהנגן לא יקרטע ללא באפר בכלל:

Typical 480p/720p low-bitrate profile movie:

Length: 01:35:00 (5700sec)
Filesize: 700MB
Required bandwidth: 0.122MB/s / 126KB/s / 0.98Mbit/s

Typical 720p high-bitrate profile movie:

Length: 01:50:00 (6600sec)
Filesize: 4.36GB (4464MB)
Required bandwidth: 0.676MB/s / 700KB/s / 5.4Mbit/s

Typical 1080p movie:

Length: 01:59:37 (7177sec)
Filesize: 10.1GB (10342MB)
Required bandwidth: 1.44MB/s / 1475KB/s / 11.5Mbit/s

אם המקור או הספק או התשתית לא מסוגלים לתת את מהירות ההורדה הדרושה בממוצע לאורך נגינת הסרט
כמו למשל בשעות שיש עומס על שרת המקור אז גם הגדלת הבאפר לא תעזור.
הנגן תוך כמה שניות ירוקן את הבאפר ממה שנצבר בו, ואם לא ניתן במקביל למלא אותו חזרה באותו קצב
אז לאורך זמן הוא פשוט ישאר ריק.

itt8 · שליחה #53 23/01/2015 11:18

אתם נכנסים לסוגיות תוכנה שלא קשורות לבעיה, הצפיה ב kodi כמו צפיה ממקורות אחרים ברשת מבוסבת על פלטפורמת ה www ושם מה לעשות יש buffering מדי פעם לפעם בזמן צפייה ב סרטונים סלש צפיה ישירה

shimi810 · שליחה #54 23/01/2015 11:18

kalda01

נחתכה לך השורה האחרונה (Required bandwidth) ב־1080p.

kalda01 · שליחה #55 23/01/2015 11:20

תיקנתי....תודה...

maya1 · שליחה #56 23/01/2015 13:01

דני , ברור שאם מקבלים קצב נתונים שנמוך מהנדרש לצפיה רצופה אז יש עצירה לבאפר, הבאפר הגדול יותר יעזור במקרים שאין מהירות קבועה. ולפעמים קצב הנתונים מהרשת יהיה איטי מדי לזמן מסויים, אך אם באותו הזמן המאגר ימשיך לאגור ולמרות שהוא יקטן הוא עדיין יספיק לצפיה רצופה מבחינתנו זאת הצלחה מלאה....הצלחה חלקית תחשב שרק הצלחנו להוריד את מספר העצירות פר סרט...

Idpo · שליחה #57 23/01/2015 13:11

מנסיוני,
ה BUFFER משפיע ב 2 דרכים.
הראשונה, הוא כשהבאפר קטן יותר מגדול התוכן. יווצר מצב בו החיבור לשרת מופסק בכל פעם שהבאפר מתמלא.
מסיבה שלא ברורה לי, יש הרבה שרתים שלא אוהבים את הענין הזה ובשלב מסויים החיבור יואט מאוד או יפסק באופן כללי (ב HIVE לדוגמה, הוא מפסיק).

השניה היא בעצם תלויית תשתית ועומס.
נניח ואתה מסוגל לקבל מהירות מהשרת של 20MBit/s.
התוכן צריך 10MBit/s.
כלומר, ניתן להוריד את כל התוכן למחשב באופן מקומי בחצי ממשך התוכן.
סביר להניח שהחיבור לא יהיה יציב על 20MBIT בכל הזמן. הוא ינוד. מספיק שבחלק מסויים מהזמן הוא "יתקע" על 5MBIT יתקבל מצב בו צריך לחכות לבאפר (מאחר והוא לא היה מספיק גדול בשביל שיהיה "ספייר" מספיק).
לכן, אני טוען שהבאפר הכי טוב - הוא מקבל להורדת התוכן המלא בכל פעם לדיסק. בצורה הזו אפשר להקטין למינימום את התלות בחיבור לא יציב מכל סיבה שהיא.

maya1
לגבי ה SD.
מסכים עם כל מילה, אבל דווקא במכשירים כמו RPI שמוגבלים מאוד בזכרון - זה שווה את הנזק.
אם נקח את המספר הנתון של 10000 מחזורי כתיבה (אני חושב שהוא נדיב מידי, אבל שיהיה) זה אומר שאחד כזה של 16GB ניתן לצפות בקירוב ב 160,000 פרקים (בקירוב של 1GB לפרק).
אם נסתכל על תוכן ששוקל 10GB - עדיין מקבלים 16,000 צפיות אפשריות.
כמובן שמדובר על כתיבה זה לא כזה חישוב פשוט אבל עדיין,
אם נסתכל על הדברים בפרופורציה - הדבר אומר שאפשר "לטחון" כרטיס SD כזה בלי יותר מידי דאגות.

moshebit · שליחה #58 23/01/2015 13:12

kalda01 כתב:חברים, מהבדיקות שאני עשיתי עם באפרינג לסרטים וסדרות בHD, אז הגדלת הבאפר רק עוזרת אם יש
האטה רגעית במהירות ההורדה מהאינטרנט ואז יש מספיק תוכן בבאפר כדי שלא תהיה תקיעה
עד שהמהירות של ההורדה מתאוששת למצב נורמלי.

אף באפר בכל גודל שהוא לא יעזור אם מהירות ההורדה היא באופן קבוע יותר איטית מקצב צריכת הנתונים של הנגן.

הנה נתוני המהירות המינימלית הדרושה כדי שהנגן לא יקרטע ללא באפר בכלל:

Typical 480p/720p low-bitrate profile movie:

Length: 01:35:00 (5700sec)
Filesize: 700MB
Required bandwidth: 0.122MB/s / 126KB/s / 0.98Mbit/s

Typical 720p high-bitrate profile movie:

Length: 01:50:00 (6600sec)
Filesize: 4.36GB (4464MB)
Required bandwidth: 0.676MB/s / 700KB/s / 5.4Mbit/s

Typical 1080p movie:

Length: 01:59:37 (7177sec)
Filesize: 10.1GB (10342MB)
Required bandwidth: 1.44MB/s / 1475KB/s / 11.5Mbit/s

אם המקור או הספק או התשתית לא מסוגלים לתת את מהירות ההורדה הדרושה בממוצע לאורך נגינת הסרט
כמו למשל בשעות שיש עומס על שרת המקור אז גם הגדלת הבאפר לא תעזור.
הנגן תוך כמה שניות ירוקן את הבאפר ממה שנצבר בו, ואם לא ניתן במקביל למלא אותו חזרה באותו קצב
אז לאורך זמן הוא פשוט ישאר ריק.
...

אשמח להסבר על מה אומר כל אחד לפני הסלאש :
Required bandwidth: 0.676MB/s / 700KB/s / 5.4Mbit/s

תודה רבה.

·

Idpo · שליחה #59 23/01/2015 14:37

MegaByte/sec / KiloByte/sec / MegaBits/sec
פשוט יחידות שונות שאומרות את אותו הדבר.
BIT זה מה שמוכרים לך שאתה מתחבר.
BYTE זה מה שאתה רואה כשאתה מוריד משהו ברשת.

danielby · שליחה #60 25/01/2015 23:35

הכנסתי את ההגדרות ל cache כפי שמצויין כאן לתוך ה advancesettings.xml.
ואז נוצרו לי בעיות בהזרמת מוזיקה מתוך תוספי המוזיקה כגון SoundCloud ו Youtube Music.
מישהו עוד שם לב לזה?