M3UIPTV плагин для управления IPTV

[xellar55]

Может кто запустил. Не знаю.

OpenPli  от foxbob , крайняя за 4 декабря сего года , установил с его фида этот плагин  СПАСИБО автору плагина , настроил прочитав эту тему , букеты прописались , EPG  подтянулось , архив помечен галками . Работает нормально.
Возьму на резерв , пока IPtvDream и OTT FOSS эксплуатирую .

[Simakovav]

Satfan777, Работает и со ссылки и с плейлиста.

[mishel-67]

Слетает epg если выключить с розетки. Как исправить. Флешка примонтирована как HDD. Epg сохраняется там же.

[Марчелла]

mishel-67, думаю это косяк самого имиджа если речь об OpenPli, на e2m3u2bouquet от Дорика такая же трабла.

[mishel-67]

На BH тоже слетает

[сергей 999s]

на e2m3u2bouquet от Дорика такая же трабла.

От Дорика

Спойлер   :

вопрос

EPG пропадает после перезагрузки   энигмы,

ответ Дорика

А при чем тут плагин ? Плагин - генерирует букеты, т.е. создает некие текстовые файлы определенного формата , в простонародии "букеты", точно так же как это делали бы вы "пультом" для спутникввых каналов,  проверят наличие и "скачивает" пиконы присваивая им имя файла в определенном формате, точно так же как это делали бы вы для спутниковых каналов ... и импортирует EPG, точно так же как это происходит в случае со спутниковыми каналами ... т.е. "работа" плагина заключается в неком "эмулировании" спутника для IPTV ... как только плагин закончил генерацию букетов и импорт EPG ... дальше у вас все точно так же как со спутниковыми каналами ... просмотр, переключение, воспроизведение, EPG, пиконы и т.д. это все к вашему имиджу ... Посему проверяйте настройки используемого имиджа

Импорт EPG это "наполнение" некого  стандартного "словаря" в вашем имидже ... он "называется" eEPGCache ... периодически ваш имидж "сбрасывает" данные этого словаря в файл epg.dat ... это происходит или по таймингу или при выключении реса ... При включении реса ваш имидж считывает данные из файла epg.dat в eEPGCache и после этого вы видите  EPG на экране .... это все видно в логе запуска имиджа 

Так вот .... где плагин в описанном вами поведении EPG у вас на ресе? Проверяйте настройки имиджа, наличие свободного места на флехе куда имидж кеширует данные  EPG , т.е. где хранится epg.dat и т.д.


Если это какая-то древняя OpenPli , то это проблема "древней" OpenPli... Скорее всего вы делаете полный ребут системы ... после этого у вас "слетает" синхронизация времени ... и часы  показывают 1970 год ... Вы через 20-30 сек после того как ребутнули рес  сделайте просто restart gui (Restart Enigma2) ... И о чудо ! EPG на месте ))) ... Так же проверьте как у вас настроена синхронизация времени транспондер или по сети ..."Копайте" в сторону вашего имиджа .. плагин тут 100500 не при делах


Плагин, перед началом импорта чего бы то ни было, синхронизирует текущее время имиджа через службу точного времени в "интернетах" (я в коде заранее не доверяю имиджам , пользователям и т.д.) ... согласитесь ... глупо импортировать EPG за сегодня , если время системы 01/01/1970 ))).... Так вот ... запуск плагина в вашем случае просто корректно устанавливает текущее время вашей системы ... ну и заодно импортирует EPG

Или 

вопрос

EPG пропадает после перезагрузки

Раньше тоже так было на Openpli homebuild 2019-07-20(develop),переписал путь хранения епг в меню /etc/enigma2/ и епг теперь не  слетает.Попробуйте может поможет...Правда переписывать надо очень внимательно,если попутаете хоть одну букву латиницы с русской,а они на энигмовской клаве одинаковые,не пропишится,а если все правильно нажимать будете,в конце после /epg.dat само выскочит.Аааа пардон,посмотрел вашу подпись у вас тюнер другой,более продвинутый,но все равно хотел удалить свое сообщение,пускай висит,может кому на древние пли пригодится..

