Project

General

Profile

Bug #5764

Out of memory on OpenWrt while recording

Added by Pavol Grohol about 5 years ago. Updated almost 4 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
Category:
PVR / DVR
Target version:
-
Start date:
2019-11-02
Due date:
% Done:

0%

Estimated time:
Found in version:
4.2.8-33~g8ef4c0c
Affected Versions:

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

#1

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).

#2

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)

#3

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....

#4

Updated by Pavol Grohol about 5 years ago

I also do not see any file created in recordings. Only when changing Character set.

#5

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.

#6

Updated by Luis Alves about 5 years ago

Where are you saving the recordings (filesystem type) ?

#7

Updated by Pavol Grohol about 5 years ago

It is ext3

#8

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?

#9

Updated by Pavol Grohol about 5 years ago

It is possible. I am from Slovak republic

#10

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.

#11

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?

#13

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.

#14

Updated by Luis Alves about 5 years ago

Seems related with #5073

#15

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?

#16

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.

#17

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)
2020-04-12 16:29:34.257 [WARNING]:TS: DVB-C Network/474MHz/SRF zwei HD: H264
#2012 Continuity counter error (total 1)
2020-04-12 16:29:34.257 [WARNING]:TS: DVB-C Network/474MHz/SRF zwei HD: AC3 #2015 Continuity counter error (total 1)
2020-04-12 16:29:34.262 [WARNING]:TS: DVB-C Network/474MHz/SRF zwei HD: MPEG2AUDIO
#2014 Continuity counter error (total 1)
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

#18

Updated by Flole Systems almost 4 years ago

  • Status changed from New to Invalid

Also available in: Atom PDF