| Wednesday, January 2nd, 2013, 00:32 UTC | ||
| [00:32:52] | zoran119_ (zoran119_!~zoran@ppp121-44-176-13.lns20.syd7.internode.on.net) has quit (Quit: leaving) | |
| [00:43:35] | joki (joki!~joki@p54865A26.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [00:43:36] | IReboot (IReboot!~doug@CPEc8be1961e24d-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [00:43:53] | joki- (joki-!~joki@p54865A9A.dip.t-dialin.net) has joined #mythtv | |
| [00:44:01] | joki- is now known as joki | |
| [01:28:48] | IReboot (IReboot!~doug@CPEc8be1961e24d-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [01:39:18] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [02:16:20] | SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has joined #mythtv | |
| [02:30:44] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:09:11] | zombor (zombor!~zombor__@65.29.231.135) has joined #mythtv | |
| [03:09:11] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [03:09:11] | zombor (zombor!~zombor__@65.29.231.135) has quit (Changing host) | |
| [04:27:11] | jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 255 seconds) | |
| [04:32:59] | gigem: | stichnot: I noticed a couple of issues with the new timing code tonight while watching a program as it records. The program in questions is primarily progressive, 60fps with occasional interlaced, 30fps commercials. I'll recheck the issues when the recording finishes. |
| [04:33:05] | gigem: | 1. The current position appears correct in all conditions. The total recorded time is correct in progessive sections, but is off in interlaced sections. For example, at the 1:05:00 of 2:00:00 point, the OSD shows 1:05:00 of 2:20:00 and at the 1:05:00 of 2:40:00 point, it shows 1:05:00 of 2:43:00. |
| [04:33:08] | gigem: | 2. While paused, pressing FFWDSTICKY and RWNDSTICKY move 1 frame forward or backward, respectively. They are supposed to move 1 second. RIGHT and LEFT do correctly move 1 frame. |
| [04:40:03] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 276 seconds) | |
| [04:44:25] | jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [04:45:33] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [04:48:31] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 244 seconds) | |
| [04:49:36] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:53:33] | sraue_ (sraue_!~stephan@91-115-20-153.adsl.highway.telekom.at) has joined #mythtv | |
| [05:05:15] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit) | |
| [05:21:53] | stichnot: | gigem: Thanks for checking. For the second issue, do you know if the FFWDSTICKY/RWNDSTICKY seek behavior is a regression with my commit, versus a regression from some older commit? |
| [05:23:22] | stichnot: | gigem: For the first issue, I'll try to reason it out from the code, but what would also help is logs with -v playback,network --loglevel verbose. |
| [05:27:17] | Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has joined #mythtv | |
| [05:50:37] | gigem: | stichnot: I only took a quick glance, but I think the regression is in your new commit. Take a look at the change to TV::SeekHandleAction(). I'll see if I can capture the requested log now. |
| [05:59:11] | stichnot: | gigem: I see what you mean about TV::SeekHandleAction. Apparently I don't seek much while paused. :) |
| [06:05:46] | stichnot: | gigem: I see in tv_play.cpp: REG_KEY("TV Playback", "FFWDSTICKY", QT_TRANSLATE_NOOP("MythControls", "Fast Forward (Sticky) or Forward one frame while paused"), ">,."); Did I accidentally fix a bug? :) |
| [06:25:50] | gigem: | stichnot: I just mailed you the log. No, I think you found an old, documentation bug! :) |
| [06:27:27] | stichnot: | got the log, thanks. I'll look through it tomorrow, and fix the seek-while-paused behavior. |
| [06:35:19] | stichnot: | When you want to display the timestamp for a frame, and the target frame is beyond the end of the currently loaded duration map, it extrapolates based on the last duration map entry and the "current" frame rate (which is probably the frame rate at the point of playback, not at the point of the target frame). Regardless, this approximation should normally be OK if the frame count is only... |
| [06:35:21] | stichnot: | ...slightly ahead of the duration map. My guess is that I also need to force a seektable update from the DB/encoder when displaying timestamps, not just when seeking. |
| [06:39:07] | rsiebert_ (rsiebert_!~quassel@g225056035.adsl.alicedsl.de) has joined #mythtv | |
| [06:42:13] | rsiebert (rsiebert!~quassel@g225062133.adsl.alicedsl.de) has quit (Ping timeout: 245 seconds) | |
| [06:44:41] | Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [07:09:38] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [08:46:17] | stoffel (stoffel!~quassel@pD9E43DF3.dip.t-dialin.net) has joined #mythtv | |
| [09:02:26] | dekarl1: | gigem, does that look sane? http://paste.ubuntu.com/1487450/ <- reschedule less often for active scan and restrict it to the current video source (with copy'n'pasted QMutexLocker stuff, I'm not into multithreading) |
| [09:02:31] | dekarl1 is now known as dekarl | |
| [09:23:44] | Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has joined #mythtv | |
| [09:44:12] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [09:54:40] | dekarl: | quick unscientific test looks promising http://paste.ubuntu.com/1487523/ but thats with a buggy database (3 sources, 1 dvbt, 1 iptv, 1 buggy with lots of data due to running mfdb with xmltv but without matching channel, resulting in heaps of channels created :/ ) |
| [09:55:11] | dekarl: | but it shows that the restriction to one source work |
| [10:43:13] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [10:55:35] | sraue_ is now known as sraue | |
| [10:55:39] | sraue (sraue!~stephan@91-115-20-153.adsl.highway.telekom.at) has quit (Changing host) | |
| [10:55:40] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [10:59:40] | dekarl: | channel count per video source to illustrate "heaps of channels" http://paste.ubuntu.com/1487623/ |
| [11:00:00] | dekarl: | I had to manualy abort mfdb |
| [11:46:45] | Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has quit (Ping timeout: 255 seconds) | |
| [11:48:12] | stoffel (stoffel!~quassel@pD9E43DF3.dip.t-dialin.net) has quit (Ping timeout: 264 seconds) | |
| [11:50:10] | zombor (zombor!~zombor__@65.29.231.135) has joined #mythtv | |
| [11:50:10] | zombor (zombor!~zombor__@65.29.231.135) has quit (Changing host) | |
| [11:50:10] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [11:54:05] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [12:02:14] | dmfrey (dmfrey!~dmfrey@64-121-93-243.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has quit (Quit: Ex-Chat) | |
| [12:29:59] | stoffel (stoffel!~quassel@pD9E43DF3.dip.t-dialin.net) has joined #mythtv | |
| [12:55:32] | IReboot (IReboot!~doug@CPEc8be1961e24d-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [12:58:57] | IReboot (IReboot!~doug@CPEc8be1961e24d-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [13:18:45] | stoffel (stoffel!~quassel@pD9E43DF3.dip.t-dialin.net) has quit (Ping timeout: 276 seconds) | |
| [13:46:19] | stoffel (stoffel!~quassel@pD9E43DF3.dip.t-dialin.net) has joined #mythtv | |
| [13:51:49] | stoffel (stoffel!~quassel@pD9E43DF3.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [14:00:53] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [14:04:36] | stichnot: | danielk22 (and anyone else): How concerned are we about supporting new recordings from recorders that do not derive from the DTVRecorder class? (i.e. framegrabbers, I believe) |
| [14:05:52] | stichnot: | In particular, I want to know if I should worry about potential performance issues when displaying position/duration during Live TV or in-progress recordings from such recorders. |
| [14:06:26] | Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has joined #mythtv | |
| [14:08:50] | peper03 (peper03!~peper03@port-92-203-45-224.dynamic.qsc.de) has joined #mythtv | |
| [14:13:41] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [14:14:19] | stichnot: | actually, never mind. I just realized I will have this particular issue for all recorders, so I need a proper solution |
| [14:21:08] | zombor (zombor!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv | |
| [14:21:09] | zombor (zombor!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host) | |
| [14:21:09] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [14:30:20] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [14:34:13] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv | |
| [14:35:30] | Seeker`: | how safe is it to upgrade to head right now? Been away for a couple of weeks so not kept up with commits |
| [14:39:30] | dekarl: | Seeker`: I use it in production with a DVB-T setup. HLS Recorder is not working atm, the last ffmpeg resynch fixed teletext, mfdb doesn't like unconnected video sources. |
| [14:41:40] | Seeker`: | I;m running on github from a few weeks ago, so was just wondering if there was any major breakage in the last couple of weeks. Doesn't look like it from trac though |
| [14:56:13] | danielk22: | stichnot: 2% of our user base still have framegrabbers installed in their systems. We were considering dropping support for frame grabbers once CaptainMurdoch's new non-NUV transcoder is ready. So not terribly important that minor things like duration info are 100% correct, but basic playback should work. |
| [15:11:55] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit) | |
| [15:16:17] | stichnot: | danielk22: The issue was that when displaying position/duration, there could be a flurry of continual requests for duration map updates from the encoder, which would never come for a non-DTVRecorder. However, for any in-progress recording, the current frame count will almost always be past the end of the current duration map, and this would also trigger a flurry of futile update requests. |
| [15:16:51] | stichnot: | So I will just throttle such requests to once every 3 seconds and solve both problems. |
| [15:22:06] | IReboot (IReboot!~doug@CPEc8be1961e24d-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Ping timeout: 245 seconds) | |
| [15:23:40] | danielk22: | stichnot: That shouldn't really be much of a problem for framegrabbers since they have a fixed framerate, so the "estimate" will actually be spot on. |
| [15:25:06] | IReboot (IReboot!~doug@CPEc8be1961e24d-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [15:25:31] | stichnot: | danielk22: the problem is that while the OSD is displaying position/duration, there would be several DB queries per second if the recorder has not yet produced any seektable data, likely leading to stuttering on many systems. |
| [15:26:00] | danielk22: | right, i mean the throttling shouldn't have any negative effect on framegrabbers. |
| [15:26:35] | stichnot: | ah, ok. |
| [15:27:03] | Seeker`: | erm, trying to build from github. Mythbackend won't start because the mythbackend ABI version apparently doesn't match the library version. What am I doing wrong? |
| [15:27:06] | stichnot: | All my sources have fixed framerates as well, so I'm relying on gigem for testing :) |
| [15:29:06] | stichnot: | gigem: can you try this patch for fixing duration display for in-progress variable-framerate recordings? http://pastebin.com/z8pcDvwA |
| [15:33:56] | stichnot: | Seeker`: sorry if this is obvious, but did you make distclean on both mythtv and mythplugins? |
| [15:45:30] | Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [15:48:48] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [15:51:38] | Seeker`: | stichnot: I did. Was a different sort of stupid – turns out my backend was using the mythbuntu nightly builds instead. Clearly I've not woken up from the holiday yet. |
| [15:52:34] | stichnot: | :) |
| [16:17:51] | dekarl: | Seeker`: I'm running patched mythbuntu nightlies (building them via what is in packaging/deb). works well |
| [16:24:05] | danielk22: | Anyone else having trouble with "make install" with the latest master on a root squashed NFS mount? |
| [16:26:11] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [16:34:24] | IReboot (IReboot!~doug@CPEc8be1961e24d-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Ping timeout: 264 seconds) | |
| [16:36:36] | Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has joined #mythtv | |
| [16:37:06] | IReboot (IReboot!~doug@CPEc8be1961e24d-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [16:49:02] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [17:03:36] | skd5aner: | Captain_Murdoch: is #11287 something you'd be interested in taking a look at? |
| [17:03:36] | ** MythLogBot http://code.mythtv.org/trac/ticket/11287 ** | |
| [17:04:56] | skd5aner: | seems serious enough to potentially fix for 0.26-fixes, seems a show-stopper for any new users (or people refreshing their lineups) who might have large lineups – which anymore is probably the majority of cable/sat. users |
| [17:11:27] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:16:01] | skd5aner: | !seen jya |
| [17:16:01] | MythLogBot: | jya was last seen 5 days 4 hours 54 minutes 1 second ago |
| [17:21:08] | garybuhrmaster (garybuhrmaster!~gtb@128.3.3.159) has joined #mythtv | |
| [17:24:12] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [17:24:32] | Captain_Murdoch: | skd5aner, Since that's only used by the blocking download methods, I'm wondering if it's OK to just bump that 10 up to 60 by default. |
| [17:26:02] | Sharky-Sleep is now known as Sharky112065 | |
| [17:28:34] | skd5aner: | Captain_Murdoch: yea, what's the worst that could happen at 60 seconds? |
| [17:31:42] | skd5aner: | 45 covered it for me, in my case, but I didn't try to go through and find where the line was from working to not working- I just tried 45 and was happy :) |
| [17:41:18] | stichnot (stichnot!~stichnot@207.198.105.19) has joined #mythtv | |
| [17:41:19] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:41:19] | stichnot (stichnot!~stichnot@207.198.105.19) has quit (Changing host) | |
| [17:44:54] | peper03 (peper03!~peper03@port-92-203-45-224.dynamic.qsc.de) has quit (Quit: Konversation terminated!) | |
| [17:48:18] | gigem: | dekarl: That looks like a nice improvement. Your patch looks fine to me, but danielk22 is the one who should really check it. |
| [17:48:35] | gigem: | stichnot: As I said in email, I'll try your patch this afternoon. |
| [17:49:19] | stichnot: | gigem: thanks. |
| [17:49:58] | superm1: | skd5aner: oh yeah I hit that the other day trying to redo my lineups too. I thought I was going crazy |
| [17:53:42] | IReboot (IReboot!~doug@CPEc8be1961e24d-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Ping timeout: 276 seconds) | |
| [17:59:46] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:95f7:ea10:d50f:f564) has quit (Read error: Connection reset by peer) | |
| [18:09:15] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [18:10:35] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [18:11:29] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [18:11:56] | Mousey: | happy new year! |
| [18:15:56] | Mousey (Mousey!~r0dent_@ross154.net) has quit (Read error: Connection reset by peer) | |
| [18:16:03] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds) | |
| [18:16:25] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [18:22:54] | stichnot (stichnot!stichnot@nat/google/x-xvleixmmbnvelwdn) has joined #mythtv | |
| [18:22:55] | stichnot (stichnot!stichnot@nat/google/x-xvleixmmbnvelwdn) has quit (Changing host) | |
| [18:22:55] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [18:23:03] | dekarl (dekarl!~dekarl@p4FCEE498.dip.t-dialin.net) has quit (Ping timeout: 255 seconds) | |
| [18:27:31] | dekarl (dekarl!~dekarl@p4FCEF7D9.dip.t-dialin.net) has joined #mythtv | |
| [18:43:02] | SteveGoodey (SteveGoodey!~steve@host86-148-172-139.range86-148.btcentralplus.com) has joined #mythtv | |
| [18:49:10] | bas-t: | Just upgraded to master head. Everything seems to be ok, but the log from mythbackend is flooded with this: |
| [18:49:13] | bas-t: | Client speaks protocol version 75 but we speak 77! |
| [18:49:59] | bas-t: | Brand new db |
| [18:55:37] | stuartm: | distclean |
| [18:55:58] | stuartm: | bas-t: your frontend is not running master |
| [18:56:53] | bas-t: | yeah, I realise i left one of them running, my bad! |
| [18:57:22] | bas-t: | fixed that now |
| [18:59:07] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [19:05:44] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit) | |
| [20:04:38] | SteveGoodey (SteveGoodey!~steve@host86-148-172-139.range86-148.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [20:29:42] | Goga777 (Goga777!~Goga777@128-71-66-132.broadband.corbina.ru) has quit (Quit: Leaving) | |
| [20:35:25] | danielk22: | Is there a C++ equivalent of unistd.h ? i.e. is the existence "#include <cunistd>" a POSIX requirement? |
| [20:37:49] | danielk22: | The reason I ask is we have some ::read(), ::write(), ::close() constructs in our code. And C99 API's are supposed to be in the std namespace in C++. But it looks like only fread(), fwrite(), fclose() have an official C++ header. |
| [20:43:51] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [20:57:13] | Mousey (Mousey!~r0dent_@ross154.net) has quit (Quit: Read Error: Connection reset by beer) | |
| [20:59:11] | garybuhrmaster: | danielk22: My c++ is really rusty, but I believe unistd has no equivalent, and I seem to recall that iostream/fstream is the abstraction to avoid unix'isms. Or is that not what you are asking? |
| [21:01:12] | danielk22: | garybuhrmaster: My worry is more that ::read() and friends might disappear from the global namespace. If there isn't a std::read() then this isn't going to happen, if there is a header that puts it in std and we're not using it then it might as cleanup for C++11 progresses. |
| [21:13:01] | gigem: | stichnot: Your patch is better, and while not perfect, is probably good enough for now. I'll leave it up to you, though, whether or not you want to attack this last nit. |
| [21:13:03] | gigem: | The best way to see the last nit is to pause (so the position/duration OSD stays on) in a 30fps section. When this is done, the duration advances at twice the expected rate, probably because the recorder is recording a 60fps section. Then, every few seconds, probably when an update is received from the recorder, the duration jumps back to the correct time. It then advances at twice the rate again until the |
| [21:13:05] | gigem: | next update is received. |
| [21:18:53] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit) | |
| [21:24:21] | garybuhrmaster: | danielk22: Is there some date/version which C++11 compliance will be required? 0.3x? (I have this vague recollection of compiling mythtv with c++0x compliance, and having to submit a few minor patches to get it to compile, but that is far different than using the new features.) |
| [21:25:50] | stichnot: | gigem: that behavior doesn't surprise me, as I suspected the extrapolation would be based on the framerate at the playback position rather than at the current end of the recording. |
| [21:26:31] | stichnot: | One way to address it would be to ask for recorder updates more frequently than the 3 seconds coded in the patch. |
| [21:27:01] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [21:27:20] | stichnot: | I picked 3 seconds based on the 3s value for kOSDTimeout_Short |
| [21:28:55] | stichnot: | Another way would be if I could get framerate updates from the recorder, which would lead to good behavior most of the time, and only funky when the recorder crosses a framerate boundary. |
| [21:30:40] | stichnot: | In any case, I'd prefer to deal with that nit. |
| [21:31:30] | danielk22: | garybuhrmaster: No. I am compiling with c++11 on one of the builders just so we can shake out the problems now rather than trying to do it in a big hurry when some compiler pushes us to be c++11 compliant. |
| [21:32:54] | danielk22: | garybuhrmaster: In general all the compiler writers are implementing C++11 and any code that isn't compliant and worked fine with an old compiler may produce bad code in the future even if the standard is set to c++03. |
| [21:34:24] | danielk22: | I just fixed some code like this "a = b+c / ++b;" today because it threw off a C++11 warning, but the code was always bogus.. |
| [21:35:00] | danielk22: | But now it won't produce the result the programmer wanted even though it did with an earlier gcc. |
| [21:35:17] | jheizer: | eww |
| [21:35:59] | jheizer: | that is just ugly |
| [21:36:02] | danielk22: | jheizer: it was debugging code not normally compiled.. |
| [21:36:44] | jheizer: | assuming it treated ++b as a function so did b+c/(b+1)? |
| [21:37:03] | jheizer: | admit I had to read it a few times |
| [21:37:33] | garybuhrmaster: | danielk22: I think that code deserves a special prize. |
| [21:39:02] | danielk22: | jheizer: Right, the intent was "a = b+c / (b+1); ++b;" which is how I rewrote it. |
| [21:40:20] | jheizer: | I hate when people get "too" lazy |
| [21:44:08] | danielk22: | danielk22: I don't know if I wrote that particular code, but I've been known to do silly things like that myself especially in debugging code. :| |
| [21:44:59] | stichnot: | gigem: well whaddayaknow, QUERY_RECORDER GET_FRAMERATE exists. cool. |
| [21:47:10] | danielk22: | stichnot: probably a left-over from the duration code 3 or 4 generations ago ;] |
| [21:48:16] | stuartm: | interesting, I can see that causing a few problems tbh, it's ugly code sure, but I'm sure I've seen plenty of similar examples relying on pre-increment like that |
| [21:54:14] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat) | |
| [21:59:14] | gigem: | stichnot: Fix as and if you see fit. The new code with your latest patch is a such huge improvement that I'm happy enough. |
| [22:01:10] | stichnot: | gigem: ok, thanks :) |
| [22:02:35] | stichnot: | danielk22: RecorderBase::GetFrameRate() returns video_frame_rate. I think it should return m_frameRate instead. What do you think? |
| [22:06:38] | stichnot: | danielk22: I trust m_frameRate because it is being used to calculate total duration and durations in the duration map. I'm not sure whether video_frame_rate is being used in any meaningful way. |
| [22:11:39] | danielk22: | stichnot: There shouldn't be a m_frameRate + video_frame_rate. They both represent the same info. |
| [22:11:56] | IReboot (IReboot!~doug@CPE001fc65acdff-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [22:12:12] | danielk22: | Beirdo: Do you remember 9ef808914de16deb14f26d37f57b2f65f8cec2e5 ? Why wasn't video_frame_rate used? |
| [22:15:03] | danielk22: | stichnot: I think we should merge the two variables and use that. But maybe there was some reason to keep the two separate. |
| [22:20:02] | stichnot: | danielk22: afaict, video_frame_rate is set to either 25.00 or 29.97 at the beginning of the recording and never changes. I see a potential problem in DTVRecorder::FindAudioKeyframes() which uses video_frame_rate. |
| [22:21:29] | danielk22: | stichnot: right, m_frameRate gets reset to 0 which wouldn't work so well for this code... |
| [22:26:11] | stichnot: | danielk22: for now, I will go ahead and change RecorderBase::GetFrameRate() to return m_frameRate, and look at combining the two fields later. |
| [22:30:32] | danielk22: | makes sense |
| [22:31:34] | danielk22: | Beirdo: I had another question for you. Are things printed to cerr captured by the new logging? I'm wondering where errors reported by libc and other low level libs is ending up these days, especially for memory errors. |
| [22:40:22] | brfransen (brfransen!~brfransen@64.179.141.163) has quit () | |
| [22:48:38] | brfransen (brfransen!~brfransen@64.179.141.163) has joined #mythtv | |
| [22:52:33] | stichnot: | gigem: Here's a new version of the duration patch to try. http://pastebin.com/8W4FaAR0 |
| [22:53:09] | stichnot: | I haven't tested it myself with an in-progress recording yet, but I will later tonight |
| [22:54:40] | stichnot: | You will still likely see an anomaly for ~3 seconds when the recorder changes framerate, but there shouldn't be the constant "pulsating" effect that you see now. |
| [22:57:31] | gigem: | stichnot: I'll give it a whirl shortly. |
| [22:57:35] | gigem: | I need to add some disks (which I already have) to my production backend. Because I'm out of free SATA ports, I'm thinking of building a new system. I had a couple of bad experiences with budget, AMD motherboards a few years ago, so all of my recent builds have been Intel based. I'm considering AMD again for this build because they still appear to have the better bang for the buck. |
| [22:57:37] | stichnot: | I could reduce that 3 seconds, but it would probably mean more stuttering for in-progress framegrabber recordings due to DB accesses, and aren't those people suffering enough already? :) |
| [22:57:38] | gigem: | Does anyone familiar with the current AMD offerings have any advice or recommendations? Upon first glance, it looks like socket FM1/FM2 is the "new" stuff. Is that correct or is socket AM[23]+? still going strong? Also, did they fix the issue where the whole memory subsystem also slowed down when the CPU clock was throttled down? |
| [23:02:09] | jheizer: | Too many sockets/procs to keep up on now a days. Can say my X6 makes a great backend |
| [23:05:29] | skd5aner: | yea, I gave up about 5 years ago following everything too... just changed too rapidly with too many variants and offerings |
| [23:12:59] | gigem: | Yeah, that's why I'm asking! :) I haven't paid any attention at all to AMD and haven't found anything yet to tell me why I might want FM1/2 over AM2/3. |
| [23:14:05] | Chutt: | gigem, they're still releasing stuff on am3+, i thought |
| [23:15:22] | Chutt: | their "high end", though it's just mid-range compared to intel |
| [23:20:20] | stichnot: | gigem: in that patch, I forgot to ignore the framerate from the recorder if it is reported as <=0.0, but that should only happen for framegrabbers. |
| [23:43:40] | garybuhrmaster: | gigem: FM2 is the "new" stuff for the trinity APUs (FM1 is essentially dead). AM3+ is for the bulldozer (and claimed to support the next gen steamroller) parts. |
| [23:46:50] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [23:47:00] | gigem: | Chutt: I know when Intel came out with Core and Core2, you couldn't directly compare clock rates anymore, but I figured AMD had narrowed that gap some by now. It sounds like not. |
| [23:47:04] | gigem: | garybuhrmaster: Thanks. |
| [23:47:09] | garybuhrmaster: | gigem: For long term stability, I still purchase Intel branded motherboards. They do not have all the bells and whistles of some of the enthusiast boards, but they are rock solid. |
| [23:47:14] | gigem: | stichnot: What's a framegrabber? :) |
| [23:50:20] | garybuhrmaster: | gigem: AMD lost the highest performance crown a long time ago, but moved the marketing to the best performance/watt. |
| [23:51:23] | garybuhrmaster: | gigem: AMD is often the best performance / monetary_unit too. |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.