CPU usage increases as a function of time (1 Viewer)

jonesdb

Portal Pro
January 11, 2008
113
6
Santa Clara, CA
United States of America United States of America
Country flag
TV-Server Version: MP/TV Server 1.0 RC2
MediaPortal Version: MP/TV Server 1.0 RC2
MediaPortal Skin: Blue Two
Windows Version: Windows XP Pro SP3
CPU Type: Intel P4 3.2GHz
HDD: Seagate 250GB
Memory: 2 GB
Motherboard: ASUS P5AD2-E_Premium
Video Card: Nvidia GeForce N6600
Video Card Driver: 6.14.11.6375
Sound Card:
Sound Card AC3:
Sound Card Driver:
1. TV Card: AverMedia M780
1. TV Card Type: Analog, ATSC, DVB-C
1. TV Card Driver: 2.5.026
2. TV Card:
2. TV Card Type:
2. TV Card Driver:
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec: MPV
MPEG2 Audio Codec: MPA
h.264 Video Codec: Sonic Cinemaster 4.1
Satelite/CableTV Provider: Comcast
HTPC Case:
Cooling:
Power Supply:
Remote: MCE
TV:
TV - HTPC Connection:

I've noticed that since I moved to RC2 that when I tune to an analog channel that the CPU utilization increases as a function of time (see attached MP1.0 RC2 Analog.gif). I have tried changing to a second analog channel and then to a QAM channel (see attached MP1.0 RC2 Analog2.gif which is a zoom of the latter part of the first gif). After changing to a QAM channel things seem to reset and if I change to an analog channel again the CPU utilization starts all over again at a low level and then climbs. This does not happen on the QAM channels. I thought it might be related to the tuner driver, so I tried the same experiment with Aver MediaCenter. CPU utilization with that program is constant on both QAM and Analog channels. I attempted to isolate the issue by looking at other counters for the TVServer Process and found that I/O write operations and I/O write bytes/sec both show a similar trend to the CPU utilization. I'm happy to run other experiments to try to isolate the issue, but need some ideas on how to isolate further. Any ideas are welcome. This is a single seat setup on under XP Pro SP3. Was doing the same thing under SP2.
 

Attachments

