MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (89):

45PAAODBD, aloril, Anssi, antgel, anykey_, brfransen, CaCtus491, Captain_Murdoch, cattelan_away, Chutt, clever, cocoa117, coling, Cougar, damaltor, danielk22, David_Mi1ler, dblain, dekarl, dinamic|screen, eharris, ElmerFudd, foobum, foxbuntu, frankster, ghoti, Glenuk, gregL, GreyFoxx, highzeth, idl0r, J-e-f-f-A, jams, jarle, jcarlos, joe____, joki, jpabq, jstenback, jwh, jwhite, kc, knightr, kormoc, kurre2, kwmonroe, laga, mag0o, map7_, markcerv_, Mousey, mrand, mrec, MythBuild, MythLogBot, mzanetti, NightMonkey, peitolm, Peps, petefunk, poptix, purserj, rsiebert, seld, sensesay_, Sharky112065, Slasher`, SmallR2002, sphery, sraue, stichnot_, stuarta, sutula, taylorr, tgm4883, ThisNewGuy, tomimo, tris, Unhelpful, vallor, Vernon_at_work, wagnerrp, wahrhaft, wseltzer, xavierh, XChatMav, XDS2010_, yb0t, _charly_
Wednesday, June 6th, 2012, 00:00 UTC
[00:00:16] stichnot: In that vein, I was planning on delaying this work until closer to the release to minimize impact on backports.
[00:00:52] knightr: if the underscore is not permitted, "Common_Strings" might be nice...
[00:00:58] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 260 seconds)
[00:01:35] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv
[00:02:00] knightr: stichnot, good idea (especially on a large scale, it will have to be not too close to release though otherwise we'll piss them off if we have too much work for them to do at the last minute...)
[00:02:37] knightr: stichnot, is there any portable way to retrieve the class name in C++?
[00:02:59] stichnot: Good point. So I'll try to use judgment about how early to make changes.
[00:04:37] stichnot: knightr: personally, I would just define a static function in each file, something like static void TR(QString s1, QString s2="") { QCoreApplication::translate("MythPlayer", s1, s2); }
[00:04:53] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.)
[00:05:22] stichnot: it's not quite as precise if there's more than one class defined in the file, but at least it refines the context to the file level instead of QObject
[00:05:32] knightr: ah, I was thinking more of a macro (I'm no C++ guru though so maybe it's not doable to do it with a macro)
[00:06:32] knightr: yep, it's better and anyway if there ar emore than one class they are related in what they are used for...
[00:09:12] knightr: disambiguation string is infrequently used BTW, it's only needed when you want to make sure you differenciate between the two string which have the same context, same English text but might have different translation...
[00:10:06] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds)
[00:18:28] taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has joined #mythtv
[00:18:44] taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has quit (Changing host)
[00:18:44] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv
[00:37:30] kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 244 seconds)
[00:50:47] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[01:56:18] Mousey (Mousey!~r0dent_@ross154.net) has quit (Remote host closed the connection)
[01:56:54] dekarl1 (dekarl1!~dekarl@p4FE84F08.dip.t-dialin.net) has joined #mythtv
[01:59:22] dekarl (dekarl!~dekarl@p4FCEE964.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[02:04:41] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection)
[02:34:12] aramus (aramus!442d0862@gateway/web/freenode/ip.68.45.8.98) has joined #mythtv
[02:34:24] aramus (aramus!442d0862@gateway/web/freenode/ip.68.45.8.98) has quit (Client Quit)
[02:48:09] stichnot (stichnot!~chatzilla@192.55.54.38) has joined #mythtv
[02:48:09] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[02:48:09] stichnot (stichnot!~chatzilla@192.55.54.38) has quit (Changing host)
[03:02:03] stichnot: jya: I might be able to make it up to SF some weekday next week after work (except for Tuesday)
[03:03:02] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[03:04:59] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[03:05:46] wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has quit (Quit: No Ping reply in 180 seconds.)
[03:06:03] wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has joined #mythtv
[03:06:25] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 260 seconds)
[03:06:25] jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has quit (Ping timeout: 260 seconds)
[03:06:52] jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has joined #mythtv
[03:14:19] jpabq: Can someone remind me where the "non exact seeking" setting is? Skipping "around" in HD-PVR is much slower lately, like that setting has gotten turned on by accident, but I can't remember what screen that is on. It is not so noticeable skipping forward, but it is very noticeable skipping backwards.
[03:18:24] jpabq: I should say, it is like "exact seeking" has gotten turned on.
[03:22:18] jpabq: Ok, I found http://code.mythtv.org/trac/changeset/4d0bbbe . . . 462f2/mythtv
[03:22:40] stichnot: yeah, I was just about to post that...
[03:22:51] jpabq: What I am experiencing is not so much that the *seek* takes a long time, it is that it takes much longer for the playback to smooth out after the seek.
[03:24:17] stichnot: My seeking back 7 seconds or forward 30 seconds is almost instantaneous, but now that you mention it, I do see a little stuttering for half a second until it smooths out
[03:24:44] jpabq: This is with VDPAU "normal". It really only takes about half a second for it to smooth out, but that is jarring compared to the way it used to be.
[03:26:01] jpabq: For normal watching, it is not a problem. However, I tend to skip around in sporting events like Tennis, and it is pretty harsh.
[03:27:31] stichnot: You could try changing MythPlayer::kInaccuracyDefault to 1.0 which would disable all exact seeking.
[03:27:39] jpabq: I wonder if the keyframes are not accurately being entered into the DB, such that on playback it is not actually starting on a keyframe?
[03:28:01] jpabq: stichnot, I will give that try.
[03:31:25] zombor (zombor!~zombor_@65.29.231.135) has joined #mythtv
[03:31:25] zombor (zombor!~zombor_@65.29.231.135) has quit (Changing host)
[03:31:25] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[03:31:27] stichnot: actually a value like 1000 would be better, though I think 1.0 will have the desired effect
[03:32:24] jpabq: Yup. Changing that to 1.0 took care of it. The stutter after seeking is gone (or is so short that it is no longer perceptible). Thanks.
[03:33:16] stichnot: I wonder what it would take to eliminate the stutter
[03:34:43] jpabq: taylorr, or mark spieth might have the best insight. Mark is the one that figured out how to make timestretch playback smoothly.
[03:38:29] jpabq: For now, I am happy to have a that fixed on my production machine. Thanks for the insight.
[03:38:42] stichnot: fwiw, the value kInaccuracyDefault=0.1 means that if you are seeking N frames away, it will attempt to snap to the nearest keyframe of the target if there is one within N*0.1 frames from the target.
[03:42:15] jpabq: If I understand correctly, that would mean that it would NOT find the closest keyframe by default? Especially given that the HD-PVR's keyframes are so far apart? Changing it to 1.0 means it will look farther afield for a keyframe?
[03:45:18] jpabq: If so, maybe it should be MAX(128, N*kInaccuracyDefault) ?
[04:00:55] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[04:06:37] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[04:11:07] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[04:34:13] stichnot: jpabq: changing it to 1.0 means that if you seek 5 seconds, it will look for a keyframe within 5 seconds of the target which is guaranteed in the case of hdpvr recordings with keyframe distance 128. I didn't understand which calculation you're suggesting should be max(128, N*...).
[04:37:07] cattelan is now known as cattelan_away
[05:29:19] jpabq: stichnot, Ah, I was thinking it was at a frame resolution, not seconds. In that case I should have said max(2, N*kInaccuracyDefault). But, I have not looked at the code, so will stop guessing.
[05:42:44] brfransen (brfransen!~brfransen@64.179.142.146) has quit (Ping timeout: 244 seconds)
[05:53:15] brfransen (brfransen!~brfransen@64.179.142.146) has joined #mythtv
[06:32:14] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Ping timeout: 245 seconds)
[06:49:11] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[07:20:57] zombor (zombor!~zombor_@65.29.231.135) has joined #mythtv
[07:20:57] zombor (zombor!~zombor_@65.29.231.135) has quit (Changing host)
[07:20:57] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[07:22:24] rsiebert_ (rsiebert_!~quassel@g226060187.adsl.alicedsl.de) has joined #mythtv
[07:25:09] rsiebert (rsiebert!~quassel@g226060180.adsl.alicedsl.de) has quit (Ping timeout: 245 seconds)
[07:33:26] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[07:48:37] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[08:04:49] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Quit: leaving)
[08:15:52] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc)
[08:25:55] jwh (jwh!~jwh@scarlett.lon.rewt.org.uk) has quit (Remote host closed the connection)
[08:26:12] jwh (jwh!~jwh@scarlett.lon.rewt.org.uk) has joined #mythtv
[08:30:44] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Ping timeout: 260 seconds)
[08:31:50] jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv
[08:32:48] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has joined #mythtv
[08:49:24] Goga777 (Goga777!~Goga777@2.95.188.189) has joined #mythtv
[09:11:48] Goga777 (Goga777!~Goga777@2.95.188.189) has quit (Remote host closed the connection)
[09:12:46] Sharky-Sleep (Sharky-Sleep!~Sharky112@c-67-170-55-74.hsd1.wa.comcast.net) has joined #mythtv
[09:13:24] Sharky112065 (Sharky112065!~Sharky112@c-67-170-55-74.hsd1.wa.comcast.net) has quit (Read error: Connection reset by peer)
[09:33:17] stuartm: danielk22: I can't seem to find what I'm looking for in the commit history (as far as github is concerned the UTC merge occurred out of thin air with all the history missing), you didn't include a replacement for the MythTimeToString() function, is that because calling MythDate::toString() with a QTime will perform an implicit conversion to QDateTime?
[10:02:04] colonelqubit (colonelqubit!~qubit@c-24-60-237-162.hsd1.nh.comcast.net) has joined #mythtv
[10:05:02] Guest53729 (Guest53729!~mike@c-98-232-220-158.hsd1.or.comcast.net) has quit (Remote host closed the connection)
[10:05:57] 45PAAODBD (45PAAODBD!~mike@c-98-232-220-158.hsd1.or.comcast.net) has joined #mythtv
[10:06:00] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[10:06:06] dekarl1 (dekarl1!~dekarl@p4FE84F08.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[10:10:30] Sharky-Sleep is now known as Sharky112065
[10:47:21] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[10:49:32] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[12:11:51] danielk22: stuartm: QTime is not timespec aware so it is best avoided. That said the MythDate::toString() does have a "kTime" to print just the time part of a QDateTime
[12:14:21] stuartm: aye, I noticed that kTime was still there
[12:15:37] stuartm: if we're no longer using QTime anywhere then the question is moot, I just happened to notice that there was no equivalent, but try as I might I can't see to get a single diff of all the changes made so I wasn't sure what affect that had
[12:26:59] danielk22: stuartm: There are a few places where we still use QTime, like the manual record screen and in MythTimer. But mostly QDateTime is used whenever possible. This was the case prior to the conversion too, there were only a few uses of QTime by itself to convert.
[12:33:23] stuartm: I didn't think there were many, but I did seem to recall some
[12:33:56] stuartm: can anyone spot whatever it is that I seem to be missing in http://code.mythtv.org/trac/ticket/10807#comment:2 ?
[12:34:40] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[12:35:12] stuartm: the valgrind output seems to be suggesting a leak in the QMap, I can't see a leak in MythUIStateType or anything wrong in the usage of QMap
[12:42:51] danielk22: stuartm: Calling GetChild() and then delete on what is returned leaves the child in the m_ChildrenList.
[12:43:04] danielk22: stuartm: The middle change can be ignored.
[12:44:24] danielk22: stuartm: The last change is to add DeleteAllChildren() to the destructor. I'm surprised that wasn't already there.
[12:44:53] stuartm: yeah, the first/last parts of the patch are correct, I just wasn't sure how they related to the valgrind report – in fact they don't appear to do so and I can't explain the valgrind stuff
[12:45:21] stuartm: danielk22: it's not required, QObject destructor handles deletion of the children
[12:45:51] stuartm: as Isaac had to remind me more than once when I declared I'd discovered the same 'leak' :)
[12:47:18] danielk22: i.c. so these are in the QObject's child link.. in that case we should put some warning in the destructor...
[12:48:29] danielk22: I think valgrind is just seeing pointers to free'd memory in the QMap. The first part of the patch fixes that.
[12:49:18] stuartm: yeah, the constructor parents them to QObject, "MythUIType::MythUIType(QObject *parent, const QString &name)  : QObject(parent)"
[12:50:28] stuartm: danielk22: well the second report maybe, the first relates to a MythUIGroup not a ButtonList ...
[12:51:17] stuartm: I'll commit the good bits of the patch, maybe someone will manage to explain the valgrind report later on
[12:59:42] natanojl: stuartm: I'm not sure it's related but shouldn't the argument in MythUIType::DeleteChild(MythUIType *child) be MythUIType *&child or MythUIType **child for the "child = NULL" to have any effect?
[13:01:50] danielk22: jya: I'd like to merge in the devel/ceton branch sooner rather than later do you want to have a stab at porting the HLS stuff over first?
[13:02:28] jya: danielk22: sorry I don't follow… what is there to port ? you mean your rtp branch ?
[13:03:06] danielk22: jya: Yeah, the ceton branch includes the changes in the rtp branch + makes the ceton recorder use that code.
[13:03:21] jya: i see...
[13:03:48] jya: would I be able to make the HLS recorder also part of the IPTV/RTP recorder?
[13:03:51] danielk22: When running with just the utc branch I noticed how bad the ceton recordings were without it... so I want to get that in before 0.26.
[13:04:17] stuartm: natanojl: no, that's correct, we pass in a pointer and want it to be pointing at NULL after the child has been deleted
[13:04:23] danielk22: I dunno, what are the HLS requirements?
[13:05:01] jya: danielk22: not sure there are any… I went for the simplest… the IPTV recorder expect a TS stream, so I just output that.
[13:05:39] jya: the iptvrecorder class provided all that was required for tuning, interrupting etc..
[13:06:15] natanojl: stuartm: I'm not sure I agree :)
[13:06:30] jya: plus I liked that it took a m3u playlist to define channels. I didn't feel like having to manually set a new recorder for each channel was worth the trouble (I don't like that option)
[13:06:43] danielk22: jya: I think you really just want a separate recorder. DTVRecorder handles pretty much everything when you pass a TS stream the the MPEGStreamData.
[13:07:26] jya: danielk22: but if I do go for a separate recording option, I have to handle all the m3u stuff again myself...
[13:07:43] jya: the iptvrecorder does all that already
[13:08:18] danielk22: I sounds like you just want the m3u stuff and nothing else. There is a class that handles just that.
[13:08:22] jya: does the new RTP stuff manage the m3u parsing ? if so, I'll go with that class and plug my stuff in
[13:09:08] danielk22: yeah, let me find the class. I think it's the only class that I got from the old iptv recorder.
[13:09:08] jya: danielk22: do as you feel is best.. if it means removing the HLS recorder for the time being so be it. and give me some pointer on how I can parse m3u myself..
[13:09:25] jya: but I won't be able to re-add HLS for at least a month, if not more
[13:10:29] danielk22: IPTVChannelFetcher — pretty much in tact, just parses some extra #EXTMYTHTV fields.
[13:10:46] danielk22: jya: Right, you are traveling.. Coming to the NYC area?
[13:11:08] jya: unfortunately, no… SF then Reno & Carlson City
[13:11:37] jya: but when I get back, renovation at our house will start, have to move out… that will take me offline for a while
[13:12:15] danielk22: I'll take a look at the HLS stuff & if I grok it fairly quickly I'll create a new recorder or port as appropriate.
[13:13:08] jya: danielk22: the HLS recorder is trivial, 99% of the work is done in the hlsringbuffer class
[13:13:09] natanojl: stuartm: The child pointer is passed as a copy so the child = NULL has no effect except locally in that function. That's why *& or ** is needed
[13:13:39] stuartm: natanojl: right, sorry brain's on Holiday
[13:13:58] danielk22: jya: Yeah, it sounds like I can whip up a fairly trivial new recorder around it.
[13:14:29] jya: so can we change channels in livetv for the IPTV stuff ? :)
[13:15:06] danielk22: With the new IPTV stuff yeah.. but I still plan to take a look at the old one for backport to 0.25 reasons..
[13:16:09] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[13:22:48] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[13:23:51] stichnot: I just upgraded to post-UTC merge. I see a couple of minor issues so far.
[13:24:21] stichnot: Backend status page now shows a lot more than 4 hours worth of job queue jobs.
[13:25:00] stichnot: Mythweb upcoming recordings page. When I mouse over an upcoming recording, a description for the wrong show pops up.
[13:26:02] danielk22: stichnot: Can you create tickets? I should be able to address them all fairly quickly, but I don't want any reports to get lost.
[13:27:29] stichnot: Will do.
[13:27:53] danielk22: thx
[13:29:42] stichnot: while I'm at it, preview generation seems to be using the first frame, rather than the bookmark or the other fancy cutlist/skiplist/padding calculation
[13:31:53] map7_ (map7_!~map7@ppp118-209-23-122.lns20.mel4.internode.on.net) has joined #mythtv
[13:33:31] stichnot: hmm, the preview generation thing is a little weird. It's working for an in-progress recording, but not for any of the pre-UTC recordings. I'll see what happens in 30 minutes after this recording finishes.
[13:35:04] danielk22: stichnot: maybe we are relying on the name of the recording to give us the recstarttime of the recording somewhere in the preview generation?
[13:36:23] stichnot: sounds plausible. I'll take a quick look at all of these issues before opening tickets in case it's obvious.
[13:38:55] amessina (amessina!~amessina@2001:470:1f11:a4:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[13:39:15] knightr: stuartm, those ind of translation (concatenated strings) are about the same thing I can change code-wise without review... I will work on them when I get the chance so please leave me some...
[13:41:14] foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has quit (Ping timeout: 246 seconds)
[13:43:13] knightr: oops, s/same/onlly geez, I need a coffee..
[13:46:19] foxbuntu (foxbuntu!~foxbuntu@75-170-214-203.desm.qwest.net) has joined #mythtv
[13:46:25] foxbuntu (foxbuntu!~foxbuntu@75-170-214-203.desm.qwest.net) has quit (Changing host)
[13:46:25] foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has joined #mythtv
[13:49:26] stichnot: Pre-UTC recordings can't be edited because it thinks there is no seektable. (possibly related to the preview generator issue)
[14:04:10] stuarta: i'd guess they would be the same, since all the metadata is keyed off the starttime/endtime etc
[14:08:56] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[14:18:38] stichnot: looks like preview generation doesn't quite work because of the belief that there is no seektable – first line of MythPlayer::SeekForScreenGrab()
[14:19:57] eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv
[14:24:05] ** knightr must be losing his mind, I meant to say "those kind of translation tickets (concaternated strings and the like) are about the only thing I can change code-wise without review"). **
[14:38:35] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Remote host closed the connection)
[14:39:21] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[14:40:57] tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has quit (Quit: Ex-Chat)
[14:50:12] tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[15:02:57] map7_ (map7_!~map7@ppp118-209-23-122.lns20.mel4.internode.on.net) has quit (Read error: Operation timed out)
[15:07:27] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[15:09:01] sphery: though stichnot has disappeared, it does look like the DB update missed updating recordedseek and recordedmarkup
[15:09:29] sphery: unfortunately, if not fixed quickly, the housekeeper will delete all of the old seek tables and marks (daily cleanup of recorded* tables)
[15:09:55] stuartm: ouch
[15:10:09] stuartm: glad I held off updating
[15:10:27] sphery: also, recordedrating, recordedcredits need updates
[15:11:54] sphery: actually, looks like credits is there, so just seek, markup, and rating
[15:12:12] danielk22: sphery: I'll add those tables to an update today..
[15:13:10] sphery: yeah, it's not /that/ big a deal--only data we'll lose that's not re-creatable by tools is bookmarks... users can run mythcommflag --rebuild on all recordings and then run mythcommflag on all recordings to get back data
[15:13:40] sphery: sorry I missed that the other day... Didn't look closely enough at the update when you dekarl was asking about DST on it
[15:15:23] sphery: and the only users who will lose data are those whose daily housekeeping run occurs after the 1303 update, and before 1304
[15:15:50] sphery: (and, only those who updated between updates)
[15:16:25] stuartm: maybe a warning to the list though? So those affected can decide to take their backends offline until a fix is available?
[15:16:40] sphery: sounds like it would be a useful thing
[15:19:21] sphery: technically, they could work around it with: UPDATE housekeeping SET lastrun = DATE_ADD(NOW(), INTERVAL 24 HOUR) WHERE tag = 'DailyCleanup';
[15:19:26] sphery: to delay their cleanup
[15:19:47] sphery: do you want to send an e-mail?
[15:19:54] danielk22: I've sent a mail to the list. Thanks for finding this sphery.
[15:20:14] sphery: thanks for taking care of it (and the e-mail)
[15:32:20] sphery: (oh, and apologies for not having already switched us to the recordedfile schema, which will use IDs rather than chanid/starttime for all these foreign references, so would have made this change a lot easier)
[15:34:56] sphery: danielk22: I'm wrong... we do need an update for recordedcredits
[15:35:41] sphery: danielk22: your update of credits affects the credits for shows in program, but recordedcredits keeps credits info for shows that have been recorded (since they will often exist long after program listings are removed)
[15:36:48] sphery: danielk22: so that means recordedseek, recordedmarkup, recordedrating, and recordedcredits
[15:38:36] sphery: danielk22: and recordedprogram...  :)
[15:46:32] sphery: (and ignore the existing recordedfile--it's not used anywhere and I have a DB update that removes it, which will be pushed just before the update that adds the "new" recordedfile table)
[15:47:00] stichnot (stichnot!~chatzilla@192.55.54.38) has joined #mythtv
[15:47:00] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[15:47:00] stichnot (stichnot!~chatzilla@192.55.54.38) has quit (Changing host)
[15:49:28] danielk22: sphery: What is the ETA on the recordedfile stuff? 0.26 ?
[15:56:59] stichnot: good ... my DailyCleanup isn't scheduled for another 5 hours :)
[16:03:44] stuartm: so LinkedIn has leaked user email addresses and passwords ... unsalted hashes
[16:04:18] stuartm: an impressive gaff for a site that claims to be for IT professionals
[16:09:07] stichnot: "for", not "by", I suppose
[16:15:57] stuartm: seems that way :)
[16:17:31] Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv
[16:18:06] stuartm: three hours after first acknowledging the reports of a leak they are still saying they have not confirmed there was a leak, although lots of users are popping up to say their credentials were among those posted on a Russian website
[16:18:57] joki (joki!~joki@p54862229.dip.t-dialin.net) has quit (Ping timeout: 250 seconds)
[16:19:17] stuartm: two possibilities, either they are just dithering and delaying or I guess there's still a possibility that the 'leaked' details were in fact taken via phishing
[16:19:20] joki (joki!~joki@p54865648.dip.t-dialin.net) has joined #mythtv
[16:25:00] sphery: danielk22: Originally I was hoping for 0.26, but with the talk of a short release cycle, I wasn't sure. I do plan to get the tables in place, soon, then start the actual conversion in a branch, so it can go in when it's ready.
[16:26:11] stichnot: As for the jobqueue entries showing up for jobs more than 4 hours old, it looks like the schema update modified all jobqueue.statustime values (as the schema says it should do), so this is most likely a "problem" that will fix itself soon after an upgrade.
[16:28:37] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)
[16:30:12] stuartm: sphery: tbh I'm not sure whether the short cycle plan is really on track, one of the aims was to get all the 'unfinished' stuff from 0.25 finished for 0.26 so we could start fresh for 0.27 but the web based setup stuff has stalled, the mythmusic overhaul likewise, HLS is making progress but slowly
[16:31:24] stuartm: little of the polishing that I imagined doing has actually been done, so ultimately I have to wonder what the point of sticking to that 0.26 release date really is
[16:34:04] stuartm: a lot of what has happened so far in master has been bug fixing, much of that has been backported, so not much sets 0.26 apart from 0.25 and users might rightly be wondering why for a second successive release so much seems to be left incomplete
[16:34:46] stichnot: danielk22: in HttpStatus::PrintEncoderStatus() there is a pair of lines os << "scheduled to end at " << endTs.toString(timeformat); How to get endTs rendered as local time instead of UTC?
[16:35:32] sphery: stuartm: Yeah, that's a good point. Either way, I figure it's best to work on the changes in a branch (with a big old warning) so that I can merge it when I feel it's ready.
[16:35:41] stichnot: on a side note, doesn't HttpStatus have a whole bunch of untranslated strings?
[16:36:12] danielk22: endTs.toLocalTime().toString(timeformat); should work.. or could possibly use MythDate::toString() and use one of the standard formats.
[16:36:19] sphery: stichnot: yeah, I think knightr had plans for adding translations for HttpStatus
[16:36:41] knightr: stichnot, if it`s the web status page, it`s untranslated...
[16:37:13] knightr: it`s served by the backend and before the web setup went in, the backend had no translation...
[16:38:06] knightr: I beliee someone who is no longer with us had mentionned that this page would be redone but if it`s not I could translate it...
[16:39:46] knightr: Thing is, I kinda feel weird with having the backend process supporting languages in the same process that handles scheduling, recording, etc... everything that deals with the user should be in another process IMHO...
[16:39:55] stuartm: stichnot: for consistency I'd use MythDate::toString(endTs, MythDate::kTime);
[16:40:35] Goga777 (Goga777!~Goga777@95-30-73-47.broadband.corbina.ru) has joined #mythtv
[16:40:36] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Remote host closed the connection)
[16:40:49] knightr: unless I misunderstood what was done for the web setup we support one language (and one language only) in the backend.
[16:41:26] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv
[16:41:30] knightr: If the part that deals with the user was in another process these process could load different translation files (and support different languages...)
[16:41:42] stichnot: danielk22: I'll test the former suggestion and check it in, if that's OK
[16:41:53] danielk22: go ahead
[16:42:29] knightr: if we merge MythWeb in the backend like some people suggested we will lose the flexiblity of supporting multrile languages with the same backend we had...
[16:43:07] Goga777 (Goga777!~Goga777@95-30-73-47.broadband.corbina.ru) has quit (Client Quit)
[16:43:42] knightr: sphery, actually I didn`t as (like I said above) I thought it was supposed to disappear and be redone the same way as the web setup...
[16:44:14] sphery: knightr: some of that split might be handled when we (finally) get around to splitting up mythbackend
[16:45:56] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[16:46:27] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[16:47:28] stuartm: knightr: done that way you'd need multiple 'mythweb' processes running to support multiple languages?
[16:49:29] stuartm: fwiw translations don't have to be done application wide, you can translate into multiple languages from a single process – see QTranslator
[16:49:34] stichnot (stichnot!chatzilla@nat/intel/x-jwpsvlehagxvnsga) has joined #mythtv
[16:49:34] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv
[16:49:34] stichnot (stichnot!chatzilla@nat/intel/x-jwpsvlehagxvnsga) has quit (Changing host)
[16:50:15] stuartm: so we can at runtime switch which translation we use when responding to an http query
[16:50:48] stuartm: brb
[16:55:39] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Read error: Connection reset by peer)
[16:55:57] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[17:02:14] stichnot: I try to create a new recording rule (either "record only this showing" or "any time on any channel") via mythweb, and I think the scheduler is refusing to record episodes within the next N hours possibly because it thinks the episodes are in the past.
[17:03:33] stichnot: danielk22: I'm impressed by the small number of issues from such a pervasive change.
[17:08:42] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[17:11:10] stoffel (stoffel!~quassel@pD9E43A6D.dip.t-dialin.net) has joined #mythtv
[17:15:19] sphery: stichnot (I think he's trying to ignore me... His ninja join/leave ability...): we have some (mysql) NOW() usage in scheduler.cpp that needs cleaned up
[17:24:01] knightr: stuartm, QTranslator is finicky and changing them on the fly doesn`t always work (in some circumstances, it can crash according to what I read)...
[17:25:05] knightr: ttyl
[17:25:40] stoffel (stoffel!~quassel@pD9E43A6D.dip.t-dialin.net) has quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
[17:28:12] sphery: stichnot: if you do change the NOW() stuff in scheduler.cpp, it would be much better if you pass in a QDateTime through prepared query bind variables, so that text format of the date/time doesn't come into play. It looks like all are prepared queries--even if they don't use bind variables--so shouldn't be too difficult to do it that way.
[17:29:37] danielk22: sphery: stichnot: hmm, I haven't had that problem with manual records (i.e. they happen even if scheduled seconds in advance). Although this makes me think that there may be issues with timezones ahead of GMT that I wouldn't have encountered on my local system.
[17:31:51] danielk22: sphery: The NOW() is ok, see mythdbcon.cpp:183.
[17:32:22] sphery: ah, ok
[17:33:29] danielk22: stichnot: I'm surprised at how quickly significant issues have been found. :)
[17:34:28] stoffel (stoffel!~quassel@pD9E43A6D.dip.t-dialin.net) has joined #mythtv
[17:37:41] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[17:42:28] SteveGoodey (SteveGoodey!~steve@host86-160-43-123.range86-160.btcentralplus.com) has joined #mythtv
[17:42:46] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Remote host closed the connection)
[17:43:26] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[17:43:28] sphery: danielk22 / stichnot: perhaps that should be m_db.exec("SET @@session.time_zone='+00:00'");
[17:43:35] sphery: i.e. change local to session...
[17:44:05] danielk22: sphery: I'm not a mysql expert.. can you explain the difference?
[17:44:21] sphery: local variables have scope within a statement or block of statements, so I wouldn't be surprised if it goes out of scope after, say, completing a prepared statement
[17:44:29] sphery: session scope is "on the connection"
[17:44:54] sphery: it definitely won't hurt to change it, and just might fix the issue he's seeing
[17:44:56] danielk22: Ok, it sounds like it should definately be session then.
[17:47:54] danielk22: The mysql docs seem to only talk about a session and global time_zone. I wonder where I read to use @@local.
[17:48:33] sphery: hehe, I'm sure someone out there on the internet has a page that says to :)
[17:48:50] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:57:39] kormoc: sphery, "LOCAL and @@local. are synonyms for SESSION and @@session."
[18:00:25] stichnot (stichnot!~chatzilla@192.55.55.37) has joined #mythtv
[18:00:25] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[18:00:25] stichnot (stichnot!~chatzilla@192.55.55.37) has quit (Changing host)
[18:00:31] sphery: ah, then that won't help :(
[18:04:40] stoffel (stoffel!~quassel@pD9E43A6D.dip.t-dialin.net) has quit (Ping timeout: 250 seconds)
[18:05:49] danielk22: stichnot: Can I assume you updated mythweb too?
[18:06:06] stichnot: danielk22: no, you can't :)
[18:07:03] danielk22: :) Well that will cause some issues.. I was struck initially by how much of mythweb worked without changes, but it did need a few changes to work with UTC.
[18:08:34] danielk22: mythweb already works with utc internally but it relies on the DB for conversion in some cases and the backend timezone in other cases.
[18:10:23] kormoc: danielk22, how's that looking? Any key area that needs work right now?
[18:11:56] danielk22: kormoc: no known issues atm. except what jim is reporting and I think he needs to update :)
[18:12:03] kormoc: snaz!
[18:16:33] gigem: stuartm, danielk22: If it's not too late already (I'm behind on IRC), the job queuing fix really should go into 0.25.1 too.
[18:20:19] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
[18:25:39] danielk22: gigem: I believe stuartm already cut 0.25.1 & I just committed the fix to master.
[18:27:29] stuartm: 0.25.1 was tagged/released on Monday
[18:27:58] stuartm: there was no accompanying announcement
[18:29:50] danielk22: stuartm: Did you see the message on mythtv-dev about tagging mythweb as well?
[18:30:33] danielk22: gigem: stuartm: Nothing prevents us from tagging a 0.25.2 in short order, right?
[18:30:48] zombor_ (zombor_!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv
[18:30:48] zombor_ (zombor_!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host)
[18:30:48] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv
[18:30:58] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Read error: Operation timed out)
[18:31:06] stuartm: danielk22: no, the release script was supposed to do the tagging, I guess it didn't account for mythweb being in a different repo
[18:31:25] stichnot (stichnot!~chatzilla@192.55.55.37) has joined #mythtv
[18:31:25] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[18:31:25] stichnot (stichnot!~chatzilla@192.55.55.37) has quit (Changing host)
[18:31:25] stuartm: danielk22: could do it right now, doesn't take much work
[18:32:15] danielk22: stuartm: I'd like to look at fixing LiveTV iptv. I should have a little time for that this weekend.
[18:32:41] stuartm: hmm, release script does indicate that it will tag mythweb too, I'll have to do it manually for now and figure out where it went wrong later
[18:33:04] stuartm: danielk22: ok, Monday then?
[18:33:12] stuartm: or just let me know when you're ready
[18:33:36] danielk22: ok, Monday is probably good. I'll let you know.
[18:34:29] stuartm: heh, ok release script did tag 0.25.1, it just didn't push the tags – just done that
[18:37:04] stuartm: Beirdo: any idea why that would be the case? The same commands are called for both repos but it seems it never pushed the 0.24.3 or 0.25.1 tags
[18:37:21] stuartm: for mythweb
[18:37:40] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[18:44:33] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Quit: leaving)
[18:49:09] gigem: danielk22: It was your commit to master that reminded me about it. I knew it was being discussed, but I didn't see anything that said it was actually done.
[18:51:38] stichnot: danielk22: updating mythweb (and restarting the browser to deal with some browser cache weirdness) seems to have resolved all the problems I saw
[18:51:50] stichnot: oh, plus the minor commit I pushed
[18:52:14] stichnot: the scheduler is doing what I expect when scheduling recordings via mythweb
[18:52:55] stichnot: I guess the good outcome here is that when users report such problems, we'll know to remind them to update mythweb...
[18:53:24] cattelan_away is now known as cattelan
[18:55:40] stichnot: as expected, the "job queue entries more than 4 hours old" issue cleared up 4 hours after the upgrade
[18:58:31] stichnot: regarding 0.26 release timing. I want to try refactoring teletextscreen.cpp and subtitlescreen.cpp into a common framework, but I want plenty of time before a release for testing, so I've put that off based on the expectation of an early 0.26 release.
[19:03:20] ocrateb (ocrateb!~ocrateb@s83-177-186-55.cust.tele2.se) has joined #mythtv
[19:03:20] ocrateb (ocrateb!~ocrateb@unaffiliated/ocrateb) has joined #mythtv
[19:03:20] ocrateb (ocrateb!~ocrateb@s83-177-186-55.cust.tele2.se) has quit (Changing host)
[19:15:06] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has joined #mythtv
[19:28:37] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Remote host closed the connection)
[19:29:17] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[19:43:59] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 244 seconds)
[19:45:47] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[19:46:26] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[19:48:46] abqjp (abqjp!c742f80c@gateway/web/freenode/ip.199.66.248.12) has quit (Ping timeout: 245 seconds)
[19:48:57] superm1 (superm1!u4318@ubuntu/member/superm1) has quit (Remote host closed the connection)
[19:50:07] XDS2010_ (XDS2010_!u1218@gateway/web/irccloud.com/x-eaxdcwcbvkwqqqcp) has quit (Remote host closed the connection)
[19:55:07] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Remote host closed the connection)
[19:57:30] jwh_ (jwh_!~jwh@scarlett.lon.rewt.org.uk) has joined #mythtv
[19:58:35] jwh (jwh!~jwh@scarlett.lon.rewt.org.uk) has quit (Read error: Connection reset by peer)
[19:58:35] jwh_ is now known as jwh
[19:59:20] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[20:05:40] XDS2010_ (XDS2010_!u1218@gateway/web/irccloud.com/x-zqvhqmvhmzkvtich) has joined #mythtv
[20:07:13] Beirdo: stuartm: I may have missed the push of the tag in the script
[20:10:21] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[20:12:49] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Remote host closed the connection)
[20:13:37] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv
[20:13:53] stichnot (stichnot!~chatzilla@192.55.55.39) has joined #mythtv
[20:13:53] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[20:13:53] stichnot (stichnot!~chatzilla@192.55.55.39) has quit (Changing host)
[20:14:52] stichnot: Should 0.25.2 be added to the trac milestones?
[20:19:49] taylorr: jpabq: I tried to tune to channel 219 on directv to watch an infomercial about the best pillow ever and it not only wouldn't get a lock but would leave my HD-PVR in a state that it had to be rebooted
[20:20:28] taylorr: wondering if it's 480i and possibly the new code not working well with it.... I haven't had one single isssue with 720p and 1080i channels
[20:20:54] taylorr: the worst part is I now don't know which pillow to buy :)
[20:25:56] danielk22: stichnot: added
[20:26:57] stichnot: thx
[20:38:16] SteveGoodey (SteveGoodey!~steve@host86-160-43-123.range86-160.btcentralplus.com) has quit (Remote host closed the connection)
[20:39:11] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[20:40:11] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: http://www.youtube.com/watch?v=yEtg7QZCbPk Good Dog.)
[20:41:00] sphery: and I added a 0.25.1 to versions
[20:46:22] stoffel (stoffel!~quassel@pD9E43A6D.dip.t-dialin.net) has joined #mythtv
[20:51:23] superm1 (superm1!u4318@gateway/web/irccloud.com/x-hirwnpfqmllotwpy) has joined #mythtv
[20:51:23] superm1 (superm1!u4318@ubuntu/member/superm1) has joined #mythtv
[20:51:23] superm1 (superm1!u4318@gateway/web/irccloud.com/x-hirwnpfqmllotwpy) has quit (Changing host)
[20:56:33] dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat)
[21:00:54] colonelqubit (colonelqubit!~qubit@c-24-60-237-162.hsd1.nh.comcast.net) has quit (Ping timeout: 260 seconds)
[21:19:03] xris: who's working on the ffmpeg sync stuff?
[21:23:39] Dj_FlyBy[MS] (Dj_FlyBy[MS]!~djflyby-m@75-119-235-229.dsl.teksavvy.com) has joined #mythtv
[21:25:16] stuartm: xris: Beirdo and jya have both done syncs in this cycle
[21:25:46] Beirdo: jya most recently
[21:26:09] Beirdo: I'm mostly hands off it for the moment as he's been working with it
[21:26:43] danielk22: jya: Is offline for the next month or so...
[21:28:00] Beirdo: ick
[21:28:13] Beirdo: OK, well, I guess I'll fill in as best I can then :)
[21:28:15] xris: looks like ffmpeg tries to build crystalhd if the libs are installed, no matter what
[21:28:20] Beirdo: just didn't want to stomp on his toes
[21:28:37] Beirdo: xris: I'll take a look tonight, see if I can't make it behave
[21:28:49] xris: but maybe beirdo's right (from private IM conversation) that it's probably easier for me to just disable ti as an option in the rpm
[21:29:11] Beirdo: yeah, if you don't have the hardware, there's just no point, really
[21:29:19] xris: next set of fedora17 build errors are things like: audio/audiopulsehandler.cpp:255:21: error: 'usleep' was not declared in this scope
[21:29:35] Beirdo: oh fun
[21:30:41] stuartm: heh, LinkedIn are trotting out that old favourite about password security – 1) make it complicated and hard to remember, 2) never use the same password on another site 3) change it frequently 4) never ever write it down ... yeah, that's all perfectly feasible, of course you have to write them down because you've no chance of remembering the dozens of passwords you'll have and which sites they belong to
[21:30:46] Beirdo: it's supposed to use the one from the Qt class
[21:32:27] xris: stuartm: 1password ftw  ;)
[21:32:28] ** jwh has a list of passwords on his desk **
[21:32:55] xris: I used to use an encrypted vim file but decided I should probably start using something my wife could understand
[21:33:00] jwh: chance of someone breaking into the right house and finding password list under all my mess: almost 0
[21:33:04] Beirdo: a former coworker used to write down the root password for work systems on a post-it and put it in his unlocked filing cabinet
[21:33:04] stuartm: Beirdo: it's funny but there's some stuff where we require the use of the Qt versions, and others where we prefer stdlib, it's not always easy to keep them straight
[21:33:09] jwh: chance of everyone being compromised: almost 100%
[21:33:31] Beirdo: stuartm: ick :) we should fix that
[21:34:20] Beirdo: now for my next nagios magic trick.
[21:34:28] Beirdo: I'm getting so sick of nagios
[21:34:50] stuartm: I actually use kwallet – basically an encrypted file of key (site) > value (password) pairs, I also have my browser (opera) remember most username/password combos for a one-click login – again it encrypts those
[21:36:46] stuartm: Beirdo: the logic is that stdlib is mostly portable and familiar to every C++ developer so it makes it easier for people with no knowledge of QT to contribute, whereas QT is better/more portable in specific areas and so preferred for some stuff
[21:37:08] stuartm: but these are unwritten rules and it's something of a minefield
[21:37:22] Beirdo: yeah, we should at least find a way to clean the minefield
[21:39:09] stuartm: usleep is deprecated in POSIX 2001 anyway
[21:39:23] Beirdo: for nanosleep, I'd assume?
[21:39:26] stuartm: but hardly any of our code respects that
[21:39:41] stuartm: Beirdo: yeah
[21:41:58] stuartm: actually, we might be overriding it in compat.h for linux
[21:42:24] stuartm: since I don't think Windows has nanosleep
[21:42:48] ** Beirdo facepalms **
[21:43:01] danielk22: stuartm: nanosleep has more complex semantics too. Not a great alternative..
[21:43:05] Beirdo: windows is the bane of our existance, I tell ya
[21:43:37] Beirdo: danielk: not really
[21:43:53] stoffel (stoffel!~quassel@pD9E43A6D.dip.t-dialin.net) has quit (Ping timeout: 246 seconds)
[21:43:55] Beirdo: you can put NULL for the remainder pointer and it should act about the same
[21:44:03] stuartm: danielk22: aye I agree it's not as simple
[21:44:13] Beirdo: but yeah, uses structures
[21:44:15] Beirdo: blech
[21:44:33] Beirdo: hardly as easy as usleep(number)
[21:44:49] sphery: Captain_Murdoch: http://code.mythtv.org/trac/ticket/10810 implies 2 things... a) that RemoteFile remotefile(filename, false, false, 0); actually populates RemoteFile's filesize field (which I see no evidence of in code, but haven't tested) and b) that RemoteFile::Exists() ignores hostname in myth:// URIs and just always sends a QUERY_FILE_EXISTS to the master backend (which only checks file systems it can see--where this one seems to ...
[21:44:55] sphery: ... be the case on initial inspection). Do you happen to know if either is the case? Any reason why RemoteFile::Exists() should ignore host name or why QUERY_FILE_EXISTS shouldn't check with remote backends (and any preference on which approach would be better--I'm leaning toward changing QUERY_FILE_EXISTS)?
[21:44:59] danielk22: We could create a wrapper myth_usleep() :)
[21:45:11] stuartm: fwiw I'm not advocating the use of nanosleep over usleep, just noting that the latter is deprecated and one day that might actually mean we have to switch
[21:47:05] stuartm: and no, we have nothing in compat.h for usleep/nanosleep
[21:51:56] stichnot: knightr, stuartm: If I have a wrapper function TR(const char *str) which calls QCoreApplication::translate("MyContext", str), will the strings passed to TR() be captured by the translation tools? Or do I need TR to be a macro?
[21:52:28] Beirdo: stichnot: I don't think that will work at all
[21:52:52] Beirdo: I tried to do something very similar to that, and the tools couldn't grok it
[21:53:17] Beirdo: check out the TR stuff in the devel-action-redo branch to see what I settled on that seemed to work
[21:53:52] stichnot: I was afraid of that. I'll have a look at yours
[21:54:05] Beirdo: if you can make it happy, by all means :)
[21:54:50] Beirdo: I fought with it for a few days before settling on that, and one of these days that branch will get some testing and measurements taken to show why it was worth the trouble... then merging
[21:55:30] stichnot: what's a good file to look at?
[21:56:00] Beirdo: umm, trying to recall. one moment
[21:56:31] Beirdo: mythtv/libs/libmyth/programtypes.* and recordingtypes.*
[21:57:05] Beirdo: I had to use QT_TRANSLATE_NOOP
[21:57:19] Beirdo: and QT_TRANSLATE_NOOP3
[21:57:54] Beirdo: and the Q_DECLARE_TR_FUNCTIONS
[22:07:19] stichnot: Q_DECLARE_TR_FUNCTIONS looks perfect, except that it inexplicably lacks the third argument of QObject::tr()
[22:07:53] gigem: danielk22: record.findtime and .findday need to be updated for UTC. The recordfilter.clause for the "In primetime" filter and several time-related, custom rule clauses need to be fixed too. The clauses will be tough because they really need to be done completely in SQL.
[22:11:05] dekarl (dekarl!~dekarl@p4FE84F08.dip.t-dialin.net) has joined #mythtv
[22:17:02] cattelan is now known as cattelan_away
[22:17:27] deevee_ (deevee_!~deevee_@c-75-73-17-173.hsd1.mn.comcast.net) has joined #mythtv
[22:18:48] natanojl: sphery: I had noticed the commflag issue in #10810 as well and was leaning toward changing QUERY_FILE_EXISTS. I looked at the code again and I think the patch is ok. The constructor calls Open() which calls openSocket() twice, where the second call should populate the filesize
[22:18:48] ** MythLogBot http://code.mythtv.org/trac/ticket/10810 **
[22:19:48] natanojl: I haven't tried the patch though, and it's time for some sleep now
[22:23:34] stichnot: looks like Q_DECLARE_TR_FUNCTIONS allows the third arg to tr(), despite the documentation
[22:25:17] rsiebert_ (rsiebert_!~quassel@g226060187.adsl.alicedsl.de) has quit (Remote host closed the connection)
[22:26:51] rsiebert (rsiebert!~quassel@g226060187.adsl.alicedsl.de) has joined #mythtv
[22:26:52] sphery: natanojl: ah, yeah, you're right--missed the ANN FileTransfer stuff (I skipped over it thinking, "there's no way it would actually transfer the file, yet, so that must be conditional," not realizing it's just an announce)
[22:30:26] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 265 seconds)
[22:32:07] rsiebert (rsiebert!~quassel@g226060187.adsl.alicedsl.de) has quit (Remote host closed the connection)
[22:33:21] Dj_FlyBy[MS] (Dj_FlyBy[MS]!~djflyby-m@75-119-235-229.dsl.teksavvy.com) has quit (Read error: Connection reset by peer)
[22:34:10] rsiebert (rsiebert!~quassel@g226060187.adsl.alicedsl.de) has joined #mythtv
[22:35:20] Dj_FlyBy[MS] (Dj_FlyBy[MS]!~djflyby-m@69-196-137-249.dsl.teksavvy.com) has joined #mythtv
[22:38:28] stichnot: so Beirdo, knightr, for my purposes, it looks like Q_DECLARE_TR_FUNCTIONS is the best way to go, letting you use tr() in classes not inheriting from QObject. In the rare cases that doesn't work (maybe less rare for Beirdo...), use QT_TRANSLATE_NOOP or QT_TRANSLATE_NOOP3.
[22:45:45] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[22:49:57] Beirdo: yes, that should do it
[22:50:56] xris: ok, rpm build scripts finally up to date. too bad it doesn't compile. heh.
[23:03:16] Beirdo: one thing at a time
[23:07:02] deevee_ (deevee_!~deevee_@c-75-73-17-173.hsd1.mn.comcast.net) has quit (Quit: Leaving)
[23:07:33] stichnot: stuartm: started doing my part at improving the translation infrastructure. I'll wait for feedback before continuing.
[23:14:28] Dj_FlyBy|MS| (Dj_FlyBy|MS|!~djflyby-m@69-165-148-31.dsl.teksavvy.com) has joined #mythtv
[23:16:50] Dj_FlyBy[MS] (Dj_FlyBy[MS]!~djflyby-m@69-196-137-249.dsl.teksavvy.com) has quit (Ping timeout: 252 seconds)
[23:29:22] Dj_FlyBy|MS| (Dj_FlyBy|MS|!~djflyby-m@69-165-148-31.dsl.teksavvy.com) has quit (Read error: Connection reset by peer)
[23:45:07] Dj_FlyBy|MS| (Dj_FlyBy|MS|!~djflyby-m@76-10-164-45.dsl.teksavvy.com) has joined #mythtv
[23:46:02] jya: xris: Beirdo : so you want to make crystalhd disable by default unless the user specify --enable-crystalhd or something ?
[23:46:11] jya: that's an easy change
[23:47:32] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc)
[23:47:35] xris: jya: that's what I ended up doing.
[23:47:56] xris: or rather, what I think myth does by default. but not ffmpeg
[23:48:18] xris: or ffmpeg changed the configure line to disable it.
[23:48:34] jya: xris: could behave the same if it used the same configuration setting variable as ffmpeg
[23:48:56] jya: AFAIK, myth uses its own detection code as when it was added ffmpeg didn't support it
[23:49:03] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.)
[23:49:31] xris: or ffmpeg doesn't have a configure option, and just looks at the environment.
[23:49:57] xris: Beirdo said he'd look into it, but it's low priority now that I've just fixed it in the rpm spec
[23:50:13] jya: xris: ffmpeg always have option for everything… it's just enabled by default or not
[23:50:55] jya: if enabled by default and the dependencies are met, it will be built
[23:50:57] xris: ah
[23:51:28] xris: that behavior bugs me about linux apps. if I specifically ask to enable something, configure should fail if it can't.
[23:51:59] Beirdo: that's just our/ffmpeg's crappy configure
[23:51:59] jya: in the configure script, there's a long list of variable that are set by default. remove it, and it's now disable by default
[23:52:14] jya: Beirdo: mplayer does that same
[23:52:43] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[23:52:55] Dj_FlyBy{MS} (Dj_FlyBy{MS}!~djflyby-m@76-10-141-113.dsl.teksavvy.com) has joined #mythtv
[23:52:55] jya: xris: configure doesn't do that… if a dependency isn't met, even if you did --enable-blah it will not build
[23:53:09] Beirdo: a *normal* autoconf configure would die happily
[23:53:31] jya: now, if it does, it's a bug that we introduced. I've seen it happening with our VAAPI autodetection, and the opengl one too
[23:53:40] map7_ (map7_!~map7@ppp118-209-177-6.lns20.mel6.internode.on.net) has joined #mythtv
[23:53:58] jya: oops, sorry, I misread… yes, it will not fail if it can't build
[23:54:21] jya: that probably make the life easier for packager...
[23:54:39] xris: well, in my case I was not enabling it (probably is by default in its own config), but ffmpeg was still building because I had the libs installed
[23:55:06] jya: xris: that's because it's enabled by default :)
[23:55:09] jya: let me have a look
[23:55:16] xris: but it's off by default in myth
[23:55:26] xris: so myth isn't sending "disable" to ffmpeg
[23:55:59] Dj_FlyBy|MS| (Dj_FlyBy|MS|!~djflyby-m@76-10-164-45.dsl.teksavvy.com) has quit (Ping timeout: 245 seconds)
[23:56:20] jya: xris: yep.. it is off by default.. so the bug is in our crystalhd detection
[23:57:04] jya: misuse of || and && in shell
[23:57:46] xris: ooh, a legit bug.  :) I'm useful today.
[23:58:06] jya: mythtv and ffmpeg use the same variable name
[23:58:15] jya: "crystalhd"
[23:58:25] jya: so if myth sets it, ffmpeg will build it
[23:58:28] Dj_FlyBy{MS} (Dj_FlyBy{MS}!~djflyby-m@76-10-141-113.dsl.teksavvy.com) has quit (Quit: Leaving)
[23:59:35] jya: xris: can you lodge this on trac and assign it to me.. I'll have a look later

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