Bug #5764
Out of memory on OpenWrt while recording
0%
Description
Tvheadend: 4.2.8-33~g8ef4c0c
OpenWrt: 18.06.4
I was getting OOM when recording on Banana PI R1 with OpenWrt.
I do not know what is the reason.
The way to solve this is to go into the Configuration/Records/Digital Video Recorder Profiles/Default profile and then go down to the Filename character set option and change it from ASCII to UTF-8 and then restart.
The solution is from https://forum.turris.cz/t/recording-tv-with-tvheadend-on-turris-openwrt-heres-a-setting-tweak-to-be-able-to-successfully-save-recordings/10729
History
Updated by Luis Alves about 5 years ago
Changing character set to solve the issue doesn't make much sense...
What do you have set on the "Cache scheme" option?
If not already, try recording using "Sync" (and change character set back to ASCII).
Updated by Luis Alves about 5 years ago
Actually you should set it to "Don't keep" or "Sync + Don't keep".
(you can find the description for the modes in the help)
Updated by Pavol Grohol about 5 years ago
I have "Don't keep" selected in "Cache scheme".
The issue is still there even when I select "Sync".
The memory and buffers/cache is used more and more.
I also do not see the reason why Character set is solving the issue, but it does....
Updated by Pavol Grohol about 5 years ago
I also do not see any file created in recordings. Only when changing Character set.
Updated by Pavol Grohol about 5 years ago
"Don't keep" is working but only with Filename character set to UTF-8. It may by some OpenWrt issue with file creation? I actually put it here for other having same issue.
Updated by Joe User about 5 years ago
Luis Alves wrote:
Changing character set to solve the issue doesn't make much sense...
From the link:
.. ends up buffering video in RAM until it runs out of memory. It doesn’t end up creating any recording files and it is completely unobvious why it isn’t working.
Do your filenames contain Czech characters?
Updated by Jaroslav Kysela about 5 years ago
It appears like that wrong / limited iconv library is used, thus the utf-8 to ASCII conversion does not work or so. Anyway, check logs, there should be reason why the file is not created.
Updated by Luis Alves about 5 years ago
What Jaroslav said plus this patch:
https://github.com/kkudielka/packages/blob/playground/multimedia/tvheadend/patches/010-remove-intlconv-safe-check.patch
Makes me believe that the issue is the limited libiconv used in openwrt.
Are you compiling tvheadend from sources or using the pre-compiled package?
Updated by Jaroslav Kysela about 5 years ago
Luis Alves wrote:
What Jaroslav said plus this patch:
https://github.com/kkudielka/packages/blob/playground/multimedia/tvheadend/patches/010-remove-intlconv-safe-check.patch
Wow, people are crazy.
Updated by Pavol Grohol about 5 years ago
I have compiled tvheadend myself to get version 4.2.8 without any patches. Unfortunately patches in repository is quite old.
Updated by Luis Alves about 5 years ago
This old PR (https://github.com/tvheadend/tvheadend/pull/90) added a --enable-dvbconv switch:
"[...] that adds built-in conversions for all charsets used by tvheadend and does not use iconv at all, as well as a number of fixes that enable at least partial support when compiling against either the stripped-down or full iconv implementations available in OpenWRT (and probably a number of other embedded environments as well). "
Is this config switch still there?
Updated by Jaroslav Kysela about 5 years ago
Luis Alves wrote:
This old PR (https://github.com/tvheadend/tvheadend/pull/90) added a --enable-dvbconv switch:
"[...] that adds built-in conversions for all charsets used by tvheadend and does not use iconv at all, as well as a number of fixes that enable at least partial support when compiling against either the stripped-down or full iconv implementations available in OpenWRT (and probably a number of other embedded environments as well). "
Is this config switch still there?
No, the current tvh requires working iconv library.
Updated by Niels Rahn over 4 years ago
I also have this problem - recorded only around 45 minutes of HD video and then the memory was fully used and TVHeadend stops responding...
Last messages were:
2020-04-12 16:29:28.149 [WARNING]:linuxdvb: Silicon Labs Si2168 #0 : DVB-C #0 - read() EOVERFLOW
2020-04-12 16:29:30.008 [WARNING]:linuxdvb: Silicon Labs Si2168 #0 : DVB-C #0 - read() EOVERFLOW
2020-04-12 16:29:32.265 [WARNING]:linuxdvb: Silicon Labs Si2168 #0 : DVB-C #0 - read() EOVERFLOW
2020-04-12 16:29:32.499 [WARNING]:linuxdvb: Silicon Labs Si2168 #0 : DVB-C #0 - read() EOVERFLOW
2020-04-12 16:29:34.203 [WARNING]:linuxdvb: Silicon Labs Si2168 #0 : DVB-C #0 - read() EOVERFLOW
2020-04-12 16:29:34.257 [WARNING]:TS: DVB-C Network/474MHz/SRF zwei HD: TELETEXT #2019 Continuity counter error (total 1)
#2012 Continuity counter error (total 1)
2020-04-12 16:29:34.257 [WARNING]:TS: DVB-C Network/474MHz/SRF zwei HD: H264
2020-04-12 16:29:34.257 [WARNING]:TS: DVB-C Network/474MHz/SRF zwei HD: AC3 #2015 Continuity counter error (total 1)
#2014 Continuity counter error (total 1)
2020-04-12 16:29:34.262 [WARNING]:TS: DVB-C Network/474MHz/SRF zwei HD: MPEG2AUDIO
2020-04-12 16:29:34.262 [WARNING]:TS: DVB-C Network/474MHz/SRF zwei HD: MPEG2AUDIO @ #2013 Continuity counter error (total 1)
Setting the encoding of the file names from ASCII to UTF-8 seems to have resolved the problem for me aswell.
I'm on Raspbian Strech, HTS Tvheadend 4.2.8-34 on a Raspberry Pi 3B