tourettes

Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    Could you check with setuptv.exe if there are multiple timeshiftings ongoing at the same time after changing the channel? Sounds like there could be some issue when stoppping the previous channel's timeshifting. At least the symptoms would point into that direction.
     

    jonesdb

    Portal Pro
    January 11, 2008
    113
    6
    Santa Clara, CA
    United States of America United States of America
    Country flag
    Thanks for the reply and the great work on MP. SetupTV.exe only shows a single (1) timeshift stream during all the testing. (I have experienced the 0001475: Timeshifting not stopped when watching a live recording problem, but it doesn't appear to be related to this issue.) There may be a clue in the fact that the usage and I/O operations increase in discrete steps that appear to take place approximately every 5 minutes. This seems to be quite regular. The steps are more obvious in the I/O operations/sec and I/O bytes/sec plots, but also can be seen in CPU utilization. I/O write operations/sec seems to be increasing approximately 5.25 K write ops/sec at each step and I/O bytes written/sec is increasing approximately 1.22 M bytes/sec at each step. Is there an easy way to narrow down the module that is increasing its write operations?
     

    jonesdb

    Portal Pro
    January 11, 2008
    113
    6
    Santa Clara, CA
    United States of America United States of America
    Country flag
    Increasing CPU usage update

    It looks like the ideas from the forum have dried up on this CPU usage problem, but I have continued to investigate it so here is the update.
    So far I believe that the problem is in mpFileWriter.ax or at the least calling of it from TVService.
    mpFileWriter.ax writes to C:\Documents and Settings\All Users\Application Data\Team MediaPortal\MediaPortal TV Server\timeshiftbuffer\live2-0.ts.tsbuffer every time that MP writes ts data (188 bytes) to C:\Documents and Settings\All Users\Application Data\Team MediaPortal\MediaPortal TV Server\timeshiftbuffer\live2-0.ts.tsbuffer7.ts

    I'm not sure I understand why the xxx.tsbuffer file should be written to every time a 188 byte packet is written to the .tsbufferX.ts file as it always overwrites the file from the beginning (offset 0). So be it, something that I just don't understand at this point. The bytes written to the .tsbuffer file are 8+4+4+264+2+4+4 when timeshifting first starts. Every time the a new .tsbufferX.ts is started (approximately every 5 minutes in my case an additional 264 bytes of data is added to the data being written to the .tsbuffer file. Thus while the second .tsbufferX.ts file is being written the new stream to the .tsbuffer file looks like 8+4+4+264+264+2+4+4. This packet stream increases by 264 bytes with each new .tsbufferX.tx file written.
    As you can see, it doesn't take long before writing to the .tsbuffer file starts taking up a lot of time.
    I have attached TVService problem.txt file that shows what I'm talking about and TVService Stack.txt file (read from bottom to top for the sequence of calls) that shows the stack when the write is being done. Note the time differences in the TVService problem.txt file. The first block is from when I first started timeshifting and the second block is from 33 minutes later when MP was working on the 7th xxx.tsbufferX.ts file.
    I have my timeshift buffer file size set to 256 MB and a max of 20 files.

    Any thoughts? What is the purpose of the xxx.tsbuffer file and why should it be overwritten every time a TS packet is written to the .ts file?

    Any help is appreciated.
     

    Attachments

    elconejito

    Portal Pro
    April 28, 2005
    164
    5
    Falls Church, VA
    United States of America United States of America
    Hey jonesdb, I saw your message on the Stuttering in LiveTV thread (I have a few posts there with logs). I *may* have had the same problem your posting about. I searched high and low in this forum over the last week looking if anyone had similar troubles and I didn't see yours at all :)confused:)

    Long story short, I had occasional stuttering, it got worse as I tried different SVNs and RCs. Finally by last week I was getting 50% CPU just turning on TV. 2 tuners in use brought it up to about 80-90% CPU and TV was unwatchable. Like you, I had no problems with HD (clear QAM also), only analog. Unfortunately, I didn't find anyone else with the problem so I assumed it was something specific to my system. I did a complete re-format and re-install and so far I haven't seen any issues. Admittedly, I've only done light testing so far. I have only setup the analog tuners so far, I haven't had a chance to setup the HD tuners yet.

    I will keep an eye on this and let you know if I see the CPU increase you mention. How long does it take before you notice the increase in CPU?

    The only similarity I see is we are both using AverMedia's M780 (I have 2 installed).
     

    jonesdb

    Portal Pro
    January 11, 2008
    113
    6
    Santa Clara, CA
    United States of America United States of America
    Country flag
    Similar systems ...AverMedia M780 on an XP machine. The amount of time to CPU increase is a function of the number of timeshift files in use and the rate of the data being written. For the default of 250MB files, I was getting a slight increase about every 5 minutes. The CPU usage would get higher and higher until either I switched to a digital channel, turned the TV OFF or the minimum number of timeshift files was reached (7 in my case). At that point TVService was using 50-60% of the CPU. Changing the timeshift buffer file size to 1 GB with 3 files minimum and 5 max has had a big impact .... all positive. CPU usage now does not exceed about 23% no matter how long I leave an analog channel on. (Before the changes it became unwatchable after about 30 minutes unless I switched to QAM and back)
    The issue seems to be in how the xxxx.ts.tsbuffer and the .ts files are written. For analog channels, mpFileWriter.ax writes 188 bytes + overhead to the .ts file and 264*n bytes + overhead to the .tsbuffer files. As described above, the n multiplier is the number of .ts files that have been written. For 7 .ts files this comes to 1848 bytes + overhead being written to the .tsbuffer file for every 188 bytes of MPG data written to the .ts file. A huge overhead. When using the digital tuner TSFileWriter.ax is used to write these files. The process looks to be similar except that each write to the .ts file is 1880 bytes instead of the 188 bytes I see from mpFileWriter.ax, thus even with 7 .ts files the overhead of writing to the .tsbuffer file is about 50% of the total bytes written. For the analog tuner with 7 .ts files the overhead of writing to the .tsbuffer file is about about 90%. I'd like to understand why the two operations are different for digital and analog tuners (maybe only the M780, I don't know yet) and why the different packet size for the mpFileWriter.ax and TSFileWriter.ax. I'll keep you posted as I learn more.
     

    infinite.loop

    Retired Team Member
  • Premium Supporter
  • December 26, 2004
    16,163
    4,133
    127.0.0.1
    Austria Austria
    Country flag
    on my system CPU usage and Ram usage go up and down.
    up when the service is recording/timeshifting/epg grabbing

    after ~14 days my server is now active, it has nearly the same CPU/ram usage as it had at the day i installed RC2.
     

    elconejito

    Portal Pro
    April 28, 2005
    164
    5
    Falls Church, VA
    United States of America United States of America
    This is a pretty interesting conversation :D

    OK, after a few days of off and on testing (I did a complete re-format/re-install last Sunday), I haven't seen the CPU rate increase... and stay increased. Using one analog tuner uses between ~7-13 CPU, using two analog tuners uses between ~13-21% CPU. This is just leaving it on one channel and watching TV. The longest it has been on has been about 2 hours straight (without any channel change or anything else), and the CPU usage fluctuates between those values I listed above. It does "seem" like it creeps up into the upper part of the range, but it doesn't seem to go above those values I listed. I do wonder what causes those fairly wide fluctuations, but it doesn't seem to impact watchability. And at this point... I notice *every* single glitch, pause, stutter, etc.

    I have to note that watching HD (through the digital tuner, clear QAM) takes far less CPU than watching analog SD (through STB via S-Video). Using one or both of the digital tuners doesn't go over 10%. I'd say one tuner uses about 5%, and there is a only a few more % when the 2nd tuner is working. So I do wonder why that would be, as I would expect the HD to be mch more resource intensive.

    @infinityloop - The way to duplicate is to leave it on one analog channel for an extended period of time. for jonesdb, he sees the effects within 30mins, which is somewhat near what I experienced before my re-format/re-install (which I don't see anymore). If you change channels or stop TV, the "problem" resets itself which is why your system may be OK for days and weeks at a time if you keep resetting the "problem". -OR- your system just may not have this issue :) Just out of curiosity, what CPU usage do you get with analog and digital?
     

    infinite.loop

    Retired Team Member
  • Premium Supporter
  • December 26, 2004
    16,163
    4,133
    127.0.0.1
    Austria Austria
    Country flag
    @infinityloop - The way to duplicate is to leave it on one analog channel for an extended period of time.
    no analog broadcast here anymore since more the one year. all dvb now.
    so no analog cards. :(
     

    elconejito

    Portal Pro
    April 28, 2005
    164
    5
    Falls Church, VA
    United States of America United States of America
    Seems like a majority of devs are in countries where analog is not common or even non-existent. An ongoing issue that I don't think will get any better as more and more countries go digital. Sucks for us here as STB are here to stay for the foreseeable future. I guess the only thing we can do is provide logs?
     

    Users Who Are Viewing This Thread (Users: 0, Guests: 1)

    Top Bottom