Prog wrote:Любой кодек, демукс, плагин,... повиснув - без вариантов вешают всё приложение. Они же в одном процессе.

А нельзя работать с ними в параллельном потоке и если поток завис то прибивать поток?

Такое было когда то. Отдельно интерфейс и движок в разных процессах. Но плохо получилось. Слишком сложная система со сложной синхронизацией и давала больше проблем чем плюсов. А потом ещё и BDA драйвера, которые в половине случаев виснут если приложение падает не завершившись, сводя на нет всю плюсы такой сложной системы.

crazycat wrote:

Prog wrote:rena-s: Дак вроде не было когда искал. Пришлите ссылку?
crazycat: tif тут не поможет?

нет, там по идее должны быть стандартные расширения BDA-драйвера Realtek для управления PID-фильтрацией на уровне чипа. См. у себя там сурцы библиотеки RTL283XACCESS (то что ты используеш для поддержки пульта на rtl283x). В BdaExtenProp.h есть описание методов KSPROPERTY_BDA_ENABLE_PID_PROPERTY, KSPROPERTY_BDA_DISABLE_PID_PROPERTY, KSPROPERTY_BDA_PID_FILTER_STATUS_PROPERTY. Только хрен его душу знает как их юзать, у меня нихрена не вышло.

Интересно, а как реализовано в DVB Dream?
DVB Dream видит все мультиплексы в DVB-C.

Prog wrote:разумеется. Интересно, по моим наблюдениям elecard кодеки чуть ли не самые устойчивые к битому трафику. А вот демукс в этом контексте не тестировал. Может тоже лучший?

Ну в общем-то да, демукс у них в этом плане устойчивый. Я его юзал еще во времена Win XP, кажеться тогда у тебя своего демукса не было (ProgDVB Elecard edition 4.85 кажеться). Сейчас впринципе встроенный твой работает хорошо тоже + кодеки LAV или MS. С демуксом elecard кажеться какие-то косяки с timeshift.

А вообще по висякам я больше бы пинал на BDA-подситему и собственно BDA-дрова. Особенно это касается Win8, 10 - там чего-то намутили и я бы посоветовал в первую очередь отключить использование Ms demux + TIF и ITuneRequest. Ну а вообще для обсуждения подобных вопросов упоминать используемый демукс, кодеки, настройки BDA-модуля и естесно версию винды.

Поставил новую версию ProgDVB.
В DVB-T2 всё нормально.Выбор PLP работает,но перестал видеть и сканировать каналы в DVB-T.Пришлось вернуться на старую версию.

alexpupkin wrote:Поставил новую версию ProgDVB.
В DVB-T2 всё нормально.Выбор PLP работает,но перестал видеть и сканировать каналы в DVB-T.Пришлось вернуться на старую версию.

А в какой версии работало одновременно T1 и T2 ? Странно… Ведь драйвер насколько я понимаю не имеет автовыбора, и софт должен явно задавать режим. Но ProgDVB режим не задаёт.

зы. есть для этого фича с указанием неправильной частоты, если указать частоту с +0.001мгц - то это будет интерпретировано как режим DVB-T1. А иначе - режим DVB-T2. Тут несколько страниц назад ведь про эту фичу было рассказано…

видимо по-умолчанию драйвер лочил DVB-T ? Тоесть без последних нововведений.

f2065 wrote:

alexpupkin wrote:Поставил новую версию ProgDVB.
В DVB-T2 всё нормально.Выбор PLP работает,но перестал видеть и сканировать каналы в DVB-T.Пришлось вернуться на старую версию.

А в какой версии работало одновременно T1 и T2 ? Странно… Ведь драйвер насколько я понимаю не имеет автовыбора, и софт должен явно задавать режим. Но ProgDVB режим не задаёт.

зы. есть для этого фича с указанием неправильной частоты, если указать частоту с +0.001мгц - то это будет интерпретировано как режим DVB-T1. А иначе - режим DVB-T2. Тут несколько страниц назад ведь про эту фичу было рассказано…

Да этот способ помог .Спасибо

rena-s wrote: Интересно, а как реализовано в DVB Dream?
DVB Dream видит все мультиплексы в DVB-C.

Обратил внимание, что DVB Dream при поиске использует bda.dev.
ProgDVB я так понял свой bda.device?

rena-s wrote: ProgDVB я так понял свой bda.device?

Конечно. Это связка между дровами и софтом. И каждый создатетель ваяет свой. тут то вся собака и порылась )). Одни валят на трафик, другие на железо, третьи по дрова... Такая вот петрушка... брат...по несчастью )))

V.Zhukoff wrote: Такая вот петрушка... брат...по несчастью )))

Да нас таких Братьёв полстраны)))
Вот только авторы ProgDVB ну нивкакую не хотят сотрудничать с ASTROMETA.
Они считают что производитель железа должен идти к каждому производителю софта с поклоном.

rena-s wrote:Они считают что производитель железа должен идти к каждому производителю софта с поклоном.

Немного не так. 1. Программ как PROgDVB -раз, о обсчелся.) 2. А производителей-до хрена. 3. И они, на мой взгляд, действительно, должны прогу все исходники давать. 4. другое дело, что Prog, являясь программистом лучше чем все эти китайцы, вместе взятые, должен ДОКАЗАТЬ, что проблема именно в производителях, а не косить на дрова и железо, и поток, голословно. 5. Тогда мы с этими доказательствами можем ткнуть им в рыло. Хоть через суд! 6. Я один раз доказывал прогу ГОД, что у него есть проблема с АТИ4ххх. Он ни в какую не признавался. потм Аkad разобрался 7. Вот сейчас он перешел на андроид, и все остальное-побоку-а он один человек всего-вот в этом и корень всех проблем.(((

V.Zhukoff wrote: Немного не так. 1. Программ как PROgDVB -раз, о обсчелся.) 2. А производителей-до хрена.

1. Нуууу... мне нравится PROgDVB только тем, что позволяет раздавать контент по сети, бесплатная версия на одного, но можно расширить до 10, для домашневого использования.
2. Производителей много, но железо то одинаковое. Взять тот же beholder, программисты этой фирмы хорошо работают, решают проблемы на лету, а не пинают на косяки прозводителей железа.

Вот так рождаются теории заговора. На самом деле проще, во времена расцвета astometa я опрашивал всех производителей на предмет SDK. Никто не дал. Возможно сами DNA связаны. Без SDK я ничего сделать не могу.

какое там нахрен SDK три костыля для переключения PLP