| Monday, September 3rd, 2012, 17:30 UTC | ||
| [17:30:46] | wagnerrp: | stuartm: has anyone mentioned a target date for release? |
| [17:35:53] | stuartm: | wagnerrp: not to my knowledge, but I was away for a week and something might have been decided in my absence |
| [17:36:37] | stuartm: | I've got a couple of bugs I'd like to squash before the release, time allowing |
| [17:37:03] | wagnerrp: | ive been working on a new low level model for the bindings, that i was planning on holding off for 0.27, but would make things easier much to deal with timezone stuff if i had time to finish it up for 0.26 |
| [17:39:55] | stuartm: | we traditionally release on a Monday since most people upgrade on a Friday/Saturday and that gives us a few days to fix any major problems that emerge |
| [17:40:27] | stuartm: | so if it's not today, and I've not heard anything to suggest that, then it's next Monday at the earliest |
| [17:45:50] | stuartm: | ok, per the original schedule, if any bugs are fixed after an RC then we reset the clock, tag another RC and wait a week |
| [17:47:00] | stuartm: | last bug fix was Saturday, I know it's not going to be the only fix before release, but if we tag RC2 today and provisionally say release next Monday would that give you enough time? |
| [17:47:36] | wagnerrp: | as far as im concerned, bug fixes in the bindings dont need to reset the clock, as long as its not something that disrupts the grabbers |
| [17:48:17] | caelor: | I think 11049 is marked as a blocker – are we expecting all 0.26 blockers fixed before release? |
| [17:48:20] | caelor: | #11049 |
| [17:48:20] | ** MythLogBot http://code.mythtv.org/trac/ticket/11049 ** | |
| [17:48:48] | caelor: | sorry, I meant #11048 |
| [17:48:48] | ** MythLogBot http://code.mythtv.org/trac/ticket/11048 ** | |
| [17:48:53] | wagnerrp: | all blockers, and typically anything critical as well |
| [17:50:13] | caelor: | stichnot has produced a patch, and I'm just trying to get the deban packaging to work so I can test |
| [17:50:50] | caelor: | but with the suspected cause being an uninitialised variable in libav, it could be a tricky one to confirm fixed |
| [17:51:46] | stuartm: | ideally all blockers should get fixed, in practice that depends on whether anyone is willing to work on those in a reasonable timeframe because we can't indefinitely postpone the release |
| [17:53:58] | anykey_ (anykey_!~anykey@46-126-245-147.dynamic.hispeed.ch) has quit (Quit: leaving) | |
| [17:56:18] | caelor: | superm1, heading towards a users question – I'm trying to use the packaging scripts to create the debs, but I'm not seeing any debs produced, just dsc, tar.gz, .build, .changes, etc. I suspect I'm lacking something fundamental in my understanding |
| [17:56:27] | anykey_ (anykey_!~anykey@46-126-245-147.dynamic.hispeed.ch) has joined #mythtv | |
| [17:57:00] | caelor: | is there a basic background doc I can look to for guidance? |
| [18:18:01] | zombor_ (zombor_!~zombor_@65.29.231.135) has joined #mythtv | |
| [18:18:02] | zombor_ (zombor_!~zombor_@65.29.231.135) has quit (Changing host) | |
| [18:18:02] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [18:27:51] | Seeker`: | I'm in the middle of building now, should be able to give an initial indication in 30 mins or so |
| [18:31:48] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [18:41:37] | Seeker`: | caelor: stichnot: that patch makes at least one previousy broken recording work |
| [18:43:42] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Ping timeout: 246 seconds) | |
| [18:43:50] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [18:43:50] | caelor: | Seeker`, debian build using the packaging scripts? |
| [18:44:51] | Seeker`: | ./build-deb master building |
| [18:45:14] | Seeker`: | caelor: do you get any errors? |
| [18:45:50] | caelor: | not that I can see, just it doesn't build any debs. It looks like the mythtv compile step finishes incredibly quickly, but I can't find any configure/build output |
| [18:46:16] | Seeker`: | caelor: try pastebinning the output? |
| [18:47:18] | caelor: | I was trying build-dsc.sh within a script. Have just tried build-debs.sh and am now getting an error |
| [18:47:25] | caelor: | get-build-deps: not found |
| [18:48:47] | caelor: | http://irclogs.ubuntu.com/2011/11/30/%23ubuntu-mythtv.txt looks like a possibilty – looks like a packaging script problem? |
| [18:49:01] | caelor: | but if so, I don't understand how other people have it working |
| [18:49:40] | Seeker`: | caelor: try changing build-deps to sudo apt-get build-deps mythtv |
| [18:50:13] | Seeker`: | *get-build-deps |
| [18:51:25] | caelor: | ok, it got past that point now. Fingers crossed! |
| [18:51:55] | caelor: | if I have more build issues, I'll bump over to -users |
| [18:52:12] | Seeker`: | caelor: ping me in there if you do |
| [18:52:31] | caelor: | will do. it's starting configure now, so hopefully it's just a case of waiting |
| [19:21:13] | Steve-Goodey (Steve-Goodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [19:26:26] | Steve-Goodey (Steve-Goodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has joined #mythtv | |
| [19:27:43] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 255 seconds) | |
| [19:27:45] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [19:41:39] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-171-28-68.hsd1.wa.comcast.net) has joined #mythtv | |
| [19:41:48] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-171-28-68.hsd1.wa.comcast.net) has quit (Changing host) | |
| [19:41:48] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [19:54:39] | caelor: | Seeker`, looks like the build finished successfully. Thanks for your help |
| [19:55:04] | caelor: | stichnot, I've got a build with the patch in, but won't be able to test it until tomorrow. I'll check back in then |
| [19:55:42] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
| [19:56:00] | Seeker`: | caelor: cool |
| [20:00:32] | caelor is now known as caelor_ | |
| [20:14:27] | Steve-Goodey (Steve-Goodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [20:15:42] | stuartm: | stuarta: the screwy ep stuff seems to be a fixup bug, they've changed it from "S5 Ep1" to "S5 Ep1/19" |
| [20:17:01] | Seeker`: | stichnot: now up to 4 recordings which were broken before the patch which now work |
| [20:19:06] | stuartm: | stuarta: just not seeing which fixup it is yet |
| [20:22:05] | dekarl1 is now known as dekarl | |
| [20:23:08] | stuartm: | ah, it's the series fixup, obviously ... |
| [20:23:50] | stuartm: | not sure if it's best to leave the series/ep info in the description or strip it as it seems we do for other formats |
| [20:24:56] | stuartm: | stripping it entirely breaks matching of previously recorded episodes, but so does leaving it untouched since they've changed the format ... |
| [20:33:36] | stuartm: | ok, here's a head scratcher ... when is it a 'episode' and when is it a 'part'? iirc internally we treat 'partnumber' and 'parttotal' as special, the former is not the same as the episode number |
| [20:34:00] | stuartm: | but does a mini series have espiodes or just parts ... |
| [20:35:03] | stuartm: | seems the UK EIT fixups are sticking the episode number into the partnumber field, which I'm pretty sure is wrong |
| [20:36:03] | superm1: | caelor_: ah therei s a problem with the dependency resolver if you do direct binary builds at Seeker` pointed out |
| [20:36:14] | superm1: | we only use it for source package builds normally, so that just needs to be fixed up |
| [20:42:55] | dekarl: | stuartm if its a movie it has parts but if its a series it has episodes :) |
| [20:43:53] | dekarl: | unless its long episodes split in half... happens when 3x90 minutes gets cut up as 6x45 and similar. |
| [20:44:08] | dekarl: | these might have episode and part number |
| [20:45:06] | stuartm: | I think we need to document the program table with some clear explanations of how and when fields get used |
| [20:45:38] | stuartm: | it's a mess atm, even within the different network fixups things are done differently |
| [20:46:15] | dekarl: | aye, cleaning up the "is a repeat" fixups to do the same across networks/countries would be nice |
| [20:46:33] | stuartm: | I'm not sure whether I go for the short term fix for 0.26, or re-write the fixup entirely to do things 'properly' whatever that means |
| [20:47:41] | dekarl: | doing it properly involves unit testing in my book :/ |
| [20:48:08] | stuartm: | we definitely need distinct Season, Episode fields IMHO and despite what RobertM felt, we can use those as hints for metadata lookups most of the time ... but that's something for 0.27 at this stage |
| [20:48:18] | dekarl: | so many things to do, so little time :( |
| [20:49:42] | dekarl: | imho we need a proper upstream metadata database and eit hashing to connect the datasets. season/episode is doomed when you leave "local series on their own channel". |
| [20:49:49] | stuartm: | seems whatever solution I choose for the 'CBS' fixups, it's still going to result in duplicate matching on past descriptions being broken, that's unavoidable |
| [20:50:57] | dekarl: | I hope thetvdb gets enough donations so they don't do the basic/premium split soonish |
| [20:59:12] | SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has quit (Remote host closed the connection) | |
| [21:04:28] | stuartm: | stuarta: proposing that for 0.26 we stop stripping the part/episode information from the description, we'll still parse it but I'm not actually convinced we need to remove it, at least not until we have proper season/episode support and can display those in the UI |
| [21:07:11] | stuartm: | better to leave it than accidentally strip out the wrong string or just part of the string leaving stuff like "S4 Ep" or any number of variations of the same |
| [21:30:47] | Seeker`: | stichnot: also fixes the wilfred clip I sent you. Unless it has introducted another bug (which I don't really see why it would) I'd consider that patch a successful fix. I'll let you know if there are any changes from 'fixed' over the next day or two. |
| [21:32:15] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [22:02:28] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 248 seconds) | |
| [22:09:38] | Yancho (Yancho!~mpulis@unaffiliated/yancho) has quit (Ping timeout: 246 seconds) | |
| [22:32:20] | Wolfgang1 (Wolfgang1!~Thunderbi@178-27-151-224-dynip.superkabel.de) has quit (Quit: Wolfgang1) | |
| [22:33:52] | sphery: | stuartm: partnumber/parttotal is for 2-part (or more, if they exist?) episodes or mini-series. See http://www.gossamer-threads.com/lists/mythtv/dev/108868#108868 (also describes some of the other generally-misunderstood fields) |
| [22:34:03] | DougMac (DougMac!~chatzilla@78-105-185-36.zone3.bethere.co.uk) has joined #mythtv | |
| [22:34:12] | sphery: | so, it could be S1E16 part 1 of 2 or whatever |
| [22:35:10] | stuartm: | sphery: yeah, that was my general understanding, just seems like it gets a bit confusing around things like mini-series (defined differently in the UK/US) |
| [22:35:41] | stuartm: | and it's definitely been misunderstood in the EIT code |
| [22:36:15] | sphery: | yeah, seems there are many problems with eit data interpretation, based on what dekarl was finding before |
| [22:37:07] | DougMac: | stichnot: I tried the patch and it's looking good. I couldn't get my sample to segfault (it would normally crash within 5 playback attempts) |
| [22:37:36] | DougMac (DougMac!~chatzilla@78-105-185-36.zone3.bethere.co.uk) has left #mythtv () | |
| [22:43:56] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 244 seconds) | |
| [23:33:35] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.) | |
| [23:34:40] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [23:40:41] | SteveGoodey (SteveGoodey!~steve@host86-140-215-72.range86-140.btcentralplus.com) has joined #mythtv | |
| Tuesday, September 4th, 2012 | ||
| [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. |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.