Project

General

Profile

Bug #1660

tvheadend (on OpenELEC) writes 32kB/sec continuously

Added by Dag Wieers over 11 years ago. Updated over 11 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
General
Target version:
-
Start date:
2013-03-12
Due date:
% Done:

100%

Estimated time:
Found in version:
3.3.491
Affected Versions:

Description

As reported at:

https://github.com/OpenELEC/OpenELEC.tv/issues/2051

tvheadend is continuously writing 32kB/sec (on average in fact about 42kB/sec) in files like /storage/.xbmc/userdata/addon_data/service.multimedia.tvheadend/dvbmuxes/_dev_dvb_adapter0_Afatech_AF9013/_dev_dvb_adapter0_Afatech_AF9013482000000 with content like:

{
        "quality": 100,
        "enabled": 1,
        "status": "OK",
        "transportstreamid": 1,
        "originalnetworkid": 8248,
        "network": "VRTmux1",
        "frequency": 482000000,
        "initialscan": 0,
        "bandwidth": "8MHz",
        "constellation": "QAM64",
        "transmission_mode": "8k",
        "guard_interval": "1/4",
        "hierarchy": "NONE",
        "fec_hi": "1/2",
        "fec_lo": "1/2" 
}

This is problematic on SSD devices and happens even when the system is idle and tvheadend not being used.

If anything we should be able to direct it to a tmpfs filesystem or (if unneeded) disable this behavior.

History

#1

Updated by Adam Sutton over 11 years ago

OK, looks like a stupid mistake (by me no doubt) on updating of network properties. please can you try this patch:

http://pastebin.com/raw.php?i=gPLqzYFb

Adam

#2

Updated by Dag Wieers over 11 years ago

I can find the tvheadend package directory in OpenELEC, but I fail to find where it is being build (or a reference in build*/.stamps to make it rebuild). Very weird.

#3

Updated by Adam Sutton over 11 years ago

I think you need to build the addon separately, so if you've never built tvheadend you won't have anything.

got this on #openelec:
(16:14:39) sraue: PROJECT=xxx ARCH=xxx ./scripts/create_addon xxx

so fill in PROJECT and ARCH and then I'd guess the addon is called tvheadend (or service.multimedia.tvheadend?).

You'll probably have to start the build, patch the code and complete the build. Or else stick the patch in the relevant patches directory (and name it properly).

Probably worth asking on #openelec for help with building.

Adam

#4

Updated by Dag Wieers over 11 years ago

I can find the tvheadend package directory in OpenELEC, but I fail to find where it is being build (or a reference in build*/.stamps to make it rebuild). Very weird.

#5

Updated by Dag Wieers over 11 years ago

(Damn reload resubmits comments :-/)

What is weird then is that I have made more than 200 builds myself that I have installed to this system, so if you tell me I never build tvheadend it means it has been installed from an addon repository instead, right ?

#6

Updated by Adam Sutton over 11 years ago

There is also a bug in that patch, no idea why I didn't spot that...

Anyway, use this instead:

http://paste.ubuntu.com/5608170/

Adam

#7

Updated by Adam Sutton over 11 years ago

  • Status changed from New to Accepted

I've stuck the patch on my own server and it appears to be doing the business there. However I'll wait for confirmation before I push the fix and close the issue.

Adam

#8

Updated by Dag Wieers over 11 years ago

With the second patch on the latest OpenELEC master branch I get:

[dag@moria OpenELEC.tv]$ PROJECT=ATV ./scripts/create_addon tvheadend
  GET      tvheadend
--2013-03-12 17:39:11--  http://sources.openelec.tv/devel/tvheadend-3.3.491.tar.gz
Resolving sources.openelec.tv... 212.101.13.11
Connecting to sources.openelec.tv|212.101.13.11|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2206892 (2.1M) [application/x-gzip]
Saving to: `sources/tvheadend/tvheadend-3.3.491.tar.gz'

100%[===========================================================================================>] 2,206,892   1.53M/s   in 1.4s    

2013-03-12 17:39:13 (1.53 MB/s) - `sources/tvheadend/tvheadend-3.3.491.tar.gz' saved [2206892/2206892]

  UNPACK   tvheadend
      APPLY PATCH (common):   packages/addons/service/multimedia/tvheadend/patches/tvheadend-001-avoid_writes.patch
patching file src/dvb/dvb_multiplex.c
Hunk #2 succeeded at 851 (offset -5 lines).
Hunk #3 succeeded at 877 (offset -5 lines).
Hunk #4 succeeded at 899 (offset -5 lines).
Hunk #5 succeeded at 917 (offset -5 lines).
Hunk #6 succeeded at 942 (offset -5 lines).
patch unexpectedly ends in middle of line
Hunk #7 FAILED at 956.
1 out of 7 hunks FAILED -- saving rejects to file src/dvb/dvb_multiplex.c.rej
#9