[mishel-67]

Спасибо. Буду пробовать.

[Марчелла]

сергей 999s,

думаю это косяк самого имиджа если речь об OpenPli

к плагину притензий нет

[_bolvan_]

Если вы внимательно прочтёте данную тему, будет ясно что работать данный плагин не будет на Pli 9.0.

Но читать это не к вам я так полагаю?

P/s  Поправил первый пост выделив красным для тех кому изучать данную тему табу, а для тех кто в танке будут получать читательский билет.

Я вот, вместо темы прочел исходники , поправил и все работает на Pli9 dev ... и для OBH 5.4 там тоже "подкуртил"  ... Автор красава. Крутой код на питоне, глубокие знания и понимание всех нюансов Enigma2 на уровне "атомов"  . Первый раз за последние лет пять хоть у кого-то увидел реально правильный синтаксис и семантику Py3 ... Но часть решений я бы так не делал (это никак не критика, это скорее "рацуха") .. особенно цикл "fоr line in lines" по provider.list при переключении каналов ... На плейлистах M3U, особенно у "буржуинов" в Европе, с кол-вом записей 100'000+ будет тупить что при переключении каналов что при старте реса по питанию  ... Чисто ради эксперимента "сгенерил" несколько имеющихся у меня m3u от "европейских пользователей" с кол-ом записей в плейлисте 800'000 с "гаком" и 1'200'000+ .... Заскучал ждать когда переключит  ... Я бы в такой логике "переключений" делал бы dict  вместо list ... Как ни крути индексный поиск шустрее при любых раскладах ... даже с учетом break, если найден среди "fоr line in lines"... один фиг там с "завидной" периодичностью парсятся результаты "request за плейлистом" и куда "пихать" результат, в list или dict - без разницы .... А вот последующая выборка при переключениях, повторюсь, по "индексу" - 100500 "веселее"
Добавлено  19 декабря | 2024г. | 18:42:01

сергей 999s,

 Я могу подумать о том, как это можно расширить...

Там не сложно в текущей логике данного плагина - просто ь сформировать необходимые файлы channels.xml ... Математику используемых алгоритмов для поиска "по похожести", которая используется в IPTVBouquetMaker, я выкладывал ... Алгоримы Jaro (c оптимизацией от Winkler) или TF/IDF - не есть тайной за "семью печатями" .... Глядя в ваш код я точно уверен что у вас получится 
Добавлено  19 декабря | 2024г. | 19:02:58
О! И еще требует доработки логика regexp-ов для CATCHUP ...Там не без нюансов ... Общая логика - правильная, абсолютно верная, но жизнь не идеальна ...  мог бы сходу привести ряд "живых" ссылок из реальных m3u-плейлистов нескольких популярных "пиратиков" где ваша текущая логика точно работать не будет ... хотя у них есть "архивные" записи и они прекрасно работают, но я тут "харам" , и мне запрещена публикация ссылок ....
Добавлено  19 декабря | 2024г. | 19:13:39
И в парсере M3U тоже рацуха нужна  ... иначе столкнетесь с кучей "фе" от "интуристов" в теме по плагу на форуме линукс-сат ...
Чисто ради интереса проверьте как у вас распарсит

tvg-ID="нечто"

А у "буржуинов" вот такой синтаксис -  tvg-ID - именно с таким сочетанием "больших и малых" букв - сплошь и рядом ... В текущем коде такое проигнорит ...

Все ... беглое чтение кода закончил. Красивый код. Приятно читать.
Добавлено  19 декабря | 2024г. | 19:33:17
p.s. Ну и пока меня тут не забанили в очередной раз ... В такой логике формирования serviceref, я имею ввиду

 REFTYPE:FLAGS:STYPE:SID:TSID:ONID:NS:PARENT_SID:PARENT_TSID:UNUSED , а именно "связки" - SID:TSID:ONID:NS

