MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (81):

aloril, andreax1, Anssi, anykey_, Beirdo, brfransen, CaCtus491, caelor_, cattelan, Chutt, clever, coling, Cougar, damaltor, dblain, dinamic|screen, eharris, ElmerFudd, fafa88, gary_buhrmaster, ghoti, gigem, gpd, gregL, GreyFoxx, hemi770, highzeth, IReboot, J-e-f-f-A, jams, jarle, joe___, joki, jpabq, jstenback, jwhite, kc, kenni, knightr_, kurre2, kwmonroe, laga, mag0o, makoto, markcerv, MissDee, Mousey, mrand, MythBuild, MythLogBot, neufeld, NightMonkey, peitolm, Peps, poptix, purserj, rsiebert_, Seeker`, seld, Sharky-AFK, Slasher`, SmallR2002_, sphery, sraue, stuarta, sunkan, superm1, sutula, taylorr, tgm4883, toeb, tris, vallor, Vernon_at_work, wagnerrp, wahrhaft, wolfgang, XDS2010_, xris, Yancho_, _charly_
Tuesday, September 4th, 2012, 00:01 UTC
[00:01:57] dekarl (dekarl!~dekarl@p4FCEE503.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[00:02:07] dekarl (dekarl!~dekarl@p4FCEE503.dip.t-dialin.net) has joined #mythtv
[00:26:36] dekarl (dekarl!~dekarl@p4FCEE503.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[00:40:08] fafa88 (fafa88!~fafa88@c-24-6-135-62.hsd1.ca.comcast.net) has quit (Ping timeout: 255 seconds)
[00:40:19] fafa88 (fafa88!~fafa88@c-24-6-135-62.hsd1.ca.comcast.net) has joined #mythtv
[01:19:44] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 250 seconds)
[01:35:05] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[01:48:49] SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has quit (Remote host closed the connection)
[01:50:44] zombor (zombor!~zombor_@65.29.231.135) has joined #mythtv
[01:50:45] zombor (zombor!~zombor_@65.29.231.135) has quit (Changing host)
[01:50:45] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[02:18:18] joki- (joki-!~joki@p54862115.dip.t-dialin.net) has joined #mythtv
[02:18:45] joki (joki!~joki@p54862026.dip.t-dialin.net) has quit (Ping timeout: 276 seconds)
[02:18:46] joki- is now known as joki
[02:28:40] openivo (openivo!~marc@cpe-173-88-235-117.neo.res.rr.com) has joined #mythtv
[02:42:29] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[02:48:40] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[02:58:01] fafa88 (fafa88!~fafa88@c-24-6-135-62.hsd1.ca.comcast.net) has quit (Quit: BitchX-1.2c01-svn -- just do it.)
[03:08:16] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[04:28:47] stichnot: Seeker`: thanks for testing my patch, and sorry that I forgot you were one of the affected.
[04:29:43] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 255 seconds)
[04:43:45] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[05:00:20] stichnot: btw, this is almost certainly not the patch that will get committed, since it modifies external ffmpeg code that we don't want to maintain, and is probably too heavy-handed. The good news is that at least it's clear where the crash is coming from.
[05:33:42] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 264 seconds)
[05:46:46] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[05:53:01] fafa88 (fafa88!~fafa88@c-24-6-135-62.hsd1.ca.comcast.net) has joined #mythtv
[05:58:55] Yancho (Yancho!~mpulis@unaffiliated/yancho) has joined #mythtv
[06:01:44] SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has joined #mythtv
[06:06:57] Goga777 (Goga777!~Goga777@2.95.188.67) has joined #mythtv
[06:11:35] Goga777 (Goga777!~Goga777@2.95.188.67) has quit (Remote host closed the connection)
[06:12:09] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv
[06:23:33] SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has quit (Remote host closed the connection)
[06:29:48] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Read error: Operation timed out)
[06:38:15] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[06:44:06] Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-171-28-68.hsd1.wa.comcast.net) has joined #mythtv
[06:44:07] Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-171-28-68.hsd1.wa.comcast.net) has quit (Changing host)
[06:44:07] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[07:55:39] Yancho (Yancho!~mpulis@unaffiliated/yancho) has quit (Read error: Connection reset by peer)
[07:56:04] Yancho (Yancho!~mpulis@unaffiliated/yancho) has joined #mythtv
[08:22:57] rsiebert_ (rsiebert_!~quassel@g225055016.adsl.alicedsl.de) has joined #mythtv
[08:26:39] rsiebert (rsiebert!~quassel@g231184197.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds)
[08:41:03] Seeker`: stichnot: heh, don't worry about it :) Is it not something that can be pushed upstream?
[08:41:45] Seeker`: I'm not sure i'd ever call setting unitialised memory to 0 'heavy-handed'
[08:50:49] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)
[09:07:51] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[09:09:56] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection)
[09:48:16] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[09:48:17] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[09:48:17] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[09:54:13] openivo (openivo!~marc@cpe-173-88-235-117.neo.res.rr.com) has quit (Quit: Leaving)
[10:22:57] andreax (andreax!~andreaz@p5089F4ED.dip.t-dialin.net) has joined #mythtv
[10:45:05] zombor (zombor!~zombor_@65.29.231.135) has joined #mythtv
[10:45:05] zombor (zombor!~zombor_@65.29.231.135) has quit (Changing host)
[10:45:05] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[10:59:02] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[10:59:52] Wolfgang1 (Wolfgang1!~Thunderbi@213.179.141.14) has joined #mythtv
[11:26:07] aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 240 seconds)
[11:28:33] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat)
[11:38:52] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv
[11:43:39] kenni (kenni!~kenni@mythtv/developer/kenni) has quit (Ping timeout: 240 seconds)
[11:51:33] toeb (toeb!~tob@HSI-KBW-078-042-104-026.hsi3.kabel-badenwuerttemberg.de) has quit (Ping timeout: 260 seconds)
[11:52:57] toeb (toeb!~tob@HSI-KBW-078-042-104-026.hsi3.kabel-badenwuerttemberg.de) has joined #mythtv
[11:56:03] kenni (kenni!~kenni@port649.ds1-ly.adsl.cybercity.dk) has joined #mythtv
[11:56:04] kenni (kenni!~kenni@port649.ds1-ly.adsl.cybercity.dk) has quit (Changing host)
[11:56:04] kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv
[12:11:21] zombor (zombor!~zombor_@208.54.80.240) has joined #mythtv
[12:11:22] zombor (zombor!~zombor_@208.54.80.240) has quit (Changing host)
[12:11:22] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[12:17:45] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[12:27:05] danielk22: How are we on the RC? I noticed a few more serious bug reports skimming the commits mailing list. Are some still outstanding or are the pretty much wrapped up?
[13:22:04] sphery: stichnot: Has it been changed/fixed upstream, already? If so, you can likely just merge in that upstream changeset (or part of it).
[13:22:27] zombor (zombor!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv
[13:22:27] zombor (zombor!~zombor_@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host)
[13:22:28] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[13:24:37] sphery: danielk22: There was some talk, yesterday, but I think no one really knows the plan. :) See http://irc.mythtv.org/ircLog/channel/4/2012-09-03:17:30:00
[13:26:58] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[13:27:28] stichnot: sphery: it's not an upstream bug. I'll explain.
[13:28:28] stichnot: av_init_packet() does not initialize the data or size fields of the packet. av_new_packet() calls av_init_packet() and then initializes data and size.
[13:28:57] stichnot: the ffmpeg code has lots of places where av_init_packet() is called immediately followed by explicit initialization of data and/or size
[13:29:20] stichnot: unfortunately the situation that hits us does not have this initialization
[13:29:54] stichnot: which then leads to a call in our own mpegts-mythtv.c which depends on those fields
[13:31:14] stichnot: so I don't see a way of fixing the bug without modifying part of ffmpeg that is not mpegts-mythtv.c
[13:31:34] stichnot: I don't know anything about ffmpeg merging, so I have no idea if this is an issue
[13:33:05] stichnot: If we go there, do we (1) modify av_init_packet() like the test patch, or (2) modify the specific call to av_init_packet() that leads to this particular crash?
[13:34:27] stichnot: (1) probably has some trivial performance impact which may be why ffmpeg chose the fragile approach. And there's the remote possibility that some code somewhere depends on av_init_packet() leaving the data and size fields unchanged.
[13:35:17] stichnot: (2) means there could still be paths into the mpegts-mythtv.c code with uninitialized data/size fields that we haven't found yet.
[13:35:40] stichnot: That's all. Any advice/opinions?
[13:35:57] sphery: I'll defer to someone who knows the video stuff better (like danielk22 ), but it sounds like you're leaning toward trying to find a way to fix it in mpegts-mythtv.c, and that sounds like it fits with the style of ffmpeg you described.
[13:36:20] stichnot: I believe there is no fix possible just in mpegts-mythtv.c
[13:37:15] sphery: ah, then you definitely will want to talk with someone else who knows the video stuff
[13:38:38] stichnot: http://pastebin.com/1qbnG5ED is part of the stack trace that leads to the crash
[13:40:45] andreax1 (andreax1!~andreaz@80.137.239.136) has joined #mythtv
[13:40:48] stichnot: the packet is allocated on the stack as ptk1 in estimate_timings_from_pts(), then initialized in ff_read_packet() via a call to av_init_packet()
[13:41:08] andreax (andreax!~andreaz@p5089F4ED.dip.t-dialin.net) has quit (Ping timeout: 248 seconds)
[13:43:46] stichnot: both of those are in libavformat/utils.c, so at a minimum I think we have to modify that file
[13:44:36] stichnot: mpegts-mythtv.c is far enough diverged from mpegts.c that I don't know how/whether this problem is avoided upstream
[13:45:48] stichnot: Who are the video experts who can rule on this? Beirdo/jya? (i.e. the people doing the ffmpeg merge)
[13:52:42] toeb_ (toeb_!~yaaic@89.204.130.93) has joined #mythtv
[13:54:38] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[13:57:23] stichnot: actually there is a file https://github.com/MythTV/mythtv/blob/master/ . . . /README.sync indicating that many upstream files are locally modified, so I might as well jump in and add my own.
[13:59:13] stichnot: I don't know whether/where the specific modifications are documented
[14:05:43] Yanch0 (Yanch0!~mpulis@unaffiliated/yancho) has joined #mythtv
[14:09:06] Yancho (Yancho!~mpulis@unaffiliated/yancho) has quit (Ping timeout: 264 seconds)
[14:19:28] foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has quit (Ping timeout: 246 seconds)
[14:25:24] stichnot: In any case, I will try to commit some fix within the next 5 hours to move the release along, and we can figure out the rest later.
[14:31:22] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 250 seconds)
[14:31:35] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 255 seconds)
[14:45:45] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[14:58:06] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv
[15:00:24] Wolfgang1 (Wolfgang1!~Thunderbi@213.179.141.14) has quit (Quit: Wolfgang1)
[15:03:32] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds)
[15:04:49] mag0o (mag0o!20001@slackhost.lynchmv.com) has quit (Ping timeout: 265 seconds)
[15:06:48] mag0o (mag0o!20001@slackhost.lynchmv.com) has joined #mythtv
[15:25:00] FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG)
[15:26:34] toeb_ (toeb_!~yaaic@89.204.130.93) has quit (Ping timeout: 265 seconds)
[15:26:40] Wolfgang1 (Wolfgang1!~Thunderbi@178-27-151-224-dynip.superkabel.de) has joined #mythtv
[15:37:42] danielk22: stichnot: I think av_init_packet does not initialized the data or size fields because av_new_packet initializes those. I assume in libav code either av_new_packet is called or data & size are initialized explicitly.
[15:38:12] gigem: danielk22: It's been awhile since I last brought this up, but I semi-frequently have recordings with very bogus durations. I had a little time this weekend to dig into it and traced the problem to a discontinuity in pts/dts. See http://pastebin.com/ycZsQuce for a sample -v timestamp log. The discontinuity always seems to conincide with an audio decoding error. I don't know if the error/discontinuity is
[15:38:14] gigem: intentional on Verizon's part or not or if there is something in the stream to signal the change that we're not detecting. Would you mind taking a look at this sample? It's about 30MB in size.
[15:39:15] danielk22: gigem: I'm getting on a plane this afternoon and will be at a tradeshow until late next week so I don't think I'll be able to look at it.
[15:40:50] danielk22: gigem: But we really shouldn't be using pts/dts for showing program durations. A lot of cable headend commercial insertion code as well as switching equipment will result in discontinuities.
[15:40:52] gigem: Okay. Do you know of any good programs that can decode mpeg streams and produce a nice, human readable output?
[15:41:46] danielk22: No, I've considered adding something like that to mythutil.
[15:41:57] gigem: Well, we're using it show the current position in the recording and also using to calculate the total duration after a recording ends.
[15:43:20] danielk22: gigem: I think taylorr added that code a while back, but I thought he had backed it out because of the problems it causes.
[15:44:25] danielk22: gigem: I believe the recording quality code does track the discontinuities and makes that available in XML form at the end of the recording.
[15:45:24] danielk22: The reason taylorr added that was because the way we were doing it before (using frame count) gave the wrong results for recordings where the frame rate varies.
[15:45:35] gigem: It's particularly annoying when it happens while watching. The pts/dts change is often lower and the wrap around handling results in a large time, say 22 hours. Since the supposed current postion is well past the actual duration, Myth caps it to the total duration when displaying in the OSD. The end result is you have no idea where you are in the recording.
[15:46:25] gigem: Yeah, I know. If the pts/dts change is valid, we might need to add some way of detecting the discontinuities.
[15:46:38] danielk22: gigem: For duration we should probably use the minimum of the wall clock duration and the pts/dts.
[15:47:22] danielk22: gigem: For knowing where we are in the recording, it gets pretty complicated if you want to deal with both pts/dts discontinuities and variable frame rates.
[15:48:17] danielk22: gigem: You really need to know the pts/dts of the last keyframe before the current frame and count up from there; but we don't record the pts or dts in the keyframe map.
[15:49:30] danielk22: (alternatively we could record just the discontinuities and use those to derive the current position; still a bit complicated.)
[15:50:51] danielk22: gigem: The RecordingQuality code does detect discontinuities. I'm not sure how well it works in practice, but it works in my synthetic tests.
[15:51:12] gigem: Yeah. I was hopeing, but not expecting, there might be a quick fix. I'll put this on my TODO list. That is unless and until I can coerce someone else into doing it. :) taylorr ^^^
[15:52:18] gigem: danielk22: Yes, it works in the RecordingQuality detection. That's how I quickly know if the problem occurred when I haven't watch something yet. :)
[15:52:23] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[15:53:03] SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has joined #mythtv
[15:53:16] danielk22: heh, good to know it does work in practice :) In NYC the feeds all seem to be very clean these days. Not like the early days of DTV.
[15:54:32] gigem: I never see the problem with the local changes as it appears Verizon
[15:54:59] gigem: passes them along without changes. The national cable feeds are where I see the problem.
[15:57:15] danielk22: gigem: National cable feeds have slots in them for the cable operator to insert local ads. Most local broadcasters require the signal to be passed unmolested aside from re-encoding to a lower bitrate (they have already inserted ads into the feed they get from the network).
[15:58:23] danielk22: The broadcasters all need to re-encode everything before broadcast, but the cable operators don't necessarily want to do that for directed adds that only go out to one zip code so they just switch feeds.
[15:58:52] danielk22: It's that switching where things can go really sideways.
[15:59:05] gigem: danielk22: I always suspected the insertion of local ads to be the problem, but that doesn't appear to be the case. I see the problem occuring in the middle of the normal content.
[15:59:51] danielk22: gigem: The only reason I can see that occurring is because the primary equipment is throwing errors and someone flips the switch to the redundant path.
[16:00:05] danielk22: That shouldn't happen very often...
[16:00:34] danielk22: Alternatively something is broken and they don't know about it. Does this only happen on one channel?
[16:06:58] gigem: danielk22: There's maybe only 10, non-local channels that I routinely record from and the problem occurs on all of them.
[16:08:34] danielk22: gigem: Hmm, in that case I think there is something else going on. Maybe we're miss-parsing the pts/dts or not throwing out bad packets.
[16:09:26] danielk22: Do you have a sample XML output from RecordingQuality?
[16:09:57] gigem: FWIW, mplayer reports the same discontinuity. That doesn't mean there's not still an error in ffmpeg/libav.
[16:10:55] danielk22: gigem: We have our own code for extracting pts/dts, but we do use the libav code as well...
[16:12:04] gigem: Hold on while I look for good(bad?) RecordingQuality? output.
[16:17:43] gigem: danielk22: http://pastebin.com/VvhKGisb . FYI, I have to leave now and won't be back for about an hour.
[16:22:09] danielk22: gigem: 1000 * 256*256.0 / 90000 = 7281.7777
[16:24:42] danielk22: The gap is 7282 ms ... Either a parsing error on our part or a bug in the re-encoder used by Verizon. (1/90000 seconds is the duration of a pts tick).
[16:29:52] andreax (andreax!~andreaz@p5089FAAA.dip.t-dialin.net) has joined #mythtv
[16:31:30] andreax1 (andreax1!~andreaz@80.137.239.136) has quit (Ping timeout: 246 seconds)
[16:39:22] Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv
[16:48:03] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection)
[16:49:11] stichnot (stichnot!~stichnot@192.55.54.40) has joined #mythtv
[16:49:12] stichnot (stichnot!~stichnot@192.55.54.40) has quit (Changing host)
[16:49:12] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:50:27] Beirdo: danielk22: where is -rc2 or the final release? Been 12 days :)
[16:50:57] Yanch0 (Yanch0!~mpulis@unaffiliated/yancho) has quit (Read error: No route to host)
[16:51:28] Yanch0 (Yanch0!~mpulis@unaffiliated/yancho) has joined #mythtv
[16:52:16] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[16:52:55] Yanch0 (Yanch0!~mpulis@unaffiliated/yancho) has quit (Read error: Connection reset by peer)
[17:01:00] Yancho (Yancho!~mpulis@unaffiliated/yancho) has joined #mythtv
[17:01:17] Yancho (Yancho!~mpulis@unaffiliated/yancho) has quit (Read error: Connection reset by peer)
[17:04:02] stichnot: Beirdo: what do I need to do if I want to commit a change to an ffmpeg source file that's not one of the *mythtv*.c files?
[17:04:29] stichnot: I mean, to ensure that future ffmpeg syncs also get the change
[17:07:26] Beirdo: well, when I was doing the sync, I'd diff from what we had back to what we synced from, and then add our customizations back after the sync
[17:07:40] Beirdo: but I don't know how jya intends to do it
[17:08:08] stichnot: ok. I'll make sure he's filled in when he returns.
[17:09:03] Beirdo: as far as I know, he's intending to do the ffmpeg syncs now. He hasn't indicated otherwise
[17:13:18] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:25:54] caelor_ is now known as caelor
[17:26:59] caelor: stichnot, all the recordings I've tested with your patch now work. I haven't tried removing your patch and confirming the problem comes back (but I suspect given the nature of the problem it may not do)
[17:27:44] stichnot: caelor: thanks. I'm about to commit a different solution, and I'd appreciate feedback on it.
[17:28:08] caelor: sure. Let me know when the commit goes in, and I'll kick off a new build
[17:29:29] stichnot: ok, it's committed now.
[17:30:07] caelor: commit 92016b9498?
[17:30:24] caelor: Fixes #11029. Ensure AVPacket's data and size fields are initialized.
[17:30:24] ** MythLogBot http://code.mythtv.org/trac/ticket/11029 **
[17:30:42] stichnot: yeah, that's it
[17:32:45] caelor: ok, I'll try and get it built and installed before primetime tonight
[17:33:06] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Quit: ChatZilla 0.9.88.2 [Firefox 15.0/20120824154833])
[17:39:35] stuartm: Beirdo: IMHO rc2 now, with the aim of release in a week assuming no major issues outstanding
[17:40:02] stuartm: I want to get the DVD subtitle breakage fixed, but I'm not sure that's a blocker
[17:42:29] Beirdo: stuartm: yeah, we should probably cut -rc2
[17:42:35] Beirdo: it's almost a week late :)
[17:42:58] Beirdo: we've been too busy with real life or something :)
[17:44:12] danielk22: Unless you already have the DVD code ready I say cut the rc2 now and fix the DVD stuff in the fixes branch...
[17:45:28] Beirdo: I don't think anything (other than spare time) is holding off an -rc2. The only question is whether the DVD stuff will hold off final or not (IMHO)
[17:45:33] stichnot (stichnot!~stichnot@192.55.54.40) has joined #mythtv
[17:45:33] stichnot (stichnot!~stichnot@192.55.54.40) has quit (Changing host)
[17:45:33] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:45:41] Beirdo: and I'd agree, it can probably be fixed on -fixes
[17:45:43] stuartm: Beirdo: very busy :)
[17:46:00] Beirdo: yeah, busy happens :)
[17:46:30] Beirdo: Well, if you guys haven't cut -rc2 by tonight, I'll take a look at doing it unless there's objections
[17:46:39] Beirdo: obviously, work, etc comes first
[17:46:40] stichnot: dvd subtitle breakage? what is that?
[17:47:42] stuartm: stichnot: on some disc 'Toggle Subtitles' isn't enabling subs, or it's enabling the wrong subs
[17:48:02] stichnot: is there a ticket?
[17:48:33] stuartm: stichnot: I've not opened one, so probably not, it was just something I kept meaning to look at
[17:48:47] stichnot: I see #10963
[17:48:47] ** MythLogBot http://code.mythtv.org/trac/ticket/10963 **
[17:49:16] stuartm: oh, seems I did open a ticket after all
[17:49:50] stichnot: I did some work in 0.26 on auto-selection and forced tracks, so I wonder if it's something there
[17:49:52] stuartm: short on detail because I thought I'd be the one to fix it :)
[17:50:39] stuartm: stichnot: possibly, I believe it's a regression from 0.25 but I don't think you were the only one to make changes there
[17:51:01] stichnot: :)
[17:52:02] stuartm: I was guessing that it was related to the patch which used the subtitle index from dvdnav to populate the list instead of relying on what libav tells us, since the latter is sometimes wrong/mis-labelled
[17:52:23] stuartm: might not be
[17:53:23] stuartm: if I select the subtitle from the list then it works, hence I was thinking that the auto-selection was working from the wrong metadata
[17:53:39] andreax (andreax!~andreaz@p5089FAAA.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[17:54:33] Goga777 (Goga777!~Goga777@128-71-3-176.broadband.corbina.ru) has joined #mythtv
[17:56:30] stuartm: stichnot: do you want to look at it then?
[17:58:00] gigem: danielk22: In case you're still around, I put a couple more recording quality results at http://pastebin.com/KrQCfSyH . I think the 7281 from before was just a bad conincidence. the numbers are all over the place.
[17:58:04] stichnot: stuartm: if it's related to that dvdnav patch, then I will be clueless. Also, it may be hard without the specific problematic disc in hand.
[17:58:29] natanojl: stuartm: Sounds a little bit like #9429 to which I added a patch
[17:58:29] ** MythLogBot http://code.mythtv.org/trac/ticket/9429 **
[17:58:52] stichnot: I would agree with danielk22 about putting it in -fixes
[17:59:17] natanojl: but I think the autoselection was still broken even with that patch
[17:59:39] stuartm: natanojl: hmm, that might be the patch I was thinking of, I thought it had been committed ... guess it's not that then
[17:59:46] stuartm: stichnot: ^^
[17:59:49] danielk22: gigem: yep. I agree. Amazing what a wild goose chases a little more data can avoid!
[18:00:32] stichnot: ah, I also thought that had been committed...
[18:00:55] natanojl: I never got around to it I guess
[18:08:14] stichnot: as for the rc2, I suggest waiting ~10 hours for initial feedback on the fix for the 11029 crash, then go for it (assuming there are no more blockers)
[18:10:15] natanojl: stuartm, stichnot: if I remember correctly ffmpeg didn't report any languages other than English until the movie had started. Perhaps the autoselection sticks to what was first detected
[18:12:51] stichnot: I have noticed that the auto-select code tends to stick with its first selection, which can cause problems. That whole code could use a fresh look.
[18:13:32] Goga777 (Goga777!~Goga777@128-71-3-176.broadband.corbina.ru) has quit (Quit: Leaving)
[18:13:55] stuartm: my use case is enabling subtitles manually after playback begins, but using the TOGGLE_SUBTITLES binding or menu action, it should select the English track but in a lot of cases recently that hasn't happened
[18:14:06] Goga777 (Goga777!~Goga777@128-71-3-176.broadband.corbina.ru) has joined #mythtv
[18:16:57] natanojl: ok, I can't remember if that worked or not with my patch
[18:19:42] danielk22 (danielk22!~danielk@96.57.9.142) has left #mythtv ()
[18:32:45] gpd (gpd!~gpd@www.grahamdavies.net) has joined #mythtv
[18:39:53] Goga777 (Goga777!~Goga777@128-71-3-176.broadband.corbina.ru) has quit (Read error: Connection reset by peer)
[18:47:48] andreax (andreax!~andreaz@p5089FAAA.dip.t-dialin.net) has joined #mythtv
[19:01:27] SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has quit (Remote host closed the connection)
[19:06:14] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[19:11:30] IReboot: I noticed while developing a h264 loss less cut script that when you use the frontend to manually set the cuts on key frames the cutlist produced by mythutil displays cuts one frame higher than what is in the recordedseek table. Can anyone tell me why the despondency and which number is more accurate to an actual keyframe?
[19:13:04] IReboot: s/the despondency//
[19:15:47] caelor: wagnerrp, I know you intend to move metadata fetching into the backend (possibly for 0.27?) – is there any chance of exposing that functionality to fetch metadata through the python bindings once that's done?
[19:16:35] wagnerrp: im not sure what you mean
[19:17:51] caelor: at the moment, a python script could fetch metadata by calling out to the ttvdb.py script, but once metadata fetching is centralised in the backend, it would be good to be able to query the backend for metadata instead
[19:18:08] wagnerrp: right now, you can call the grabbers directly with the VideoGrabber interface in the bindings, or query the structure over the services API
[19:18:24] caelor: ah. I hadn't appreciated that  :) makes my query moot
[19:18:34] wagnerrp: mythweb is currently using the services api for just such a reason
[19:19:04] wagnerrp: although it itself is applying the metadata
[19:19:23] wagnerrp: rather than passing it back into the backend to apply to the database
[19:20:53] caelor: ok. My thoughts were in the context of converting the h264 cutting script that IReboot is working to use the Python bindings
[19:21:27] caelor: is the cutlist info similarly available through the bindings?
[19:21:43] caelor: or service api
[19:21:45] wagnerrp: Recorded.markup.gencutlist()
[19:22:13] wagnerrp: or rather .getcutlist()
[19:22:20] caelor: fantastic! for some reason I was looking for it in the Program class, which thinking about it wouldn't make any sense
[19:22:57] wagnerrp: i have one mostly written, although pretty dirty
[19:24:27] caelor: a cutting script?
[19:25:52] wagnerrp: yeah, from the last time mythtranscode was giving me troubles with mpeg2 content
[19:26:38] caelor: yeah, I'll admit to having stopped using mythtranscode in favour of wiki-scripts for mpeg2 quite some time ago
[19:26:47] wagnerrp: i never found a good tool to fix the timecodes, and then mythtranscode started working fine again
[19:27:47] wagnerrp: it was just a GOP cutter, meaning it would leave small amounts of spare frames around the cut, and create new cuts points from the updated frame coutns
[19:28:07] caelor: the technique the h264cut script uses is to use avconv to copy a primary audio & video stream for each non-cut segment, and then use mkvmerge to concatenate them
[19:28:38] wagnerrp: this used the byte locations in the seek table
[19:28:48] wagnerrp: and just found the nearest keyframe
[19:28:53] caelor: so I don't think timecode correction would happen, and it needs keyframe aligned starts for each segment
[19:32:58] caelor: is it feasible to eventually have a mimimal re-encoding cutlist-transcode for h264, in the same way as mpeg2?
[19:33:14] wagnerrp: absolutely... someone needs to write it
[19:33:26] caelor: I'm not familiar with the data structure, so I don't know if it's just a case of somebody sitting down to do the work, or if it's sufficiently different to make it infeasible
[19:33:53] caelor: ah ok. Presumably it's non-trivial or it would have be done somewhere
[19:35:08] wagnerrp: its just a function of finding the proper location, and rebuilding any frames that lost referred frames
[19:35:11] IReboot: caelor: Since I made sure all cutlist frame numbers are adjusted to a keyframe using the recordedseek table before the cut and mergings is done I no longer get any small artifacts between cuts.
[19:35:37] IReboot: caelor: That check just happened a hour or so ago.
[19:35:40] wagnerrp: its not really much more difficult than transcoding
[19:36:11] wagnerrp: you're just selectively transcoding only parts of it
[19:36:36] caelor: fair enough. I suspect that the cut-start (segment end) point might not need to be keyframe aligned. I know the hdpvr spaces its keyframes quite far apart
[19:36:52] wagnerrp: h264 in general spaces them quite far apart
[19:37:22] wagnerrp: at least compared to the ~half second spacing in MPEG2
[19:38:05] stichnot: my hdpvr keyframes are always 128 frames apart
[19:38:26] caelor: yes. With mpeg2, aligning on keyframe interval is not too bad, but it can be a bit more jarring with h264
[20:03:25] danielk22 (danielk22!~danielk@66.43.120.114) has joined #mythtv
[20:06:26] danielk22: Hmmm. Isn't #11069 something we fixed a few months ago?
[20:06:26] ** MythLogBot http://code.mythtv.org/trac/ticket/11069 **
[20:11:12] neufeld_AFK: danielk22: I don't know, I did a trac search and didn't see anything likely. I tried checking for bugfixes that matched the description, and didn't see anything there either. It's biting me right now, and I don't know if upgrading to 0.25–2 will fix it, but upgrades are major operations for me so I don't perform them just to see if bugs have been fixed. I figured better to post the issue in case nobody had yet
[20:11:13] neufeld_AFK: seen it.
[20:12:06] neufeld_AFK is now known as neufeld
[20:12:47] danielk22: neufeld_AFK: If you are running anything other than 0.25/fixes head then you likely don't have the fix. I'm unsure if the fix was backported to 0.25, but it should have been.
[20:15:58] Wolfgang1 (Wolfgang1!~Thunderbi@178-27-151-224-dynip.superkabel.de) has quit (Quit: Wolfgang1)
[20:17:49] neufeld: danielk22: OK. I'll go through the git logs for 0.25.2, see if I can figure out whether it's been fixed in that tag. If so, I'll probably schedule an upgrade in the next couple of weeks. I'm using LinHES for the MythTV box.
[20:22:29] danielk22: Ok, I'll close it as invalid for now. Please ping here to have it re-opened if you can reproduce with the latest 0.25
[20:22:39] neufeld: danielk22: OK, thanks.
[20:23:27] neufeld: Looks like it was #10685
[20:23:27] ** MythLogBot http://code.mythtv.org/trac/ticket/10685 **
[20:23:55] danielk22: yep, thanks for finding it.
[20:23:56] neufeld: Fixed in 0.25.2, so I'll schedule an upgrade for my box at home.
[20:25:28] neufeld: danielk22: actually, checked in on 0.25.2 by you, unless there's another Daniel K. Thank you kindly.
[20:26:15] danielk22: Same danielk, I just quickly forget the details after I commit ;]
[20:28:29] neufeld: Yeah, I know how that goes. I'm often surprised at work by features I don't remember coding.
[20:28:56] danielk22: neufeld: I closed #11069 as a duplicate, if you can reproduce with the latest 0.25 please ping the #10685 ticket.
[20:28:56] ** MythLogBot http://code.mythtv.org/trac/ticket/11069 **
[20:28:56] ** MythLogBot http://code.mythtv.org/trac/ticket/10685 **
[20:29:20] neufeld: danielk22: Right, thanks. I'll do that.
[20:32:29] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Read error: Operation timed out)
[20:34:38] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[20:35:06] stichnot_ (stichnot_!~stichnot@192.55.54.42) has joined #mythtv
[20:37:15] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 276 seconds)
[20:37:15] stichnot_ is now known as stichnot
[20:37:59] danielk22 (danielk22!~danielk@66.43.120.114) has left #mythtv ()
[20:47:03] Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-171-28-68.hsd1.wa.comcast.net) has joined #mythtv
[20:47:03] Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-171-28-68.hsd1.wa.comcast.net) has quit (Changing host)
[20:47:03] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[20:58:10] Yancho (Yancho!~mpulis@78.133.42.95) has joined #mythtv
[20:58:10] Yancho (Yancho!~mpulis@78.133.42.95) has quit (Changing host)
[20:58:10] Yancho (Yancho!~mpulis@unaffiliated/yancho) has joined #mythtv
[21:00:04] Yancho_ (Yancho_!~mpulis@unaffiliated/yancho) has joined #mythtv
[21:00:23] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Read error: Operation timed out)
[21:03:15] Yancho (Yancho!~mpulis@unaffiliated/yancho) has quit (Ping timeout: 276 seconds)
[21:18:29] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[21:55:59] zombor (zombor!~zombor_@208.54.45.152) has joined #mythtv
[21:56:00] zombor (zombor!~zombor_@208.54.45.152) has quit (Changing host)
[21:56:00] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[22:00:22] scottc_ (scottc_!~scott@cpe-72-130-81-34.socal.res.rr.com) has joined #mythtv
[22:01:19] scottc_: hello mythtv world
[22:01:42] caelor: stichnot, looks like it's also working with your commit for #11048 and #11029. You have my vote for closing as fixed.
[22:01:42] ** MythLogBot http://code.mythtv.org/trac/ticket/11048 **
[22:01:42] ** MythLogBot http://code.mythtv.org/trac/ticket/11029 **
[22:03:29] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[22:04:59] stichnot: caelor: awesome, thanks for verifying.
[22:06:15] caelor: no problem. I actually just realised that I forgot to clear the original patch from my rebuild, but your commit hasn't introduced more issues. I'll rebuild again tomorrow without the patch to confirm, but it should be fine
[22:07:17] caelor: I shouldn't try and think logically late in the evening :)
[22:08:03] caelor: it still gets my vote on the improved WAF alone.
[22:09:22] andreax1 (andreax1!~andreaz@p54BF3637.dip.t-dialin.net) has joined #mythtv
[22:09:58] andreax (andreax!~andreaz@p5089FAAA.dip.t-dialin.net) has quit (Ping timeout: 240 seconds)
[22:13:33] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Ping timeout: 272 seconds)
[22:14:12] stichnot: caelor: actually it would be best to test without the original patch. The original patch initializes the problematic fields for every AVPacket (which could conceivably cause a problem), whereas the new commit only initializes the fields on one specific path (so there could still be other paths into the mpegts-mythtv.c code that trigger the problem).
[22:18:50] caelor: yes. It was an oversight that I left it in. I'll try a build tomorrow without it.
[22:20:03] stichnot: btw, I don't have an easy way of testing, but it looks like the same bug ought to be lurking in 0.25
[22:20:15] caelor is now known as caelor_
[22:24:55] Seeker`: I'll try to test the latest mythbuntu build after work tomorrow. About 18 hours from now.
[22:31:01] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[22:34:35] scottc_ (scottc_!~scott@cpe-72-130-81-34.socal.res.rr.com) has quit (Read error: Connection reset by peer)
[22:35:43] scottc_ (scottc_!~scott@cpe-72-130-81-34.socal.res.rr.com) has joined #mythtv
[22:40:59] stichnot: For the record, the best test of this lurking problem is "valgrind --leak-check=no --track-origins=yes /path/to/mythavtest myth://Videos@... " and watch for uninitialized data warnings.
[22:49:23] makoto (makoto!makoto@2001:8b0:be0e:1337:3:1337:3:1337) has joined #mythtv
[22:49:26] makoto: hey
[22:49:56] makoto: i'm getting a craptonne of what looks like SQL errors, something about tables marked as crashed
[22:50:28] makoto: Google says "Go to mythbuntu-control-centre, "Advanced Management", "Optimize tables".", but I'm on debian. What is this table optimizing?
[23:03:24] zombor (zombor!~zombor_@65.29.231.135) has joined #mythtv
[23:03:25] zombor (zombor!~zombor_@65.29.231.135) has quit (Changing host)
[23:03:25] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:05:59] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds)
[23:10:40] scottc_ (scottc_!~scott@cpe-72-130-81-34.socal.res.rr.com) has quit (Quit: scottc_)
[23:10:46] stichnot (stichnot!~stichnot@192.55.54.42) has quit (Ping timeout: 246 seconds)
[23:14:06] stichnot (stichnot!~stichnot@134.134.139.72) has joined #mythtv
[23:14:07] stichnot (stichnot!~stichnot@134.134.139.72) has quit (Changing host)
[23:14:07] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:31:34] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Read error: No route to host)
[23:35:24] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[23:40:15] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Remote host closed the connection)
[23:43:42] kieppie1 (kieppie1!~Adium@ip-58-28-154-35.static-xdsl.xnet.co.nz) has joined #mythtv
[23:43:51] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[23:43:53] kieppie1 (kieppie1!~Adium@ip-58-28-154-35.static-xdsl.xnet.co.nz) has left #mythtv ()
[23:46:51] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 246 seconds)
[23:48:56] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Remote host closed the connection)
[23:51:13] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv

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