| Friday, July 29th, 2011, 00:15 UTC | ||
| [00:15:16] | Beirdo: | danielk22: any headway on determining the thread that's knocking the system over for you? |
| [00:16:41] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has joined #mythtv | |
| [00:22:58] | Beirdo: | Well, I'd better jet. I want to get my camera TODAY :) |
| [00:56:59] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Quit: Coyote finally caught me) | |
| [00:57:00] | superm1 (superm1!~superm1@ubuntu/member/superm1) has quit (Quit: Coyote finally caught me) | |
| [00:57:00] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (Quit: Coyote finally caught me) | |
| [01:04:00] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [01:04:16] | superm1 (superm1!~superm1@204.8.45.13) has joined #mythtv | |
| [01:04:17] | superm1 (superm1!~superm1@ubuntu/member/superm1) has joined #mythtv | |
| [01:04:17] | superm1 (superm1!~superm1@204.8.45.13) has quit (Changing host) | |
| [01:04:27] | gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [01:04:27] | gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [01:04:28] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [01:28:50] | davesp (davesp!~davesp@99.43.148.233) has joined #mythtv | |
| [01:39:53] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [01:41:24] | rhpot1991 (rhpot1991!~rhpot1991@204.8.45.13) has joined #mythtv | |
| [01:41:24] | rhpot1991 (rhpot1991!~rhpot1991@204.8.45.13) has quit (Changing host) | |
| [01:41:24] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv | |
| [01:53:21] | zCougar (zCougar!~cougar@2001:67c:32c:600:250:56ff:fe81:5f) has quit (Ping timeout: 260 seconds) | |
| [02:00:18] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [02:03:15] | danielk22: | Beirdo: Not yet.. but it I haven't found a way to reproduce it easily. Most recordings work fine, but sometime in the middle of the night one doesn't. Hence, I'm assuming some kind of race condition. |
| [02:17:44] | Beirdo: | oh those suck the worst |
| [02:22:04] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [02:34:49] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [02:36:56] | tgm4883 (tgm4883!~tgm4883@204.8.45.13) has joined #mythtv | |
| [02:36:56] | tgm4883 (tgm4883!~tgm4883@204.8.45.13) has quit (Changing host) | |
| [02:36:56] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [02:45:05] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [02:56:13] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [03:09:51] | ghoti (ghoti!~paul@scratch.it.ca) has quit (Read error: Connection reset by peer) | |
| [03:09:57] | ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv | |
| [03:19:56] | davesp (davesp!~davesp@99.43.148.233) has quit (Quit: Leaving) | |
| [03:25:58] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [04:03:58] | bill6502 (bill6502!~bill6502@2002:cdb2:1a2b:7cd3:9ef4:32ea:c6ea:200) has left #mythtv () | |
| [04:08:41] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has quit (Ping timeout: 260 seconds) | |
| [04:11:57] | Goga777 (Goga777!~Goga777@shpd-92-101-143-188.vologda.ru) has joined #mythtv | |
| [04:33:29] | Goga777 (Goga777!~Goga777@shpd-92-101-143-188.vologda.ru) has quit (Remote host closed the connection) | |
| [04:34:56] | ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has quit (Read error: Connection reset by peer) | |
| [04:36:09] | ThisNewGuy (ThisNewGuy!~doug@pool-98-109-19-98.nwrknj.fios.verizon.net) has joined #mythtv | |
| [05:02:19] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has quit (Read error: Connection reset by peer) | |
| [05:02:19] | Goga777 (Goga777!~Goga777@shpd-92-101-143-188.vologda.ru) has joined #mythtv | |
| [05:02:36] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has joined #mythtv | |
| [05:03:50] | swerve (swerve!~swerve@cpe-72-226-86-206.nycap.res.rr.com) has quit (Ping timeout: 250 seconds) | |
| [05:04:35] | jpabq_ (jpabq_!~abqjp@71-37-153-77.albq.qwest.net) has joined #mythtv | |
| [05:04:35] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has quit (Read error: Connection reset by peer) | |
| [05:21:16] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat) | |
| [05:30:44] | Goga777 (Goga777!~Goga777@shpd-92-101-143-188.vologda.ru) has quit (Remote host closed the connection) | |
| [05:39:48] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [06:06:48] | coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has quit (Ping timeout: 255 seconds) | |
| [06:11:50] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [06:15:43] | coling (coling!~colin@cpc1-sgyl30-2-0-cust258.sgyl.cable.virginmedia.com) has joined #mythtv | |
| [06:30:07] | paul-h: | stuartm: Thanks, I'll take a look when I get a chance |
| [06:42:46] | jya: | anyone has tried compiling myth on a mac with lion ? gcc (llvm) 4.2 crashes when compiling libavcodec... |
| [06:43:37] | Beirdo: | heh |
| [06:43:52] | Beirdo: | you're probably the first to try it |
| [06:44:08] | Beirdo: | and to be honest llvm != gcc, and I'm not surprised |
| [06:49:29] | jya: | Beirdo: you type gcc --version and you get that |
| [06:49:42] | jya: | i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) |
| [06:49:51] | jya: | so as far as I'm concerned, it's gcc :) |
| [06:50:56] | Beirdo: | hmm, K |
| [06:51:17] | Beirdo: | anyways, I doubt many have even tried lion yet at all :) |
| [06:51:30] | jya: | the issue was with qt |
| [06:52:41] | jya: | adding -sdk /Developer/SDKs/MacOSX10.6.sdk/ to the configure line for qt was enough to compile |
| [06:53:26] | jya: | will be updating the osx-packager soon.. But for dsp_mmx.c it gives a weird error (a crash actually) |
| [06:53:51] | jya: | I got a new macbook air, and wanted to compile to compare the time with the older version |
| [06:54:10] | jya: | it seems *much* faster… It crashed compiling libavcodec aver 36 minutes only |
| [06:54:27] | jya: | knowing the previous MBA took 2h37m to compile myth and all its dependencies... |
| [06:54:48] | jya: | I'm guessing the new MBA do it under an hour easily |
| [07:10:26] | kormoc is now known as kormoc_afk | |
| [07:14:22] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Quit: Quit) | |
| [07:21:58] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [07:25:05] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [07:25:06] | MythLogBot (MythLogBot!~bot@mythtv/developer/beirdo) has quit (Ping timeout: 260 seconds) | |
| [08:23:52] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat) | |
| [08:52:13] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 252 seconds) | |
| [08:53:27] | rsiebert (rsiebert!~quassel@g226060076.adsl.alicedsl.de) has joined #mythtv | |
| [08:53:53] | rsiebert: | hi, can anyone give me a hint how to change the displaysize of an image? Id like to rotate, scale, zoomed or moved a mythuiimage within a fixed <area> defined by the themer without changing the <area>. The long term would be supporting gallery or image effects within mythuiimage. |
| [09:20:09] | rsiebert (rsiebert!~quassel@g226060076.adsl.alicedsl.de) has quit (Remote host closed the connection) | |
| [09:25:26] | rsiebert (rsiebert!~quassel@g226060076.adsl.alicedsl.de) has joined #mythtv | |
| [09:30:48] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [09:47:14] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [10:05:02] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:54] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:17:27] | rsiebert (rsiebert!~quassel@g226060076.adsl.alicedsl.de) has quit (Ping timeout: 255 seconds) | |
| [10:21:34] | zCougar (zCougar!~cougar@2001:67c:32c:600:250:56ff:fe81:5f) has joined #mythtv | |
| [11:01:05] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [11:50:24] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has joined #mythtv | |
| [12:04:48] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [12:05:16] | gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [12:05:16] | gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [12:05:16] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [12:18:12] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [12:25:43] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [12:31:25] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [12:48:03] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [12:50:40] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [13:01:19] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [13:34:34] | stuartm: | danielk22: I'm currently using QT 4.7.3 |
| [13:38:16] | danielk22: | stuartm: what distro? or is it self-compiled? |
| [13:39:17] | stuartm: | mandriva |
| [13:39:31] | stuartm: | the 2011 release candidate |
| [13:39:49] | stuartm: | although I was seeing the same with 4.7.1 iirc in the 2010 release |
| [13:41:14] | danielk22: | Beirdo: I got a core last night. MythSystemUnix::Fork() is crashing on generating LOC_ERR. AFAICT m_logcmd has no locking and is so is intended to be used by only one thread. |
| [13:42:19] | danielk22: | stuartm: ok, I may just need to fire it up in a virt.. |
| [13:43:04] | danielk22: | Beirdo: here's the backtrace of the thread http://pastebin.com/PXBE6Lgd |
| [13:44:22] | stuartm: | danielk22: if there's any debugging you'd like me to do then let me know |
| [13:46:01] | danielk22: | stuartm: http://pastebin.com/bJrDLguW <-- this patch should produce a backtrace if the Qt error message isn't pointing us in the wrong direction... |
| [13:47:57] | stuartm: | danielk22: ok, I'll apply/run that in a couple of hours |
| [13:48:34] | danielk22: | thx.. it's possible that we're doing something else wrong and the message is sending us down the wrong alley. |
| [13:55:14] | danielk22: | Beirdo: is there any reason why we're returning a modifiable reference to a string in GetLogCmd(), is it used to modify the string somewhere? |
| [14:00:25] | jya: | Beirdo: which ffmpeg version did you use for the resync? |
| [14:04:57] | jpabq_ (jpabq_!~abqjp@71-37-153-77.albq.qwest.net) has quit (Quit: jpabq_) | |
| [14:09:01] | j-rod|afk is now known as j-rod | |
| [14:09:38] | swerve (swerve!~swerve@cpe-72-226-86-206.nycap.res.rr.com) has joined #mythtv | |
| [14:23:18] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [14:23:33] | bill6502 (bill6502!~bill6502@2002:cdb2:1a2b:7cd3:9ef4:32ea:c6ea:200) has joined #mythtv | |
| [14:32:27] | danielk22: | Beirdo: MythSystem has a lot of uglies we collectively decided to avoid long ago. For instance signals/slots in backend code & the code formatting and method naming bears no resemblance to the mythtv standard. etc.. Who did your code reviews before you got commit access? |
| [14:54:57] | wagnerrp: | to be fair, i wrote much of the initial rewrite for that one |
| [14:55:37] | wagnerrp: | Beirdo restructured it, wrote the Windows version, and made it actually work |
| [14:55:43] | danielk22: | Beirdo: It appears that the LOG macro will always execute all the code in the macro while the old VERBOSE was careful to only do so if something would be logged.. so you could do expensive stuff inside the macro that would only be executed if that level of verbosity was desired. |
| [14:56:05] | wagnerrp: | out of curiosity, what are the issues caused by signals/slots that should be avoided? |
| [14:56:07] | danielk22: | wagnerrp: Who did the initial reviews for you? I feel like we've failed both you guts. |
| [14:56:14] | danielk22: | s/guts/guys/ |
| [14:56:29] | wagnerrp: | no one, i was brought on for the python bindings |
| [14:57:00] | wagnerrp: | which is why ive stayed away from committing anything large outside the bindings |
| [14:57:05] | danielk22: | ah, so you're c code wouldn't have been reviewed... i hear good things about the python binding btw. |
| [14:57:13] | wagnerrp: | letting the mythsystem and command line parser get picked up by beirdo |
| [14:58:00] | danielk22: | the signals/slots mechanism falls down flat whenever C++ inheritance or threads get involved. |
| [14:58:06] | wagnerrp: | and why i havent moved the libmythprotoserver stuff into mythbackend yet |
| [15:01:02] | danielk22: | The moc pre-processor adds a lot of additional requirements to how inheritance is done because the slots are statically assigned during compile time ; we decided that source of bugs was worth it in UI where we needed to deal with Qt anachronisms anyway, but was not worth it in the backend which we want to be super stable. |
| [15:02:35] | wagnerrp: | what about stuff like downloadFinished/Error/Progress in the download manager? |
| [15:02:45] | danielk22: | Threading wise it's just a great a source of deadlocks because developers get about which thread the other end of the signal gets executed in. |
| [15:03:53] | danielk22: | wagnerrp: if those are only sent to UI objects it's ok. especially if the signals are one way (i.e. they don't depend on being executed in any particular thread for thread safety and they don't expect some action to be taken immediately.) |
| [15:04:41] | andreax (andreax!~andreaz@p57B94EBA.dip.t-dialin.net) has joined #mythtv | |
| [15:04:58] | danielk22: | But you gotta stay away from using multiple inheritance or interfaces when using signals/slots. |
| [15:05:55] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has joined #mythtv | |
| [15:07:45] | danielk22: | There are certain limited exceptions, but you should get a Qt guru to review the code and put in lots of warnings if it really is necessary. |
| [15:08:14] | wagnerrp: | well following that MythSystem does not seem to internally use any of its own signals (it doesnt have any slots defined) |
| [15:08:57] | wagnerrp: | we could probably just remove them to no ill effect |
| [15:09:09] | wagnerrp: | although there may be bits of code using them |
| [15:12:55] | danielk22: | Yeah, I'm myth_system is totally fixable, I'm more concerned about the busy work being generated because it looks like you and Beirdo didn't get the low-down on Qt gotcha's and the limitations we place on ourselves wrt coding style and C++ features. |
| [15:13:19] | danielk22: | This usually happens when we do code reviews prior to giving commit access.. |
| [15:17:38] | wagnerrp: | beirdo has actually had commit access since 2005, but hadnt done anything since early 2006 |
| [15:17:59] | wagnerrp: | he may have simply been out of touch for too long and forgot |
| [15:20:05] | wagnerrp: | as far as i can tell, libmyth/netgrabbermanager.cpp is the only code that actually uses those signals |
| [15:22:19] | wagnerrp: | however ill have to rethink the delete thread i put into the fileserver class in libmythprotoserver |
| [15:22:37] | wagnerrp: | deleted files, and failed deletes, are signalled |
| [15:24:22] | wagnerrp: | for now, thats only being used in the mediaserver |
| [15:28:59] | danielk22: | wagnerrp: usually you can just define interfaces and use those instead. The only exception is classes where you can't use virtual because the classes rely on having a particular memory layout. |
| [15:29:52] | danielk22: | wagnerrp: those kinds of classes should be avoided anyway unless there is a very good reason for them like TSPacket. |
| [15:34:37] | wagnerrp: | well the way i had set up the delete thread, you just give it files, and it eventually deletes them |
| [15:34:54] | wagnerrp: | it would then signal out to indicate the file was deleted (or not) so associated metadata could be removed from the database |
| [15:35:19] | wagnerrp: | i could rewrite it so instead of passing in a QString, you pass in an object, and the object then does whatever it needs to do internally |
| [15:36:26] | wagnerrp: | give the object two virtuals for successful or failed deletes |
| [15:39:10] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Ping timeout: 264 seconds) | |
| [16:03:17] | andreax1 (andreax1!~andreaz@p57B95B24.dip.t-dialin.net) has joined #mythtv | |
| [16:03:47] | andreax (andreax!~andreaz@p57B94EBA.dip.t-dialin.net) has quit (Ping timeout: 240 seconds) | |
| [16:07:48] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [16:10:11] | stuartm: | danielk22: no assert, so it is a red herring, I'm wondering if the error is literal, we're calling killTimer() for a timer which has already been killed, therefore the ID is unknown |
| [16:11:06] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [16:11:33] | stuartm: | looking at the qt code it seems like that is the real issue |
| [16:12:17] | stuartm: | should be easy enough to fix, I'll come up with a patch |
| [16:14:15] | stuartm: | I think setting the timer id to zero after calling killTimer() should be sufficient |
| [16:25:35] | stuartm: | I _really_ wish people would stop mis-using the term 'crash' |
| [16:25:46] | wagnerrp: | isnt 9954 actually fixed? |
| [16:25:56] | wagnerrp: | i recall at some point in the past trying to tune a dead channel |
| [16:26:19] | wagnerrp: | and being able to use channel up/down to change channels even when it was attempting to get a lock on the first |
| [16:36:40] | Jordack is now known as HappySysAdminDay | |
| [16:37:52] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [16:39:07] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds) | |
| [16:40:15] | stuartm: | wagnerrp: the signal monitor was supposed to fix that for digital channels, and I thought more recently that an analogue version was committed, but I don't know enough about it to close the ticket |
| [16:44:36] | kth (kth!~kth@dyndsl-091-096-147-198.ewe-ip-backbone.de) has joined #mythtv | |
| [16:44:43] | kth (kth!~kth@dyndsl-091-096-147-198.ewe-ip-backbone.de) has quit (Changing host) | |
| [16:44:44] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [16:44:57] | danielk22: | stuartm: I think that was broken recently, the signal monitor hasn't been appearing for the first tune. |
| [16:45:38] | danielk22: | though there was a commit log message about fixing that. |
| [17:03:10] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [17:03:35] | gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [17:03:36] | gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [17:03:36] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [17:05:00] | danielk22: | stuartm: It looks like the signal monitor is showing up now, but the UI hangs when you click ok on the timeout dialog. |
| [17:06:27] | stoffel (stoffel!~quassel@p57B4C7B8.dip.t-dialin.net) has joined #mythtv | |
| [17:07:15] | kormoc_afk is now known as kormoc | |
| [17:11:48] | danielk22: | hmm, it's not that it has hung, it just doesn't respond to channel browsing actions.. so you can still type in a channel name, but the normal thing of hitting the up and down buttons to change the channel doesn't work. |
| [17:22:43] | brfransen (brfransen!~brfransen@216.254.250.47) has joined #mythtv | |
| [17:27:27] | danielk22: | hey, while I'm looking at this code.. how do I make that popup telling you that you should have gotten a signal by now purely informative.. i.e. I don't want the user to need to press "ok" I just want the dialog to go away on any keypress. |
| [17:39:41] | stuartm: | danielk22: where is that dialog, tv_play.cpp? |
| [17:40:09] | danielk22: | yeah, search for DIALOG_INFO_CHANNELLOCK_0 |
| [17:41:02] | stuartm: | Mark didn't use a lot of the normal mythui framework in porting the OSD, so what applies to the rest of the UI doesn't always remain true for the OSD |
| [17:42:31] | sphery: | could just do an osd popup that times out (short timeout, likely)? |
| [17:43:22] | stuartm: | hmm, I'd have used an ok dialog there instead of the menu dialog with just one entry |
| [17:44:11] | brfransen (brfransen!~brfransen@216.254.250.47) has quit (Quit: brfransen) | |
| [17:45:19] | danielk22: | There is also a visibility issue, the dialog appears under other ui elements so it can be hard to read.. |
| [17:46:37] | stuartm: | danielk22: right, one of the elements Mark omitted was the ScreenStack, so screen ordering is a little screwy |
| [17:46:55] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 260 seconds) | |
| [17:47:37] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [17:49:31] | stuartm: | which all sounds like I'm having a go at Mark when in fact I'm trying to excuse the fact that I don't know my way around the OSD :) It's not immediately familiar to anyone who has worked with the UI elsewhere |
| [17:51:17] | stuartm: | I wouldn't say that achieving what you want is easy with the current dialog, we're leveraging a menu dialog which expects at least one menu entry, it's not like the ok dialog where allowing it to be dismissed with any key would be a more natural fit |
| [17:52:22] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 264 seconds) | |
| [17:53:11] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [18:02:12] | danielk22: | stuartm: I went ahead and fixed the channel browsing bug. I left the dialog stuff alone. It's probably best to handle that when mark is back from his grand tour. |
| [18:07:31] | stuartm: | danielk22: I'm reminded of http://code.mythtv.org/trac/ticket/9723 |
| [18:07:47] | stuartm: | any chance that the fix you just committed also closes that ticket? |
| [18:08:54] | danielk22: | stuartm: no, but I think markk already fixed the issue when he introduced the browse bug :) |
| [18:09:49] | danielk22: | actually, there may be similar checks for pausing causing that bug.. so maybe these bugs were introduced at the same time as the browse bug.. |
| [18:12:26] | stuartm: | I don't know if the issue in that ticket is a regression or not, I opened the ticket as a task because it seemed that we should not be ignoring actions such as INFO when paused but not because I actually remember being able to do that in earlier versions |
| [18:14:53] | sphery: | danielk22: btw, any chance https://github.com/MythTV/mythtv/commit/1c6e0ee46 may have fixed http://code.mythtv.org/trac/ticket/9643 ? |
| [18:14:56] | danielk22: | dunno, i know channel browsing used to work :) it looks like MythPlayer::IsPaused() changed from meaning, "No UI Available" to meaning "No A/V Stream Playing" but the places using IsPaused() weren't all changed. |
| [18:16:26] | danielk22: | sphery: Maybe, I haven't tried to debug that issue so I don't actually know what is going on there. |
| [18:16:59] | danielk22: | The error message I fixed is present.. but that alone doesn't mean anything. |
| [18:17:46] | sphery: | yeah, was just thinking that if that's preventing us from finding the recording, it would explain why we can't cancel the recording |
| [18:21:24] | stuartm: | huh, I thought I'd done away with ScheduledRecording when I created RecordingRule but apparently I forgot to handle that last remnant |
| [18:44:09] | danielk22: | BTW I spent an hour updating http://www.mythtv.org/wiki/Coding_Standards this morning... Some of the info was just plain wrong, but I'm sure I didn't catch everything and I left out some stuff... |
| [18:44:35] | taylorr: | danielk22: did you ever intend to backport this -> https://github.com/MythTV/mythtv/commit/d14b6 . . . 243325e73047 |
| [18:45:36] | danielk22: | taylorr: No, that's a huge one.. I had wanted to get it done before 0.24, but didn't have the time. |
| [18:47:18] | kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv | |
| [18:47:36] | taylorr: | cool, just asking cause I saw a ticket still open that is related |
| [18:48:01] | danielk22: | The channel favorites stuff? |
| [18:50:16] | taylorr: | I had it up last night but can't find it now... nothing to do with the channel favorites... I'll search later and see if I can find it again |
| [18:58:18] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 258 seconds) | |
| [19:06:54] | sphery: | taylorr / danielk22 : perhaps http://code.mythtv.org/trac/ticket/9575 ? |
| [19:06:55] | bill6502 (bill6502!~bill6502@2002:cdb2:1a2b:7cd3:9ef4:32ea:c6ea:200) has left #mythtv () | |
| [19:10:25] | wagnerrp: | danielk22: you just dont want new signals being added, but slots for signals from qt stuff like QTimer is acceptable, right? |
| [19:12:53] | Captain_Murdoch: | Beirdo, the linking trick you were talking about yesterday is basically what I used in a proof of concept patch that enabled remote playback of encrypted DVDs. I overrode the internal dvdcss open and close routines inside mythiowrapper.cpp to allow the dlopen-ed dvdcss to use our RemoteFile and RingBuffer. |
| [19:13:43] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [19:14:54] | danielk22: | wagnerrp: Not in backend code.. you can use startTimer()/killTimer() and listen to the event in timerEvent(QTimerEvent *te) instead. The difference is that QTimer can fire an event after the class has been deleted.. |
| [19:15:28] | Beirdo: | Captain_Murdoch: cool. |
| [19:19:28] | Beirdo: | OK, I will hereby voice my strong objection to putting into our coding standard the non-intuitive and pointless use of the construct: "if (3 == variable)" |
| [19:19:35] | danielk22: | Beirdo: FYI I found the crash inducer.. it appears to be QString reference counting issue... |
| [19:19:42] | Beirdo: | that is not C++-proper code |
| [19:19:42] | stuartm: | danielk22: by the look of the diff there was a lot of stuff which was wrong with that coding standards page, some things like the enum I was aware of but I'd missed other fairly obvious stuff |
| [19:19:49] | Beirdo: | danielk22: oooh, nice |
| [19:20:12] | Beirdo: | QString being abused across threads without detach(), I guess? |
| [19:20:16] | danielk22: | heh, I don't care about const==variable.. I use it because it's saved me problems. |
| [19:20:34] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 264 seconds) | |
| [19:20:35] | Beirdo: | well, it's slipped into the examples in the coding standards on the wiki |
| [19:20:57] | Beirdo: | I think that one should be up to individual style and not pushed onto others |
| [19:21:32] | Beirdo: | I do understand that it protects against missing = in some cases :) |
| [19:21:42] | danielk22: | Beirdo: Nah, looks like the problem is a Get method that returns a reference.. I'm testing just changing that.. |
| [19:22:19] | Beirdo: | oooh, we need to check the Gets in MythSystem for that, I may have gotten it backwards there |
| [19:22:26] | stuartm: | danielk22: I'm not sure about the all-lower + underscore in function names? Is that really a standard that's widely followed? If anything I'd say that's the opposite of what we've all been doing (Upper first letter of each word, no underscore) |
| [19:22:29] | danielk22: | I'll add a note about the const==variable thing... Please look at other stuff. |
| [19:22:44] | Beirdo: | I will :) |
| [19:23:11] | Beirdo: | yeah, the only file that MUST have tabs: Makefile |
| [19:23:43] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [19:25:02] | stuartm: | and in fact the text still reads – "Methods are StudlyCaps.", so are we saying that non-member functions should be lower_with_underscore and member functions should be StudlyCaps? |
| [19:25:54] | wagnerrp: | danielk22: how flexible is that 80-character limit? |
| [19:26:49] | wagnerrp: | i know that was actually discussed in here a couple days ago |
| [19:27:19] | Captain_Murdoch: | danielk22, I doubt you've evern looked at it, but I'd be curious to know if you see any issues with the way I implemented the MythDownloadManager's downloadFinished() slot for QNetworkAccessManager's finished signal and MDM::downloadError() and downloadProgress() for QNetworkReply's error and downloadProgress signals. all data is lock protected, and it doesn't matter which thread those run in since they mainly just send out eve |
| [19:27:19] | Captain_Murdoch: | nts to listeners or update the locked data. |
| [19:27:21] | danielk22: | stuartm: the lower_with_underscore is not something we've discussed. Basically you want to avoid StudlyCaps so as to avoid being confused with methods. mixedCaps would work too, but it could be confused with Qt methods. |
| [19:28:09] | Captain_Murdoch: | stuartm, so I can start naming my methods something like GeThOsTnAmE (since it's StudlyCaps vs CamelCase) |
| [19:28:18] | stuartm: | danielk22: ok, that does make sense for the same reason we require m_, I hadn't given it much thought before |
| [19:28:33] | Beirdo: | I'd like to add: Use the LOG() interface rather than cout/cerr when putting in debugging logging that is more than strictly temporary. |
| [19:29:04] | wagnerrp: | unless there are very explicit reasons otherwise |
| [19:29:07] | danielk22: | Captain_Murdoch: I haven't looked at it. There is a need for exceptions sometimes, I tend to try to isolate slots to private classes when they are necessary to deal with Qt classes. |
| [19:29:09] | Beirdo: | that way the debug logging is in the logs to aid with remote debugging |
| [19:29:11] | wagnerrp: | such as the progress meter in mythcommflag |
| [19:29:40] | Beirdo: | yes, other than specific things that are meant to be on the console, or errors before logging is enabled, or in a forked child |
| [19:30:06] | stuartm: | Captain_Murdoch: heh, I'm following the convention in the coding standards which was written long before I was around, but you're right, I think somewhere along the lines the two have been confused |
| [19:31:09] | Beirdo: | that and: Use MythSystem rather than QProcess or system() or popen(), etc. If the functionality you need is not there, it can be extended. It was designed to work around long-running bugs in QProcess, and gives us a centralized method to get child programs run. |
| [19:31:17] | stuartm: | Captain_Murdoch: we should change that to read CamelCase, since StudlyCaps is confusing, even though CamelCase style conforms to the StudlyCaps rule, but not vice-versa |
| [19:31:56] | wagnerrp: | Beirdo: i would expect that to be better put in the library documentation in doxygen |
| [19:32:06] | wagnerrp: | rather than explicitly spelled out in coding standards |
| [19:32:07] | sphery: | FWIW, I'm (still :) against dropping our 80-char limit :) |
| [19:32:29] | Beirdo: | it's a Design Guidelines type of thing if it goes in there at all |
| [19:32:40] | wagnerrp: | sphery: i agree that there should be a limit, but exactly 80 characters? |
| [19:32:41] | Beirdo: | sphery: me too. |
| [19:32:46] | stuartm: | sphery: what limit would you chose instead? |
| [19:32:48] | Beirdo: | yes, exactly 80 |
| [19:33:06] | ** wagnerrp notes that the example given in the coding standards page is 82 characters long ** | |
| [19:33:07] | stuartm: | sphery: sorry, I mis-read |
| [19:33:14] | danielk22: | wagnerrp: The limit is still 80, we can decide on something else but it needs to be a constant. |
| [19:33:22] | Beirdo: | hehe, that should be fixed then |
| [19:33:22] | Captain_Murdoch: | danielk22, OK, just curious about an opinion if you get bored one day. :) it was either use the existing signals or reimplement the Qt classes using events. if you do look someday, just let me know if you see anything wrong and I'll try to fix. I don't know of any issues related to MDM though. |
| [19:33:30] | ** Captain_Murdoch is for 120 as the limit ** | |
| [19:34:17] | Captain_Murdoch: | just need to size my ~130-wide gnome-terminal down a bit. |
| [19:34:17] | stuartm: | 80 happily uses just under half the screen for me, so I can sit two files side by side on the screen with no artificial wrapping or cropped text |
| [19:34:24] | sphery: | I'd rather run all our code through a beautifier and change indents to 2char and stick with 80-char lines... it fits a default sized terminal (and I can fit 9 of those on my screen without overlapping) |
| [19:34:33] | Beirdo: | exactly |
| [19:34:36] | Beirdo: | and in stereo |
| [19:34:37] | Beirdo: | :) |
| [19:34:56] | Captain_Murdoch: | load the same file in 2 windows, cross your eyes and its 3D |
| [19:35:03] | Beirdo: | 80 columns has been and remains the defacto UNIX console and terminal window width |
| [19:35:11] | stuartm: | sphery: I like the 4-char indent, it's easier to read than 2 char |
| [19:35:37] | wagnerrp: | yeah, plus it lets you reserve 2-char for special structures like switches |
| [19:35:37] | sphery: | yeah, it stands out more, but if people are really concerned about how much fits in 80 chars, I'd rather lose the 4-char indent than the 80-char limit |
| [19:36:10] | danielk22: | I'm soft on 80 columns, but the 4-char intent is a good compromise between 2 & 8.. |
| [19:36:33] | stuartm: | 8 is too much, no question |
| [19:38:25] | stuartm: | I think in most cases 80 is enough and that the real problem comes when you've got several nested blocks – which is a good indication that maybe the code needs re-factoring and breaking into smaller methods |
| [19:38:37] | Beirdo: | yup |
| [19:39:15] | Beirdo: | whether into smaller methods, or just unravelled and put back together with fewer levels of if... plenty of ways usually to get around that |
| [19:40:05] | wagnerrp: | my big complaint is more just about logging and strings |
| [19:40:20] | wagnerrp: | having to continue on the next line because its say 83 characters |
| [19:40:31] | stuartm: | the practice of aligning arguments etc with lines above/below by inserting a lot of white doesn't help either and it's not something I like to see in code I maintain anyway |
| [19:41:29] | sphery: | yeah, I find it very annoying when I add a new variable in a block of aligned variables, and it doesn't fit |
| [19:41:43] | sphery: | (or function declarations or ...) |
| [19:41:52] | stuartm: | Beirdo: right, I meant to say 'and/or', I'm not implying that the answer is always to create new methods |
| [19:42:05] | Beirdo: | heh, wonder if the indent program can help us standardize |
| [19:42:27] | danielk22: | We can add not aligning things to the standard, it's not in our standard one way or the other... |
| [19:42:33] | stuartm: | Beirdo: I'd worry that it would handle 'wrapped' lines badly |
| [19:42:41] | Beirdo: | stuartm: yeah :) there are some methods/functions I've seen that just grate the nerves as they are SOOOOO long. |
| [19:42:42] | danielk22: | Beirdo: I just added LOG and MythSystem. |
| [19:43:45] | stuartm: | danielk22: a few people think it helps readability, personally I think it's a complete pain and doesn't help readability at all |
| [19:44:31] | Beirdo: | looks good, thanks :) |
| [19:44:34] | stuartm: | the last time I removed some alignment (to make the code comply with the 80 char rule) I got an earful from the original author |
| [19:44:37] | danielk22: | stuartm: I am one of those ppl... but it's not gospel to me. |
| [19:45:19] | Beirdo: | stuartm: yeah, I should experiment with settings on indent and see if we can find something that fits our particular needs |
| [19:45:34] | Beirdo: | I'm not sure how it deals with wrapped lines off hand either |
| [19:46:04] | Beirdo: | if we could find a particular set of settings that exactly fit our needs, we could just make git reformat on commit. heh |
| [19:47:14] | Beirdo: | danielk22: not sure if I asked this before or not... the signal/slot issues... do we have Qt docs on this, or was this our observation? |
| [19:47:22] | stuartm: | danielk22: I don't really mind, I just wouldn't choose to use it myself and I'd most likely remove it from code I maintain in order to keep the style consistent with everything else in the lib/app |
| [19:47:26] | danielk22: | Beirdo: There are always times when humans do a better job at formatting. The goal is readability. |
| [19:47:44] | Beirdo: | I'd be happy to get them out of MythSystem, but we had a couple places that currently use them |
| [19:48:01] | Beirdo: | one was net grabbers, I think, and the other mythweather, IIRC |
| [19:48:33] | Beirdo: | danielk22: yeah, true :) The tool will screw us at some point if it's a hard reformat |
| [19:49:05] | danielk22: | Beirdo: Look under limitations here: http://doc.qt.nokia.com/latest/moc.html |
| [19:49:28] | Beirdo: | another thing we'll need to add is about DB connections. Our current code is NOT properly functional |
| [19:49:45] | danielk22: | Beirdo: They don't go into all the gory details, but they do know of the limitations. |
| [19:49:52] | Beirdo: | Qt mentions not to make queries from threads other than the one that opened the connection |
| [19:50:09] | brfransen (brfransen!~brfransen@216.254.250.47) has joined #mythtv | |
| [19:50:09] | Beirdo: | and we do that all over the place, possibly contributing to our funky deadlocks |
| [19:50:20] | danielk22: | Beirdo: I think we have to come up with a workable solution first ;) |
| [19:51:10] | danielk22: | We can probably keep the current API but come up with something completely different behind the scenes. |
| [19:51:18] | Beirdo: | hehe, yeah, perhaps we should rework it before saying "use the new reworked methodology" |
| [19:51:45] | Beirdo: | it might change somewhat out of necessity |
| [19:53:17] | Beirdo: | I *think* the signal/slots in MythSystem have followed those limitations, but something might have been missed. It would be nicer to get rid of them and reimplement the users if it might be an issue though |
| [19:53:26] | danielk22: | I've been giving it some thought + I think we can keep the same API. All that is required by the MSqlQuery user is that exec() blocks until the data is available (or returns an empty cursor). The user of MSqlQuery doesn't care what thread handles the query. |
| [19:54:16] | Beirdo: | yeah, the queue to the db could go between MSqlQuery and QSqlDatabase, essentially |
| [19:54:20] | Beirdo: | that could work well |
| [19:54:41] | Beirdo: | assuming it uses a queue rather than other methodologies. |
| [19:55:21] | Beirdo: | a series of worker threads that all service the one queue would be one way to pull it off and make the database handling happy anyways |
| [19:56:09] | Beirdo: | hehe. |
| [19:56:17] | Beirdo: | "don't use C++ exceptions"... |
| [19:56:38] | Beirdo: | don't we have some of that in some of the newer code? I know we have exception handling for sure |
| [19:57:05] | danielk22: | We have some in imported code, I don't think we have any in our own code. |
| [19:57:25] | Beirdo: | I hope not. :) |
| [19:57:32] | Beirdo: | that would be naughty |
| [19:57:57] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [20:00:17] | stuartm: | err, iirc there is some in mythvideo and a little in mythui (code I didn't write) |
| [20:01:33] | Beirdo: | I'd like to update the vim modeline in there too |
| [20:02:26] | Beirdo: | mine (although more cryptic, using the short names) includes autoindent and a couple others as well |
| [20:03:32] | Beirdo: | ah yes, smartindent and softtabstop |
| [20:04:14] | Beirdo: | and we should note: the modeline must be either at the top or bottom of the file for vim to see it |
| [20:04:48] | Captain_Murdoch: | Beirdo, RE: the DB thread issue, is it just the exec() or do the prepare() and next() have to be in the same thread? prepare touches the DB (or the DB lib at least) and depending on the internal implementation, next() could as well unless the whole result set is slurped in at once internally in Qt. |
| [20:04:59] | danielk22: | Beirdo: We pretty much always put the emacs line on the top and the vim line on the bottom. |
| [20:05:22] | Beirdo: | Captain_Murdoch: yeah, not sure, let me find the wording again, they aren't very explicit |
| [20:05:46] | Beirdo: | http://doc.qt.nokia.com/latest/threads-module . . . e-sql-module |
| [20:05:50] | Captain_Murdoch: | I think prepare touches the DB from what we've seen. could be new in MySQL 5.x. sphery might remember, I think him and I looked at an issue concerning that a while back. |
| [20:05:52] | danielk22: | Captain_Murdoch: prepare touches the db as well.. I don't know about next(). |
| [20:06:00] | Beirdo: | A connection can only be used from within the thread that created it. Moving connections between threads or creating queries from a different thread is not supported. |
| [20:07:13] | Beirdo: | so there is definitely a thread-safety issue there, and the mysql API adds a bit more in that you only should destroy the connection from the same thread that created or you get annoying messages on shutdown with corresponding 5s delay |
| [20:09:17] | Beirdo: | danielk22: yeah, I'm good with emacs at the top, vim at the bottom. Just as long as people are aware... vim searches the top and bottom 5 lines (by default) when modeline is on. |
| [20:09:47] | Beirdo: | so if someone adds code below the vim modeline at the bottom, it messes things up for vim |
| [20:10:29] | sphery: | Captain_Murdoch: yeah, prepare hits the DB--it's a true prepared query, submitting the query to the DB immediately and then submitting only data to the DB for exec (since Qt4, prepared queries are real) |
| [20:11:05] | sphery: | next should be touching the database, too--pretty sure the qt-mysql drivers are using a pre-fetch mechanism on the order of 10 rows or so |
| [20:11:19] | Captain_Murdoch: | so sounds like no different-thread use at all to me which complicates things because we don't want to keep switching threads on each prepare/exec/next/next/next |
| [20:11:43] | Beirdo: | yeah, sad, isn't it? |
| [20:11:53] | Captain_Murdoch: | maybe in Qt 5.x.... |
| [20:11:58] | Captain_Murdoch: | :) |
| [20:12:03] | Beirdo: | we can try cutting corners, but... |
| [20:12:06] | sphery: | heh |
| [20:15:58] | Captain_Murdoch: | what if we create our own connection pool per thread. inside each thread, when a connection is requested by instantiating a MSQLQuery, we see if we have any connections for that thread. if so, we hand one out. if not, we create a new one. issue then is how to terminate the open connections when the thread terminates. |
| [20:17:00] | Captain_Murdoch: | that way, for long-running threads, we have connections open that are re-used for the various MSQLQuery's instantiated all over the place within that thread. |
| [20:17:13] | Captain_Murdoch: | that's /me's off-the-wall idea for the day. |
| [20:17:35] | stuartm: | sphery: do you know if and for how long the prepared query is stored? Would code benefit from the prepare being outside any loops and the bind/execs left inside the loops? Or does it store them across prepare calls and avoid duplicating identical statements? |
| [20:17:38] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [20:18:10] | danielk22: | Captain_Murdoch: We considered that, but we can |
| [20:18:12] | Captain_Murdoch: | all code would be inside MSQL* along with a hash of lists of threads. |
| [20:18:51] | danielk22: | 't issue the periodic "SELECT null;" and do the reconnection to keep the connections alive in that scenario. |
| [20:18:53] | kormoc: | A prepared statement lasts until the session ends or you DEALLOCATE PREPARE |
| [20:19:27] | kormoc: | if you re-prepare a statement, you get a new handle (assuming unique id) |
| [20:19:29] | Captain_Murdoch: | danielk22, maybe we don't need that anymore with sphery's recent change? |
| [20:19:54] | Captain_Murdoch: | stuartm, the prepare can be outside the loop with the bind's inside the loop. we do that in several places. |
| [20:19:56] | danielk22: | Captain_Murdoch: maybe, but I don't know if that actually works for threads that don't have an event loop (most of them). |
| [20:20:25] | sphery: | stuartm: prepared queries are released when you do a new prepare or exec... or, when the db connection is automatically reconnected (with the recent change) |
| [20:20:26] | kormoc: | if you prepare with the same name, it just deallocates and prepares again, it's not the best way to do it |
| [20:21:07] | sphery: | ah, I see kormoc answered (and better than I did) already |
| [20:21:59] | kormoc: | sphery, you can exec as many times as you want with a single prepared statement |
| [20:22:10] | sphery: | and since the auto-reconnect is done in MySQL C API code, I'm pretty sure it's not dependent upon Qt's event thread |
| [20:22:16] | stuartm: | sphery: ok, so we'd benefit from finding any code like A in this example and changing it to B – http://pastebin.com/U7Sk0DuC |
| [20:22:32] | sphery: | kormoc: yeah, meant an exec(sql) |
| [20:22:45] | Captain_Murdoch: | sphery, yeah, I'd expect it probably just reconnects on next use, not in the background. |
| [20:22:50] | stuartm: | sphery: which is about what I expected, since that's the case with other mysql wrappers, I just wondered if QT was any smarter |
| [20:23:06] | sphery: | Captain_Murdoch: exactly |
| [20:23:07] | danielk22: | sphery: ah, ok... then maybe we can use thread local storage and stick something in all our thread run methods... |
| [20:23:20] | danielk22: | (to do the disconnects). |
| [20:24:06] | Captain_Murdoch: | MThread, here we come... |
| [20:24:51] | sphery: | stuartm: yeah, if we have anything like A, it should be changed to B. I don't think there are many of those--more likely we have some where we do string concatenation to create SQL inside a loop instead of prepare that should be changed over to prepared statements |
| [20:24:54] | stuartm: | sphery, kormoc: I'm pretty familiar with prepared statements, just not the QT wrapper/driver behaviour and that's not to say that mysql hasn't added caching since the last time I looked |
| [20:25:38] | stuartm: | sphery: right, definitely more examples of the latter, but I have seen and even fixed some of the former |
| [20:25:52] | sphery: | yeah, we now have real prepared statements... introduced to the Qt-MySQL driver in Qt 4.x such that they're used with MySQL 4.1.8+ , which means we get them due to our min requirements |
| [20:26:59] | kormoc: | stuartm, it's purely up to how the wrapper names the statements. I'm fairly sure QT's is stupid and uses a always unique id for each call, no matter if it's the same or not |
| [20:28:39] | stuartm: | ok |
| [20:31:09] | stuartm: | at least I know I wouldn't be wasting my time if I tracked down and fixed any examples :) |
| [20:42:22] | Captain_Murdoch: | danielk22, it's probably an oversimplification, but it seems like we could just change our QList of DB connections in MDBManager to a QHash <threadID, QList<MSqlDatabase*>> and have MDBManager::(pop|push)Connection() operate on the QList for the current thread, then when the thread ends we call a MDBManager::CloseThreadConnections() to close all connections for that thread as you mentioned. |
| [20:43:38] | Captain_Murdoch: | ditto for MDBM::PurgeIdleConnections() only operating on the QList for the current thread. |
| [20:44:47] | danielk22: | Captain_Murdoch: MThread could take care of that :) |
| [20:45:47] | Captain_Murdoch: | need MRunnable as well then. |
| [20:46:19] | cesman (cesman!~cecil@pool-108-38-214-203.lsanca.fios.verizon.net) has joined #mythtv | |
| [20:46:19] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [20:46:19] | cesman (cesman!~cecil@pool-108-38-214-203.lsanca.fios.verizon.net) has quit (Changing host) | |
| [20:47:27] | danielk22: | Captain_Murdoch: No we don't want to teardown the connections when a runnable ends, we'd need to implement MThreadPool.. |
| [20:47:51] | Captain_Murdoch: | ah, yeah. :) |
| [20:48:31] | danielk22: | It's not simple.. but maybe not as complicated as I first imagined. |
| [20:48:54] | Captain_Murdoch: | we'd have to use our own thread pools instead of the default pool, but that doesn't matter much. |
| [20:49:41] | danielk22: | We actually already implement a couple threadpools... with some more desirable characteristics... |
| [20:50:24] | Captain_Murdoch: | they inherit from QThreadPool? I didn't know that. only one I knew of was the background image loader QThreadPool. |
| [20:51:20] | danielk22: | No, the backend has a thread pool that predates the Qt implementation.. |
| [20:52:08] | danielk22: | The other one I was thinking of uses QThreadPool internally (PreviewGeneratorQueue). |
| [20:53:28] | danielk22: | For the old pool see ProcessRequestThread .. in mainserver.cpp |
| [20:55:49] | danielk22: | The desirable characteristic it has is that if the pool is full for too long it grows the pool, while the Qt pool is fixed in size which can cause deadlocks. |
| [20:58:34] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer) | |
| [20:59:12] | tenminjoe (tenminjoe!~tenminjoe@cpc1-hari10-0-0-cust65.hari.cable.virginmedia.com) has joined #mythtv | |
| [20:59:27] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [21:01:50] | tenminjoe: | Hello fine myth developer people. I hope someone can help me with a question. |
| [21:02:07] | tenminjoe: | I submitted a patch (http://code.mythtv.org/trac/ticket/9632) – is that all I have to do, or should I be announcing it on the dev list or something? |
| [21:02:25] | tenminjoe: | I had the idea maybe it would automatically appear on the dev list. |
| [21:08:25] | Captain_Murdoch: | tenminjoe, file attachment notifications don't get sent out but comments do. they go to the commits list though, not -dev list. |
| [21:08:53] | tenminjoe: | Thanks. So, a post to the dev list would be useful? |
| [21:11:08] | stuartm: | tenminjoe: an email was sent to all developers when you submitted the ticket, that would be enough, unless you have something relating to the ticket that you need to discuss |
| [21:12:02] | tenminjoe: | I didn't actually submit the ticket in the first place, I just added some files and a comment. |
| [21:12:20] | stuartm: | we get emails for every update made to the ticket as well :) |
| [21:12:33] | Captain_Murdoch: | if you commented, then an email was sent out. if you just attach, we don't know unless we look. |
| [21:12:44] | tenminjoe: | Ah, well, all to the good, sounds like I've done what needs doing. |
| [21:12:54] | tenminjoe: | Thanks very much everyone. |
| [21:12:56] | Captain_Murdoch: | yep, thanks. |
| [21:14:19] | stuartm: | bear in mind that the developers have to read a lot of ticket emails and emails to the various mailing lists, it's not hard for us to spend a significant proportion of our time just keeping up with the various communication and that reduces the time we can actually spend working on code and reviewing patches which is one reason why it can seem that we respond slowly to tickets :) |
| [21:14:39] | tenminjoe: | Sure, I realise it may take a while. |
| [21:15:00] | tenminjoe: | I only submitted it a little while ago, but I'm going away for a bit and I thought it'd be good to make sure it was at least "in the queue" before I left. |
| [21:15:06] | stuartm: | that was the ultimate run-on sentence ... |
| [21:15:35] | stuartm: | grammar is the first thing to go when we're short on time ;) |
| [21:16:39] | tenminjoe: | It's my first attempt at contributing so there's every chance I've built the patch all wrong or horribly mangled the code or something. |
| [21:16:59] | stuartm: | tenminjoe: be reassured, it's definitely in the queue, we might not deal with tickets as quickly as we'd like but they don't expire or anything like that so they do eventually get seen |
| [21:17:08] | stoffel (stoffel!~quassel@p57B4C7B8.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [21:17:32] | ** stuartm needs more coffee, or perhaps less ** | |
| [21:18:37] | stuartm: | I'm going to call it a night before I butcher the language any further |
| [21:18:48] | tenminjoe: | Thanks again for the help |
| [21:19:08] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [21:29:56] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [21:47:58] | j-rod is now known as j-rod|afk | |
| [21:51:34] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv | |
| [21:55:23] | wagnerrp: | danielk22: so i would run 'startTimer()', and when that timer runs out, it automatically calls 'timerEvent()'? |
| [21:55:43] | wagnerrp: | and then to reset the timer, i would have to store the value to run 'killTimer()', and then start it a second time? |
| [21:59:10] | danielk22: | wagnerrp: yep, I believe the timers repeat by default, but I'm not certain. |
| [22:00:01] | wagnerrp: | well if the timer triggers, the thread terminates and self deletes |
| [22:00:04] | danielk22: | The same mechanism is used internally for QTimer. The Qt event loop uses a select or poll with a timeout == the time of the next timer expiry. |
| [22:00:45] | danielk22: | QTimer doesn't start a thread.. it uses an existing QThread's event loop. |
| [22:09:35] | wagnerrp: | can QThreads be restarted? or must do you have to create a new one? |
| [22:17:35] | tenminjoe (tenminjoe!~tenminjoe@cpc1-hari10-0-0-cust65.hari.cable.virginmedia.com) has quit (Quit: tenminjoe) | |
| [22:19:16] | danielk22: | wagnerrp: They can, but they might not be the right mechanism for what you want to do. Maybe you want a QRunnable? What is the algorithm you are thinking of? |
| [22:19:39] | wagnerrp: | i rewrote the delete thread for libmythprotoserver |
| [22:19:52] | wagnerrp: | i did have a qtimer set that after X seconds (currently 20) of doing nothing |
| [22:19:54] | wagnerrp: | it would terminate |
| [22:20:04] | wagnerrp: | and signal the file server to delete the thread |
| [22:20:24] | wagnerrp: | with no signal, its just sitting there as a finished qthread object |
| [22:20:35] | wagnerrp: | im wondering if i can simply start it back up as needed |
| [22:20:39] | wagnerrp: | or delete it, and create a new one |
| [22:23:43] | danielk22: | wagnerrp: what does the delete thread do? Does it implement the ext3 file truncation algorithm? |
| [22:23:52] | wagnerrp: | yes |
| [22:25:14] | danielk22: | ah, so it's a long lived thread that truncates several files at once (one on each filesystem) at a varying rate (at least the rate of the currently ongoing deletes..) Why not just let the thread live as long as each backend lives? |
| [22:25:32] | wagnerrp: | to be honest, theres no reason why not to |
| [22:25:32] | danielk22: | s/ongoing deletes/ongoing recordings/ |
| [22:25:54] | danielk22: | I think KISS applies here then :) |
| [22:25:59] | wagnerrp: | i was just writing it as markk started complaining about how our thread count has exploded |
| [22:26:12] | wagnerrp: | so since it could be terminated, i added the code to terminate it |
| [22:26:22] | wagnerrp: | although in hindsight, apparently he was talking about all the threads in the frontend |
| [22:26:52] | wagnerrp: | but since i had already written it, it seemed wrong to remove it, and... |
| [22:27:02] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has quit (Quit: abqjp) | |
| [22:32:10] | danielk22: | markk was complaining because the threads he was running into made the code more complicated. Using a long lived thread here is simpler.. |
| [22:38:56] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has joined #mythtv | |
| [22:48:57] | stuartm: | http://svn.mythtv.org/trac/ticket/9955 – wireless? |
| [22:48:57] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has quit (Read error: Connection reset by peer) | |
| [22:48:59] | jpabq_ (jpabq_!~abqjp@71-37-153-77.albq.qwest.net) has joined #mythtv | |
| [22:50:15] | wagnerrp: | stuartm: only if hes got some horrendously f-d up routing tables that puts 127.0.0.1 on another machine |
| [22:50:50] | wagnerrp: | the amusing part is that he thought to censor out the <tvshow> name |
| [22:51:03] | wagnerrp: | but left in 'S02E01.720p.HDTV.x264.mkv' |
| [22:53:32] | wagnerrp: | the other bit, 'Added 2 output surfaces (total 4, max 4)' is a bit disconcerting |
| [22:53:49] | wagnerrp: | does that mean there was already another playback in progress on that graphics card? |
| [22:56:52] | stuartm: | wagnerrp: I only glanced over the ticket, so I missed the IP |
| [22:57:46] | stuartm: | which I guess was pretty stupid since it's repeated a dozen times or more |
| [22:58:05] | wagnerrp: | my bets on his 'external HDD' being connected over USB1.1 |
| [22:59:14] | wagnerrp: | either that, or the mentioned VDPAU issue |
| [23:00:02] | stuartm: | wagnerrp: the surfaces message is normal VDPAU allocates two surfaces initially and then 2 more if required, he's cropped off the line where the first two were created |
| [23:00:38] | wagnerrp: | but considering the filename and the altered logs, i wouldnt mind just closing it |
| [23:00:53] | stuartm: | "VDPAU: Created 2 output surfaces." usually followed by "VDPAU: Added 2 output surfaces (total 4, max 4)" about 450ms later |
| [23:01:49] | wagnerrp: | hes got an old P4, i know IO panel ports on my parent's old P4 were only USB1.1 |
| [23:02:11] | wagnerrp: | USB2 was only offered through the headers |
| [23:02:57] | wagnerrp: | alternatively, he could have an old AGP system, meaning a PCI VDPAU card |
| [23:03:12] | wagnerrp: | and hes otherwise saturating the bus such that the card simply isnt getting the data he needs |
| [23:21:12] | jpabq_ (jpabq_!~abqjp@71-37-153-77.albq.qwest.net) has quit (Read error: Connection reset by peer) | |
| [23:21:20] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has joined #mythtv | |
| [23:34:14] | Captain_Murdoch: | beirdo, sphery, now that we have DB logging, we need a simple "mythbackend --dumpdblogs" or similar to dump the DB log table out to a file in case users don't have file logging turned on. :) |
| [23:37:10] | Captain_Murdoch: | actually we need "mythutil --dumpdblogs" or something like that, then we can move some of our other utility commands into a common 'helper' binary. |
| [23:37:10] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has quit (Read error: Connection reset by peer) | |
| [23:37:13] | sphery: | Captain_Murdoch: I have a partial patch for a service api log viewer. When complete, I will probably have a paste to pastebin type button. I can also do the save to file there if you like? |
| [23:37:39] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has joined #mythtv | |
| [23:38:15] | Captain_Murdoch: | yeah, just think it might be nice for users submitting tickets. and another idea for your TODO is to allow the user to mark a start and end line and paste just the relevant portion to pastebin or the file. :) |
| [23:38:18] | sphery: | since you really need to be able to select app and some other stuff (pid or start/end time, maybe level and such), I figured it would be better to make it interactive |
| [23:38:50] | Captain_Murdoch: | yeah, sounds OK if it's in the backend webserver. |
| [23:39:29] | sphery: | yeah, I'm tentatively planning for the pastebin (and save to file) stuff to allow you to select stuff with the mouse and output only that |
| [23:39:49] | sphery: | that said, it may require someone else who knows javascript better than I to get that part working :) |
| [23:39:52] | Captain_Murdoch: | no need for a file. users can 'save as' in their browser. you can probably even set it up to prompt hte user to save a file if you give it the right mime type. |
| [23:40:06] | Captain_Murdoch: | s/no need for a file/no need to save to file directly/ |
| [23:40:34] | sphery: | well, the page will have some controls on it, so might be cleaner to have a save to file, too |
| [23:41:20] | Captain_Murdoch: | right, I'm just referring to a 'mythutil --dumpdblog' saving to a file directly from the command line. web UI is enough. |
| [23:41:52] | sphery: | ah, ok |
| [23:42:05] | Captain_Murdoch: | and one set of instructions. :) |
| [23:42:56] | andreax1 (andreax1!~andreaz@p57B95B24.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [23:43:48] | Captain_Murdoch: | probably easiest to show the logs in a scrollable list, but then when you want to save to a file, it issues another request to the BE that sends another response with a different mime type that causes the browser to pop up the 'what do I do with this' box. |
| [23:44:50] | Captain_Murdoch: | that way, you can fetch logs automagically via a scripted "wget -O yesterdays_mbe_logs.log http://MBE:ip/GetLogs?hostname=mbe&startd . . . e=blah" |
| [23:45:29] | sphery: | ah, yeah, makes sense |
| [23:46:02] | wagnerrp: | Captain_Murdoch: yeah, i would /love/ to see some of those print-and-close commands in mythbackend be moved into a separate utility |
| [23:47:02] | wagnerrp: | things like the backend protocol calls, clear cache, system events, etc... |
| [23:47:06] | Captain_Murdoch: | wagnerrp, yeah, I think most of them could since they talk to the MBE over a new connection. I've considered a mythutil binary for a while, but never got around to it. there's things in mythcommflag that woudl move out as well. |
| [23:47:52] | wagnerrp: | Captain_Murdoch: would you see any worth in being able to parse the binary name in the command line parser? |
| [23:48:00] | wagnerrp: | for busybox style operation |
| [23:48:22] | sphery: | I vote against that approach--even GNU says not to do it :) |
| [23:48:39] | wagnerrp: | no opinion one way or another, just a thought |
| [23:48:41] | Captain_Murdoch: | I don't know if we have a need, but then I haven't looked at the new parsing code. |
| [23:49:00] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has quit (Remote host closed the connection) | |
| [23:49:07] | Captain_Murdoch: | we do have access to the app name already in the gCoreContext I believe, but that's after the parser. |
| [23:49:19] | abqjp (abqjp!~abqjp@71-37-153-77.albq.qwest.net) has joined #mythtv | |
| [23:49:39] | wagnerrp: | well we have access directly in argv[0] anyway |
| [23:52:53] | Captain_Murdoch: | heh, yeah, I wasn't even thinking of that. that's a reason not to use busybox style checking and to use our own MYTH_APPNAME_ #define's. if someone renames an app to something they prefer more, we still want it to work without having to "mythtvbin mythbackend --daemon blah blah" |
| [23:53:31] | Captain_Murdoch: | time to veg... |
| [23:54:11] | bill6502 (bill6502!~bill6502@2002:cdb2:1a2b:7cd3:9ef4:32ea:c6ea:200) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.