אני מתחיל לחשוב שה buffering אצלי בכלל לא קשור ל KODI אלא לתשתית המקרטעת של האינטרנט של הוט,
הנימוק: כל הזמן ניתוקים בתקשורת ב WAN , תקשורת לא יציבה, אני נאלץ לרסט את המודם לפחות פעמיים ביום , פניתי להוט החליפו לי מודם - לא נתן פתרון הניתוקים ממשיכים.
שוקל מעבר לתשתית בזק מחוסר ברירה
טוב פתרתי את כל בעיות הBuffer אצלי :D
- iChrist (פותח השרשור)
- חבר פעיל במיוחד
- הודעות: 507
- הצטרף: ספטמבר 2013
- נתן תודות: 13 פעמים
- קיבל תודות: 32 פעמים
צר לי לבשר לך אבל אני עשיתי את התהליך ההפוך (בזק>הוט) והמצב השתפר פלאות.itt8 כתב:אני מתחיל לחשוב שה buffering אצלי בכלל לא קשור ל KODI אלא לתשתית המקרטעת של האינטרנט של הוט,
הנימוק: כל הזמן ניתוקים בתקשורת ב WAN , תקשורת לא יציבה, אני נאלץ לרסט את המודם לפחות פעמיים ביום , פניתי להוט החליפו לי מודם - לא נתן פתרון הניתוקים ממשיכים.
שוקל מעבר לתשתית בזק מחוסר ברירה...
אצלי באזור התשתית של הוט מעולה וגם ב2 בלילה אפשר להנות מתוכן HD, מה שבבזק היה זוועה, קיבלתי 40 מגה בשיא והתוכן היה מקרטע ברוב שעות היום.
אבל זה אינדיבידואלי, יכול להיות שאצלך הכל ירוץ מעולה בבזק ובהוט לא.
בכל מקרה בהצלחה, מקווה שתסדר.
·
שים לב למה שכתבתי בעמוד הקודם !
כמו שאני רואה (לא ניסיתי בעצמי ואני גםם לא מתכוון לנסות) ממה שאיציק העלה ה"תוכנה" העבירה את הCACHE מהזכרון לאחסון (הצבת 0 ב הcachemembuffersize) במקרה של HDD עמיד זה פחות נורא (אם כי מיותר כשיש מספיק RAM לביצוע ה CACHE), אבל במקרה של מערכת שיושבת על כרטיסי SD למינהם - זה אומר נזק וודאי !!!
אל תשתמשו בתוכנה כזאת בלי לדעת מה היא בדיוק עושה אצלכם במערכת ! תכוונו ידנית את הפרמטרים.
כמו שאני רואה (לא ניסיתי בעצמי ואני גםם לא מתכוון לנסות) ממה שאיציק העלה ה"תוכנה" העבירה את הCACHE מהזכרון לאחסון (הצבת 0 ב הcachemembuffersize) במקרה של HDD עמיד זה פחות נורא (אם כי מיותר כשיש מספיק RAM לביצוע ה CACHE), אבל במקרה של מערכת שיושבת על כרטיסי SD למינהם - זה אומר נזק וודאי !!!
אל תשתמשו בתוכנה כזאת בלי לדעת מה היא בדיוק עושה אצלכם במערכת ! תכוונו ידנית את הפרמטרים.
נערך לאחרונה על ידי maya1 ב 31/01/2015 16:50, נערך פעם 1 בסך הכל.
maya1
בוא נרגע.
ל SSD יש המון מחזורי חיים. אני לדוגמה משתמש ב SSD כבר כמה שנים טובות. עושה BUFFER לסרטי HD מלאים לדיסק תמיד (מה שאגב, קורה בהרחבות טורנטים בכל מקרה). הדבר עדיף כמעט בכל המקרים על שימוש בזכרון, כי הזכרון (גם 16GB) לא יספיק לסרט FULLHD ששוקל מעל 6GB.
ה SSD שלי - שעובר התעללות יום יומית כבר 4 שנים - במצב מעולה. מצב "הבריאות" שלו הוא 80%.
בכרטיסי SD הבעיה קצת קשה יותר מאחר ויש להם פחות מחזורי חיים מ SSD, אבל עדיין. התוצאה המכשירים שמשתמשים בכונני SD בדרך כלל שווה את זה.
בוא נרגע.
ל SSD יש המון מחזורי חיים. אני לדוגמה משתמש ב SSD כבר כמה שנים טובות. עושה BUFFER לסרטי HD מלאים לדיסק תמיד (מה שאגב, קורה בהרחבות טורנטים בכל מקרה). הדבר עדיף כמעט בכל המקרים על שימוש בזכרון, כי הזכרון (גם 16GB) לא יספיק לסרט FULLHD ששוקל מעל 6GB.
ה SSD שלי - שעובר התעללות יום יומית כבר 4 שנים - במצב מעולה. מצב "הבריאות" שלו הוא 80%.
בכרטיסי SD הבעיה קצת קשה יותר מאחר ויש להם פחות מחזורי חיים מ SSD, אבל עדיין. התוצאה המכשירים שמשתמשים בכונני SD בדרך כלל שווה את זה.
כרטיס SD (ובכוונה לא רשמתי SSD !) לא ישרוד הרבה בעבודה שוטפת כBUFFER לוידאו. (הרבה זה עניין יחסי כמובן..)
שכל אחד יעשה את השיקולים שלו , רק כדאי להיות מודעים למה שעושים ולא לעשות בלי לדעת...
אבל שוב אני לא אומר שזה פסול (בעיקר למכשירים נמוכי RAM שממ צריכים את זה..) - רק לדעת את המשמעות .
שכל אחד יעשה את השיקולים שלו , רק כדאי להיות מודעים למה שעושים ולא לעשות בלי לדעת...
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!)....
אחד מהמפתחים של KODI בפורום KODI ^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...
אבל שוב אני לא אומר שזה פסול (בעיקר למכשירים נמוכי RAM שממ צריכים את זה..) - רק לדעת את המשמעות .
- kalda01
-
- חבר מביא חבר
- הודעות: 3099
- הצטרף: אוגוסט 2007
- שם מלא: דני קלמר
- מיקום: יבנה - נהריה
- נתן תודות: 48 פעמים
- קיבל תודות: 41 פעמים
חברים, מהבדיקות שאני עשיתי עם באפרינג לסרטים וסדרות ב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
אם המקור או הספק או התשתית לא מסוגלים לתת את מהירות ההורדה הדרושה בממוצע לאורך נגינת הסרט
כמו למשל בשעות שיש עומס על שרת המקור אז גם הגדלת הבאפר לא תעזור.
הנגן תוך כמה שניות ירוקן את הבאפר ממה שנצבר בו, ואם לא ניתן במקביל למלא אותו חזרה באותו קצב
אז לאורך זמן הוא פשוט ישאר ריק.
האטה רגעית במהירות ההורדה מהאינטרנט ואז יש מספיק תוכן בבאפר כדי שלא תהיה תקיעה
עד שהמהירות של ההורדה מתאוששת למצב נורמלי.
אף באפר בכל גודל שהוא לא יעזור אם מהירות ההורדה היא באופן קבוע יותר איטית מקצב צריכת הנתונים של הנגן.
הנה נתוני המהירות המינימלית הדרושה כדי שהנגן לא יקרטע ללא באפר בכלל:
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
אם המקור או הספק או התשתית לא מסוגלים לתת את מהירות ההורדה הדרושה בממוצע לאורך נגינת הסרט
כמו למשל בשעות שיש עומס על שרת המקור אז גם הגדלת הבאפר לא תעזור.
הנגן תוך כמה שניות ירוקן את הבאפר ממה שנצבר בו, ואם לא ניתן במקביל למלא אותו חזרה באותו קצב
אז לאורך זמן הוא פשוט ישאר ריק.
נערך לאחרונה על ידי kalda01 ב 23/01/2015 11:19, נערך פעם 1 בסך הכל.
דני , ברור שאם מקבלים קצב נתונים שנמוך מהנדרש לצפיה רצופה אז יש עצירה לבאפר, הבאפר הגדול יותר יעזור במקרים שאין מהירות קבועה. ולפעמים קצב הנתונים מהרשת יהיה איטי מדי לזמן מסויים, אך אם באותו הזמן המאגר ימשיך לאגור ולמרות שהוא יקטן הוא עדיין יספיק לצפיה רצופה מבחינתנו זאת הצלחה מלאה....הצלחה חלקית תחשב שרק הצלחנו להוריד את מספר העצירות פר סרט...
מנסיוני,
ה BUFFER משפיע ב 2 דרכים.
הראשונה, הוא כשהבאפר קטן יותר מגדול התוכן. יווצר מצב בו החיבור לשרת מופסק בכל פעם שהבאפר מתמלא.
מסיבה שלא ברורה לי, יש הרבה שרתים שלא אוהבים את הענין הזה ובשלב מסויים החיבור יואט מאוד או יפסק באופן כללי (ב HIVE לדוגמה, הוא מפסיק).
השניה היא בעצם תלויית תשתית ועומס.
נניח ואתה מסוגל לקבל מהירות מהשרת של 20MBit/s.
התוכן צריך 10MBit/s.
כלומר, ניתן להוריד את כל התוכן למחשב באופן מקומי בחצי ממשך התוכן.
סביר להניח שהחיבור לא יהיה יציב על 20MBIT בכל הזמן. הוא ינוד. מספיק שבחלק מסויים מהזמן הוא "יתקע" על 5MBIT יתקבל מצב בו צריך לחכות לבאפר (מאחר והוא לא היה מספיק גדול בשביל שיהיה "ספייר" מספיק).
לכן, אני טוען שהבאפר הכי טוב - הוא מקבל להורדת התוכן המלא בכל פעם לדיסק. בצורה הזו אפשר להקטין למינימום את התלות בחיבור לא יציב מכל סיבה שהיא.
maya1
לגבי ה SD.
מסכים עם כל מילה, אבל דווקא במכשירים כמו RPI שמוגבלים מאוד בזכרון - זה שווה את הנזק.
אם נקח את המספר הנתון של 10000 מחזורי כתיבה (אני חושב שהוא נדיב מידי, אבל שיהיה) זה אומר שאחד כזה של 16GB ניתן לצפות בקירוב ב 160,000 פרקים (בקירוב של 1GB לפרק).
אם נסתכל על תוכן ששוקל 10GB - עדיין מקבלים 16,000 צפיות אפשריות.
כמובן שמדובר על כתיבה זה לא כזה חישוב פשוט אבל עדיין,
אם נסתכל על הדברים בפרופורציה - הדבר אומר שאפשר "לטחון" כרטיס SD כזה בלי יותר מידי דאגות.
ה BUFFER משפיע ב 2 דרכים.
הראשונה, הוא כשהבאפר קטן יותר מגדול התוכן. יווצר מצב בו החיבור לשרת מופסק בכל פעם שהבאפר מתמלא.
מסיבה שלא ברורה לי, יש הרבה שרתים שלא אוהבים את הענין הזה ובשלב מסויים החיבור יואט מאוד או יפסק באופן כללי (ב HIVE לדוגמה, הוא מפסיק).
השניה היא בעצם תלויית תשתית ועומס.
נניח ואתה מסוגל לקבל מהירות מהשרת של 20MBit/s.
התוכן צריך 10MBit/s.
כלומר, ניתן להוריד את כל התוכן למחשב באופן מקומי בחצי ממשך התוכן.
סביר להניח שהחיבור לא יהיה יציב על 20MBIT בכל הזמן. הוא ינוד. מספיק שבחלק מסויים מהזמן הוא "יתקע" על 5MBIT יתקבל מצב בו צריך לחכות לבאפר (מאחר והוא לא היה מספיק גדול בשביל שיהיה "ספייר" מספיק).
לכן, אני טוען שהבאפר הכי טוב - הוא מקבל להורדת התוכן המלא בכל פעם לדיסק. בצורה הזו אפשר להקטין למינימום את התלות בחיבור לא יציב מכל סיבה שהיא.
maya1
לגבי ה SD.
מסכים עם כל מילה, אבל דווקא במכשירים כמו RPI שמוגבלים מאוד בזכרון - זה שווה את הנזק.
אם נקח את המספר הנתון של 10000 מחזורי כתיבה (אני חושב שהוא נדיב מידי, אבל שיהיה) זה אומר שאחד כזה של 16GB ניתן לצפות בקירוב ב 160,000 פרקים (בקירוב של 1GB לפרק).
אם נסתכל על תוכן ששוקל 10GB - עדיין מקבלים 16,000 צפיות אפשריות.
כמובן שמדובר על כתיבה זה לא כזה חישוב פשוט אבל עדיין,
אם נסתכל על הדברים בפרופורציה - הדבר אומר שאפשר "לטחון" כרטיס SD כזה בלי יותר מידי דאגות.
אשמח להסבר על מה אומר כל אחד לפני הסלאש :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
תודה רבה.
·