MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (86):

aloril, andreax, Anduin, Anssi, anykey_, beata, BeeBob, Beirdo, brfransen, cattelan_away, cesman, chainsawbike, Chutt, clever, coling, Cougar, dagar, Dave123, dblain, dekarl, dlblog, eharris, f33dMB, foobum, ghoti, Gibby, gregL_, GreyFoxx, Guest90316, highzeth, iamlindoro, ikonia, J-e-f-f-A, j-rod|afk, jams, jarle, jcarlos, JEDIDIAH___, joe____, jpabq, jstenback, justinh, jwhite, kc, kenni, knightr, kormoc, kurre2, kwmonroe, laga, len, mag0o, Meliorator, moodboom, Mousey, MythBuild, MythLogBot, okolsi, PointyPumper, poptix, purserj, sailerboy, Seeker`, skd5aner, Slasher`, Snow-Man, sphery, sraue, stuarta, sturebror, sutula, ThisNewGuy, timlegge, tomimo, tris, Unhelpful, vallor, wagnerrp, wahrhaft, XChatMav, xris, ybot, yoyolala, zCougar, zombor, _charly__
Thursday, August 18th, 2011, 00:00 UTC
[00:00:24] hashbang (hashbang!~alex@213-152-35-50.dsl.eclipse.net.uk) has quit (Quit: Ex-Chat)
[00:01:32] andreax (andreax!~andreaz@p57B93AEE.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[00:01:47] moodboom (moodboom!~moodboom@63.173.119.85) has joined #mythtv
[00:01:48] moodboom (moodboom!~moodboom@63.173.119.85) has quit (Changing host)
[00:01:48] moodboom (moodboom!~moodboom@pdpc/supporter/active/moodboom) has joined #mythtv
[00:12:29] wagnerrp (wagnerrp!~Wagner@nr-ft1-66-42-241-137.fuse.net) has quit (Changing host)
[00:12:30] wagnerrp (wagnerrp!~Wagner@mythtv/developer/wagnerrp) has joined #mythtv
[00:20:15] Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has quit (Quit: Leaving)
[00:36:11] Mousey (Mousey!~wtfisme@ross154.net) has quit (Ping timeout: 240 seconds)
[00:42:57] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[00:52:12] kormoc_afk is now known as kormoc
[01:03:58] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[01:04:27] gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv
[01:04:28] gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host)
[01:04:28] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[01:14:30] gigem (gigem!~gigem@mythtv/developer/gigem) has quit ()
[01:16:17] gigem (gigem!~gigem@cpe-76-187-29-95.tx.res.rr.com) has joined #mythtv
[01:16:17] gigem (gigem!~gigem@mythtv/developer/gigem) has joined #mythtv
[01:16:17] gigem (gigem!~gigem@cpe-76-187-29-95.tx.res.rr.com) has quit (Changing host)
[01:19:14] taylorr: danielk22: if we saved the wall time to a variable when each video packet/frame arrived then we could check to see the time delta between the current packet and the last packet – then we could just have a threshold that if exceeded would mark the recording as bad
[01:20:48] taylorr: but if we have gaps in the recording then that would cause issues with position and duration
[01:21:59] taylorr: I wonder if pkt->duration is available when we parse the packet to perform the frame count
[01:22:10] jya: sphery: quick mysql question for you...
[01:23:03] danielk22: taylorr: frames arrive out of order with jitter also we don't feed it through libav when recording so there are no packets.. or pkt->duration...
[01:23:38] taylorr: ugggh, that's not good
[01:23:51] danielk22: taylorr: we just do a very light parsing that finds GOP or NAL headers.
[01:23:55] taylorr: is it that common to have gaps?
[01:25:38] danielk22: taylorr: More common than you would think.. I hardly ever have gaps, but I'm in a city with an overspeced antenna.. Lots of people put up with reception that would have me in a fit.
[01:27:42] taylorr: that's true – seems my plan has some serious issues then
[01:28:35] danielk22: We can detect gaps if they are large enough. If we have been able to detect the picture groups and then lose two in a row, we know there is a significant gap.
[01:28:38] taylorr: at least I'll have it right post commflag though since it runs through libav and we accumulate the duration for each frame
[01:29:44] danielk22: heh, John Stewart and Colbert are usually deleted before commflag gets a chance to finish with em. :)
[01:30:14] taylorr: yes and some people probably don't even run commflag on everything
[01:31:02] taylorr: I dunno – do you have any ideas how to properly handle the position/duration?
[01:32:29] taylorr: it seems like the only way would be to find the duration of each video frame received but we don't have that info
[01:33:14] danielk22: taylorr: I do, but right now it's just high enough on my priority list. I want to get the channel scanner into the html backend config before I embark on something like that.
[01:34:42] taylorr: true, the html backend config is much more important
[01:34:53] taylorr: position/duration is just cosmetic
[01:36:49] taylorr: ok, in the meantime I'll at least have everything working properly for commflagged material
[01:37:44] taylorr: this would be a piece of cake if we didn't have timestamp discontinuities
[01:38:15] danielk22: I think that's a good start.
[01:40:07] danielk22: Yeah, with broadcast material with gaps the discontinuities outside of wrap are relatively rare, but when you look at hardware encoding cards there can be multiple discontinuities in a single recording.
[01:40:27] taylorr: yes, the HDPVR is very bad about that
[01:41:24] taylorr: one other idea is the record the timestmp for every keyframe then a lot of possibilities would open up
[01:42:11] danielk22: I don't know if we could easily extract the pts with GOP/NAL parsing. But if so discontinuities with all MPEG recorders could be noted using a single piece of code.
[01:43:00] danielk22: We wouldn't really need to note it on every keyframe, we'd just need to note the start and stop of each range of continuous time stamps.
[01:43:02] taylorr: might be worth investigating, dunno
[01:43:14] taylorr: good point
[01:44:04] danielk22: If you want to look at the quick parser code it's all in dtvrecorder.cpp
[01:44:30] taylorr: ok, I'll try to find time which isn't much these days
[01:53:50] danielk22: Beirdo: logging.cpp:321 ... we don't handle EAGAIN properly...
[01:54:42] danielk22: ah, it's blocking.. nm
[01:55:09] danielk22: we should still handle EINTR..
[01:56:10] danielk22: and it might be nice to report EFBIG, EIO, ENSPC (if only by adding ENO to the log line).
[02:03:13] taylorr: danielk22: hmmm, another way of handling this is for the type of recorder to be stored for the recording – if broadcast then use timestamps for position/duration and if encoded the use frame counts for position/duration
[02:04:44] taylorr: AFAIK, the encoders we support don't telecine content so we can safely assume all video frames have the same duration 1/fps
[02:14:41] Beirdo: hmm, yeah, EINTR might be a good idea
[02:15:11] Beirdo: and sure, ENO on the log line would be smart too :)
[02:26:35] danielk22: Beirdo: just noticed it as I was tearing out the fsync()..
[02:28:13] danielk22: I was thinking you were using one of the buffered calls, but when you use write directly there is 1/ no need to flush and 2/ you also need to take care of those try again error returns.
[02:29:24] Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv
[02:34:56] danielk22: taylorr: re: 2550e267ed are we sure that was unintentional? I think markk added some code to fill the buffer all the way..
[02:35:16] taylorr: I added the code to fill the buffer all the way up
[02:35:31] danielk22: taylorr: ah ok :) then you know what as intended :)
[02:36:16] taylorr: I'm not sure how it affects things but I've heard users recently complaining about sluggish seeking and such
[02:36:50] danielk22: taylorr: dunno, how hard was the spin on full buffer?
[02:36:50] taylorr: my intent was to just allow filling the buffer all the way up not change any other behavior
[02:38:01] taylorr: I didn't analyze the performance impact on it spinning in that while loop
[02:38:10] taylorr: I figured it wasn't a good thing :)
[03:17:09] taylorr: danielk22: looks like the mpeg and h264 parser can be modified to determine repeat information which is all we need :)
[03:20:19] taylorr: we can simply derive frame duration from the repeat pict values
[03:56:27] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[05:08:21] stoffel (stoffel!~quassel@p57B4DB4B.dip.t-dialin.net) has joined #mythtv
[05:13:23] ybot (ybot!~quassel@61.14.141.36) has quit (Quit: No Ping reply in 180 seconds.)
[05:13:42] ybot (ybot!~quassel@61.14.141.36) has joined #mythtv
[05:29:34] stoffel (stoffel!~quassel@p57B4DB4B.dip.t-dialin.net) has quit (Remote host closed the connection)
[05:32:32] Beirdo: danielk22: the only error that *maybe* we might want to deal with would be EINTR or ENOSPC
[05:32:49] Beirdo: EINTR is highly unlikely on a log file
[05:33:16] Beirdo: "The call was interrupted by a signal before any data was written" not likely to happen
[05:33:42] Beirdo: ENOSPC we don't need to especially handle any further than an ENO in the log
[05:33:54] Beirdo: and EAGAIN will not happen as it's blocking IO
[05:34:31] Beirdo: the only one we'd want to not close on would be EINTR/EAGAIN in any case
[05:36:02] Beirdo: we may want to check that all bytes are written though :)
[05:36:18] Beirdo: in the unlikely case of being interrupted mid-log message
[05:36:35] Beirdo: it really doesn't happen often other than as you are shutting down
[05:54:46] Goga777 (Goga777!~Goga777@shpd-92-101-137-5.vologda.ru) has joined #mythtv
[06:08:27] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[06:08:42] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[06:09:28] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 250 seconds)
[06:09:29] jya_ is now known as jya
[06:15:46] Beirdo: danielk22: something's recently borked in shutdown. I'm getting SIGABRT all over the place (with qWarning)
[06:16:04] Beirdo: QSqlDatabasePrivate::removeDatabase: connection 'DBManager3' is still in use, all queries will cease to work.
[06:26:47] Goga777 (Goga777!~Goga777@shpd-92-101-137-5.vologda.ru) has quit (Remote host closed the connection)
[06:32:44] Beirdo: bisecting right now
[06:42:58] Beirdo: seems it's 07c71f3d20f7ba114e9c9c698431d47c6c04637a
[07:21:55] jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has quit (Read error: Connection reset by peer)
[07:23:03] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[07:23:29] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds)
[07:23:30] jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has joined #mythtv
[07:36:18] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 276 seconds)
[07:48:43] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[07:49:00] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv
[08:32:34] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[09:32:41] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.)
[09:46:08] MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has quit (Ping timeout: 250 seconds)
[09:47:57] MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv
[09:53:32] Beirdo: OK, now I go to bed
[09:54:42] Beirdo: danielk22: I had to change around the database logging thread a bit as it just wouldn't end cleanly, and also wasn't flushing the queue (it would stop immediately when told to stop rather than stopping enqueuing and allowing the queue to empty)
[09:55:24] Beirdo: and also the 2s delay on startup was way too long, caused nothing at all to get to teh db from mythpreviewgen, which only runs for about that long.
[09:55:49] Beirdo: I'm sure it will need yet another round of tweaking :)
[09:57:32] Beirdo: but at least now my previewgen and commflag runs cleanly exit
[10:05:55] mike (mike!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv
[10:06:21] mike is now known as Guest90316
[12:03:35] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[12:04:02] gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv
[12:04:02] gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host)
[12:04:02] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[12:25:26] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Ping timeout: 260 seconds)
[12:25:44] danielk22: Beirdo: I planned to implement the DB flush like I did with the logging thread flush.
[12:27:11] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[12:29:25] danielk22: Beirdo: I wasn't thinking of short lived program with the sleep. The DB logging can fail if it is sent too early, the 2 second wait was just to make sure the DB Manager was up and running before we try to log to the DB.
[12:33:24] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Ping timeout: 250 seconds)
[12:42:00] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[13:15:24] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[13:17:23] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[13:25:12] danielk22: By fail I mean spew error messages to the logs, the logging actually still happens later.
[13:26:26] sturebror (sturebror!~foo@2a01:1b0:7999:446:0:6:d7a8:d17c) has joined #mythtv
[13:29:27] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (Quit: leaving)
[13:30:34] tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has quit (Remote host closed the connection)
[13:37:06] ghoti (ghoti!~paul@scratch.it.ca) has quit (Ping timeout: 250 seconds)
[13:43:03] taylorr: danielk22: looks like for MPEG2 we just need to add parsing for the PES extension type (0x01B5) which contains the picture coding extension that includes the info to derive repeat_pict
[13:43:51] danielk22: taylorr: cool :)
[13:44:04] taylorr: this would even allow us to store an accurate timecode at each keyframe (GOP boundary) if we want to achieve perfection
[13:44:49] taylorr: I'm going to leave H264 alone for now... it doesn't look hard at all but I can't test it and I've yet to hear anyone mention repeated pictures being using in the wild
[13:45:17] taylorr: I'll code up a patch soon and let you have a look
[13:46:34] danielk22: Bierdo: Actually it looks like the failure is worse than I thought without the 2 second wait.. The driver is not loaded when we create the MSqlQuery so it never works. :|
[13:56:49] jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has joined #mythtv
[13:57:49] j-rod|afk is now known as j-rod
[14:04:01] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 260 seconds)
[14:12:41] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[14:17:39] danielk22: Beirdo: I've committed a fix which avoids the problem of no DB logging with mythfrontend and mythbackend.
[14:20:18] danielk22: Beirdo: It doesn't look like you added DB logging flush, do you want me to go ahead and add it or do you have the code sitting around uncommitted?
[14:27:08] sphery: for the short-program db logging, the patch I had written to use a single prepared query waited to prepare the query until after the DB was valid
[14:28:33] oopepe (oopepe!~oopepe@g226020058.adsl.alicedsl.de) has joined #mythtv
[14:28:34] sphery: it made it a bit uglier than just preparing it in the start of the run() function, but it worked for the short progs, too
[14:34:22] danielk22: sphery: My DB logging patch waited for isDatabaseValid() then waited two extra seconds.. Unfortunately isDatabaseValid() can return true and we still get an unusable MSqlQuery.
[14:34:26] oopepe: Hi, i want to use the generatevideothumbs.pl from the mythtv wiki. The script assumes abslolute filenames for videos in the table videometadata, but they are not. How are the filenames from videometata mapped to the filesystem? I guess with the help of the storagegroup table, but i cannot figure out the connection between them.
[14:34:59] danielk22: It now just waits for isDatabaseValid() but it also recreates the MSqlQuery whenever an insert fails for any reason..
[14:35:15] Kunalagon (Kunalagon!~Kunalagon@212.200.240.184) has joined #mythtv
[14:38:24] danielk22: Beirdo: http://pastebin.com/tUcVyaEh <-- this should work for a DB logging flush, but I haven't tested it.
[14:40:15] sphery: oopepe: /topic (you want #mythtv-users )
[14:41:08] oopepe: sphery: Oh, sry, thought because its database related i should ask in here.
[14:41:38] sphery: danielk22: an, yeah, you are waiting for isDatabaseReady() to return true. I guess mine never triggered a failure because it was checking isDatabaseReady() only when logging came in--rather than in a wait loop, so I probably never hit it soon enough.
[14:43:27] danielk22: sphery: That's possible, two seconds was a very conservative value, probably < 200 ms would have been enough for my logging to work.. Having any sleeps in startup isn't a very elegant solution though.
[14:47:47] sphery: Yeah. Dealing with a database that may not be ready is definitely a challenge. It's strange that isDatabaseReady() would return true before it's really ready since it actually uses tableExists() to run a prepared query.
[14:49:27] danielk22: yep, it's downright perplexing. :)
[14:49:52] danielk22: But I've been seeing these problems since the DB logging was introduced.
[14:50:09] oopepe (oopepe!~oopepe@g226020058.adsl.alicedsl.de) has left #mythtv ("Konversation terminated!")
[14:51:49] danielk22: I think perhaps it's connecting to the local database at startup, and then we connect to the correct database after reading in config.xml.. I seem to recall seeing some strange behavior that indicated that might be happening...
[14:54:11] sphery: ah, yeah, we do that... My dev box has a local db, so that breakage wouldn't have affected me
[14:54:13] danielk22: It looks like in mythfrontend at least we call configure logging before mythcontext is created but mythcontext sets up the DB connections...
[14:54:36] danielk22: It's a problem. :|
[14:54:38] sphery: I'll bump up the priority on my "fix config.xml and UPnP autoconf usage and remove mysql.txt" patch
[14:54:45] danielk22: :)
[14:54:59] sphery: maybe that will allow us to drop (or remove) that extra wait
[14:55:17] danielk22: yep, it should.
[14:57:15] danielk22: We probably want to start up logging asap but wait to start up the db logging thread until after mythcontext has initialized the DB connection info...
[14:58:59] danielk22: Also with mythbackend http config we can not set up the DB connection stuff until the user has configured/acked the DB connection info for the initial config.xml file.
[14:59:03] Kunalagon1 (Kunalagon1!~Kunalagon@212.200.240.184) has joined #mythtv
[14:59:40] Kunalagon (Kunalagon!~Kunalagon@212.200.240.184) has quit (Quit: Leaving.)
[15:12:16] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 260 seconds)
[15:15:38] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[15:23:09] taylorr: sorry for the amateurish question but does anyone know an easy way to convert an integer containing time in milliseconds to a QString with the format HH:MM:SS.MMM?
[15:24:14] taylorr: if someone would like to take away my commit privs for such a question then I totally understand :)
[15:25:55] iamlindoro: taylorr: You could proxy it through a QTime
[15:26:05] iamlindoro: QTime time;
[15:26:16] iamlindoro: time.addMSecs(int);
[15:26:35] iamlindoro: time.toString(stringwithformat);
[15:26:49] taylorr: ok, thanks for the help
[15:27:16] iamlindoro: specifially, time.toString("HH:mm:ss.zzz");
[15:27:28] iamlindoro: I think that should give you what you want
[15:27:32] iamlindoro: http://doc.qt.nokia.com/latest/qtime.html#toString
[15:27:33] iamlindoro: np
[15:27:36] taylorr: awesome
[16:03:09] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[16:03:48] danielk22: iamlindoro: I've been thinking of fixing the daylight savings issue, do you know if the date time formatting for display code is any more isolated post MythUI than it was 2–3 years ago when I last looked at it?
[16:05:26] danielk22: I count more than 1300 instances of the string QDateTime in the code...
[16:13:42] danielk22: My thought it is to temporarily replace QDateTime with an MDateTime which drops the toString functions, to find all the locations where we convert for display. Convert those and then go back to QDateTime.
[16:25:22] Beirdo: danielk22: the flush is already there, by not aborting the loop when aborted is set until the queue is empty.
[16:26:04] Beirdo: it will continue to process until it's done, then it quits the thread
[16:28:50] Beirdo: also, the QRunnables don't seem to be calling threadRegister effectively... or maybe it's that the threads in the pool DO, and the map ends up with both. hmmm
[16:30:01] tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[16:30:06] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[16:35:59] iamlindoro: danielk22: I believe that the formatting for display has come a long way since then-- stuartm did a lot of work on it recently, too. Lots more places use the myth util code for date formatting than used to (but I can't say if that's most places, I've honestly never compared to see)
[16:36:27] Goga777 (Goga777!~Goga777@shpd-95-53-185-82.vologda.ru) has joined #mythtv
[16:38:41] stuartm: danielk22: we now use MythDateTimeToString() et al everywhere we display a date, time or date time string
[16:39:41] stuartm: well, for 'everywhere' substitute 'everywhere I found'
[16:43:00] danielk22: taylorr: you prolly want to use QDateTime::fromMSecsSinceEpoch()
[16:45:20] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[16:46:09] sphery: QDateTime::fromMSecsSinceEpoch() was added in Qt 4.7, so unless we're ready to up the min version...
[16:46:34] danielk22: Beirdo: in the threadpool call threadRegister for the pool, then deregister when we start a runnable and register with the runable's name and then afterware threadRegister with the pool's name.
[16:46:36] sphery: (yes, I'm waiting anxiously /for/ the Qt millisecond datetime support stuff)
[16:47:09] danielk22: taylorr: sphery: ah, ok.. not worth it then..
[16:49:14] sphery: but if we use a QDateTime instead of QTime, it would be ready to switch to fromMSecsSinceEpoch() when we do require 4.7
[16:49:48] sphery: (it also has an addMSecs() function)
[16:50:12] ** iamlindoro hadn't thought to use QDateTime because of the desired output format **
[16:50:48] danielk22: iamlindoro: yeah, i was just looking at the 4.7 QDateTime docs at the time...
[16:54:31] sphery: In my world time does not exist without date information, so I never think of QTime or similar. :) (That said, the same formatting string would work fine for a QDateTime, since we don't care about the date portion of it at this point.)
[17:00:49] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[17:01:31] kth (kth!~kth@unaffiliated/kth) has quit (Client Quit)
[17:03:44] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[17:04:13] gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv
[17:04:13] gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host)
[17:04:13] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[17:06:52] danielk22: Beirdo: ah, the || between !aborted !m_queue->isEmpty() ..
[17:08:25] danielk22: That won't actually work though — if (item->message[0]!='\0' && !aborted)
[17:09:19] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[17:28:17] taylorr: Beirdo: how to you produce proper commit comments where you maintain a constant line length so that it's readable with 'git log'?
[17:29:04] wagnerrp: taylorr: vi should be set to automatically skip to the next line as needed
[17:29:05] taylorr: danielk22: we should be good to go now -> https://github.com/MythTV/mythtv/commit/301ef . . . d0a59e62093d
[17:29:29] taylorr: what's the setting? mine just runs on without wrapping properly
[17:29:46] wagnerrp: git is supposed to do it internally
[17:30:06] taylorr: doesn't work here
[17:30:19] wagnerrp: i mean, the vi instance it spawns when you run 'git commit' is supposed to be set up properly by git
[17:35:02] taylorr: does anyone know of some shows carried on US broadcast stations that have telecining (ie. wrong duration displayed)? I know CBS has some but would like to know some specific shows to record.
[17:39:10] danielk22: taylorr: I believe NBC does as well, though I don't know which programs.. they would probably say something in the credits about "filmed"
[17:39:24] danielk22: I know Cheers used to do that.
[17:40:44] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[17:56:33] taylorr: danielk22: I also notice you have run-on, non-wrapping commit messages when viewed under git log.... hopefully Beirdo can help
[18:01:04] stoffel (stoffel!~quassel@p57B4CF9F.dip.t-dialin.net) has joined #mythtv
[18:01:40] Beirdo: heh, yeah, if you manually wrap em at 80 or whatever, then it should look better in git log. I've noticed that in a few cases over the last while, but didn't bother mentioning
[18:07:30] xris: we got a contact request from someone who wants to help with spanish translation. what's the process? Or who is "in charge" of that stuff?
[18:07:54] ghoti (ghoti!~paul@scratch.it.ca) has joined #mythtv
[18:10:28] danielk22: hmm, I actually do that on purpose to make the trac commits look good. i.e. I write it with wrapping and then trim the EOLs..
[18:10:30] Beirdo: I think Reynaldo was doing the Spanish, but hasn't seemed to have touched it for quite some time
[18:11:26] Beirdo: danielk22: git log however leaves the message exactly how you put it, so it would likely end up on one very long line :)
[18:11:30] brfransen (brfransen!~brfransen@216.254.250.47) has quit (Read error: Connection reset by peer)
[18:12:15] danielk22: heh
[18:12:50] brfransen (brfransen!~brfransen@216.254.250.47) has joined #mythtv
[18:13:40] iamlindoro: xris: knightr and kenni are our translation leads, and have written lots of great docs, too
[18:14:21] iamlindoro: reynaldo seems to have gone missing, leaving a lot of spanish translation tickets withering-- the above two guys have been trying to contact him, but think they have not had much response
[18:14:36] xris: cool, thx
[18:14:42] iamlindoro: np
[18:14:44] xris: I'll tell this guy to get in touch with them.
[18:14:55] xris: the email is in spanish. hope he speaks some english so they can communicate.  :)
[18:15:04] Beirdo: hehe
[18:18:30] xris: wild. I type the email in spanish in Mail.app and it spellcheck recognizes it as such.
[18:24:56] Beirdo: try klingon
[18:25:35] Goga777 (Goga777!~Goga777@shpd-95-53-185-82.vologda.ru) has quit (Read error: Connection reset by peer)
[18:28:10] taylorr: Beirdo: does you vi config automatically handle 80-line wrapping for you?
[18:30:32] Beirdo: nope, I just use my enter key a lot
[18:30:41] Beirdo: I think it can though
[18:34:35] stoffel (stoffel!~quassel@p57B4CF9F.dip.t-dialin.net) has quit (Remote host closed the connection)
[19:06:20] Beirdo: !seen Mousey
[19:06:20] MythLogBot: Mousey was last seen 18 hours 30 minutes 9 seconds ago
[19:06:46] Beirdo: hmph. OK, I'll get off my butt and walk to his desk. I think we need to kick the PPC buildslave in the head
[19:18:31] sphery: taylorr: you need to have the git syntax file installed: /usr/share/vim/vim*/syntax/gitcommit.vim (there should also be ones for gitrebase, gitconfig, gitsendemail, and git, at minimum)
[19:18:40] sphery: and you need to have autotypes enabled
[19:20:23] sphery: should yell at you when you go >50chars for summary line and should auto-wrap at 72 chars in the body (but only when not in paste mode--so if copying from other sources, you'll likely need to do select and then do a gq to reformat)
[19:21:22] sphery: (and yells at you if there's no blank line between the 50char summary line and the body)
[19:27:00] stuartm: xris: your translation guy has shown up in -users
[19:43:30] Toast__ (Toast__!~quassel@87.127.37.199) has joined #mythtv
[19:44:22] stuartm: knightr: when you read this, we should get those outstanding Spanish translation tickets committed, the existing translation is only 30% complete so even if the patches aren't perfect they should be better than nothing
[19:45:28] gregL_ (gregL_!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[19:45:32] Toast__ is now known as Toast
[19:45:53] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)
[20:02:39] paul-h (paul-h!~paulh@mythtv/developer/paul-h) has quit (Remote host closed the connection)
[20:11:59] Kunalagon1 (Kunalagon1!~Kunalagon@212.200.240.184) has quit (Quit: Leaving.)
[20:22:25] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[20:37:19] andreax (andreax!~andreaz@p57B94509.dip.t-dialin.net) has joined #mythtv
[20:39:00] Mousey (Mousey!~wtfisme@ross154.net) has joined #mythtv
[21:20:38] stuartm: wow, something has screwed up logging in master, I'm getting what looks like -v all to console
[21:21:18] stuartm: possibly -v most, since I'm not seeing db related stuff
[21:24:13] stuartm: ok, just -v gui ... it just looks like a lot more when it's flying buy during the image loading/caching
[21:32:48] ** skd5aner eyes Beirdo **
[21:32:50] skd5aner: ;)
[21:36:24] Beirdo: if it was VB_GUI before, it's likely VB_GUI now. Of course pistakes do happen :)
[21:44:07] stuartm: Beirdo: something has broken in the last day or so, I'm getting VB_GUI stuff printed to the console even if I specify -v none
[21:44:57] Beirdo: Hmmm, that must be something in what danielk22 has been changing. I don't know what off-hand. I've made one set of changes last night, but that shouldn't affect that at all
[21:46:13] Beirdo: I can take a look tonight though if it hasn't been figured out by then though
[21:51:39] danielk22: stuartm: hmm, very strange.. I'm seeing it too.. I'm even seeing debugging logging fro the VB_GUI
[21:59:52] len (len!~quassel@174-30-215-151.mpls.qwest.net) has joined #mythtv
[22:06:06] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 268 seconds)
[22:07:34] Beirdo: did the flag value get mistakenly reused perhaps?
[22:11:24] danielk22: nope, I think the problem is with VB_ALL it should be defined a (~0ULL) Right now it's not got enough 1b 's to account for the number of flags..
[22:18:15] Beirdo: Oooooh
[22:18:30] Beirdo: I think all originally was everything but a couple flags
[22:19:00] Beirdo: but undoubtedly there's something odd in there
[22:21:35] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[22:23:29] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds)
[22:38:24] clever (clever!~clever@2001:470:1d:19a:205:5dff:feff:f422) has joined #mythtv
[22:42:27] danielk22 (danielk22!~danielk@96.57.9.142) has quit (Quit: Leaving.)
[22:45:40] Toast (Toast!~quassel@87.127.37.199) has quit (Remote host closed the connection)
[23:02:57] j-rod is now known as j-rod|afk
[23:25:55] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.)
[23:32:07] Beirdo: stuartm: heh, there's always that way to fix the sse2 build issues... rrrrrriiiiip!
[23:32:40] iamlindoro: How Rustian
[23:32:52] Beirdo: well, I see the reverts :)
[23:35:17] Beirdo: ugh, my job queue is so nasty right now... with every commflag and metadatalookup last night failing to shutdown... yech
[23:35:56] Beirdo: working nicely at the moment, it seems, but I have like 30 failures that are gonna show for a week
[23:36:56] Beirdo: the joys of running master on the production box, I guess :)
[23:38:01] iamlindoro: you may have some filldatabase hung if you check, too
[23:38:34] Beirdo: hmmm, good point, I should check for stragglers
[23:39:23] j-rod|afk is now known as j-rod
[23:39:48] Beirdo: doesn't look like it, but good call. I didn't think of checking that one
[23:42:59] knightr: stuartm,reynaldo is blocking the commit of those by Kenni and I. I have contacted him multiple times and he said he would look at them but he hasn't done anything... We are aware of the problem and I fear nobody will be interested to work on the Spanish translation, a language spoken vy a *very big* number or people, if he continues to apply his veto but what are we supposed to do when another dev, more senior dev, doesn't want to apply these t
[23:42:59] knightr: ickets before he has reviewed them?
[23:48:53] knightr: stuartm, sphery, the plan, at least on my side, was if the Spanish translators could agree on making a generic Spanish translation we could then fork it and make regional ones... That was the plan but with reynaldo applying his veto my hands and Kenni's are tied...
[23:50:36] Beirdo: knightr: he could get overruled, I suppose.
[23:52:59] j-rod is now known as j-rod|afk
[23:53:23] sphery: FWIW, my opinion is that you guys (the translation leads) should feel free to handle the tickets as they come in. If someone decides the accepted patches aren't correct, they can submit new patches--and we never lose anything thanks to git, anyway. It just seems that reynaldo is too busy with other stuff and the job needs to get done somehow.
[23:53:31] knightr: Beirdo, by whom, that's the question? I don't see either Kenni or I in any position to overule him...
[23:53:56] knightr: s/overule/overrule
[23:53:57] sphery: in other words, I say do your magic and worst case scenario, reynaldo can revert the changes and then fix it up himself later
[23:54:10] iamlindoro: knightr: I do not consider reynaldo to have more authority in translation matters than you or kenni
[23:54:20] Beirdo: I'm with sphery on this... if he's gonna be around, great
[23:54:28] iamlindoro: In fact, I don't think he has any standing to veto anything
[23:54:35] sphery: agreed--I consider knightr and kenni to be translation leads (for all matters tranlation)
[23:54:35] Beirdo: if he's absent, we shouldn't let him long-term hold things up
[23:54:39] iamlindoro: He's made all of a half dozen commit all-time
[23:54:42] iamlindoro: sphery: agree
[23:54:43] knightr: sphery, I kind of agree with you there, I consider each translation to be a "work in progress"...
[23:55:21] iamlindoro: knightr: So basically, if you were looking for a go-ahead to take charge of those tickets, I think you've got it ;)
[23:55:34] sphery: so, you have support of at least 3 of us if reynaldo showed up, again, and was upset :) However, I doubt he would be upset--probably relieved to have one less thing to worry about
[23:55:57] Beirdo: if he wants to come back and actively update them where they are off, great... I don't think you'll find any resistance to putting those through from anyone who's actively around.
[23:56:21] iamlindoro: I think we're also saying you don't need our say-so to take charge of translation tickets-- if someone wants to stonewall but not fix it, then that's too bad
[23:56:34] knightr: iamlindoro, sphery, Beirdo: Thanks guys! I'll contact Kenni to let him know and I'll see what I can do about applying them (I wonder if they still apply...)
[23:57:25] Beirdo: yeah, what iamlindoro said :)
[23:57:45] knightr: thanks!
[23:58:02] Beirdo: I wouldn't wait much more than a month or something for someone to take care of things, if they don't... well... :)
[23:58:12] iamlindoro: And this has been wayyyyyyyy longer than a month
[23:58:14] Beirdo: and those have been a loooong time waiting
[23:58:17] Beirdo: yep
[23:58:28] iamlindoro: Since I remember talking to knightr about them, and about his having contacted reynaldo, months ago
[23:58:31] knightr: (if they don't apply cleanly I'll see what I can do about applying them manually, even if I do a mistake the situation can't be much worse that it currently his...
[23:58:36] iamlindoro: Nobody can say you didn't give him a chance
[23:58:42] Beirdo: for sure :)
[23:59:51] knightr: He is also aware that I feared we would lose all interests from the translators into translating it... At one point we had 3 translators now we have two and I am not sure David still works on it...

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