Continuity counter error
There is a setup with RPi2 and an DVBSky S960 USB DVB-S2 tuner (m88ds3103 chipset) running latest Libreelec 7.95.3 and Tvheadend addon in the repo. The problem described below was also seen with LE7.0.2 and an older 4.1.xxxx Tvh. No change after upgrade to latest.
There are many short picture disturbances, at least 2-3 per minute. Meanwhile many «continuity counter error» entries can be seen in the log.
The signal strength looks good, the BER counter is zero.
I assume the input signal quality is good. There is a dual output twin LNB. One output is connected to this system the other is connected to a cheap Chinese set-top-box. While this RPi system suffers continuous problems on all HD channels, the other box performs well with absolute perfect reception without any disturbance over several hours.
I have been using Tvheadend on different locations and devices for ages now, and I always experienced that TVH systems are very sensitive for disturbances and produces short picture dropouts and this hateful «continuity counter error», however not in this extent.
What shall I do to find out the root cause and get rid of this annoying problem? Could it be a performance limitation of RPi?
I like beer
I assume you’re running both Tvheadend server and client on the same Pi.
I had the same issue with my DVBSky s960 + RPi3. Here’s how you can fix it:
1) Switch from Advanced deinterlacing to Bob. Advanced deinterlace is using a lot of RAM bandwidth and it may cause issues (especially on HD channels) when both PVR client and server are on the same Pi. This is not the best solution because Advanced looks better than Bob.
2) Increase the «arm_uc» value (I use 12 0). The default value for Pi3 is «10 0». For Pi2 it is probably the same. Run «vcgencmd arbiter status» to check the current value.
To make the new setting permanent add this to autostart.sh file:
^This setting completely fixed the issue for me, I didn’t have to disable the Advanced deinterlacing.
RAM overclocking will also help a bit.
Edited once, last by smp ( Feb 13th 2017 ).
Thank you all! I will investigate according to proposals and come back with the result.
Thank you all! I will investigate according to proposals and come back with the result.
Here comes the findings.
The fault comes only if both the backend and client runs on the same RPi. If I stop the client and play the stream on an external client then the playback is fine. This is very similar what smp reported.
Open questions:
— «vcgencmd arbiter set arm_uc 12 0» command improves the behavior but it is still present. Shall I try with other parameters?
— «Switch from Advanced deinterlacing to Bob». There are only MMAL BOB and MMAL BOB halved options. By selecting them there is no picture. The configured HW acceleration is OMX and not MMAL. Does it matter?
— «Linux kernel 4.9.x perform poorly on the Pi.» I saw the same behavior with LE7.0.2 does it contain the same kernel? Is it worth testing with smp’s custom build linked in other thread?
Advanced (x2) deinterlace is very heavy on sdram bandwidth.
Some PVR backends have little tolerance to being delayed and may drop packets when sdram bandwidth is heavy.
As you have found, increasing the arm’s uncached (sdram) priority can help.
Have a read here: showthread.php?tid=269814&pid=2373475#pid2373475
The v3d_limited is another dial you can adjust which tweaks how advanced deinterlace uses sdram.
You can also try overclocking sdram which will help. Overclocking core and v3d may also help.
Options are:
Run PVR backend on a separate Pi from the one you watch.
Switch to Bob (x2) deinterlace
Switch to Advanced (x1) deinterlace
Play with some of the overclock and sdram controlling settings. Perhaps we’ll find a better set of defaults.
Note: Jarvis defaulted to Bob deinterlace for HD, so switching back to Bob on Krypton should behave much like Jarvis did.
— «vcgencmd arbiter set arm_uc 12 0» command improves the behavior but it is still present. Shall I try with other parameters?
— «Switch from Advanced deinterlacing to Bob». There are only MMAL BOB and MMAL BOB halved options. By selecting them there is no picture. The configured HW acceleration is OMX and not MMAL. Does it matter?
Always use mmal. Never enable omx except for troubleshooting purposes.
Use an older, pre-kernel 4.9 build (or my custom 7.95.2 build) + «arm_uc 12 0» and the errors should be gone.
Which kernel does your custom build use?
I can’t think of a reason why an older kernel would work better, but if it does I’d like to know why.
Which kernel does your custom build use?
I can’t think of a reason why an older kernel would work better, but if it does I’d like to know why.
I’d like to know this myself. I noticed the inferior performance of kernel 4.9 back in December with Milhouse build #1215. The issue is easy to reproduce as long as you have a DVB tuner connected to the Pi and PVR server/client are on the same Pi. The difference in performance is huge, with kernel 4.8 I can run this setup without a single issue (with Advanced deinterlacing enabled). With kernel 4.9 I absolutely have to disable Advanced deinterlacing (even increasing arm_uc doesn’t help).
I also tested Milhouse’s kernel 4.10-RC builds and they are just as bad as 4.9.x.
Edited once, last by smp ( Feb 16th 2017 ).
I’d like to know this myself. I noticed the inferior performance of kernel 4.9 back in December with Milhouse build #1215. The issue is easy to reproduce as long as you have a DVB tuner connected to the Pi and PVR server/client are on the same Pi. The difference in performance is huge, with kernel 4.8 I can run this setup without a single issue (with Advanced deinterlacing enabled). With kernel 4.9 I absolutely have to disable Advanced deinterlacing (even increasing arm_uc doesn’t help).
I’ll need to dig in to see exactly what changed between 4.8 and 4.9.
4.9 kernel uses more upstream drivers, including the upstream interrupt controller. 4.8 may have still been using the downstream one (I’d have to check).
That could mean either a difference in speed to dispatching the ISR (I would have thought that difference would be small) or a difference in precedence
(i.e. if a USB and a timer ISR are both pending which gets dispatched first) which may have more of an effect.
There is also a FIQ driver that USB uses.
Can you point sakos at your build to see if it helps his issue too?
Can you point sakos at your build to see if it helps his issue too?
A quick test is done with the custom build. (I checked the kernel version which was 4.8) The HW setup is Raspberry Pi2 with a DVBSky S960 USB DVB-S2 tuner. Eurosport HD channel on 0,8W
— after installation, Continuity counter errors (CCE) and picture disturbances
2 per minute rate
— applying «vcgencmd arbiter set arm_uc 12 0»: no significant change in CCE frequency
— selecting BOB MMAL deinterlacing (with arm_uc at 12): significant improvement. No CCE for 10 minutes then some error appeared in the log. Anyway the system is at watchable level. 
Long term test is starting.
— setting arm_uc back to default 10. Increased error rate to
It seems that combination of arm_uc increase and lighter deinterlacing selection improves the behavior. I think this test also confirms that the root cause is a performance issue. The arm_uc increase does not help in itself. The BOB interlace helps a bit in itself.
Nevertheless, I have to highlight that this working setup was not tested with 4.9 kernel, furthermore I have not found any difference yet between the two kernels. The error rates were similar with both kernels and arm_uc increase did not help in either case.
RAM/GPU overclocking should help as well. Push it as far as possible.
RAM/GPU overclocking should help as well. Push it as far as possible.
I will. However I am very disappointed. So far I thought RPi is very capable for a HTPC with DVB receiving capability. Now I can see it is on the edge when wathcing a single HD channel. I assume paralel recording or timeshifting can be completely forgotten.
Now I can see it is on the edge when wathcing a single HD channel. I assume paralel recording or timeshifting can be completely forgotten.
Not sure about RPi2 but RPi3 is usable as a DVB receiver. However, some tweaking is obviously required to get an acceptable performance. Also, in my experience VDR is far more robust than Tvheadend, so you definitely should give it a try.
Edited once, last by smp ( Feb 18th 2017 ).
I am experiencing this exact same issue on my x86_64 Generic HTPC (Acer Revo 3700) which has 4x 1.8GHz CPU Cores, 4GB RAM & 1TB SATAIII HDD.
I’m running the latest HTS Tvheadend 4.1.2415
LibreELEC Tvh-addon v8.1.109, with 2x DVBSky S960 USB DVB-S2 adapters.
If I upgrade to one of the latest beta releases 7.95.1, 7.95.2, 7.95.3 then the picture breaks up (i.e. goes blocky for a second or so) every couple of minutes when watching either Live TV or recording. The issue is worse for HD channels but does also occur on SD Channels.
When the picture goes blocky I receive Continuity Counter errors in the logfile for example:
If I downgrade to LE 7.90.009 alpha as stipulated in this post:thread-3665.html then I do not have any problems whatsoever.
I wonder whether it relates to the move from a 4.8.12 kernel to 4.9.x since the problem ONLY occurs when I upgrade to anything later than 7.90.009 
I hope this will be fixed before the production release as I’d rather not stay on the alpha release forever.
Also. I wonder whether it’s possible to swap in the 4.8.12 kernel and run this against the latest 7.95.3 beta release to identify whether the kernel is indeed the point at issue. Could that be done by simply swapping the KERNEL & KERNEL.md5 files in from the alpha 9 release into the /flash folder (after mounting the vfat partition r/w). I’d be happy to give that a go if someone could confirm it won’t break my system. If not, maybe there are other things I could try to help debug the issue?
Note: I’ve also posted the same findings in response to the thead here: thread-3665.html before then noticing this thread which seems to have picked up more of a head of steam.
What is the definition error 1.4: Continuity_count_error?
Вопрос :
What is the definition error 1.4: Continuity_count_error?
Ответ :
The formal definition of this error is given in the TR 101 290: Measurement guidelines for DVB systems document that is published by ETSI. A brief summary of this error is given below. For more information about this error or the test that generates it, please consult ETSI TR 101 290.
Every MPEG transport stream packet has a continuity count value (0-15) embedded within it. These values are required to be sent in order (0, then 1, then 2, 3, 4, 5, 6, 7, back to 0 and so on). The continuity count error indicates that one of three possible errors has occurred with regards to the continuity counter values:
Case 1: A continuity counter value was skipped in the sequence of packets. For example: if the continuity counter values received in order were …1, 2, 3, 5, 6… then this error would be reported because the value of 4 was skipped.
Case 2: Continuity counter values appeared out of order. For example: if the continuity counter values received in order were …1, 2, 4, 3, 5, 6… then this error would be reported because the values of 3 and 4 arrived in the wrong order.
Case 3: The same continuity counter value arrived twice in a row. For example: if the continuity counter values received in order were …1, 2, 3, 3, 4, 5, 6… then this error would be reported because the value of 3 appeared twice in a row.
Эти часто задаваемые вопросы относятся к
Серия приборов не найдена
Идентификатор часто задаваемых вопросов 64116
Continuity count error что это
Продукция по семействам
Продукция по категориям
Коммутатор резерва DVB-ASI (MPEG, T2-MI) бесшовный
PAC–4220
Имеет два режима автоматического резервирования: режим бесшовной коммутации, режим базовой коммутации. Переключение режимов ручное.
В режиме базовой коммутации потоки могут быть идентичными или разными. Осуществляется точно такой же анализ ошибок в основном и резервном каналах и переключение на резервный канал при отсутствии в нем ошибок и наличии их в основном канале за определенный промежуток времени.
Резерватор предназначен для круглосуточной работы в стационарном помещении с температурой окружающего воздуха от +5 до +45 о С, относительной влажности не более 80% при температуре 25 о С, атмосферном давлении 750 ± 30 мм рт. ст.
Лицевая панель PAC-4220
Задняя панель PAC-4220
Анализ потоков основного и резервного каналов на наличие ошибок I уровня ETS 1 TR 101-290
Два режима автоматического резервирования: режим бесшовной коммутации, режим базовой коммутации.
В режиме базовой коммутации обеспечивается переключение с основного на резервный вход по следующим критериям либо их комбинации:
пропадание входного сигнала ( LOSS );
отсутствие более 0,1с блоков данных ASI при сохранении кодирования 8/10 бит ( TS _ Sync _ Loss );
ошибка синхробайта блока данных ASI Sync _ byte _ error ;
ошибки PAT_error и PAT2_error;
нарушение последовательности Continuity _ counter в любом активном PID ’е потока;
ошибки PMT _ error и PMT 2_ error (пока не определяется);
ошибка PID _ Error (пока не определяется);
комбинация из перечисленных ошибок (задается пользователем).
Обратный переход выполняется при восстановлении качества потока в основном канале или при возникновении ошибок в резервном канале при исправном основном – в зависимости от выбранной схемы коммутации. Указанные критерии (за исключением первых двух) имеют возможность включения/отключения по усмотрению оператора.
Через WEB интерфейс доступны настройки и статусы:
режим резервирования – бесшовное резервирование/базовое резервирование;
наличие сигналов на входе;
состояние ошибок на каждом входе;
состояние синхронизации (устройство принимает сигнал и компенсирует задержку);
индикатор задержки между каналами;
настройка NTP клиента;
кнопки ручной коммутации;
выбор режима работы при стандартном резервировании: авто, ручной, с возвратом и без;
задание времени возврата (предполагается в более поздних версиях);
доступ к логгеру событий.
Резерватор отдает по SNMP:
активный канал « A/B ».
активный канал « A/B ».
Входы: (пока не опрашиваются)
включить режим « A/B ».
Релейный обход при выключении питания.
Входы:
Поддерживаемые стандарты
4 (2 основных и 2 резервных )
Входное сопротивление, разъём
Автоматическая коррекция кабеля
до 100 м (для кабеля 8281 или аналогичного)
Максимальная длина кабеля в режиме релейного обхода
до 100 м, длина участка до входа резерватора + длина участка от выхода до нагрузки (для кабеля 8281 или аналогичного)
Затухание несогласованности
не менее 15 дБ до 1,5 ГГц
Время нарастания и спада
Технические характеристики внешней линии управления
Характеристики сигналов GPI
Внешнее управление режимом работы основного выхода MAIN/STBY/AUTO и управление работой мониторного выхода MON MAIN/MON STBY (замыкание на землю соответствующего контакта).
Совместимы с уровнями ТТЛ
(«Лог.1»: 2… 5,5В; «Лог.0»: 0… 0,7В).
Длительность импульса
Входное сопротивление
*) Допускается формирование сигнала GPI кратковременным замыканием цепи сигнала на «общий».
Характеристики сигналов GPO
Управление ведомыми устройствами.
При прохождении на выход канала «MAIN» замкнуты контакты « MAINOUT » и « COM ».
При прохождении на выход канала « STBY » замкнуты контакты « STBYOUT » и « COM ».
«Сухие контакты» реле
Максимальная коммутируемая мощность:
Максимальное коммутируемое напряжение
Максимальный коммутируемый ток
Потребляемая мощность: не более 15Вт.
Диапазон рабочих температур: от +5 до +45 ° С.
Время непрерывной работы: 24 часа.
Габаритные размеры: 430×250х45 мм.
Масса: не более 4 кг.
Общее устройство и принцип действия
Структурная схема прохождения сигналов одного канала
« A IN » и « B IN » – входы основного и резервного каналов.
После подачи питания, транзитные реле переводят сигналы на узел электронного коммутатора (4 x 4), который обеспечивает постоянное поступление входных данных в анализатор и, одновременно, на заданный пользователем выход.
По окончании процедур первичного анализа, буферизации, выравнивания и сравнения потоков, электронный коммутатор подключает на выходы « A Out », « B Out » и « C Out » потоки, заданные в блоке конфигурирования выходов.
Алгоритм перехода на резерв
В режиме бесшовной коммутации
В случае выявления критической ошибки в основном канале, происходит переход на резервный канал с таким расчетом, чтобы выявленная ошибка не успела проникнуть на выход. Для этого, в том числе, сделана системная задержка потока на 1 с. Как только в основном канале исчезли критические ошибки, выполняется процедура перевыравнивания и оценки идентичности потоков и, по ее завершении – автоматический возврат на основной канал. В случае выявления одинаковых ошибок в обоих каналах в течение времени компенсации расхождения, переключения не происходит в силу нецелесообразности – в обоих каналах одна и та же ошибка и парировать ее имеющимися средствами невозможно.
В режиме базовой коммутации
В блоке « Switching reasons » пользователь выбирает набор ошибок (устанавливая « Enable » или « Ignore » в соответствующем пункте), на которые нужно реагировать и осуществлять переключение на резерв, но только в случае, если в резервном канале нет аналогичной ошибки:
пропадание входного сигнала ( LOSS ) – переход на резерв разрешен всегда, при наличии сигнала в резервном канале;
отсутствие более 0.1с блоков данных ASI при сохранении кодирования 8/10b (TS_Sync_Loss) – переход на резерв разрешен всегда, при наличии сигнала в резервном канале, и наличии блочной синхронизации в резервном канале;
ошибка синхробайта блока данных ASI: Sync_byte_Error (≠ 47h);
нарушение последовательности «Continuity counter»;
ошибки PAT Error и PAT Error 2 определяется пунктом « PAT Errors »;
ошибки PMT Error и PMT Error 2 определяется пунктом « PMT Errors » (предполагается в следующей версии);
ошибка PID Error (предполагается в следующей версии);
ошибка T2-MI Packet Numbering error;
ошибка T2-MI CRC error;
комбинация из перечисленных ошибок (задается пользователем).
В случае режима стандартной коммутации, при появлении любой из разрешенных для реагирования ошибок, кроме пропадания входного сигнала ( LOSS ), потери синхронизации потока или замирания данных в потоке (TS_Sync_Loss), где переход разрешен всегда, выполняется немедленный переход на резервный канал, затем запускается таймер (пока что на 1.5 с, в следующих версиях можно будет настраивать) ожидания повтора ошибки или выявления другой ошибки в этом же канале, и по истечению этого времени, если ошибки не повторились, канал признается пригодным для трансляции. Каждая новая возникшая ошибка перезапускает таймер и не позволяет признать канал исправным.
Конструктивно, коммутатор PAC –4220 построен в виде самостоятельного устройства, предназначенного для установки в стандартную 19-дюймовую стойку.
Управление с лицевой панели
Минимальный визуальный контроль работы устройства можно осуществить с помощью светодиодных индикаторов на передней панели.
Индикация (для одного канала)
MODE : двухцветный светодиод. Отображает 3 состояния: светится красным цветом – включен режим бесшовной коммутации, но она не возможна или выполняется процедура выравнивания потоков по времени. Светится зеленым цветом – включен режим бесшовной коммутации, потоки выравнены по времени и возможен бесшовный переход на резервный поток в случае повреждения главного. Не светится – режим бесшовной коммутации не активен.
IN A и IN B : двухцветные светодиоды. Показывают состояние соответствующих входов. Зеленый – поток на соответствующем входе исправен и пригоден к трансляции. Красный – поток содержит ошибки и к трансляции не пригоден или условно пригоден, если другой поток содержит более грубые повреждения.
В следующей панели можно выбрать одну из 6 схем переключения:
« Only A » – разрешено использование только входа « A », поток будет пробуферизирован и задержан на 1 секунду для обеспечения возможности перехода к режиму бесшовной работы с двумя потоками. В это время другой канал тоже анализируется, но его использование запрещено вне зависимости от его состояния;
« Only B » – разрешено использование только входа « B », поток будет пробуферизирован и задержан на 1 секунду для обеспечения возможности перехода к режиму бесшовной работы с двумя потоками. В это время другой канал тоже анализируется, но его использование запрещено вне зависимости от его состояния;
« No Out » – ничего не выдавать на данный выход;
« Protected Main » – на данный выход будет выдан защищенный главный канал, целостность которого требуется обеспечить;
« Direct A » – на данный выход будет выдан поток, который приходит на вход «А», в том же виде, в котором он поступает на вход устройства, независимо от выбранной схемы переключения.
« Direct B » – на данный выход будет выдан поток, который приходит на вход « B », в том же виде, в котором он поступает на вход устройства, независимо от выбранной схемы переключения.
В случае отключения питания устройства, на выходы « A » и « B » через схему релейного обхода, поступят потоки, приходящие, соответственно, на входы « A » и « B ». На выход «С» ничего выдаваться не будет.
На рис унке приведены панели отображения некоторых измеренных параметров поступающих потоков. Битрейт, усредненный период следования байт, усредненный период следования пакетов, период следования пакетов, содержащих фрагменты PAT (если эта таблица содержит более 44 записей и дробится на части) и период следования самой таблицы.
В строке « Seamless switching » индицируется возможность осуществления бесшовного перехода на резервный канал в случае отказа основного (« Possible » – возможен, « Impossible » – невозможен). Для этого должны быть выполнены следующие условия: оба канала должны быть активны, исправны (не содержать критических ошибок), должна быть завершена процедура выравнивания и заголовки пакетов в обоих каналах должны быть идентичны. Содержимое поля данных не проверяется, но возможность реализации такой функции есть.
В строке « Aligning » отображается состояние процедуры выравнивания потоков между собой: завершена ( Complete ) и выполняется ( In Progress ).
В строке « Output stream » индицируется состояние выходного потока: « Running » (передается) и « Destroyed » (разрушен). Качество выходного потока встроенными средствами пока не контролируется, определяется только факт передачи пакетов данных. Теоретически, есть возможность контроля качества выходного потока.
В строке « Active channel » выполняется отображение активного канала – того, из которого в данный момент времени идет трансляция защищенного потока.
В случае режима базовой коммутации, в разделе настроек добавляется блок « Switching reasons », который позволяет выбрать набор ошибок, выявление которых должно вызывать переключение на резервный вход, переведя переключатель в одно из состояний (« Enable » – разрешить переход на резерв при обнаружении этой ошибки, или « Ignore » –игнорировать возникновение этой ошибки):
« Sync Byte error » – контроль ошибки синхробайта;
« PAT errors » – контроль ошибок PAT и PAT 2;
« PMT errors » – контроль ошибок PMT и PMT 2. Выявление этой ошибки планируется в следующей версии;
« T 2- MI packet numbering error » – контроль ошибки нумерации пакетов T 2- MI ;
Контроль ошибок « LOSS » и « Transport Stream Sync loss » отключить невозможно – их обнаружение всегда будет приводить к переходу на резерв, если есть такая возможность.
Из панели « Diagnostics » можно открыть протокол последних 2000 событий. Он един для обоих каналов, в записях о событиях есть сведения о том, в каком канале они произошли.