Updated by Adam Sutton over 11 years ago

See if there is a missing EOL in the file, this seems to happen a lot with pastebin. Also that patch was made against master, it may be incompatible with what OE is using, so you might need to massage it.

Adam

#10

Updated by Dag Wieers over 11 years ago

Strike that last comment, the copy&paste failed to included the last 2 "empty" lines. Now it works...

#11

Updated by Dag Wieers over 11 years ago

Ok, as far as I can tell it does not seem to be fixed, but the behavior seems to have changed.

First and foremost I assume this is the newly build tvheadend. I produced a new addon .zip and installed it manually in OpenELEC XBMC. But there is no way to be sure this is the new build.

I do see the same behavior but now only in bursts, no longer all the time (unless I was lucky in my previous tests and always tested when there was a burst).

xbmc02:~ # /storage/dstat/dstat -td --top-bio 1
----system---- -dsk/total- ----most-expensive----
     time     | read  writ|  block i/o process   
12-03 18:02:31| 120k   56k|loop0        99k    0 
12-03 18:02:32|   0    36k|tvheadend     0    36k
12-03 18:02:33|   0    32k|tvheadend     0    32k
12-03 18:02:34|   0    72k|tvheadend     0    32k
12-03 18:02:35|   0    36k|tvheadend     0    36k
12-03 18:02:36|   0    32k|tvheadend     0    32k
12-03 18:02:37|   0    32k|tvheadend     0    32k
12-03 18:02:38|   0    28k|tvheadend     0    28k
12-03 18:02:39|   0     0 |                      
12-03 18:02:40|   0    40k|                      
12-03 18:02:41|   0     0 |                      
12-03 18:02:42|   0     0 |                      
12-03 18:02:43|   0     0 |                      
12-03 18:02:44|   0     0 |                      
12-03 18:02:45|   0     0 |                      
12-03 18:02:46|   0     0 |                      
12-03 18:02:47|   0     0 |                      
12-03 18:02:48|   0     0 |                      
12-03 18:02:49|   0     0 |                      
12-03 18:02:50|   0     0 |                      
12-03 18:02:51|   0     0 |                      
12-03 18:02:52|   0     0 |                      
12-03 18:02:53|   0     0 |                      
12-03 18:02:54|   0     0 |                      
12-03 18:02:55|   0     0 |                      
12-03 18:02:56|   0     0 |                      
12-03 18:02:57|   0     0 |                      
12-03 18:02:58|   0    32k|                      
12-03 18:02:59|   0    20k|tvheadend     0    20k
12-03 18:03:00|   0    32k|tvheadend     0    32k
12-03 18:03:01|   0    32k|tvheadend     0    32k
12-03 18:03:02|   0    36k|tvheadend     0    36k
12-03 18:03:03|   0    32k|tvheadend     0    32k
12-03 18:03:04|   0    72k|tvheadend     0    32k
12-03 18:03:05|   0    36k|tvheadend     0    36k
12-03 18:03:06|   0    32k|tvheadend     0    32k

These bursts seems to go on for about 20 seconds, then stop for 20 seconds.

12-03 18:04:15|   0     0 |                      
12-03 18:04:16|   0     0 |                      
12-03 18:04:17|   0     0 |                      
12-03 18:04:18|   0    32k|                      
12-03 18:04:19|   0  4096B|tvheadend     0  4096B
12-03 18:04:20|   0  4096B|tvheadend     0  8192B
12-03 18:04:21|   0    40k|tvheadend     0    36k
12-03 18:04:22|   0    36k|tvheadend     0    36k
12-03 18:04:23|   0    40k|tvheadend     0    40k
12-03 18:04:24|   0    76k|tvheadend     0    36k
12-03 18:04:25|   0    36k|tvheadend     0    36k
12-03 18:04:26|   0    36k|tvheadend     0    40k
12-03 18:04:27|   0    40k|tvheadend     0    36k
12-03 18:04:28|   0    36k|tvheadend     0    36k
12-03 18:04:29|   0    72k|tvheadend     0    36k
12-03 18:04:30|   0    36k|tvheadend     0    32k
12-03 18:04:31|   0    32k|tvheadend     0    32k
12-03 18:04:32|   0    36k|tvheadend     0    36k
12-03 18:04:33|   0    32k|tvheadend     0    32k
12-03 18:04:34|   0   224k|xbmc.bin      0   108k
12-03 18:04:35|   0    36k|tvheadend     0    36k
12-03 18:04:36|   0    32k|tvheadend     0    32k
12-03 18:04:37|   0    24k|tvheadend     0    24k
12-03 18:04:38|   0     0 |                      
12-03 18:04:39|   0     0 |

