Bug #5096
Working installation with Kodi frontend for Live TV, but recording fails with "mpegts: too much queued table input data..." after creating "(null)" directory
0%
Description
This is a new Linux installation on my x86-64 desktop (kernel 4.16.4). Only TVHeadEnd is running on the desktop; I access it via wired Ethernet from a Kodi media center in another room. The video source is an HDHomeRun on the same network (also wired), and I have the userspace library (userhdhomerun) and kernel DVB device (dvb_hdhomerun) installed and working correctly.
TVHeadEnd is running with normal user permissions (user "tvh") and is part of the "video" group so it has access to the DVB devices. AFAICT the permissions are ok because live TV is working just fine. However, I have not been able to get any recordings to work!
When a recording is due to start, the logs say
2018-05-01T23:59:28.00037 daemon.info: May 1 23:59:28 tvheadend[18251]: dvr: "BBC World News America" on "KCTS-HD" recorder starting 2018-05-01T23:59:28.00049 daemon.info: May 1 23:59:28 tvheadend[18251]: dvr: About to set stop timer for "BBC World News America" on "KCTS-HD" at start 1525219198 and original stop 1525220998 and overall stop at 1525220998 2018-05-01T23:59:28.00055 daemon.info: May 1 23:59:28 tvheadend[18251]: mpegts: 189.028MHz in SeattleOTA - tuning on HDHomeRun ATSC #2 : ATSC-T #0 2018-05-01T23:59:28.00060 daemon.info: May 1 23:59:28 tvheadend[18251]: subscription: 004A: "DVR: BBC World News America" subscribing on channel "KCTS-HD", weight: 300, adapter: "HDHomeRun ATSC #2 : ATSC-T #0", network: "SeattleOTA", mux: "189.028MHz", service: "KCTS-HD", profile="pass" 2018-05-01T23:59:58.00166 daemon.warn: May 1 23:59:58 tvheadend[18251]: dvr: Unable to change directory permissions to "775" for "/pvr/(null)" (keeping "755") 2018-05-02T00:03:03.82894 daemon.warn: May 2 00:03:03 tvheadend[18251]: mpegts: too much queued table input data (over 2MB), discarding new 2018-05-02T00:03:13.87814 daemon.warn: May 2 00:03:13 tvheadend[18251]: mpegts: too much queued table input data (over 2MB), discarding new 2018-05-02T00:03:23.85803 daemon.warn: May 2 00:03:23 tvheadend[18251]: mpegts: too much queued table input data (over 2MB), discarding new 2018-05-02T00:03:33.90583 daemon.warn: May 2 00:03:33 tvheadend[18251]: mpegts: too much queued table input data (over 2MB), discarding new 2018-05-02T00:03:43.89278 daemon.warn: May 2 00:03:43 tvheadend[18251]: mpegts: too much queued table input data (over 2MB), discarding new
...and so on, every 10 seconds.
As soon as this happens, the web UI becomes unresponsive and the tvheadend process becomes unkillable except for kill -9. If I restart tvheadend while the recording is still supposed to be happening, it tries again with the same result.
Interestingly, although the tvheadend process is unresponsive, the system is basically idle---CPU less than 5%. But I wonder if the kernel DVB driver is behaving badly? because there are occasional kernel messages like this:
[10228.322175] perf: interrupt took too long (4386 > 4362), lowering kernel.perf_event_max_sample_rate to 45000 [31918.857361] perf: interrupt took too long (5514 > 5482), lowering kernel.perf_event_max_sample_rate to 36000
Also note the delay (three minutes) before the first "too much queued data" error. So maybe the data are being queued somewhere, pending writes to disk, but the disk access isn't happening, and it takes the queue about three minutes to overflow.
I don't understand the permissions error. My PVR path is set to an XFS-formatted partition mounted on /pvr. Directory permissions are set to 775:
drwxrwxr-x 4 tvh video 20480 May 1 16:59 pvr
and after the recording fails to start correctly, I see a new empty directory in /pvr:
drwxrwxr-x 2 tvh tvh 6 May 1 16:59 (null)
So:
Why is the directory called "(null)"?
Why does tvheadend complain that it cannot set permissions to 775 when, in fact, is has already done precisely that (the directory did not exist before)?
Why does tvheadend not create a file in this directory and start to write data?
History
Updated by Joe User over 6 years ago
Updated by What are the settings for the recording profile? More specifically, Filesystem Settings and Subdirectory Settings.
Updated by Mark Haun over 6 years ago
Updated by Is this what you mean?
"Recording File Options":
Recording system path: /pvr
Maintain free storage space in MiB: 1000
Maintain used storage space in MiB (0=disabled): 0
File permissions (octal, e.g. 0664): 0664
Filename character set: ASCII
Tag files with metadata: yes
Skip commercials: no
"Full pathname specification": $c/$t$n.$x
"Subdirectory options":
Directory permissions (octal, e.g. 0775): 0775
Make subdirectories per day: no
Make subdirectories per channel: yes
Make subdirectories per title: no
"Filename options":
Include channel name in filename: no
Include date in filename: no
Include time in filename: no
Include episode in filename: no
Include subtitle in filename: no
Don't include title in filename: no
Remove all unsafe characters from filename: yes
Replace whitespace in title with '-': no
Use Windows-compatible filenames: no
Updated by Joe User over 6 years ago
I am using 4.3 and not 4.2, so there may be some differences, but it seems that setting
"Full pathname specification": $c/$t$n.$x
and
Make subdirectories per channel: yes
Seems redundant??
Updated by Mark Haun over 6 years ago
Perhaps, but of course there all sorts of redundancies between the format string and the checkboxes which follow. That raises the question, should they be set to match (redundant)? or should one or the other be left empty/off (conflicting)? It's far from obvious.
In any case, this is pretty close to the defaults. I know for certain that I did not change the format string. Based on my symptoms, do you have reason to suspect a configuration issue? If so, I should be in the forum rather than the bug tracker, but if not, I guess I'm still waiting for a tvh maintainer to offer their opinion.
Thanks.
Updated by Mark Haun over 6 years ago
Perhaps, but of course there are all sorts of redundancies between the format string and the checkboxes which follow. That raises the question, should they be set to match (redundant)? or should one or the other be left empty/off (conflicting)? It's far from obvious.
In any case, this is pretty close to the defaults. I know for certain that I did not change the format string. Based on my symptoms, do you have reason to suspect a configuration issue? If so, I should be in the forum rather than the bug tracker, but if not, I guess I'm still waiting for a tvh maintainer to offer their opinion.
Thanks.
Updated by Joe User over 6 years ago
It does not hurt to try and change some things. :)
I would first remove the $c/ from the full path spec, then try unchecking the make subdirs and see if that works.
It is possible there is a problem with the channel name and that is why it is coming up as null.
Updated by Mark Haun over 6 years ago
Sorry for the delay... other things came up and I had to set this aside for several days. I've tried the changes you suggested. Unfortunately, recording is failing in pretty much the same way:
2018-05-11T04:50:30.00312 daemon.info: May 11 04:50:30 tvheadend[14148]: dvr: "test-recording" on "KCTS-HD" recorder starting 2018-05-11T04:50:30.00333 daemon.info: May 11 04:50:30 tvheadend[14148]: dvr: About to set stop timer for "test-recording" on "KCTS-HD" at start 1526014260 and original stop 1526014800 and overall stop at 1526014800 2018-05-11T04:50:30.00356 daemon.info: May 11 04:50:30 tvheadend[14148]: mpegts: 189.028MHz in SeattleOTA - tuning on HDHomeRun ATSC #2 : ATSC-T #0 2018-05-11T04:50:30.00378 daemon.info: May 11 04:50:30 tvheadend[14148]: subscription: 0010: "DVR: test-recording" subscribing on channel "KCTS-HD", weight: 300, adapter: "HDHomeRun ATSC #2 : ATSC-T #0", network: "SeattleOTA", mux: "189.028MHz", service: "KCTS-HD", profile="pass" 2018-05-11T04:51:00.51813 daemon.err: May 11 04:51:00 tvheadend[14148]: dvr: Unsupported charset ASCII using ASCII 2018-05-11T04:51:00.52144 daemon.err: May 11 04:51:00 tvheadend[14148]: dvr: Recording error: "test-recording": Unable to create file 2018-05-11T04:54:20.19257 daemon.warn: May 11 04:54:20 tvheadend[14148]: mpegts: too much queued table input data (over 2MB), discarding new 2018-05-11T04:54:30.23764 daemon.warn: May 11 04:54:30 tvheadend[14148]: mpegts: too much queued table input data (over 2MB), discarding new 2018-05-11T04:54:40.22022 daemon.warn: May 11 04:54:40 tvheadend[14148]: mpegts: too much queued table input data (over 2MB), discarding new
Well, the "unable to change directory permissions" error is gone, presumably because it is no longer trying to create a subdirectory of /pvr. But it still seems to believe that it cannot create the file, even though I'm fairly sure that it can. I also don't know what the "unsupported charset ASCII using ASCII" is all about.
It would be great if a developer could weigh in on this. I'm happy to help debug the problem, but as it stands, it is not debuggable by me, because these error messages aren't giving me much to go on 