Project

General

Profile

Bug #5764

Out of memory on OpenWrt while recording

Added by Pavol Grohol 16 days ago. Updated 14 days ago.

Status:
New
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 16 days 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 16 days 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 16 days 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 16 days ago

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

#5

Updated by Pavol Grohol 16 days 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 15 days ago

Where are you saving the recordings (filesystem type) ?

#7

Updated by Pavol Grohol 15 days ago

It is ext3

#8

Updated by Joe User 15 days 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 15 days ago

It is possible. I am from Slovak republic

#10

Updated by Jaroslav Kysela 15 days 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 15 days 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?

#12

Updated by Jaroslav Kysela 15 days ago

#13

Updated by Pavol Grohol 15 days 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 15 days ago

Seems related with #5073

#15

Updated by Luis Alves 14 days 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 14 days 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.

Also available in: Atom PDF