Так вот ... при такой логике формирования как у вас вы ограничены в кол-ве групп в плейлистах и в кол-ве каналов внуттри группы ... Математику такого "явления" я объяснял "интуристам" на форуме linux-sat ... это я возвращаюсь к плелйистам с 500 000+ и "хреновым" кол-вом групп в поейомсте ... Собственно это то с чем я сходу у вас столкнулся, кроме скорости переключения каналов, при "игрищах" с мегаплейлистами ... Но для плейлистов пиратиков из постсовкового пространства - сойдет  Ссылку на математические выкладки, подтверждающие мою правоту, привести тут не могу , мне это запрещено .... но поиск на linux-sat - творит чудеса
 
Добавлено  19 декабря | 2024г. | 21:50:57

а именно "связки" - SID:TSID:ONID:NS

Процитирую сам себя .. лень переводить.. Я видел у вас хороший английский на linux-sat...

That’s true... But ... A little theory ... Based on the C code, a unique hash sum for EPG is formed from serviceref's SID:TSID:ONID

uniqueEPGKey service(eit->getServiceID(), onid, tsid);

If we consider the provider name specified in the card as OriginalNetworkID (ONID). then we only have ServiceID and TransportServiceID (SID:TSID) ... Let's assume that each channel "inside" the provider has a unique "transponder" (TSID) ... Therefore, the number of possible options (channels) within one provider can be 168 - 1 = 4 294 967 295 ... If we consider TSID as a "group name" then a provider can contain a maximum of 65534 groups (bouquets) each of which can contain a maximum of 65534 channels -> this option is not suitable because:

1) The playlist can be “planar” and not contain a single group and have more than 65534 entries (channels)
2) One group (bouquet) can contain more than 65534 records (channels)
3) The same channel can be located in several groups (bouquets) at the same time... although in each

So only the first option remains, which gives us the maximum possible number of channels per m3u-playlist - 4 294 967 295 ... I hope this is enough for any user

Думаю вам будет понятно почему ваш код столкнется с ограничением по кол-ву записей как внутри букетов так и самих групп в плейлисте при существующей логике формирования serviceref

На этом позвольте откланяться ...

[sunriser]

Я вот, вместо темы прочел исходники , поправил и все работает

На этом позвольте откланяться ...

Сергей, Ваш бы опыт и наработки...
Но, автор плагина - молодец, развивается своим путём.
Да, и не откланивайтесь...

[DimitarCC]

_bolvan_,
Я знаю, что есть много недостатков у некоторых неизвестных провайдеров... Но я не могу видеть все, что там есть. Я сделал это относительно провайдеров, которые у меня есть в руках.
Что касается постоянного чтения списка при переключении канала...
Это невозможно, так как когда у вас динамически меняются URL-адреса каналов, вам всегда приходится перебирать исходный плейлист. Так что вы в любом случае будете читать построчно.

Провайдеры с 10/20000 каналов в основном пиратские, и для них вам следует выбирать статические URL-адреса. Тогда никаких проблем при переключении каналов.

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

[_bolvan_]

_bolvan_,

Это невозможно, так как когда у вас динамически меняются URL-адреса каналов, вам всегда приходится перебирать исходный плейлист. Так что вы в любом случае будете читать построчно.

Речь шла не о "невозможно" , а о выборе объекта для хранения того того что "распарсено" и логике того где это делается с последующим поиском данных ... Вы храните сейчас считанный плейлист в list() ... и при переключении каналов постоянно  "бегаете" по элементам этого list в поисках совпадения channelforSearch да еще и каждый раз делаете анализ строк используя regexp (т.е. паристе плейлист)... Вам что ресурсы девать некуда? Зачем это делать при каждом переключении канала?   .. моя мысль, которую я пытался донести, была о том что объектом хранения распарсеных данных M3U сделать dict с ключом channelforSearch и тогда не нужно будет "колбасить"  цикл -> iptv-m3u-reader/src/M3UProvider.py строка 234

