Bug #4827
closed
Unable to play recorded program through webgui
Added by David Pollard over 7 years ago. Updated about 7 years ago.
100%
Description
First of all, GREAT work with TVHeadEnd - very impressed !
This MAY be a docker issue in which case, sorry for wasting your time.
I run 4.3-861~g715a4a844 in a docker container by linuserver.io
All works fine, and recordings are playable through KODI etc... But not playable through the webgui.....
Clicking the webgui play button next to a recording downloads a file. Clicking the file opens Ubuntu's video application which says "The film could not be read". Opening the file in VLC Media Player says :- VLC is unable to open the MRL blah blah blah.....
The error in the logs on TVHeadEnd is :-
2018-01-03 10:49:23.882 [ ERROR] http: 192.168.1.100: HTTP/1.1 GET /dvrfile/e815d3e1369052572096a9f7f8eb1230 -- 500
Hope this helps you guys.....
Thank you
dp
Files
| http.log (16.6 KB) http.log | Torbjørn Brekke, 2018-01-03 19:03 | ||
| gdb.txt (5.36 KB) gdb.txt | Torbjørn Brekke, 2018-01-04 17:24 | ||
| http.log (17.7 KB) http.log | Torbjørn Brekke, 2018-01-04 17:24 | ||
| gdb-new.txt (823 Bytes) gdb-new.txt | Torbjørn Brekke, 2018-01-05 16:15 | ||
| http-new.log (73.6 KB) http-new.log | Torbjørn Brekke, 2018-01-05 16:15 | ||
| gdb-4.3-909~g50ab53f4e.txt (806 Bytes) gdb-4.3-909~g50ab53f4e.txt | Torbjørn Brekke, 2018-01-07 13:28 | ||
| http-4.3-909~g50ab53f4e.log (57 KB) http-4.3-909~g50ab53f4e.log | Torbjørn Brekke, 2018-01-07 13:28 | ||
| gdb-1466-1488.txt (4.9 KB) gdb-1466-1488.txt | Torbjørn Brekke, 2018-01-08 23:42 | ||
| gdb-1466-1492.txt (1.25 KB) gdb-1466-1492.txt | Torbjørn Brekke, 2018-01-08 23:42 | ||
| gdb-1488-1497.txt (837 Bytes) gdb-1488-1497.txt | Torbjørn Brekke, 2018-01-08 23:42 | ||
| gdb-1488-1492.txt (851 Bytes) gdb-1488-1492.txt | Torbjørn Brekke, 2018-01-08 23:42 | ||
| http-1466-1488.log (71.9 KB) http-1466-1488.log | Torbjørn Brekke, 2018-01-08 23:42 | ||
| http-1488-1492.log (27.3 KB) http-1488-1492.log | Torbjørn Brekke, 2018-01-08 23:42 | ||
| http-1466-1492.log (74.1 KB) http-1466-1492.log | Torbjørn Brekke, 2018-01-08 23:42 | ||
| http-1488-1497.log (72 KB) http-1488-1497.log | Torbjørn Brekke, 2018-01-08 23:42 |
Updated by Mark Clarkstone over 7 years ago
You need to provide some more info :)
Attach yourself to the container via bash & kill tvh then run with..
--debug http --trace http --logfile /tmp/http.log
Generate the error then use nc to upload the log..
cat /tmp/http.log | nc termbin.com 9999
post the log here.
Updated by Torbjørn Brekke over 7 years ago
I can provide some more info also. I'm one of the maintainers of the docker container David use and have know about this some time now, but didn't have the time to report it.
I believe it's musl related as the docker container uses Alpine Linux (3.7) and this issue does not occur using ubuntu as the base OS.
Here I get a 401 in the log, not 500 for some reason. Tvheadend crashes when the file is being tried played in vlc (After entering username/password).
Attached the log with your command Mark. The below is what happens on the host OS (unraid 6.4)
Jan 3 18:55:39 unDev kernel: traps: tvh:tcp-start[1051] general protection ip:55a0c189d3cd sp:14d79f3eeb90 error:0 in tvheadend[55a0c171c000+3bc000]
@David
You can't use the method Mark described as tvheadend restarts automatically if it's killed. Instead you can add the RUN_OPTS variable to the container. If on unraid, you can just edit the template and the container will get recreated, if on other OS, then you must delete the container and create it again with the RUN_OPTS variable. It's described at our github [[https://github.com/linuxserver/docker-tvheadend]] Just change the last part of the command to /config/http.log to have easier access to the file.
Here is the full build log of the container, including the tvheadend compile. [[https://ci.linuxserver.io/job/Docker-Builders/job/x86-64/job/x86-64-tvheadend/133/consoleFull]]
If you need any more info, please let me know.
Updated by Mark Clarkstone over 7 years ago
Updated by Torbjørn Brekke over 7 years ago
Mark Clarkstone wrote:
Torbjørn Brekke wrote:
... snip..
Thank you for giving the correct info in order to Help debug this issue. I don't use docker much so can only give hints :).
I think Jaroslav would need a trace/debug info. See Debugging & Traces for info. How you'd go about that in docker I have no clue.
I'll read that page and enable what is needed. Might need to get info about which parts to add to debug if more than http is needed. But I guess Jaroslav can point in the right direction.
Updated by Mark Clarkstone over 7 years ago
Torbjørn Brekke wrote:
Mark Clarkstone wrote:
Torbjørn Brekke wrote:
... snip..
Thank you for giving the correct info in order to Help debug this issue. I don't use docker much so can only give hints :).
I think Jaroslav would need a trace/debug info. See Debugging & Traces for info. How you'd go about that in docker I have no clue.
I'll read that page and enable what is needed. Might need to get info about which parts to add to debug if more than http is needed. But I guess Jaroslav can point in the right direction.
I think the CRASH lines would be more than enough :), but yes, Jaroslav will be the best to decide here.
Updated by David Pollard over 7 years ago
http.log file uploaded to termbin
Shout if you need anything else...
Thanks all
dp
Updated by Jaroslav Kysela over 7 years ago
The docker image should contain addr2line tool (binutils) and the debugging binary (with unstripped debugging symbols) should be used to get reasonable CRASH lines. Also, try to put a sleep between 'rerun'.
Updated by Jaroslav Kysela over 7 years ago
It may not work. It seems that musl does not implement backtrace functions (execinfo.h). You need gdb to debug this. https://sourceware.org/gdb/onlinedocs/gdb/Remote-Debugging.html
Updated by David Pollard over 7 years ago
Thanks Jaroslav
gdb debugging (remote or otherwise) is a bit beyond me I'm afraid.
@Torbjørn - If you can provide similar pointers as you did in post #2,I'm happy to do some work on this to return some useful debug info.
Thanks all
dp
Updated by Torbjørn Brekke over 7 years ago
David Pollard wrote:
Thanks Jaroslav
gdb debugging (remote or otherwise) is a bit beyond me I'm afraid.
@Torbjørn - If you can provide similar pointers as you did in post #2,I'm happy to do some work on this to return some useful debug info.
Thanks all
dp
It's just easier that I debug it here. I have to test that the container with gdb works anyway.
Updated by Torbjørn Brekke over 7 years ago
Jaroslav Kysela wrote:
It may not work. It seems that musl does not implement backtrace functions (execinfo.h). You need gdb to debug this. https://sourceware.org/gdb/onlinedocs/gdb/Remote-Debugging.html
I remember now that I tried to find execinfo.h for alpine before and didn't succeed. I'll try to get gdb backed into a container here.
Updated by Torbjørn Brekke over 7 years ago
Here is the gdb log and http trace log. If you need any more subsystems than http in the trace, I can run it again.
Updated by Jaroslav Kysela over 7 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset commit:tvheadend|6d00befe814edea9529b9a4b2a2409d16ce1ba08.
Updated by Torbjørn Brekke over 7 years ago
- File gdb-new.txt gdb-new.txt added
- File http-new.log http-new.log added
Jaroslav Kysela wrote:
Thanks, fixed. v4.3-889-g6d00befe8
Sorry, but it's still not fixed. Tvheadend doesn't crash anymore, but still 401 and 500 errors when trying to play the file (Or pressing the download button in the finished recordings tab.
I have attached the new log files.
Updated by Jaroslav Kysela over 7 years ago
- Status changed from Fixed to Accepted
401 errors are fine for requests without authorization. 500 error code - it seems that it is probably returned from http_serve_file() function after "bad" lseek() call in src/webui/webui.c . Could you check what value is returned from lseek() for musl ?
Updated by Torbjørn Brekke over 7 years ago
Jaroslav Kysela wrote:
401 errors are fine for requests without authorization. 500 error code - it seems that it is probably returned from http_serve_file() function after "bad" lseek() call in src/webui/webui.c . Could you check what value is returned from lseek() for musl ?
I could check it, but I have no idea how to check it I'm afraid.
Updated by Jaroslav Kysela over 7 years ago
I added the error log to recent v4.3-907-gfb22b9565. Please, retry and repost logs.
Updated by Torbjørn Brekke over 7 years ago
- File gdb-4.3-909~g50ab53f4e.txt gdb-4.3-909~g50ab53f4e.txt added
- File http-4.3-909~g50ab53f4e.log http-4.3-909~g50ab53f4e.log added
Doesn't look like it added anything to the log.
Started tvheadend with this:gdb --args /usr/bin/tvheadend -c /config --debug http --trace http --logfile /config/http.log
Updated by Jaroslav Kysela over 7 years ago
If you run gdb in this way, could you add breakpoint to http_serve_file, like:
$ gdb --args ... (gdb) l http_serve_file (gdb) l (gdb) break 1466 (gdb) run (gdb) until 1488 ...
etc.. We need to find a line where the program returns with the 500 error code (HTTP_CODE_INTERNAL).
Updated by Torbjørn Brekke over 7 years ago
- File gdb-1466-1488.txt gdb-1466-1488.txt added
- File gdb-1466-1492.txt gdb-1466-1492.txt added
- File gdb-1488-1492.txt gdb-1488-1492.txt added
- File gdb-1488-1497.txt gdb-1488-1497.txt added
- File http-1466-1488.log http-1466-1488.log added
- File http-1466-1492.log http-1466-1492.log added
- File http-1488-1492.log http-1488-1492.log added
- File http-1488-1497.log http-1488-1497.log added
I'm not sure about what I'm doing here....
So I have attached on log with break from 1466 to 1488. The webui did not go as far as internal server error 500 then.
Running with break from 1488 to 1492, I get internal server error 500. But the gdb log doesn't show much.
Running with break from 1466 to 1492, I get internal server error 500, and the gdb log has some info.
So I hope there are something usefull, if not I'll run some more tests :)
Updated by Torbjørn Brekke about 7 years ago
Is there something more you want me to test?
Updated by Jaroslav Kysela about 7 years ago
Upgrade to master - I added more traces to '--trace http' subsystem.
Updated by Jaroslav Kysela about 7 years ago
- Status changed from Accepted to Fixed
Applied in changeset commit:tvheadend|4535a2cf6ccf5209d220971890869390e1567889.