Поток тупит...

22.11.2011

Сменил версию сэма - проблема осталась :( T_T.. Курпатов, скинь плз конфиг свой icecast, вдруг поможет?

22.11.2011

Айс тут не причем, ну если тебе станет легче, на

1. <icecast>
2. <limits>
3. <clients>1000</clients>
4. <sources>4</sources>
5. </limits>
6. <authentication>
7. <source-password>*******</source-password>
8. <admin-user>*******</admin-user>
9. <admin-password>*******</admin-password>
10. </authentication>
12. <directory>
13. <yp-url-timeout>15</yp-url-timeout>
14. <yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
15. </directory>
17. <hostname>*******</hostname>
18. <listen-socket>
19. <port>*****</port>
20. </listen-socket>
22. <fileserve>1</fileserve>
23. <paths>
24. <logdir>./logs</logdir>
25. <webroot>./web</webroot>
26. <adminroot>./admin</adminroot>
27. <alias source="/" dest="/index.html"/>
28. </paths>
29. <logging>
30. <accesslog>access.log</accesslog>
31. <errorlog>error.log</errorlog>
32. <loglevel>2</loglevel> <!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
33. <logsize>200000</logsize> <!-- Max size of a logfile -->
34. <logarchive>1</logarchive>
35. </logging>
36. </icecast>

23.11.2011

А если не причем, то в чем же проблема? Будь добр напиши в icq 760006, так явно проще провести диагностику и решить проблему, если ты конечно не занят и не против.

23.11.2011

Я тебе писал выше про проверку пинга во время затыка, ты вообще смотрел?
Я ответа так и не увидел.

23.11.2011

С компа делать пинг к серверу? 1) Не принимает, у меня все порты закрыты кроме icecast 2) Лагает не в раз у тех кто слушает а в разное время и в разных местах трека...

23.11.2011

КЭП
1) причем тут порты?
2) это как раз подтверждает что надо проверить пинг )

23.11.2011

окей
делаем пинг когда нету лагов...

C:\Users\Артём>ping 46.1*.4*.2* -t
Обмен пакетами с 46.1*.4*.2* по с 32 байтами данных:


Дубль два лагов до сих пор нет


Спустя 5 минут начались лаги... делаем пинг... Все по-прежнему

Добавлено спустя 5 минут 15 секунд:
P.S Не знаю совпадение или нет, но последил за нагрузкой ЦП, когда происходили скачки с 13% до 25-30% в это время и происходит лаг, но мне кажется это тупо совпадение :D

23.11.2011

Превышен интервал ожидания для запроса.
(100% потерь)
Лагов нет ? Это как? Тут вообще связи с сервером нет !
Это адресс со звездочками или боишся что мы узнаем ip сервера?

23.11.2011

Нет просто не стал писать сюда, я хз почему нету связи, поток идет... нате тестите слушайте... 46.17.44.27:8008/1ive_256.m3u

23.11.2011

то что ип не пингуеться уже хреново в остальном я б уже не удивлялся

23.11.2011

попробуй юзать сторонний стримхостинг. если поток не будет тормозить - значит проблема типа той что у меня была+)

24.11.2011

нет смысла, одна и тажа проблема была на 3 сервер Windows... я хз что за wtf


Поподробнее

24.11.2011

Настраивай свой фаер, программно по сути только он блочит пакеты, в следствии этого они не возвращаются в обратку. Если же не фаер, печальный у тебя хостинг провайдер.

24.11.2011

У трех разных брал, разные ДЦ и провайдеры, разные ОС, все разное кроме ПО(ice & SAM)

13.06.2012

Leff27, так и не нашел решения этим "затыкам"?
Тоже уже довелось сменить несколько машин, последняя уже с Win XP, icecast перепробованы kh 29-35.5, обычный, trunk что-то не удалось найти. На всех icecast версиях подобное, настройки буфера и других параметров в конфиге айса резултата не дали.
Проблема явно в сэме, а именно в том, как он передаёт данные в локальный icecast, тестил 4.9.2 онли. Та же проблема.
К примеру aipm2 - через 4-8 минут "затыки" и так дальше, пока не остановишь и перезапустишь.
На VLC - чуть подругому, на нём просто останавливается через такой же промежуток времени, через 1-2 секунды играет дальше.
В общем такое чувство, что буфер как-то не стабильно уходит из сэма и уже соответственно из айса. Получается программы прослушивающие поток слушают буфер так:
5сек (1-2мин), 3сек (3-4мин), 2сек(5-6мин), 1-0сек(6-8мин) следовательно как буфер потока подходит к концу, разные проигрыватели, по разному реагируют, флеш сбрасывает буфер, якобы переподключаясь, vlc также, aimp2 - начинает заикаться как только буфер кончается.
Как победить уже хз, кручение вертелок всевозможных в сэме результатов не даёт, смены серверов тоже.
Есть подозрение, что нужно копать в более тонкую настройку tcp/ip системы, в размеры пакетов и т.д.
Или же всё куда более сложнее чем кажется. Странно, но почему-то ранее эта проблема не замечалась)

13.06.2012

Могу сказать по собственному опыту: icecast trunk 2.3.2 и SAM 4.2.2. - никаких затыков. WIn Server 2008 R2 64 bit

13.06.2012

Проблема вот в чем..
Используется win 2003/2008 + SAM(db - firebird) + icecast
Если закидывать треки напрямую в queue, то лагов нет, а если настраивать автодиджей, тобишь закидывать треки в плейлист сэма, чтобы он сам их оттуда брал, тогда начинаются жесткие лаги...

13.06.2012

Возможно все таки виновата firebird?

В таком случае можно попробовать настроить чтоб сэм сам в queue их кидал из базы, у меня так и лагов нет.
********** скрин настройки

Настройка Clockwheel:

1. Cat['Tracks'].QueueBottom(smRandom, EnforceRules);

13.06.2012

В моём случае, база, к сожалению не причём. До этого на firebird было так же, сейчас mysql, и так же эти "затыки" через некоторое время. Это никак не связано с количеством добавленных треков в queue, при любом количестве треков в queue подобное. (в моём случае)
Falcon, 4.2.2 разве не **********? Эту версию не пробовал тестить. Что-то стрёмно как-то)
Есть ещё идея попробовать shoutcast в качестве подопытного и послушать на нём поток. Если всё в норме на нём будет, боюсь придётся делать кастыль с релеем шоуткаст потока в icecast.

13.06.2012

Krueger, спасибо кэп))))
Так и делаю, только закидываю скриптом напрямую из папок.

Render, в queue дох.. может быть треков, а в плейлисте не должно(или как он там, где папки Tracks и т.п.)