У вас prov.playlist - "рефрешится" с какой-то там переодичностью  ... так вот когда вы его считали
playlist = response.read().decode('utf-8') ,
его сразу надо "распарсить" в dict  ОДИН раз, а не при каждом переключении каналоа,  и хранить данные в dict с ключем  channelforSearch и поиск в нем при перключении будет занимать O(1), а не O(n) да еще и с regexp, startswith и всем вот тем парсингом как сейчс ... все равно "динамические" url трансляций (как вы их называете) поменяются у вас только при очередном/последующем response.read() , в чем смысл "беготни" и парсинга ОДНОГО И ТОГО ЖЕ плейлиста (в промежутках между его обнолениями по  response.read()) при каждом переключении

Надеюсь так понятно ? Парсить плейлист только тогда когда он "рефрешнулся" (был считан по ссылке) , а не за каждым переключением .... храня результаты парсинга в dict, что обеспечит мгновенное переключение практически при любом размере плейлиста

[DimitarCC]

_bolvan_,
Я понимаю вашу точку зрения...
Однако это означает, что когда плейлист должен быть проанализирован, он должен проанализировать все строки и преобразовать его в словарь...
В настоящее время он останавливает его анализ, как только находит канал..
Также в значении "dict" должен быть сохранен объект "channel", который будет содержать все другие необходимые вещи, такие как группы, URL, catchup и т. д.

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

Если вы используете статические URL, то парсинг плейлиста вообще не происходит. Этот режим предназначен для огромных списков с 5000 - 20000 каналов.
Для списков с каналами менее 5000 я действительно не вижу проблем с производительностью на современных приемниках.

Имейте в виду, что плагин не предназначен для использования с плейлистами, содержащими записи VOD (которых может быть много). Только с сервисами, которые позволяют вам отделять записи VOD от прямых трансляций.

[_bolvan_]

_bolvan_,
В настоящее время он останавливает его анализ, как только находит канал..

Верно =) Но что происходит если я постоянно переключаю каналы в "нижней" части списка ....

_bolvan_,
Если вы используете статические URL, то парсинг плейлиста вообще не происходит.

Верно от части, только это касается "рефреша" плейлиста (строка 218 в M3UProvider.py) ... а вот при переключении у вас всегда отрабатывает цикл поиска для channelForSearch и реального url (nref_new) для старта трансляции и там вы в цикле "бегаете" пока не найдете при каждом переключении, "развлекаясь" regexp (стр 238, стр 247) для КАЖДОЙ строки пока не найдете искомую .. в этой части кода что "динамические", что статические - до лампочки ... вы "дергаете" processService при каждом переключении канала (вы в plugin.py делаете переопределения для класса NavigationInstance добавляя playServiceWithIPTV где и дергаете processService), а processService каждый раз "дергает" processDownloadPlaylist, где в зависимости от настроек, или будет рефрешится плейлист или нет ... а вот "беготня" по prov.playlist - ВСЕГДА ... если честно я там никакой другой логики в коде не увидел

_bolvan_,
Также в значении "dict" должен быть сохранен объект "channel", который будет содержать все другие необходимые вещи, такие как группы, URL, catchup и т. д.

Что сложного в структуре dict у ключей которого value = dict() ? Я даже более чем уверен что такая структура будет жрать меньше памяти чем планарный текст считанный из response 

Ок .. не вижу смысла спорить или доказывать ... я же сразу написал что для постсовковых IPTV пиратиков "пациеннты" могут и не заметить "подтупливаний" при переключениях .... причину когда и почему будет тупить на огромных списках я вроде как описал, более того я даже умудрился ее словить и неоднократно, от чего и вник в логику переключений и понял где то "узкое" место возникает

Добавлено  20 декабря | 2024г. | 18:11:26

_bolvan_,
Имейте в виду, что плагин не предназначен для использования с плейлистами, содержащими записи VOD (которых может быть много). Только с сервисами, которые позволяют вам отделять записи VOD от прямых трансляций.

Ну мне это понятно ))) Как это объяснить 99% "интуристов" на форуме linux-sat... Европейские пиратские IPTV плейлисты - это "нечто" ... там такой компот и каша ... что "вайдот благодарных пользователей" - гарантирован ... А призывы к ДАЙТЕ ЛОГ и меньше "Ля Ля" , например на этом форуме, привела к моей "вечной" блокировке )))) ... Как вариант вот вам сходу вопросы к которым надо быть готовым -
А какие сервисы мне позволят отделить VOD от Live в используемом мной плейлисте?
Ваш плагин этого не умеет?
А вы можете сделать чтобы по VOD сервисам просто создавались отдельные букеты?
и т.д.

 