Looking at syslog, there does seem to be a relation between the bursts and what is logged in syslog:

Mar 12 18:02:57 xbmc02 daemon.debug tvheadend[3930]: eit: install table handlers
Mar 12 18:02:58 xbmc02 daemon.debug tvheadend[3930]: eit: begin processing
Mar 12 18:03:00 xbmc02 daemon.debug tvheadend[3930]: epg: expire event 20975 from Canvas
Mar 12 18:03:00 xbmc02 daemon.debug tvheadend[3930]: epg: now/next 0/19095 set on Canvas
Mar 12 18:03:00 xbmc02 daemon.debug tvheadend[3930]: epg: arm channel timer @ 1363107840 for Canvas
Mar 12 18:03:00 xbmc02 daemon.debug tvheadend[3930]: epg: inform HTSP of now event change on Canvas
Mar 12 18:03:17 xbmc02 daemon.debug tvheadend[3930]: eit: processing cancelled
Mar 12 18:03:17 xbmc02 daemon.debug tvheadend[3930]: dvb: "/dev/dvb/adapter0" tuning to "VRTmux1: 666,000 kHz" (Autoscan)
Mar 12 18:03:17 xbmc02 daemon.debug tvheadend[3930]: eit: install table handlers
-snip-
Mar 12 18:03:17 xbmc02 daemon.debug tvheadend[3930]: eit: begin processing
Mar 12 18:04:00 xbmc02 daemon.debug tvheadend[3930]: epg: now/next 19095/20977 set on Canvas
Mar 12 18:04:00 xbmc02 daemon.debug tvheadend[3930]: epg: arm channel timer @ 1363109220 for Canvas
Mar 12 18:04:00 xbmc02 daemon.debug tvheadend[3930]: epg: inform HTSP of now event change on Canvas
Mar 12 18:04:17 xbmc02 daemon.debug tvheadend[3930]: dvb: "/dev/dvb/adapter0" tuning to "VRTmux1: 482,000 kHz" (Autoscan)
Mar 12 18:04:17 xbmc02 daemon.debug tvheadend[3930]: eit: install table handlers
Mar 12 18:04:18 xbmc02 daemon.debug tvheadend[3930]: eit: begin processing
Mar 12 18:04:19 xbmc02 daemon.debug tvheadend[3930]: dvb: "VRTmux1: 482,000 kHz" on adapter "Afatech AF9013", status changed to No signal
Mar 12 18:04:21 xbmc02 daemon.debug tvheadend[3930]: dvb: "VRTmux1: 482,000 kHz" on adapter "Afatech AF9013", status changed to OK
Mar 12 18:04:37 xbmc02 daemon.debug tvheadend[3930]: eit: processing cancelled
Mar 12 18:04:37 xbmc02 daemon.debug tvheadend[3930]: dvb: "/dev/dvb/adapter0" tuning to "VRTmux1: 506,000 kHz" (Autoscan)
Mar 12 18:04:37 xbmc02 daemon.debug tvheadend[3930]: eit: install table handlers
Mar 12 18:04:37 xbmc02 daemon.debug tvheadend[3930]: eit: begin processing
Mar 12 18:04:57 xbmc02 daemon.debug tvheadend[3930]: eit: processing cancelled
Mar 12 18:04:57 xbmc02 daemon.debug tvheadend[3930]: dvb: "/dev/dvb/adapter0" tuning to "VRTmux1: 482,000 kHz" (Autoscan)
Mar 12 18:04:57 xbmc02 daemon.debug tvheadend[3930]: eit: install table handlers
Mar 12 18:04:57 xbmc02 daemon.debug tvheadend[3930]: eit: begin processing
Mar 12 18:05:17 xbmc02 daemon.debug tvheadend[3930]: eit: processing cancelled

Hope this helps !

#12

Updated by Jens Brehm Nielsen over 11 years ago

Well, I had the same issue as you report here. I have a HDhomerun TV tuner and in my setup the problem was basically caused by TVheadend logging data from the TV tuner. I was able to stop it by typing "tvheadend option log disable" and then restart tvheadend. I don't know which TVtuner you are using, but if you have the option and haven't tried it, it's probably worth giving a try.

#13

Updated by Dag Wieers over 11 years ago

Where exactly do you type "tvheadend option log disable" ? We modified the start script to not enable option "-s" which caused debug logging to syslog, however this only accounted for about 1kB/minute, not 32kB/sec.

In fact we traced it back to something different as you can see above.

#14

Updated by Adam Sutton over 11 years ago

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

Applied in changeset commit:07cdfdaf6af06ae08a779ccc9082a517757c6fd3.

Also available in: Atom PDF