| Monday, March 12th, 2012, 00:39 UTC | ||
| [00:39:44] | xavierh (xavierh!~chatzilla@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has quit (Remote host closed the connection) | |
| [00:51:37] | tester68 (tester68!~david@host70.16.intrusion.com) has quit (Ping timeout: 246 seconds) | |
| [00:52:08] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [00:52:08] | tester68 (tester68!~david@host70.16.intrusion.com) has joined #mythtv | |
| [00:52:33] | gigem_ (gigem_!~david@host70.16.intrusion.com) has joined #mythtv | |
| [00:52:40] | gigem_ (gigem_!~david@host70.16.intrusion.com) has quit (Changing host) | |
| [00:52:41] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [00:58:26] | tester68 (tester68!~david@host70.16.intrusion.com) has quit (Ping timeout: 246 seconds) | |
| [00:58:47] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Ping timeout: 246 seconds) | |
| [01:16:40] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Operation timed out) | |
| [02:10:56] | stichnot: | What's the best way to do a 'git bisect' over a period of time that involves many schema changes, protocol changes, etc.? |
| [02:34:42] | gigem: | stichnot: i did that just today! start with the earliest version you want to test. create the database and configure myth just how you want it, including doing a full mythfilldatabase, and then make a database backup. now, start your git bisection. if the git bisect chooses a later version to test, simply start mythbackend and let it update your database if needed. if the git bisection chooses a later version to test, then restore your database |
| [02:34:44] | gigem: | backup before starting mythbackend. |
| [02:42:48] | stichnot: | but gigem, I need some of the recordings info from the database for testing. I think what I really want is a patch to disable the schema upgrade test, and hope that there were no "important" schema changes during that period. |
| [03:02:14] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [03:09:21] | stichnot (stichnot!chatzilla@nat/intel/x-egfsaaxhtyyflwvh) has joined #mythtv | |
| [03:09:21] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [03:09:21] | stichnot (stichnot!chatzilla@nat/intel/x-egfsaaxhtyyflwvh) has quit (Changing host) | |
| [03:15:29] | gigem: | stichnot: can't you make your with your earliest version or add them manually? iow, have the information you need in the database before you make the backup. bypassing the upgrade checks will probably work, but there's no guarantee. |
| [03:17:06] | stichnot: | yeah, I think something like that could work. |
| [03:43:06] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [04:07:28] | sphery: | stichnot: compile with --extra-cxxflags='-D IGNORE_SCHEMA_VER_MISMATCH -D IGNORE_PROTO_VER_MISMATCH' (but you should back up first, because any broken pieces are yours to keep :) |
| [04:08:20] | sphery: | gigem's approach is the best one, though... the above throws all caution to the wind and ignores schema/proto version changes (and may actually cause other problems that may invalidate the testing) |
| [04:10:35] | jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has quit (Read error: Operation timed out) | |
| [04:10:51] | sphery: | stichnot: also, remember the qt timer issue that caused increased CPU usage for some users on some distros that caused you to write your MythSignalingTimer patch? Doesn't that sound like the same underlying cause that we never identified could be causing the recording CPU usage issue gigem found ( http://www.gossamer-threads.com/lists/mythtv/dev/508050#508050 ) |
| [04:11:00] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Read error: Operation timed out) | |
| [04:11:22] | jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has joined #mythtv | |
| [04:11:35] | yb0t (yb0t!quassel@nat/nokia/x-qhxusftqqbffrxum) has joined #mythtv | |
| [04:12:03] | stichnot: | sphery: I doubt that's the same issue, as it caused either 7% or 14% CPU usage regardless of the CPU power. |
| [04:12:22] | ybot_ (ybot_!quassel@nat/nokia/x-voutwarmabxvrdai) has quit (Ping timeout: 255 seconds) | |
| [04:12:31] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
| [04:12:45] | stichnot: | I'd go with excessive date/time calculations, assuming gigem's code snippet was executing every frame |
| [04:12:50] | sphery: | right, but that was using one loop and 70/s reads versus X recordings/loops |
| [04:13:13] | stichnot: | these date/time calculations can be very expensive if the right operations aren't in place |
| [04:13:14] | noahric (noahric!~noahric@50.46.147.0) has quit (Quit: noahric) | |
| [04:13:23] | stichnot: | which makes me wonder if a specific version of Qt is also involved |
| [04:13:33] | stichnot: | s/operations/optimizations/ |
| [04:15:00] | sphery: | and I know the older issue was a busy loop (meaning the CPU usage wasn't real and was displaced by any real usage), but it seemed that there was some huge inefficience in Qt's reading of the time--IIRC, someone found that it was spending nearly all its time in the time calls... |
| [04:16:36] | stichnot: | I think I found that the CPU cost was high if TZ was unset or something like that |
| [04:16:52] | stichnot: | gigem indicates the problem in void DTVRecorder::BufferedWrite(const TSPacket &tspacket) |
| [04:17:22] | stichnot: | so date/time calculations once per packet could be much more than once per frame, right? |
| [04:25:50] | sphery: | then again, is DTVRecorder::BufferedWrite(). |
| [04:25:56] | sphery: | only called once per write? |
| [04:26:39] | sphery: | anyway, it just seemed familiar to me--spending too much time on time calls for some people and not others |
| [04:28:29] | mindstormmaster (mindstormmaster!~Adium@c-69-181-45-221.hsd1.ca.comcast.net) has joined #mythtv | |
| [04:29:54] | stichnot: | yeah, the thought did hit me as well |
| [04:31:34] | stichnot: | jya, if you read this, I just saw your -users email saying you plan to look into #10212 this week. I'm pretty sure I have a bunch of recordings with this problem, and I can upload actual samples (not videotapes of the TV) to a site that doesn't demand your personal info to download |
| [04:47:51] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [05:02:18] | tester68 (tester68!~david@160.86.16.70) has joined #mythtv | |
| [05:04:47] | mindstormmaster (mindstormmaster!~Adium@c-69-181-45-221.hsd1.ca.comcast.net) has quit (Quit: Leaving.) | |
| [05:46:02] | noahric (noahric!~noahric@50.46.147.0) has joined #mythtv | |
| [06:27:50] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc) | |
| [06:31:13] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [06:38:01] | Goga777 (Goga777!~Goga777@128-71-200-102.broadband.corbina.ru) has joined #mythtv | |
| [06:55:28] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [07:05:32] | stoffel (stoffel!~quassel@pD9E42AAE.dip.t-dialin.net) has joined #mythtv | |
| [07:13:48] | noahric (noahric!~noahric@50.46.147.0) has quit (Quit: noahric) | |
| [07:15:51] | Goga777 (Goga777!~Goga777@128-71-200-102.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [07:33:17] | warped (warped!~piotro@91.189.74.10) has joined #mythtv | |
| [07:53:10] | warped (warped!~piotro@91.189.74.10) has quit (Quit: warped) | |
| [07:53:31] | Beirdo: | I see the "crashes on info from PBB" is STILL not fixed |
| [07:53:55] | Beirdo: | I'll work on that tomorrow night. This is getting to be too long. |
| [09:05:33] | stuarta: | morning all |
| [09:58:47] | xavierh (xavierh!~xavier@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has joined #mythtv | |
| [10:05:02] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:59] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv | |
| [10:39:10] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 260 seconds) | |
| [11:06:50] | Goga777 (Goga777!~Goga777@128-71-149-206.broadband.corbina.ru) has joined #mythtv | |
| [11:08:19] | joki (joki!~joki@p548642CC.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [11:09:17] | joki (joki!~joki@p54865224.dip.t-dialin.net) has joined #mythtv | |
| [11:29:20] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Ping timeout: 252 seconds) | |
| [12:04:56] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [12:05:18] | gigem_ (gigem_!~david@host70.16.intrusion.com) has joined #mythtv | |
| [12:05:19] | gigem_ (gigem_!~david@host70.16.intrusion.com) has quit (Changing host) | |
| [12:05:19] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [12:35:31] | jya: | stuarta: what xcode / gcc are you using on the buildbot ? |
| [12:36:13] | stuarta: | what's the thing to run that returns the version? |
| [12:36:33] | stuarta: | gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) |
| [12:36:37] | jya: | xcodebuild -version |
| [12:36:41] | jya: | ok.. so not llvm |
| [12:36:53] | stuarta: | Xcode 3.2.6 |
| [12:36:53] | stuarta: | Component versions: DevToolsCore-1809.0; DevToolsSupport-1806.0 |
| [12:36:53] | stuarta: | BuildVersion: 10M2518 |
| [12:37:45] | jya: | I've been chasing why my 64 bits build of 0.24 , I get no video… but I'm starting to think that it's related to llvm.. What's weird is that it works with master just fine.. I wonder what we changed in the past year that would fix that |
| [12:37:51] | jya: | how was Munich? |
| [12:37:59] | stuarta: | beer, food :) |
| [12:38:06] | stuarta: | can't complain |
| [12:44:32] | pclark (pclark!~pclark@193.35.8.5) has joined #mythtv | |
| [12:44:39] | jya: | oh well, it's not gcc vs llvm ; my build using gcc 4.2 give me no video either… wtf.. |
| [12:51:47] | j-rod|afk is now known as j-rod | |
| [12:58:29] | pclark (pclark!~pclark@193.35.8.5) has quit (Read error: Connection reset by peer) | |
| [12:58:31] | pclark_ (pclark_!~pclark@193.35.8.5) has joined #mythtv | |
| [13:02:09] | pclark_ (pclark_!~pclark@193.35.8.5) has quit (Remote host closed the connection) | |
| [13:02:46] | Goga777 (Goga777!~Goga777@128-71-149-206.broadband.corbina.ru) has quit (Read error: Operation timed out) | |
| [13:16:48] | Goga777 (Goga777!~Goga777@128-71-149-206.broadband.corbina.ru) has joined #mythtv | |
| [13:19:38] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:19:59] | pclark (pclark!~pclark@193.35.11.116) has joined #mythtv | |
| [13:31:14] | pclark_ (pclark_!~pclark@193.35.8.5) has joined #mythtv | |
| [13:31:22] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:33:35] | pclark (pclark!~pclark@193.35.11.116) has quit (Ping timeout: 260 seconds) | |
| [13:49:56] | stichnot (stichnot!chatzilla@nat/intel/x-ltwafpdopqmsbavl) has joined #mythtv | |
| [13:49:56] | stichnot (stichnot!chatzilla@nat/intel/x-ltwafpdopqmsbavl) has quit (Changing host) | |
| [13:49:57] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [14:09:41] | pclark_ (pclark_!~pclark@193.35.8.5) has quit (Remote host closed the connection) | |
| [14:12:52] | pclark (pclark!~pclark@193.35.8.5) has joined #mythtv | |
| [14:35:44] | pclark (pclark!~pclark@193.35.8.5) has quit (Remote host closed the connection) | |
| [14:39:31] | pclark (pclark!~pclark@193.35.8.5) has joined #mythtv | |
| [14:47:00] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [15:00:07] | pclark (pclark!~pclark@193.35.8.5) has quit (Remote host closed the connection) | |
| [15:19:10] | pclark (pclark!~pclark@193.35.11.116) has joined #mythtv | |
| [15:29:45] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [15:31:13] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds) | |
| [15:34:08] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 246 seconds) | |
| [15:38:24] | pclark (pclark!~pclark@193.35.11.116) has quit (Read error: Operation timed out) | |
| [15:42:20] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [15:43:01] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Client Quit) | |
| [15:43:25] | pclark (pclark!~pclark@193.35.11.125) has joined #mythtv | |
| [15:45:53] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [16:03:18] | pclark (pclark!~pclark@193.35.11.125) has quit (Remote host closed the connection) | |
| [16:06:19] | pclark (pclark!~pclark@193.35.11.125) has joined #mythtv | |
| [16:09:10] | pclark (pclark!~pclark@193.35.11.125) has quit (Remote host closed the connection) | |
| [16:11:05] | pclark (pclark!~pclark@193.35.11.125) has joined #mythtv | |
| [16:12:01] | pclark (pclark!~pclark@193.35.11.125) has quit (Remote host closed the connection) | |
| [16:14:12] | rsiebert (rsiebert!~quassel@g225048116.adsl.alicedsl.de) has joined #mythtv | |
| [16:14:44] | rsiebert_ (rsiebert_!~quassel@g225063092.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds) | |
| [16:14:51] | pclark (pclark!~pclark@193.35.11.125) has joined #mythtv | |
| [16:16:52] | stichnot (stichnot!chatzilla@nat/intel/x-vqfebtikvvnotezj) has joined #mythtv | |
| [16:16:52] | stichnot (stichnot!chatzilla@nat/intel/x-vqfebtikvvnotezj) has quit (Changing host) | |
| [16:16:53] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [16:22:48] | stichnot: | danielk22: re #10212. I'm seeing that in the problematic recordings, ringbuffer.cpp safe_read() logging is always reporting 2KB reads, and the playback stats OSD shows the available buffer at 0%, hence the stuttering. |
| [16:23:37] | stichnot: | The recordings are transcoded to mp4 in the .nuv container, so I guess maybe the bitrate estimation is going wrong. |
| [16:30:54] | danielk22: | stichnot: The bitrate estimation on non-mpeg-2 stuff from avlib has always been a bit wonky, but we should have some hacks to deal with that. |
| [16:31:16] | pclark (pclark!~pclark@193.35.11.125) has quit (Remote host closed the connection) | |
| [16:34:12] | pclark (pclark!~pclark@193.35.11.125) has joined #mythtv | |
| [16:48:33] | stichnot: | danielk22: this may be the issue: "ringbuffer.cpp:284 (UpdateRawBitrate) RingBuf(myth://Videos@192.168.0.205:6543/cctest/sample.nuv): UpdateRawBitrate(0Kb)" followed by "(UpdateRawBitrate) RingBuf(myth://Videos@192.168.0.205:6543/cctest/sample.nuv): Bitrate too low – setting to 64Kb" |
| [16:50:39] | danielk22: | 8000 bytes per second is pretty darn low... but we should scale up the bitrate based on the actual bitrate pretty quickly.. way before we start video playback.. |
| [16:51:43] | wagnerrp: | danielk22: thanks for the explination... to be honest, i have exactly zero practical experience in having to deal with performance issues surrounding context switching |
| [16:52:47] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [16:54:57] | stichnot: | The next (and final) CalcReadAheadThresh log is "ringbuffer.cpp:394 (CalcReadAheadThresh) RingBuf(myth://Videos@192.168.0.205:6543/cctest/sample.nuv): CalcReadAheadThresh(64 Kb)#012#011#011#011 -> threshhold(7168 KB) min read(32 KB) blk size(2 KB)" |
| [16:55:39] | danielk22: | wagnerrp: It really only matters inside the tightest of loops.. this is one of the few dozen functions in all of mythtv where it matters. |
| [16:56:10] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 260 seconds) | |
| [16:57:07] | stichnot: | then lots of 2KB reads happen while playback is initializing, followed by frequent "Waiting for video buffers..." while 2KB safe_read calls continue going on |
| [16:59:57] | pclark (pclark!~pclark@193.35.11.125) has quit (Remote host closed the connection) | |
| [17:00:41] | cattelan_away (cattelan_away!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has joined #mythtv | |
| [17:06:00] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [17:06:25] | gigem_ (gigem_!~david@host70.16.intrusion.com) has joined #mythtv | |
| [17:06:25] | gigem_ (gigem_!~david@host70.16.intrusion.com) has quit (Changing host) | |
| [17:06:25] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [17:07:48] | pclark (pclark!~pclark@193.35.11.125) has joined #mythtv | |
| [17:13:34] | warped (warped!~piotro@91.189.74.10) has joined #mythtv | |
| [17:27:51] | j-rod: | mrand: patch for that device sent upstream |
| [17:29:40] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [17:30:13] | stichnot: | danielk22: nuppeldecoder.cpp:598 sets bitrate=0. If I change that to something more reasonable like 8000, the problem goes away. Is that an acceptable fix? |
| [17:41:22] | stichnot: | danielk22: My guess is, whatever mechanisms allowed bitrate=0 to work originally, were sidelined as a result of the low-bitrate optimizations associated with commits listed in #9824. |
| [17:43:37] | noahric (noahric!~noahric@74.125.59.74) has joined #mythtv | |
| [17:44:13] | Beirdo: | stichnot: wouldn't surprise me one bit. Don't we know what bitrate we are recording to? (playing catch-up here) |
| [17:45:00] | kenni (kenni!~kenni@port649.ds1-ly.adsl.cybercity.dk) has joined #mythtv | |
| [17:45:00] | kenni (kenni!~kenni@port649.ds1-ly.adsl.cybercity.dk) has quit (Changing host) | |
| [17:45:00] | kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv | |
| [17:45:58] | stichnot: | Beirdo: I would think so, but then nuppeldecoder.cpp goes and sets it to 0. |
| [17:48:26] | Beirdo: | I'm sure there was a historical reason for it, but what you are proposing sounds reasonable to me. Let's see what danielk thinks though. It was his code at one point at least, so may have a better recollection. |
| [17:49:44] | stichnot: | yep, I'm not touching this without having Daniel to blame :) |
| [17:51:08] | stichnot: | fwiw, my transcoded recordings that show the problem have a bitrate of about 1500 Kb/s |
| [17:54:07] | danielk22: | stichnot: Yeah, acceptable fix. I think your probably right about the source of the problem too. |
| [17:54:47] | danielk22: | nuppeldecoder.cpp predates my involvement in the project.. :) |
| [17:55:16] | Beirdo: | wow. I thought you'd dabbled in that one :) my bad |
| [17:55:34] | stichnot: | danielk22: I can check that in tonight after I have a chance to observe it on the TV screen. |
| [17:59:15] | pclark (pclark!~pclark@193.35.11.125) has quit (Remote host closed the connection) | |
| [18:00:56] | Beirdo: | oooh, yay. meetings. |
| [18:02:31] | Anduin (Anduin!~awithers@cpe-67-244-130-50.rochester.res.rr.com) has joined #mythtv | |
| [18:02:39] | Anduin (Anduin!~awithers@cpe-67-244-130-50.rochester.res.rr.com) has quit (Changing host) | |
| [18:02:40] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has joined #mythtv | |
| [18:04:25] | stoffel (stoffel!~quassel@pD9E42AAE.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [18:28:18] | tester68 (tester68!~david@160.86.16.70) has quit (Quit: WeeChat 0.3.7) | |
| [18:29:33] | tester68 (tester68!~david@pool-71-170-160-242.dllstx.fios.verizon.net) has joined #mythtv | |
| [18:29:55] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Quit: Konversation terminated!) | |
| [19:00:11] | taylorr: | j-rod: still no response from Mauro... I officially give up! |
| [19:01:23] | j-rod: | was out sick the end of last week, haven't pinged him again myself |
| [19:02:01] | taylorr: | j-rod: no worries, I was just hoping you wouldn't need to |
| [19:02:01] | j-rod: | but yeah. ugh. |
| [19:03:04] | taylorr: | been sick too, hard to avoid when you little ones stick their hands in you mouth or eyes and wipe their noses on your shirt :) |
| [19:03:29] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Ping timeout: 252 seconds) | |
| [19:04:36] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [19:05:21] | stuartm: | danielk22: CPU usage is still high following 2f6c4eec, maybe not as high as it was, but I'm seeing 21% for a 2.5Ghz X2 with just one recording in progress, I'd expect that to be at or below 10% iirc around 8% normally |
| [19:06:08] | j-rod: | taylorr: yup, I think I got it from my daughter, as it happens |
| [19:06:57] | stuartm: | danielk22: in fact my 'production' box running 0.24-fixes uses just 8% and that's a slower 2Ghz CPU |
| [19:07:37] | danielk22: | stuartm: I'm seeing 15% with three HDHomeRun recordings. It seems a lot of the problems reported are with AMD chips.. are AMD cpu's really that much slower? |
| [19:07:58] | highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 245 seconds) | |
| [19:08:30] | noahric (noahric!~noahric@74.125.59.74) has quit (Quit: noahric) | |
| [19:09:49] | stuartm: | I really don't know how they are supposed to stack up against Intel's CPUs, price and not performance was made me choose these CPUs at the time |
| [19:10:07] | highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv | |
| [19:10:50] | stuartm: | I haven't got any Intel boxes to compare against |
| [19:13:16] | davide: | stuartm, danielk22: my cpu usage is back to normal, i.e. what it was with 0.24. fwiw, all my systems are intel. |
| [19:15:30] | wagnerrp: | danielk22: clock-for-clock, the Stars (Ath II, Phenom II) are typically 5–10% slower than the nehalem chips, and maybe 15–20% slower than SB |
| [19:16:04] | danielk22: | From some random googling it looks like the i5 architecture is about 20% faster per clock cycle than Phenom II, which doesn't seem enough to explain the different. |
| [19:17:07] | wagnerrp: | perhaps older UDP vs. newer RTP firmwares? |
| [19:17:15] | wagnerrp: | im still running august 2010 |
| [19:17:52] | wagnerrp: | (i actually didnt know there was a significant operational difference until a few days ago) |
| [19:18:17] | danielk22: | wagnerrp: Nah, I don't think that was really relevant. |
| [19:18:55] | wagnerrp: | didnt know if the older mode caused that loop to cycle more frequently |
| [19:19:01] | stuartm: | fwiw, with 0.24 two recordings uses around 14%, i.e. some of that 8% is spent doing things other than recording |
| [19:19:03] | wagnerrp: | (causing higher load) |
| [19:19:40] | stuartm: | with 0.25 it only climbs to 27% for two recordings, which is odd |
| [19:20:30] | stuartm: | danielk22: oh, could the difference between my machine and yours have anything to do with frequency scaling? At those low loads my CPU is only running at 1Ghz |
| [19:20:36] | wagnerrp: | ive recorded four shows at a time in multiple instances since late last year |
| [19:20:58] | wagnerrp: | and have not noticed any corrupted recordings |
| [19:21:27] | danielk22: | stuartm: hehe, yes. if frequency scaling is turned on then the numbers won't scale. |
| [19:21:35] | stuartm: | wagnerrp: same here, but I wouldn't have noticed the additional load, I don't sit watching top and unlike the IP based recorders the higher load doesn't seem to affect DVB recorders |
| [19:22:26] | danielk22: | stuartm: can you compare the 0.24 and 0.25 cpu usage with frequency scaling disabled? |
| [19:22:33] | stuartm: | meaning no corrupted recordings and no reason to suspect anything was wrong, until today |
| [19:22:44] | wagnerrp: | looks like my chip idles all the way down to 800MHz, from 3300MHz |
| [19:22:51] | wagnerrp: | with intermediates at 2600 and 2200 |
| [19:22:52] | danielk22: | I really don't expect much difference. |
| [19:22:58] | warped (warped!~piotro@91.189.74.10) has quit (Quit: warped) | |
| [19:23:53] | stuartm: | danielk22: 8% with 0.24 (2Ghz), 12% with 0.25 (2.5Ghz) |
| [19:24:13] | warped (warped!~piotro@91.189.74.10) has joined #mythtv | |
| [19:24:14] | stuartm: | so still higher, even ignoring the difference in clock speed between those two machines |
| [19:24:38] | stuartm: | both are recording two programmes |
| [19:24:44] | danielk22: | stuartm: ok, I'll do a profile and see if anything turns up. |
| [19:25:10] | wagnerrp: | yeah, but maybe 50% higher on what is limited requirements in the first place |
| [19:27:27] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [19:33:50] | danielk22: | So far oprofile is saying 84% of the CPU time is spent in the kernel.. |
| [19:34:53] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [19:46:59] | kenni: | stuartm: I don't get any results with the two queries you wrote: http://pastebin.com/raw.php?i=8chJFt50 |
| [19:47:53] | stuartm: | kenni: which of those are the 0-byte recordings? |
| [19:48:03] | kenni: | let me check |
| [19:48:30] | stuartm: | actually, it doesn't really matter, let me check something |
| [19:50:06] | davide: | Beirdo: please correct me if i'm wrong, and i hope i am. the default loglevel is info and the default verbose filter is general, so i only get VB_GENERAL LOGs that are LOG_INFO or higher. more importantly, i don't get LOGs from anything other than VB_GENERAL even if they are at LOG_EMERG! that doesn't seem right. there should be a way to get LOGs from any subsystem that are at a significant loglevel, say LOG_ERR, unless they are eplicitly turned |
| [19:50:08] | davide: | off. |
| [19:50:16] | kenni: | it's all of the early ones with matching names |
| [19:50:16] | davide: | note that i'm not blaming you — it appears to be a fallout from the original VERBOSE logging. this is probably why some LOG_ERR messages use VB_GENERAL instead their normal, VB_ subsystem. that still leaves some 500 or so LOGs at loglevel LOG_ERR or higher that don't get logged in the default or typical configuration. |
| [19:50:34] | stuartm: | danielk22: the zero byte recordings kenni reported have a start and endtime which is identical to the actual recording, the zero byte recordings should have a very short time but it seems like it's getting screwed up because we key off the startime/chanid when updating the endtime |
| [19:50:38] | Beirdo: | that is correct. That's exactly how it works |
| [19:51:43] | Beirdo: | We'll have to consider how to do it differently, but yes, the VB mask currently trumps the LOG_ level |
| [19:52:48] | danielk22: | stuartm: Hmmm, RecordingInfo::StartRecording() should be incrementing recstartts so they don't end up with the same recstarttime.. |
| [19:53:10] | danielk22: | s/StartR/StartedR/ |
| [19:53:18] | davide: | i was thinking of just having another loglevel that always applies to everything. so, for example, --allloglevel err would mean we always log everything at err or higher regarless of the filter. |
| [19:53:33] | stuartm: | sorry, I'm blind, the second component for those recordings _is_ different, but the endtime is identical |
| [19:54:13] | Beirdo: | davide: yeah, that sounds reasonable. Would take a wee bit of work, and set the default at ERR, sounds good |
| [19:54:24] | stuartm: | kenni: ok, so there is a bug there, we expire short livetv recordings using the endtime – starttime, but here weh ave an endtime which doesn't reflect when the recording actually ended |
| [19:54:26] | Beirdo: | another thing to add to logging after release :) |
| [19:54:51] | danielk22: | stuartm: ok, then we are not updating the end time of the dummy recordings, I can see that as an unintended fallout from some refactoring... |
| [19:56:21] | danielk22: | kenni: Can you create a ticket with this info? |
| [19:56:22] | davide: | Beirdo: great. the reason this has came up is i have a very intermittent problem with my ceton card. i can't run with -v record because it sometimes causes corrupted recordings, but i'd still like to get the VB_RECORD/LOG_ERR messages. |
| [19:57:01] | Beirdo: | makes sense. We'll likely need to cleanup the LOG_ levels again doing this, but that's fine |
| [19:57:52] | kenni: | danielk22: Sure, I'll create one. |
| [19:58:00] | noahric (noahric!~noahric@74.125.59.74) has joined #mythtv | |
| [19:58:02] | kenni: | stuartm: Thanks for the help |
| [19:58:04] | kenni: | :) |
| [20:03:11] | kenni: | danielk22/stuartm: Re: "ok, then we are not updating the end time of the dummy recordings" – The endtime of the real live tv recordings doesn't get updated either (see pastebin above) – is this by design or perhaps even the real cause of the issue? |
| [20:04:29] | stuartm: | kenni: were those recordings exited normally? or did the backend crash? |
| [20:05:14] | kenni: | normally, those recordings are from one live TV session with 4 channel changes |
| [20:05:43] | stuartm: | kenni: ok, just checking :) |
| [20:07:01] | xavierh (xavierh!~xavier@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has quit (Remote host closed the connection) | |
| [20:08:19] | danielk22: | kenni: both end times should get updated. That is the recendts not the endts should be updated. |
| [20:10:14] | stuartm: | kenni: yeah, just out of interest, what does progend say for those? That should be the programme end time according to the guide data, if endtime isn't being updated then it should be identical to progend |
| [20:14:02] | kenni: | stuartm: progend is identical to endtime on all dummy and real live tv recordings |
| [20:14:44] | stuartm: | kenni: ok, thanks for checking |
| [20:26:59] | SteveGoodey (SteveGoodey!~steve@host86-149-7-150.range86-149.btcentralplus.com) has joined #mythtv | |
| [20:33:52] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [20:35:54] | Yancho (Yancho!~mpulis@unaffiliated/yancho) has quit (Ping timeout: 260 seconds) | |
| [20:50:02] | j-rod is now known as j-rod|afk | |
| [20:50:07] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [20:51:09] | danielk22: | stuartm: wagnerrp: It looks like most of the CPU is spent in ff_find_start_code 30% followed by 12% in HttpStatus::PrintMachineInfo(). |
| [20:52:03] | SteveGoodey (SteveGoodey!~steve@host86-149-7-150.range86-149.btcentralplus.com) has quit (Remote host closed the connection) | |
| [20:52:05] | stuartm: | hmm, that last one sounds odd |
| [20:54:52] | stuartm: | how is that getting called during recording? |
| [20:55:26] | danielk22: | stuartm: dunno, I just added logging to it so I can see how often it is called.. |
| [20:56:58] | ben1066 (ben1066!~quassel@unaffiliated/ben1066) has joined #mythtv | |
| [20:58:12] | danielk22: | Actually not using much CPU.. it's just in an odd place in the callgraph. |
| [21:00:29] | danielk22: | The next thing after ff_find_start_code is 11% libQtCore, followed by 6.7% memcpy, 5.2% wordcopy, 3.4% DTVRecorder::BufferedWrite(). |
| [21:03:01] | danielk22: | This is after a local only change to reduce the number of calls to StreamHandler::UpdateFiltersFromStreamData() which was consuming about 10% CPU and now consumes <1%. Still this does not account for any significant changes from 0.24. |
| [21:06:45] | pclark (pclark!~pclark@host86-141-244-167.range86-141.btcentralplus.com) has joined #mythtv | |
| [21:08:04] | taylorr: | jpabq_: when you get a chance could you tell me what your GPU temp is on your GT430 when running 1080i for a while? command is nvidia-settings -q GPUCoreTemp|grep Attribute |
| [21:08:58] | stuartm: | I can try profiling, I'll need to read up on it though, I've only used oprofile once before, some years ago |
| [21:14:51] | pclark (pclark!~pclark@host86-141-244-167.range86-141.btcentralplus.com) has quit (Remote host closed the connection) | |
| [21:17:36] | pclark (pclark!~pclark@host86-141-244-167.range86-141.btcentralplus.com) has joined #mythtv | |
| [21:19:00] | danielk22: | stuartm: It might be interesting, but I really don't think it is CPU usage that is the culprit for any problems post [2f6c4eec]. With the performance governor I'm seeing CPU usage of 9% for two HD and one SD recording. |
| [21:21:33] | stuartm: | yeah, I'm not seeing any problems aside from higher than usual cpu usage and that's not a critical bug on it's own |
| [21:22:22] | stuartm: | I was just prompted to look at the cpu usage because the subject had come up |
| [21:23:16] | MythBuild: | build #2108 of master-linux-ppc is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2108 blamelist: Daniel Thor Kristjansson <danielk@cuymedia.net > |
| [21:23:58] | warped (warped!~piotro@91.189.74.10) has quit (Quit: warped) | |
| [21:43:03] | xavierh (xavierh!~chatzilla@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has joined #mythtv | |
| [21:43:09] | skrock (skrock!~martin@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv | |
| [21:43:10] | pclark (pclark!~pclark@host86-141-244-167.range86-141.btcentralplus.com) has quit (Remote host closed the connection) | |
| [21:46:32] | danielk22: | Beirdo: The ppc build error doesn't make any sense, there is no ` on line 84 of mpegutls.cpp... |
| [21:49:38] | Beirdo: | one sec |
| [21:50:03] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 245 seconds) | |
| [21:52:08] | Beirdo: | that does seem borked |
| [21:52:10] | Beirdo: | hmm |
| [21:52:19] | Beirdo: | MythBuild: force build master-linux-ppc |
| [21:52:20] | MythBuild: | build forced [ETA 13m36s] |
| [21:52:20] | MythBuild: | I'll give a shout when the build finishes |
| [21:52:36] | Beirdo: | maybe it had an internal burp, let's see if it repeats |
| [21:56:13] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [21:57:09] | ** stuarta offers the ppc build a cup of tea ** | |
| [21:57:28] | MythBuild: | build #2109 of master-linux-ppc is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2109 |
| [22:00:45] | stuarta: | Beirdo: i think you need to hit your mingw build slave too |
| [22:01:41] | Beirdo: | hehe, so I do |
| [22:01:43] | Beirdo: | one moment |
| [22:02:16] | skrock (skrock!~martin@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.7) | |
| [22:02:27] | skrock (skrock!~martin@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv | |
| [22:05:27] | Beirdo: | and we wait for windows to reboot |
| [22:08:39] | Beirdo: | there we go. |
| [22:08:48] | Beirdo: | I should put an email notification on that one |
| [22:09:06] | Beirdo: | if it goes down, automatically email me so I can kick it. |
| [22:33:06] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 244 seconds) | |
| [22:35:39] | skrock (skrock!~martin@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.7) | |
| [22:41:30] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [22:41:43] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [22:46:55] | dekarl (dekarl!~dekarl@dslb-084-058-159-001.pools.arcor-ip.net) has left #mythtv () | |
| [22:50:04] | zombor (zombor!~zombor_@65.29.231.135) has joined #mythtv | |
| [22:50:05] | zombor (zombor!~zombor_@65.29.231.135) has quit (Changing host) | |
| [22:50:05] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [23:15:49] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer) | |
| [23:39:39] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 260 seconds) | |
| [23:52:02] | Goga777 (Goga777!~Goga777@128-71-149-206.broadband.corbina.ru) has quit (Ping timeout: 244 seconds) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.