p.s. Но код таки красиво написан .. и "морж" даже етсь местами ... осталось только структуры if elif elif...else заменить новомодными matching case и вааще будет "пусичка" 
p.s.s. Рацуха в синтаксисе и семантике 
Сейчас

Код: [Выделить]

Вам не разрешен просмотр кода. Войдите или Зарегистрируйтесь для просмотра.Как бы одно и то же ... но дело вкуса и избранного стиля "написания"  ... да и regexp будет шутрее раза в ДВА отрабатывать, что весьма критично если его по сути чуть ли не по каждой строке "чекать" (от слова проверять)   

Код: [Выделить]

Вам не разрешен просмотр кода. Войдите или Зарегистрируйтесь для просмотра.Чтобы не быть голословным примеры ниже , обратите внимание на кол-во шагов за которые отрабатывает одну и туже строку , но с разным regexp

Код: [Выделить]

Вам не разрешен просмотр кода. Войдите или Зарегистрируйтесь для просмотра.А результат - одинаков 

[DimitarCC]

Верно от части, только это касается "рефреша" плейлиста (строка 218 в M3UProvider.py) ... а вот при переключении у вас всегда отрабатывает цикл поиска для channelForSearch и реального url (nref_new) для старта трансляции и там вы в цикле "бегаете" пока не найдете при каждом переключении, "развлекаясь" regexp (стр 238, стр 247) для КАЖДОЙ строки пока не найдете искомую .. в этой части кода что "динамические", что статические - до лампочки ... вы "дергаете" processService при каждом переключении канала (вы в plugin.py делаете переопределения для класса NavigationInstance добавляя playServiceWithIPTV где и дергаете processService), а processService каждый раз "дергает" processDownloadPlaylist, где в зависимости от настроек, или будет рефрешится плейлист или нет ... а вот "беготня" по prov.playlist - ВСЕГДА ... если честно я там никакой другой логики в коде не увидел

Если задан «Статический URL», код никогда не обращается к этой внутренней функции плагина... Поэтому из него ничего не считывается.
Вызванный processService из IPTVProviders.py.
И там, если у вас есть статический URL то букет формируется таким образом, что переходит на строку 21 и выходит даже до перехода к processDownloadPlaylist...

Что сложного в структуре dict у ключей которого value = dict() ? Я даже более чем уверен что такая структура будет жрать меньше памяти чем планарный текст считанный из response

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

Ну мне это понятно ))) Как это объяснить 99% "интуристов" на форуме linux-sat... Европейские пиратские IPTV плейлисты - это "нечто" ... там такой компот и каша ... что "вайдот благодарных пользователей" - гарантирован ... А призывы к ДАЙТЕ ЛОГ и меньше "Ля Ля" , например на этом форуме, привела к моей "вечной" блокировке )))) ... Как вариант вот вам сходу вопросы к которым надо быть готовым -
А какие сервисы мне позволят отделить VOD от Live в используемом мной плейлисте?
Ваш плагин этого не умеет?
А вы можете сделать чтобы по VOD сервисам просто создавались отдельные букеты?
и т.д.

Плагин уже создает отдельные списки с VOD, которые вы можете найти в главном меню. Но это работает только для провайдеров XtreamCodes, а не для M3U. Это потому, что там вы можете получить VOD отдельно от сервера.

p.s. Но код таки красиво написан .. и "морж" даже етсь местами ... осталось только структуры if elif elif...else заменить новомодными matching case и вааще будет "пусичка"

Могут быть улучшения кода... Но, к сожалению, нельзя использовать новые вещи, так как некоторые версии изображений Python не поддерживаются...
Однако спасибо за все предложения. Я открыт для предложений. Так что если вы можете улучшить часть кода, вы можете легко предложить запрос на слияние