Bug #4940

Can't play recorded video file inside of tvheadend

Added by vistalba vistalba almost 4 years ago. Updated almost 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Found in version:
Affected Versions:



As described here ( I've some problems to play a recorded file.

Recording works fine but if I try to play the file from the webgui (download) and open it in VLC I get only errors.

tvheadend debug & trace output if trying to play the file:

2018-02-13 21:47:04.044 [  TRACE]:thread: created thread 139663960447720 [tvh:tcp-start / 0x55e69a632060(0x55e6a230e280)]
2018-02-13 21:47:04.044 [  TRACE]:http: HTTP/1.1 GET /play/dvrfile/7fd1f4552858df1420719c0a004b7012?title=Fussball%3A%20UEFA%20Champions%20League{{,User-Agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36,Accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,Accept-Encoding=gzip, deflate, br,Accept-Language=de-CH,de-DE;q=0.9,de;q=0.8,en-US;q=0.7,en;q=0.6,Authorization=Digest,Cookie=__cfduid=d428b3c5f172888208319578b5a6ccc341514563594; ys-api/dvr/entry/grid_upcoming=o%3Acolumns%3Da%253Ao%25253Aid%25253Ds%2525253Adetails%25255Ewidth%25253Dn%2525253A46%255Eo%25253Aid%25253Ds%2525253Acategory%25255Ewidth%25253Dn%2525253A32%255Eo%25253Aid%25253Dn%2525253A2%25255Ewidth%25253Dn%2525253A25%255Eo%25253Aid%25253Dn%2525253A3%25255Ewidth%25253Dn%2525253A64%25255Ehidden%25253Db%2525253A1%255Eo%25253Aid%25253Dn%2525253A4%25255Ewidth%25253Dn%2525253A147%255Eo%25253Aid%25253Dn%2525253A5%25255Ewidth%25253Dn%2525253A147%255E
2018-02-13 21:47:04.044 [  TRACE]:access: vistalba:vistalba [SATWRE    *], conn=0:s0:r0:l2, matched, profile=ANY, dvr=ANY, tag=ANY
2018-02-13 21:47:06.323 [  TRACE]:http: HTTP/1.1 GET /dvrfile/7fd1f4552858df1420719c0a004b7012?ticket=31f9f0c6593f2df6ac1eabb701bad95ab9f6a8c9{{,User-Agent=VLC/3.0.0 LibVLC/3.0.0,Accept=*/*,Accept-Language=de,Cookie=traefik-session-tvheadend=,Range=bytes=0-,X-Forwarded-For=,,X-Forwarded-Port=443,X-Forwarded-Proto=https,X-Forwarded-Server=srv-cluster1,X-Real-Ip=}}
2018-02-13 21:47:06.324 [   INFO]:http: using ticket 31f9f0c6593f2df6ac1eabb701bad95ab9f6a8c9 for /dvrfile/7fd1f4552858df1420719c0a004b7012
2018-02-13 21:47:06.324 [  TRACE]:idnode: find node 7fd1f4552858df1420719c0a004b7012 class dvrentry
2018-02-13 21:47:06.324 [  ERROR]:http: unable to convert filename 'ASCII//TRANSLIT//IGNORE' to a safe form using charset '2018-02-13_20-30_Fussball_-UEFA-Champions-League_SRF-zwei-HD.mp4'
2018-02-13 21:47:06.324 [  ERROR]:http: HTTP/1.1 GET /dvrfile/7fd1f4552858df1420719c0a004b7012 -- 500

tvheadend on docker linuxserver/tvheadend:latest (running in kubernetes cluster)
Host: ubuntu 16.04 LTS
RProxy: traefik with https and let's encrypt certificate

Associated revisions

Revision 4535a2cf (diff)
Added by Jaroslav Kysela almost 4 years ago

intlconv: add safe check for transil feature (to detect wrong musl builds), fixes #4940, fixes #4827



Updated by vistalba vistalba almost 4 years ago

Additional info: also download the recorded file doesn't work.. "Error 500" from tvheadend.


Updated by Jaroslav Kysela almost 4 years ago

It seems to be an issue with 'man 3 iconv' on your system:

2018-02-13 21:47:06.324 [  ERROR]:http: unable to convert filename 'ASCII//TRANSLIT//IGNORE' to a safe form using charset '2018-02-13_20-30_Fussball_-UEFA-Champions-League_SRF-zwei-HD.mp4'

The arguments are switched in the log message, but the error is printed. Appearently, there's something wrong with the tvh build.


Updated by vistalba vistalba almost 4 years ago

I don't understand what the problem is. How can I get this solved? Is there anything that I can do?
I'm not sure if it is the tvh build... I think a lot of people are using linuxserver/tvheadend:latest so there would be more people with this issue.


Updated by Jaroslav Kysela almost 4 years ago

The iconv routines were mostly tested with build-in glibc implementation. Your build is using another package - so you should work with the author of this 'build' to cover this problem. This docker build uses gnu-libiconv - I don't really know the difference between glibc iconv implementation and this library. But the code from gnu-libiconv returns an error when the ascii/translit conversion is requested (to make the resulted filename for the browser safe).


Updated by Torbjørn Brekke almost 4 years ago

I guess this is the same as issue #4827.
I haven't had the time to test after more traces was added to http.

So this problem comes from iconv on musl not being like iconv in glib?
This is what I found about iconv on musl. From [[]]

The iconv implementation musl is very small and oriented towards being unobtrusive to static link. Its character set/encoding coverage is very strong for its size, but not comprehensive like glibc’s. In particular:

Many legacy double-byte and multi-byte East Asian encodings are supported only as the source charset, not the destination charset. At least JIS-based ones will be supported as the destination beginning with version 1.1.19.
Transliterations (//TRANSLIT suffix) are not supported.
Converting to legacy 8-bit charsets is significantly slower than converting from them.
Stateful conversions are not supported, and plain UTF-16 and UTF-32 do not process or honor BOM, as of version 1.1.18. Future versions will support ISO-2022-JP (stateful) and possibly other encodings.
Misleading, deprecated charset aliases like UNICODE as an alias for UCS-2 are not supported. The IANA preferred MIME charset names should be used instead.
Contrary to POSIX, glibc iconv generates EILSEQ when a character is not representable in the destination charset. musl, in accordance with POSIX, performs an implementation-defined conversion and returns the number of such inexact conversions performed. At present, it replaces the character with an asterisk, but something akin to glibc’s //TRANSLIT mode may be substituted in the future. Code written assuming the glibc semantics (error when no exact conversion is possible) may need to be tuned to work well on musl and other conforming iconv [email protected]


Updated by Jaroslav Kysela almost 4 years ago

I'm afraid, but tvheadend depends on TRANSIL. I suggest to use the GNU iconv which can be used with musl, too.


Updated by vistalba vistalba almost 4 years ago

As I understand it is a problem only occours in docker image. The problem looks to me like the gnu-libiconv alpine package dosen't support all the stuff required by tvheadend.

What is about switch to a ubuntu/debian based docker image? Or is there any ETA when the gnu-libiconv for alpine will support the required stuff?


Updated by Torbjørn Brekke almost 4 years ago

It does look like I have fixed the problem here.
The gnu-libiconv-dev package place the iconv.h file in /usr/include/gnu-libiconv/, but musl-dev adds iconv.h in /usr/include/ and tvheadend used this one instead of the gnu-libiconv. Replacing /usr/include/iconv.h with the gnu-libiconv iconv.h fixes this issue.

How can we handle this the best way?
Can you add a check for musl and if true, use /usr/include/gnu-libiconv/iconv.h when checking for libiconv?
Or can I set the path myself when running ./configure?
Or just replace the file as I have done?


Updated by Jaroslav Kysela almost 4 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Updated by Jaroslav Kysela almost 4 years ago

Ok, I added runtime check for the transil feature which does not allow to run tvh with broken iconv routines. The iconv header file might be specified as a configure argument like --cflags="-I/usr/include/gnu-libiconv" .


Updated by Torbjørn Brekke almost 4 years ago

After you added the check, tvheadend is not working at all even when applying the fix I used with replacing the iconv.h.

Error is:
2018-02-19 15:09:39.818 [ ERROR] main: iconv() routine is not working properly, aborting!


Updated by Jaroslav Kysela almost 4 years ago

Then the proper iconv routines are not used at runtime (linking issue?). This check works with glibc.


Updated by Torbjørn Brekke almost 4 years ago

The reported issue was fixed when I applied the workaround mentioned in comment 9. It was possible to download the file through the webui.

Below is the output of ldd and ls -la of /usr/lib/libiconv*. So it shouldn't be a linking issue?

root:/$ ldd /usr/bin/tvheadend
/lib/ (0x1514c09e6000) => /usr/lib/ (0x1514c0161000) => /lib/ (0x1514bfef8000) => /lib/ (0x1514bfad8000) => /lib/ (0x1514bf8c1000) => /usr/lib/ (0x1514bf632000) => /usr/lib/ (0x1514bf422000) => /usr/lib/ (0x1514befa3000) => /usr/lib/ (0x1514beb79000) => /usr/lib/ (0x1514bd4c4000) => /usr/lib/ (0x1514bd23f000) => /usr/lib/ (0x1514bd022000) => /usr/lib/ (0x1514bcd42000) => /lib/ (0x1514c09e6000) => /usr/lib/ (0x1514bcb23000) => /usr/lib/ (0x1514bc89a000) => /usr/lib/ (0x1514bc67e000) => /usr/lib/ (0x1514bc461000) => /usr/lib/ (0x1514bc247000) => /usr/lib/ (0x1514bbf0f000) => /usr/lib/ (0x1514bbd02000) => /usr/lib/ (0x1514bba36000) => /usr/lib/ (0x1514bb3ab000) => /usr/lib/ (0x1514bb054000) => /usr/lib/ (0x1514bac1d000) => /usr/lib/ (0x1514ba974000) => /usr/lib/ (0x1514ba74d000) => /usr/lib/ (0x1514ba511000) => /usr/lib/ (0x1514ba2fb000) => /usr/lib/ (0x1514ba0a7000) => /usr/lib/ (0x1514b9e3c000) => /usr/lib/ (0x1514b9c38000) => /usr/lib/ (0x1514b9915000) => /usr/lib/ (0x1514b970f000) => /usr/lib/ (0x1514b950c000) => /lib/ (0x1514b92c0000) => /lib/ (0x1514b8f1a000) => /usr/lib/ (0x1514b8cbe000) => /usr/lib/ (0x1514b895a000) => /usr/lib/ (0x1514b874a000) => /usr/lib/ (0x1514b8516000) => /usr/lib/ (0x1514b82e3000) => /usr/lib/ (0x1514b807f000) => /usr/lib/ (0x1514b7d2d000) => /usr/lib/ (0x1514b7b27000) => /usr/lib/ (0x1514b7917000) => /usr/lib/ (0x1514b76f1000) => /usr/lib/ (0x1514b74eb000) => /usr/lib/ (0x1514b72db000) => /usr/lib/ (0x1514b70d3000) => /usr/lib/ (0x1514b6ec1000) => /usr/lib/ (0x1514b6cbe000) => /usr/lib/ (0x1514b6ab8000) => /usr/lib/ (0x1514b68a6000)

root:/$ ls -la /usr/lib/libiconv*
lrwxrwxrwx 1 root root 17 Feb 19 15:14 /usr/lib/ ->
-rwxr-xr-x 1 root root 915096 Apr 17 2017 /usr/lib/
[email protected]:/$


Updated by Jaroslav Kysela almost 4 years ago

What is in the log when you add this?

diff --git a/src/intlconv.c b/src/intlconv.c
index fb0d176c0..abb4e4da7 100644
--- a/src/intlconv.c
+++ b/src/intlconv.c
@@ -29,6 +29,7 @@ intlconv_test( void )
   /* The string is "Yellow Horse" in Czech for the curiosity */
   const char *charset = intlconv_charset_id("ASCII", 1, 1);
   char *s = intlconv_utf8safestr(charset, "ŽluťoučkýKůň", 128);
+  tvhinfo(LS_MAIN, "intlconv_test: '%s'", s);
   if (strcmp(s, "ZlutouckyKun")) {
     tvherror(LS_MAIN, "iconv() routine is not working properly, aborting!");

Glibc result:

2018-02-19 16:02:27.010 [   INFO] main: intlconv_test: 'ZlutouckyKun'

Updated by Torbjørn Brekke almost 4 years ago

I get this:

2018-02-19 16:42:51.315 [ INFO] main: intlconv_test: 'Zlutouck'yKun'

So then the gnu-libiconv is not working correctly on musl.


Updated by Torbjørn Brekke almost 4 years ago

I tested with gnu-libiconv 1.15 on ubuntu xenial and get the same result there. So what am I doing wrong here?

2018-02-19 17:54:51.069 [ INFO] main: intlconv_test: 'Zlutouck'yKun'


Updated by Jaroslav Kysela almost 4 years ago

It seems that the result depends also on the locale. Try latest, where tvh forces to use locale 'C.utf8'.


Updated by Torbjørn Brekke almost 4 years ago

It did not change the result of the test in both ubuntu xenial or alpine.
Should the locale not be C.UTF-8? That is what I have for ubuntu.

Also available in: Atom PDF