:: #mythtv

Daily chat history

Current users (83):

aarcane, allesmueller_, aloril_, Anssi, Beirdo, brfransen, caelor, Captain_Murdoch, cesman, Chutt, clever, coling, Cougar, dblain, dekarl, eharris, ElmerFudd, fetzerch, ghoti, ghoti_, Gibby, gigem, gregL, GreyFoxx, Guest59384, jams, jarle, jarryd, jheizer, joe_____, johanbr, joki, jpharvey, jst, jwhite, jya, kc, kenni, knightr, kurre2, kwmonroe, laga_, materdaddy, MaverickTech, moparisthebest, mrand, MythBuild, MythLogBot, NightMonkey, Nothing4You, nyloc, peper03, poptix, purserj, rhpot1991, rkulagow, robink, rsiebert_, Seeker`, seld_, Sharky112065, shodan45, skd5aner, sl1ce, SmallR2002, sphery, sraue, stichnot, stuarta, stuartm, superm1, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang4, XDS2010, xris, _charly_
Thursday, October 3rd, 2013, 00:15 UTC
[00:15:55] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[00:54:09] rsiebert_ (rsiebert_! has joined #mythtv
[00:54:15] rsiebert (rsiebert! has quit (Read error: Operation timed out)
[00:59:43] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[01:18:51] kc (kc!~Casper@unaffiliated/kc) has quit (Read error: Connection timed out)
[01:19:38] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[01:22:25] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[01:47:19] stichnot (stichnot! has joined #mythtv
[01:47:22] stichnot (stichnot! has quit (Changing host)
[01:47:22] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:02:55] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (Ping timeout: 245 seconds)
[02:09:11] allesmueller_ (allesmueller_! has joined #mythtv
[02:09:57] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv
[02:14:53] nyloc (nyloc! has joined #mythtv
[02:19:02] _nyloc_ (_nyloc_! has quit (Ping timeout: 240 seconds)
[02:35:36] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection)
[02:37:56] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv
[02:52:56] joki (joki! has quit (Ping timeout: 245 seconds)
[02:55:55] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds)
[02:56:55] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:58:06] joki (joki! has joined #mythtv
[03:06:34] jya: dblain: I think it's very poor form to keep in the main repo, the source code of dependencies required for the win32 build...
[03:06:45] jya: that shouldn't be there…
[03:07:54] jya: have links in a file if you wish, but storing the dependencies.. especially as in the end they are required by all platforms, not just win32
[03:08:11] Chutt (Chutt! has quit (Ping timeout: 248 seconds)
[03:08:38] jya: unless we decide to move like xbmc has done, and have a local copy of all external libs and not rely on anything outside. (like we did with the main external directory).
[03:08:46] jya: and then who is going to maintain that
[03:19:42] Chutt (Chutt! has joined #mythtv
[03:22:48] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[03:26:48] dgeary2 (dgeary2! has joined #mythtv
[03:38:40] dblain: jya: how is that any different that the external directory?
[03:39:29] dblain: either it's allowed or it's not.
[03:39:36] superm1: thank dblain appreciate it
[03:40:22] dgeary2 (dgeary2! has quit (Ping timeout: 240 seconds)
[03:40:36] dblain: superm1: np.
[03:47:08] dblain: jya: unlike linux, there is no repository windows users can go to get prebuild libraries. In order to reduce the complexity and possible incompatiilities of different versions of libraries, I decided that it would be best to keep the source for the supported version in git, but I isolated it to a platform specific directory.
[03:48:37] dblain: if you and enough other core developers feel that it is "bad form" then I will remove them, but it will mean that windows becomes a 2nd class citizen again.
[03:49:42] dblain: I want the experiance to be as easy as possible, and it starts with building the system (since we don't supply binaries).
[03:51:04] dblain: having to go to a half dozen different sites to pull down source and follow hundreds of steps to manually compile each one will just cause to many people to give up.
[03:52:41] dblain: if I was to take this one step further, why wouldn't we want to control all mythtv dependencies for all platforms. there would be less bugs due to people using newer or older versions of a library. We could decide when it was time to upgrade to a newer version.
[03:57:56] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds)
[03:59:22] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:11:29] jya: dblain: because we maintain the external directory, along all the modifications we made to them…
[04:11:58] jya: and neither do mac os … all the external dependencies are managed by the packaging repo… that's where it should go
[04:13:29] jya: dblain: it doesn't mean windows is 2nd class… just that we have an existing repository to manage build on all platforms. that's the packaging repo… a script that download the source code from a given url and build it is how its done on all the other platforms… I'm just saying we should stay in that predicament...
[04:14:18] jya: on the mac script I wrote, there's just one script to run, it manages it all; applies all the patches if any that need to be applied. the user doesn't have to fetch the source code, or individually compile them.
[04:16:34] jya: dblain: as far as managing all the dependencies, to me it's the wrong way to take it… I believe we should be as standard as possible.. In fact we shouldn't even need our own ffmpeg tree, and focus on our own code.. less thing to maintain, update and worry about….
[04:26:42] dgeary2 (dgeary2! has joined #mythtv
[05:07:06] dgeary2 (dgeary2! has quit (Quit: Ex-Chat)
[05:50:31] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[05:52:59] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[06:10:24] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[06:10:26] jya: hmmm… the pi isn't even fast enough to simply play a ALAC trac via airplay…. wonder if there's any point going further there...
[06:17:48] Guest59384 (Guest59384! has joined #mythtv
[06:22:28] jwhite (jwhite! has quit (Read error: Operation timed out)
[06:26:17] jwhite (jwhite! has joined #mythtv
[06:40:33] jams (jams! has quit (Read error: Operation timed out)
[07:07:03] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[07:20:56] shodan45 (shodan45! has joined #mythtv
[07:26:16] dekarl1 (dekarl1! has joined #mythtv
[07:28:27] dekarl (dekarl! has quit (Ping timeout: 248 seconds)
[07:28:49] warped_ (warped_! has joined #mythtv
[07:39:39] warped_ (warped_! has quit (Quit: warped_)
[07:41:20] superm1: dblain: looking through, I think also when you merged MSVC support some paths in mythtv/external/qjson/src/ look to have gotten mucked with a bit
[07:41:31] superm1: in commit 0281d432355ad882f2edc1b584f04671b3fcb282
[07:41:49] superm1: those things should still be going into usr/include/mythtv/ not usr/include
[07:44:04] superm1: same thing goes for the prl file, it is ending up in /usr/lib but shouldn't be
[07:44:14] superm1: libmythqson.prl that is
[07:53:06] doev (doev! has joined #mythtv
[07:59:03] Merlin83b (Merlin83b! has joined #mythtv
[08:42:14] jams (jams! has joined #mythtv
[09:15:29] jya: even though I modified my ~/.mythtv/config.xml to point to (my dev box running master); everytime I start it it connects to (my production system running 0.27); and config.xml is reverted to… how could that be?
[09:15:36] jya: in the mean time, I can't test my code now :(
[09:15:44] jya: always want to upgrade the db
[09:16:48] stuarta: ah. lemme find the magic
[09:17:33] stuarta: jya: set MYTHCONFDIR= and point it to a different config directory
[09:18:05] stuarta: that's how i can run both prod and dev on the same box
[09:29:02] jya: stuarta: that's not the problem! i config.xml points to my dev box; it just gets changed back to every single time.
[09:29:08] jya: I don't know where it gets that value
[09:29:22] jya: does UPnP takes precedence over the config.xml file?
[09:29:52] stuarta: i have no idea
[09:30:19] jya: damn that's annoying, it never did that before.
[09:30:24] stuarta: i do disable upnp on my dev backend, which runs on the same box as the prod backend
[09:30:30] jya: where the hell is it getting that ip address
[09:31:13] jya: could it be that the local database, contains the other backend IP address so it reverts to that each time ?
[09:31:27] jya: sounds rather idiotic
[09:34:16] stuarta: sounds like some work is required
[09:34:56] jya: i don't know if that's the problem… i need to track where the IP address is determined as it's obviously not what's defined in the config.xml
[09:35:12] jya: i can try to shutdown the other backend temporarily and see how that goes
[09:52:27] dekarl1 (dekarl1! has quit (Ping timeout: 248 seconds)
[11:11:14] stuartm: dblain: in the case of external, we only include those in the main source because we need to patch them for one reason or another – in the case of FFMPEG you've also got the added instability of the API and differences in behaviour between different versions, including ffmpeg means we're not forever having to deal with bugs that exist in different versions of ffmpeg
[11:13:00] stuartm: dblain: as jya notes, the packaging repo seems like the more natural home for the stuff needed to support the windows build – BUT I'm not really that bothered either way
[11:22:01] stuartm: technically, in the case of stuff like libhdhomerun, it's included because it's not available for most platforms
[11:38:19] knightr: stuartm, I am responsible for a lot of the breakagage of those MythUI patches, I think it would be only fair that I fix those alone...
[11:39:30] dekarl (dekarl! has joined #mythtv
[11:43:43] knightr: That said, I have already started reapplying them manually and it's going pretty well, I could have them OK before next week for sure, most likely for Saturday night (your time...)
[11:54:11] doev (doev! has quit (Ping timeout: 245 seconds)
[11:54:51] doev (doev! has joined #mythtv
[11:57:57] wolfgang4 (wolfgang4! has quit (Ping timeout: 248 seconds)
[11:59:00] wolfgang4 (wolfgang4! has joined #mythtv
[12:05:47] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection)
[12:12:50] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv
[12:31:07] FabriceMG (FabriceMG!~Thunderbi@ has quit (Quit: FabriceMG)
[12:39:40] FabriceMG (FabriceMG! has joined #mythtv
[12:40:42] FabriceMG (FabriceMG! has quit (Client Quit)
[12:40:47] Jordack (Jordack! has joined #mythtv
[12:46:32] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[12:52:40] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[12:58:10] stuartm: sphery: the more I think about this 'suggested runtime' hack, the less I'm happy with it, but it would fix a significant flaw in the current shutdown behaviour and honestly I don't have the time to spend on a better solution that would involve the housekeeper
[13:00:17] stuartm: my question is, can you think of an equally simple solution that at least is a step in the right direction e.g. having the housekeeper set the next run time in advance instead of circumventing it entirely?
[13:35:28] stuartm: does anyone know if mysql's prepared statement caches are used with the QT driver? Might there be some benefit from ensuring that prepared statements for guide data insertion are prepared just once instead of per-program?
[13:36:43] stuartm: obviously the whole point of prepared statements to that they should only be prepared once, but if mysqls caches are working it shouldn't make a lot of difference
[13:40:08] dekarl: stuartm, btw what are you trying to achieve with the change to "suggested runtime"?
[13:42:24] dekarl: according to QTBUG-7299 prepared statements should be supported
[13:54:09] gary_buhrmaster: stuartm: re: mysql cache and prepared statements. In mysql versions before 5.1<something> prepared statements would not use the query cache at all, and there were some changes along the 5.1<something_else> that kept adding new capabilities
[13:56:50] gary_buhrmaster: stuartm: Obviously prepared statements can, in some cases, substantially improve performance, but until you instrument it, it is not possible to know if the effort was worth it (at which point you have done all the work anyway).
[14:04:10] stuartm: dekarl: if we're going to wake up the backend to run mythfilldatabase then we need to know in advance at what time that should occur, and when the backend wakes up it also needs to know that it's been woken up for that purpose otherwise it will just shutdown again, maybe before mfdb can actually start
[14:05:31] stuartm: the current housekeeper doesn't decide in advance when the next run should occur, it just keeps checking how long it was since the previous run and adds some randomness to the intervals
[14:06:22] stuartm: using the existing suggested runtime mechanism means that for little effort we get something that works for both xmltv and schedules direct
[14:20:27] gary_buhrmaster: stuartm: I sometimes wonder if the ROI on supporting shutdown/wakeup is worth it in the long term. With Haswell and C6/C7 power states, the idle power use of the system can be 10–20 watts even with a fast CPU (and 4–5 watts for an optimized design).
[14:20:54] stuartm: it's worth it
[14:22:34] stuartm: mostly because very few people are putting the latest and most expensive hardware into their backends, instead they are re-purposing old hardware
[14:24:22] gary_buhrmaster: stuartm: That is why I said long term. For those that turn off their mobile, and turn off their WAP, and turn off their cable modem, and turn off their household IP phones every evening to save another 30 watts, there will never be enough savings.
[14:24:24] stuartm: besides which, it's not just the CPU which draws power in a backend, the tuners are especially power hungry, then you've got several disks
[14:25:24] stuartm: my production machine draws 70W idle, even with the CPU spending most of it's time at 1000Mhz instead of 2500Mhz
[14:26:04] stuartm: and 70W adds very fast for something that's on 24/7 (with UK electricity prices)
[14:26:59] gary_buhrmaster: stuartm: Tuners (and drivers) that support sleep states should take less power. Same for disks (many will idle down).
[14:27:12] stuartm: of course, idle is relative, it's never truely idle because of all the background tasks like EIT scanning
[14:28:08] stuartm: gary_buhrmaster: well all I'm saying is that we're not there yet, and until then shutting down (or suspending) is definitely necessary
[14:28:19] stuartm: I wish it wasn't :(
[14:28:23] gary_buhrmaster: stuartm: Some day Haswell will be ancient technology too.
[14:29:11] gary_buhrmaster: stuartm: I do not dispute the desire/need today. It was long term planning.
[14:29:27] stuartm: we can hope :) For now I've no plans to replace my production hardware until it actually fails
[14:31:54] gary_buhrmaster: stuartm: I wonder if there should not be (as there is in the States for automobiles that are "old/polluters") a rebate to get those old, inefficient PCs out of the home, and replace them with more power efficient equipment. My local power company has rebates for old refrigerators. They should expand that to old PCs (TVs, etc.)
[14:32:26] danielk22: jya: If MythTV is rewriting a good config.xml that is a bug. There are workarounds of course, but the one of the reasons for config.xml support is to override the UPnP stuff.
[14:32:35] gary_buhrmaster: stuartm: Make a proposal to the national grid, offering to be a test case :-)
[14:33:57] jya: danielk22: i believe it is a bug… haven't got the change to track it today.. so I've stopped working on myth for the time being
[14:33:59] gary_buhrmaster: stuartm: (I seem to recall the company running things was the national grid. Replace with whatever name they have changed to to protect the guilty.)
[14:34:07] jya: s/change/chance
[14:34:11] stuartm: stuarta: saw the first ep/pilot of Defiance last night, have to agree with you – struck me as a tired western but with Aliens, no interesting ideas and not what I look for in sci-fi
[14:35:46] stuarta: stuartm: find continuum :)
[14:36:02] danielk22: I also have an update on the syslog-ng log aggregation we did at work. It turns out we weren't losing any messages in forwarding, we were just filtering out messages we shouldn't have been due to dns issues. I'm pretty sure we could come up with a simple foolproof recipe for aggregating mythtv logs.
[14:36:25] stuartm: gary_buhrmaster: National Grid run the infrastructure, power lines etc, but there are numerous companies that actually do the billing of consumers – they buy energy wholesale and make huge profits when selling it on
[14:36:25] danielk22: +1 on continuum, cheesy sci-fi cop show. :)
[14:39:43] gary_buhrmaster: stuartm: SyFy took almost all the SciFi out when they "rebranded" themselves a few years ago. And I doubt that now that they are owned by a cable company things are going to ever get any better.
[14:41:01] gary_buhrmaster: stuartm: Thanks for the clarification.
[14:52:18] stuartm: the best sci-fi for me – exploration of big or novel ideas, quasi-philosophical stuff – is pretty difficult to pull off on TV, at least I struggle to think of examples that fit the criteria, it's more the domain of Film (and of course the books on which most of the good Films were based)
[14:52:50] stuartm: stuff like the Outer Limits might actually be the very best example of that when it comes to TV
[14:55:08] stuartm: doesn't mean I can't enjoy the cheesy stuff, but simply dumping 'aliens' into a common scenario that would have worked pretty much exactly the same without them is generally going to be a disappointment
[14:56:17] stuarta: stuartm: then you'll love continuum, it's essentially an exploration of how companies are running the world, with time travel thrown in
[14:57:06] stuartm: In Defiance, at least that first episode, you could have replaced the alien races with different ethnic groups in a Western US town at the mid-point of the 19th centuary and still told the exact same story – what's the point?
[14:58:01] stuartm: stuarta: I'll check it out :)
[14:58:24] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[15:00:43] gary_buhrmaster: stuartm: The point, as always, is to sell advertising (and for Defiance, the video game tie-in). SyFy lost their original core audience some time ago. Now they have the fantasy, (and what got them a pigasys award) paranormal, and wrestling. And the occasionally cheesy movie like "Sharknado".
[15:02:23] gary_buhrmaster: stuartm: s/pigasys/pigasus/
[15:03:12] stuartm: gary_buhrmaster: harks back to the terrible programming coming out from the US in the 70s, 80s and even early 90s – thrown together for a pittance, with terrible acting, worse scripts and a complete lack of originality :(
[15:04:22] stuartm: what we need is a Sorkin type writing sci-fi for TV :)
[15:06:12] stuartm: problem is the big TV companies won't touch SciFi with a barge pole, partly because so many people have come to associate it with the crap – soap operas in space etc
[15:06:32] gary_buhrmaster: stuartm: There *is* good programming on TV (Sorkin is busy with his HBO "The Newsroom" show), but SyFy has no longer any demonstrated abilities there.
[15:12:12] knightr_ (knightr_! has joined #mythtv
[15:14:55] gary_buhrmaster: stuartm: The reality (in the US) is that it is tough to get any serious show (whether drama, comedy, or dramedy) green-lit these days in hollywood. You are correct that adding SciFi to the pitch is not a winning strategy these days.
[15:14:57] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[15:15:39] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 248 seconds)
[15:19:43] gary_buhrmaster: stuartm: Which is amusing and confusing, since BSG (the reboot) was, to some critics, one of the best shows on TV at one point. I think '33' even got a Hugo.
[15:28:03] sphery: stuartm: Might be better to leverage the existing guide data period and min/max hour settings and just compute based on that. When using suggested time, it disables the min/max hours and period logic (which I think is still appropriate for xmltv). Or, better, if you can pull some or all of it from the xmltv grabber's "suggestions" just do the right thing (and either remove or auto-set appropriate settings).
[15:28:31] gary_buhrmaster (gary_buhrmaster!~gtb@2001:470:80e4:6700::24) has quit (Ping timeout: 245 seconds)
[15:28:46] sphery: (don't grabbers say how much info to pull and when or?)
[15:34:27] dekarl: sphery: nope. grabbers just give you a hint if its preferred to grab the whole time span of all days you care about instead of cherry picking. allatonce <- if you want monday and friday you should just grab monday to friday and throw away tuesdas to thurday
[15:36:03] dekarl: . . . ferredmethod
[15:36:32] stuartm: sphery: actually, the suggested time stuff still honours the min/max window
[15:37:42] stuartm: I think ... maybe it refers to a different window
[15:40:18] stuartm: nope, same window, in MythFillDatabaseTask::DoCheckRun() we check InWindow() is true in the if (UseSuggestedTime()) block
[15:41:31] stuartm: if we've exceeded the suggested interval, but we're not in the window, then return false and keep trying until we've reached the window
[15:42:58] stuartm: dekarl: those capabilities can be extended, the preferred method stuff was originally added at my request so that we could get rid of grabber specific behaviour hacks from mythfilldatabase
[15:44:11] stuartm: I'd guess that most xmltv grabber authors can suggest an appropriate update interval based on their knowledge of the source e.g. uk_rt would be after midnight each day
[15:44:58] dekarl: midnight in which time zone? :D
[15:45:30] stuartm: the catch is that there still needs to be some randomness to when each client grabs data – if everyone grabbed it at 12:01 the load spike on the source would definitely be noticed and might result in them blocking the xmltv grabber
[15:45:39] FabriceMG (FabriceMG!~Thunderbi@ has quit (Quit: FabriceMG)
[15:46:32] dekarl: the source could simply return a random time in the low load time span
[15:46:51] dekarl: the grabber would then convert that into a common format / UTC
[15:48:44] dekarl: in the end you have to wager last-minute-changes vs. load balancing. btw, the UK guide should already be updated more often then just once a day... or its about to change, can't remember atm
[16:03:28] gigem: knightr_, stuartm: Do you know on what commit Xavier's last patches were based? I've been wanting to take a look at them myself. I tried a couple of commits from around that time, but got a failed hunk that was bigger than I was willing to wade through by hand.
[16:06:48] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:12:01] SteveGoodey (SteveGoodey! has joined #mythtv
[16:19:47] danielk22 (danielk22! has left #mythtv ()
[16:21:27] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[16:32:13] knightr_: gigem, stuartm, exactly, no... I applied them and am currently applying by hand everything that failed... I am now working on the last two (one of them is the huge globalsettings.cpp).
[16:34:07] knightr_: I wish he hadn't removed some of the classes he removed in globalsettings (this has an impact translation-wise) but he knows how UI stuff works a lot better than I do some I am going to trust him on this...
[16:39:56] knightr_ is now known as knightr
[16:44:08] stuartm: knightr: if it needs work after being merged to improve the translation situation then we can do that, it's not always possible to get something this big perfect from day one
[16:46:16] knightr: stuartm, it will be OK, it's just that the way it was before it had more granularity which will be lost since he regrouped some stuff together...
[16:51:14] knightr: there is some stuff missing in his patch tough according to the ticket description (is it still the case?) and it depends on tickets which haven't been committed.
[16:52:09] stuartm: iirc there are one or two outstanding patches to libmythui which also need to be applied
[16:53:28] Merlin83b (Merlin83b! has quit (Quit: Leaving)
[16:56:31] gigem: knightr: Okay. I might make another attempt tonight. I want to see if what he wound up with matched what I thought he was doing. Oh, and many thanks for picking this up. It's long overdue.
[16:57:13] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:04:51] knightr: once I have finished is it supposed to be stable enough to apply to master or should be branch out to complete to work before merging to master? the ticket seems to suggest it is still pretty broken...
[17:06:47] knightr: (I have not yet tried it and the one I haven't completed has a few TODOs that suggest it is still broken somewhat...)
[17:07:17] knightr: gigems np....
[17:07:45] knightr: oops, gigem ^
[17:09:24] knightr: (our Internet connection is serverely lagging and I am remoting my pc, it takes forever to see what I typeds...
[17:09:40] knightr: gotta go, ttyl
[17:11:33] warped_ (warped_! has joined #mythtv
[17:25:03] dblain: superm1: Reverted path changes in Let me know if you find anything else.
[17:25:52] superm1: dblain: thank will keep an eye out
[17:27:40] ** dblain is wondering what's happening with MySQL... it keeps corrupting his timezone tables :( **
[17:31:42] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Quit: ChatZilla [Firefox 23.0/20130803215302])
[17:34:37] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:37:23] sphery: stuartm: If you enable suggested run time, it ignores the min/max hours specifically because of users shutting down their systems. See #3302 and [13250]
[17:37:23] MythLogBot: SVN 13250: (branch master)
[17:37:23] ** MythLogBot **
[17:38:34] sphery: I haven't looked at the code recently, but I'd guess the window you're seeing is the "is it suggesting we run it at some time that would mean we go for longer than period days, and if so, run sometime before that"
[17:39:46] sphery: (code which probably should be removed, eventually, too--period makes much less sense these days, especially if users run --dd-grab-all, than it used to, so if nothing else, remove it after we can make --dd-grab-all the default)
[17:41:23] sphery: btw, in case I'm doing a bad job of explaining what I mean, the help text from MythFillGrabberSuggestsTime says: If enabled, allow a DataDirect guide data provider to specify the next download time in order to distribute load on their servers. Guide data program execution start/end times are also ignored.
[17:41:43] sphery: (the last part being what I'm trying to say)
[17:50:30] NightMonkey (NightMonkey! has joined #mythtv
[17:50:31] NightMonkey (NightMonkey! has quit (Changing host)
[17:50:31] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:53:03] shodan45: how hard would it be to make the music player use the backend for storage?
[18:38:40] doev (doev! has quit (Remote host closed the connection)
[18:42:33] stuartm: sphery: that commit only stopped the datadirect parser from setting the mix/max window (overriding the user's configured preference), it doesn't stop the window being respected
[18:43:20] stuartm: basically the change didn't do exactly what it said it did
[18:43:54] stuartm: and the help text is just wrong
[18:45:26] stuartm: the housekeeper still reads in the min/max settings and then checks that we're within them before allowing the data to be collected
[18:47:53] superm1: could someone look at my two trivial pull requests for some other small stuff that I found going through packaging? and
[18:51:01] stuartm: sphery: entirely possible the old behaviour was re-enabled later in a different way, but that's definitely how it works now
[18:52:39] stuartm: MythFillDatabaseTask constructor calls SetHourWindowFromDB() which reads MythFillMinHour and MythFillMaxHour from the settings, in turn it calls DailyHouseKeeperTask::SetHourWindow()
[18:53:40] stuartm: this is the window that's specifically checked in DoRunCheck() when MythFillGrabberSuggestsTime is true
[18:54:25] stuartm: if (InWindow(now)) return true;
[18:56:54] stuartm: ignoring the window wouldn't be a complete fix for the shutdown problem, and may actually cause a different problem (the min/max windows exists to allow users to block mfdb hammering the database when they may be recording or watching recordings)
[18:59:10] stuartm: and it still assume that the backend will wake up once a day (more than that and the user starts missing important updates)
[19:03:23] stuartm: I think I'll stick with the suggesting runtime approach, it's not perfect but it's better than the status quo and I really don't want to spend very long working on this issue
[19:14:34] stuartm: could just use it where AllowBackendShutdown is enabled
[19:46:53] warped_ (warped_! has quit (Quit: warped_)
[19:51:33] warped_ (warped_! has joined #mythtv
[19:54:46] warped_ (warped_! has quit (Client Quit)
[20:01:51] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds)
[20:18:24] stichnot (stichnot!stichnot@nat/google/x-mqxcjgdbdffknmol) has joined #mythtv
[20:18:24] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[20:18:24] stichnot (stichnot!stichnot@nat/google/x-mqxcjgdbdffknmol) has quit (Changing host)
[20:53:12] superm1: jya: 5dccbd5f6b3019a67ecc69213ee405bba4b30994, is it possible to pass those LDFLAGS like that to stuff besides darwin? what broke?
[20:53:24] jarle (jarle! has quit (Read error: Connection reset by peer)
[20:54:00] jarle (jarle! has joined #mythtv
[21:04:18] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[21:15:29] stuartm: heh, inline documentation in stdlib for max() is – "This does what you think it does"
[21:16:14] stuartm: very professional guys, because naturally everyone, even complete newcomers to the language know what max() does ...
[21:56:12] Jordack (Jordack! has quit ()
[21:56:13] MythBuild: build #87 of master-win8-msvc-2010–32bit is complete: Failure [4failed Configure and Build] Build details are at . . . it/builds/87 blamelist: Stuart Morgan < >
[22:02:17] nyloc (nyloc! has quit (Remote host closed the connection)
[22:02:48] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 240 seconds)
[22:04:19] nyloc (nyloc! has joined #mythtv
[22:38:26] MythBuild: build #89 of master-win8-msvc-2010–32bit is complete: Success [3build successful] Build details are at . . . it/builds/89
[22:44:38] sl1ce_1g (sl1ce_1g! has quit (Quit: Konversation terminated!)
[22:48:01] sl1ce (sl1ce! has joined #mythtv
[22:54:02] jya: superm1: not sure I understand your message and what you want to do, commit 5dccbd5f6b3019a67ecc69213ee405bba4b30994 is over 2 years old
[22:54:39] superm1: jya: yeah, I was exploring why the hardening stuff in debian and ubuntu wasn't working properly. LDFLAGS isn't populating into stuff for qmake
[22:55:00] superm1: changing that from darwin only to running everywhere the LDFLAGS populate in and all the hardening stuff starts to work
[22:55:46] jya: i remember that change… this expects all the Qt libs to be in the same folders like /usr/local/lib… But on mac, libraries are organised in frameworks. So libQtCore will be in /Library/System/Frameworks/QtCore.framework/.../lib/libQtCore things like that
[22:56:53] jya: you mean line 4952 in mythtv/configure ?
[22:57:19] jya: actually, no, it shouldn't even be on mac either… it would work without it now on mac...
[22:57:34] superm1: jya: i'm talking about line 6398
[22:57:57] jya: . . . 05bba4b30994 ?
[22:58:17] superm1: yeah that exact commit
[22:58:33] jya: it's up to qmake to provide the right path, not set a generic global ldglags.. this is a brute force attempt trying to get around a misuse of qmake
[22:58:46] jya: don't see 6398 there
[22:59:01] jya: but i'm guess you're referring to configure
[22:59:22] superm1: yeah in configure, line 6398 today
[23:01:33] superm1: is there a better way to get the global LDFLAGS to apply to qmake part of the build like how they apply to the ffmpeg of the build? that seemed the easiest way to me
[23:37:59] stuartm: superm1: is there a repo for the mythbuntu stuff, specifically I wanted to check the pre-made lircrc configs
[23:38:31] superm1: stuartm: lircrc configs are made on the fly at install via mythbuntu-lirc-generator
[23:39:06] superm1: . . . erator/files
[23:39:25] jya: superm1: what did suddenly break? why wouldn't it be required for several years, and suddenly it is ?
[23:40:22] superm1: jya: it's not actually broken, but when things did break from dblain's msvc changes I was reviewing what was left to make this compatible with debian. they have hardening policies that weren't working
[23:41:48] jya: i'm not sure changes to msvc should any be relevant to debian-like… if something got broken, up to the msvc build to fix it, not the other way round… I absolutely hate unrelevant changes that dirty the whole lot just because it "works"
[23:42:42] superm1: jya: no it's not that msvc changes are relevant to debian, when I was digging through for what broke with MSVC it remiinded me to see what it would take to make deb's compatible to debian policy not just ubuntu policy
[23:43:26] stuartm: superm1: ok thanks, I was trying to figure out if I'd screw up while editing my lircrc some time back, or whether it was the generated file, but it had bound both 'Next' and 'FFWD' on an mceusb remote to the same button, ditto for 'Again' and 'RWD'
[23:43:33] jya: there are so many of those brute force changes in configure and the other .pro files… you always end up finding places where it's not appropriate (and I found just on of those compiling on the Pi where the OGL libraries where in a different location
[23:43:37] superm1: is supposed to basically automatically handle things
[23:44:10] superm1: jya: where do you think the best place to put a change like that is then? I'm a bit baffled how else to get LDFLAGS into the qmake part of the build
[23:44:33] jya: superm1: which lib are you missing and where?
[23:45:10] stuartm: superm1: how can I prevent my lircrc being overwritten, is it possible short of removing write perms?
[23:45:12] superm1: jya: well no libs are missing, but the -Wl,-z,relro is a policy in debian but it doesn't get applied during any linking
[23:45:28] superm1: stuartm: just move it out of the way somehere else
[23:45:49] jya: I'm not sure what the problem is if it isn't missing any libs why would you need to change the ldflags globally?
[23:45:53] stuartm: superm1: hmm, remove write perms it is then :)
[23:46:00] superm1: heh
[23:46:35] superm1: jya: LDFLAGS can still pass options to the linker, specifically in this case for read only relocations
[23:47:46] superm1: . . . _-z_relro.29 explains what it actually is
[23:48:56] jya: superm1: I'll have a look later today, got to take the kids to the science museum today
[23:49:01] superm1: Ok
[23:49:41] jya: IRC, there's already an variable that is passed to qmake, extra_ldflags or something like that
[23:51:17] superm1: it's only passed to the ffmpeg part of the build from what I can tell
[23:51:40] superm1: all the binaries in ffmpeg pass the hardening check, but nothing out of the qmake part does
[23:53:12] stuartm: looking at those scripts it seems like the mapping issue was my fault :)

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.