Bug #3479
Tvheadend crashes when stopping recording
0%
Description
As prior described and sadly rejected in Bug #3401 (Rejected): Tvheadend crashes when stopping recording.
On commit bdda940cafea2fc322b3548aef16144fdb9ffb3b the Problem exists:
When starting a recording (by hand or via timer) all is working fine, current recording is shown in list an the .ts file is written to disk constantly. But when i click on "stop recording" or "abort recording", the frontend will show "wait while..." for about 10 sec. After that i can not do anything in the frontend, it does not react any more.
The record-file is still be written.
Files
History
Updated by Jaroslav Kysela almost 9 years ago
It looks like a stall in ioctl() - 0x00000000004d1672 in linuxdvb_frontend_monitor (aux=0x1b7a6a0) at src/input/mpegts/linuxdvb/linuxdvb_frontend.c:824 :
824) if (!ioctl(lfe->lfe_fe_fd, FE_READ_SNR, &u16)) {
Blame your driver.
Updated by Uli Bruckdorfer almost 9 years ago
Jaroslav Kysela wrote:
It looks like a stall in ioctl() - 0x00000000004d1672 in linuxdvb_frontend_monitor (aux=0x1b7a6a0) at src/input/mpegts/linuxdvb/linuxdvb_frontend.c:824 :
[...]
Blame your driver.
Ok, but it would take some time to fix this driver at the kernel sources. Do you think it would be possible to do a short workaround at my side? As far as i have seen the only time the ioctl with FE_READ_SNR is called at linuxdvb_frontend.c.
Would it work if i comment the if state and do mmi->tii_stats.snr_scale = SIGNAL_STATUS_SCALE_UNKNOWN; instead?
Updated by Uli Bruckdorfer almost 9 years ago
I have tested with an other driver (https://github.com/DigitalDevices/dddvb/releases) with the result that everything is working except the Signal Strenght is always shown with 100% on the web interface. Multiple Channels can be watched live via streaming, there a no problems. But the described crash when stopping a record via the web interface or automaticaly by the time still exists.
By the way, there are no problems when i use other tools like gnutTv or kaffein, so i will not blame the driver.
I did some more debugging with gdb and found
(gdb) bt
#0 0x00007f616db47797 in ioctl () from /usr/lib/libc.so.6
#1 0x00000000004d1512 in linuxdvb_frontend_monitor (aux=0x230b5e0)
at src/input/mpegts/linuxdvb/linuxdvb_frontend.c:900
#2 0x000000000040ce14 in mainloop () at src/main.c:557
#3 main (argc=<optimized out>, argv=<optimized out> at src/main.c:1112
(gdb) continue
Continuing.
[New Thread 0x7f61177fe700 (LWP 739)]
[New Thread 0x7f6145ffb700 (LWP 740)]
[New Thread 0x7f6144ff9700 (LWP 741)]
// Here stop was pressed, now program hang at _lll_lock_wait
Program received signal SIGINT, Interrupt.
0x00007f616e31fcfc in __lll_lock_wait () from /usr/lib/libpthread.so.0
(gdb) bt
#0 0x00007f616e31fcfc in __lll_lock_wait () from /usr/lib/libpthread.so.0
#1 0x00007f616e31b8a0 in __pthread_mutex_cond_lock ()
from /usr/lib/libpthread.so.0
#2 0x00007f616e31d4fa in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /usr/lib/libpthread.so.0
#3 0x000000000040ce94 in mainloop () at src/main.c:571
#4 main (argc=<optimized out>, argv=<optimized out> at src/main.c:1112
i have a core-dump file for this state, but its quite big to attach. If you want to take a look let me know so i will search a possibility to share the coredump with you.
Updated by Jaroslav Kysela almost 9 years ago
Thread 1 (Thread 0x7f162f3e9b40 (LWP 5010)): #0 0x00007f162b12b797 in ioctl () from /usr/lib/libc.so.6
The tvh main thread is stuck in ioctl() - this fcn locks the mutex global_lock, so all other threads start waiting for this lock release. Really a driver issue, the ioctl should not block. Other apps probably uses a different device I/O sequences which don't trigger this issue. You may just comment out this ioctl.
Updated by Jaroslav Kysela almost 9 years ago
And don't forget to report this to the authors of the driver.