| Saturday, January 19th, 2013, 00:10 UTC | ||
| [00:10:03] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [00:29:14] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds) | |
| [00:31:59] | skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8) | |
| [00:38:11] | stichnot (stichnot!~stichnot@199.189.98.185) has joined #mythtv | |
| [00:38:11] | stichnot (stichnot!~stichnot@199.189.98.185) has quit (Changing host) | |
| [00:38:11] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [00:45:17] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Remote host closed the connection) | |
| [00:45:36] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [00:52:51] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 248 seconds) | |
| [01:07:40] | drussell_ (drussell_!~drussell@d172-219-194-101.abhsia.telus.net) has quit (Ping timeout: 260 seconds) | |
| [01:11:45] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [01:13:24] | joki (joki!~joki@p54865156.dip.t-dialin.net) has quit (Ping timeout: 248 seconds) | |
| [01:14:54] | joki (joki!~joki@p5486239A.dip.t-dialin.net) has joined #mythtv | |
| [01:17:38] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [01:35:33] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [01:47:43] | MythBuild: | build #124 of master-linux-64bit-clang is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . g/builds/124 blamelist: John Patrick Poet <jpoet@mythtv.org > |
| [02:05:04] | MythBuild: | build #546 of master-linux-64bit-icc is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . c/builds/546 blamelist: John Patrick Poet <jpoet@mythtv.org > |
| [02:05:29] | danielk22: | jpabq: I don't agree with pushing card id info into the classes in libs/libmythtv/mpeg |
| [02:06:19] | danielk22: | Those classes aren't supposed to know or care about recording hardware. |
| [02:08:18] | lentferj (lentferj!~lentferj@p579B71BF.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [02:08:35] | jpabq: | danielk22: okay. It can just be very hard to follow what information in the logging goes with which recording. |
| [02:09:38] | lentferj (lentferj!~lentferj@p5798161D.dip.t-dialin.net) has joined #mythtv | |
| [02:09:46] | danielk22: | maybe as a temporary thing to debug the 17,000 no program num bug it makes sense, but it violates the intended separation between the recording and mpeg processing. |
| [02:10:47] | danielk22: | + if we're going to add it, we should just do it at MPEGStreamData creation and not add it to individual method calls... |
| [02:11:26] | jpabq: | I thought about that, but with multirec that would get tricky, wouldn't it? |
| [02:12:21] | danielk22: | The different recorders don't share an MPEGStreamData... |
| [02:13:02] | jpabq: | Ah, right, I was thinking of the streamhandlers, not the streamdata. |
| [02:13:40] | jpabq: | Anyway, for now I will revert that part. |
| [02:13:52] | danielk22: | Yeah, streamhandlers are shared, but the streamdata is what does the per recording filtering. |
| [02:14:18] | danielk22: | jpabq: Feel free to keep it in until that bug is tracked down, I just don't like it long term. |
| [02:14:37] | jpabq: | Okay |
| [02:15:08] | danielk22: | + If you feel it is needed long term lets talk about how to do it nicely. |
| [02:16:19] | jpabq: | It all comes down to trying to parse a log file for the relevant info, in a situation like this PMT problem. I do see your point, though. |
| [02:20:09] | jpabq: | BTW, I have determined that when the PMT failure happens, in TvRec:TuningSignalCheck, the streamdata (typecast to atsc) has the channel as -1.-1 |
| [02:20:09] | danielk22: | Yeah, I just feel if we're need to violate the boundary of concerns we should do it with some care. |
| [02:21:08] | stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [02:21:08] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [02:21:08] | stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [02:21:21] | jpabq: | I have not determined why or where the channel info is getting lost — it is fine just before that, as the signalmonitor succeeds, and has valid channel info. |
| [02:22:18] | danielk22: | jpabq: Is this a channel with a atsc_major and atsc_minor ? i.e. was it ever set? |
| [02:22:26] | jpabq: | I probably have 200 daily 5 minute manual recording rules setup at this point, trying to trap the failure. |
| [02:22:28] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 248 seconds) | |
| [02:22:52] | jpabq: | yes, atsc_major and atsc_minor show up fine earlier in the sequence of events. |
| [02:23:19] | jpabq: | It works for me 99% of the time. |
| [02:23:19] | danielk22: | & this is with master? |
| [02:23:24] | jpabq: | Yes. |
| [02:23:48] | jpabq: | I never had this problem before about a month ago. |
| [02:24:10] | jpabq: | I did update the firmware in my hdhomerun about that time, so the root of the problem could be there. |
| [02:24:16] | danielk22: | I reworked how Reset() works in the *StreamData classes because of some g++ complaints. |
| [02:24:26] | danielk22: | This would have been after 0.26 I believe. |
| [02:24:54] | jpabq: | Was that within the last month, though? I run master even in production. |
| [02:24:55] | danielk22: | e75fb21c45942ee8a17a8d5c64901f2868658440 |
| [02:25:15] | danielk22: | No, I have hardly touched the code in the last month. |
| [02:25:36] | danielk22: | Too busy learning new stuff @ new job. |
| [02:26:13] | jpabq: | Nov 27th. Hmmm, it could have been that long. |
| [02:26:25] | danielk22: | But it was near the end of November, maybe you updated in Dec.. noticed the problem sometime after... |
| [02:26:41] | jpabq: | It happens to me so rarely, that I can't say for sure. In production I see about one failure every couple of weeks. |
| [02:28:48] | danielk22: | It really doesn't sound like [e75fb21c459], it sounds like a race. |
| [02:29:13] | jpabq: | It does sound like a race, but that commit may have exposed it... |
| [02:29:41] | danielk22: | possible. the race itself is most likely in tv_rec.cpp |
| [02:31:23] | jpabq: | I will try and trace that interaction, and see if I spot anything. Thanks. |
| [02:38:03] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [02:40:51] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Ping timeout: 245 seconds) | |
| [02:42:42] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (Ping timeout: 276 seconds) | |
| [02:45:04] | tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:e022:396:b27f:1e8b) has joined #mythtv | |
| [02:45:05] | tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:e022:396:b27f:1e8b) has quit (Changing host) | |
| [02:45:05] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [02:45:44] | rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:e022:396:b27f:1e8b) has joined #mythtv | |
| [02:45:45] | rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:e022:396:b27f:1e8b) has quit (Changing host) | |
| [02:45:45] | rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv | |
| [02:50:20] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 260 seconds) | |
| [03:02:07] | skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has left #mythtv ("Leaving") | |
| [03:02:24] | skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has joined #mythtv | |
| [03:37:11] | kwmonroe` (kwmonroe`!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [03:37:42] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Read error: Operation timed out) | |
| [03:46:39] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [03:52:22] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [03:55:00] | kwmonroe` (kwmonroe`!~kwmonroe@32.97.110.60) has quit (Ping timeout: 252 seconds) | |
| [03:55:59] | peper03 (peper03!~peper03@port-92-203-50-115.dynamic.qsc.de) has quit (Ping timeout: 240 seconds) | |
| [04:12:44] | kwmonroe` (kwmonroe`!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [04:13:13] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Ping timeout: 246 seconds) | |
| [04:22:36] | jafa (jafa!~jafa@c-76-102-118-75.hsd1.ca.comcast.net) has joined #mythtv | |
| [04:25:01] | kwmonroe (kwmonroe!kwmonroe@nat/ibm/x-oxwvjfbznmglwdev) has joined #mythtv | |
| [04:25:16] | kwmonro`` (kwmonro``!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [04:27:45] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds) | |
| [04:27:47] | kwmonroe` (kwmonroe`!~kwmonroe@32.97.110.60) has quit (Ping timeout: 248 seconds) | |
| [04:29:04] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:29:18] | kwmonroe (kwmonroe!kwmonroe@nat/ibm/x-oxwvjfbznmglwdev) has quit (Ping timeout: 245 seconds) | |
| [04:34:25] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [04:37:05] | kwmonro`` (kwmonro``!~kwmonroe@32.97.110.60) has quit (Ping timeout: 260 seconds) | |
| [05:21:13] | Korny (Korny!~Korny@98.159.25.72) has joined #mythtv | |
| [05:31:10] | Goga777 (Goga777!~Goga777@128-71-159-119.broadband.corbina.ru) has joined #mythtv | |
| [05:42:14] | jafa (jafa!~jafa@c-76-102-118-75.hsd1.ca.comcast.net) has quit (Ping timeout: 255 seconds) | |
| [06:39:41] | rsiebert_ (rsiebert_!~quassel@g224251091.adsl.alicedsl.de) has joined #mythtv | |
| [06:43:06] | rsiebert (rsiebert!~quassel@g224251248.adsl.alicedsl.de) has quit (Ping timeout: 272 seconds) | |
| [07:09:29] | Goga777 (Goga777!~Goga777@128-71-159-119.broadband.corbina.ru) has quit (Quit: Leaving) | |
| [07:25:38] | drussell_ (drussell_!~drussell@d172-219-194-101.abhsia.telus.net) has joined #mythtv | |
| [07:29:42] | stoffel (stoffel!~quassel@pD9E43ADA.dip.t-dialin.net) has joined #mythtv | |
| [07:40:54] | SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv | |
| [08:45:21] | Steve-Goodey (Steve-Goodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv | |
| [09:15:02] | Steve-Goodey (Steve-Goodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [09:17:31] | Steve-Goodey (Steve-Goodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv | |
| [10:12:49] | skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv | |
| [10:29:49] | stoffel (stoffel!~quassel@pD9E43ADA.dip.t-dialin.net) has quit (Ping timeout: 246 seconds) | |
| [10:30:31] | sphery_ (sphery_!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [10:32:40] | sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Ping timeout: 256 seconds) | |
| [10:33:58] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [11:42:09] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [12:09:04] | stoffel (stoffel!~quassel@pD9E43ADA.dip.t-dialin.net) has joined #mythtv | |
| [12:26:00] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Read error: Connection reset by peer) | |
| [12:26:15] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [12:35:46] | SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [12:46:47] | SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv | |
| [12:54:09] | Korny (Korny!~Korny@98.159.25.72) has quit (Quit: Leaving) | |
| [13:03:40] | SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [13:06:48] | SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv | |
| [13:09:49] | drussell_: | stichnot: Does your dying drive still read at all? If so, you can probably still get some stuff off it with a "dd if=/dev/sdOLD of=/dev/sdNEW bs=128k conv=sync,noerror" rather than trying to read the filesystem... |
| [13:10:18] | drussell_: | stichnot: Assuming you have a new drive of equal or larger size, of course... |
| [13:13:19] | stichnot: | dd: reading `/dev/sdb': Input/output error :( |
| [13:14:18] | stichnot: | oops, missed the conv=sync,noerror |
| [13:14:26] | drussell_: | stichnot: yeah, unfortunately you're hosed then.... Unless it's a board problem and you can swap boards from an identical drive, but this sounds like problems in the HDA, not the board... |
| [13:14:41] | stuartm: | ddrescue ? |
| [13:15:15] | drussell_: | stichnot: Yeah, but if it won't even read a little at the beginning, your probably toast... You could try ddrescue but if you can't even get any sectors with bs=512 it's not going to be able to get anything either... |
| [13:16:30] | drussell_: | ddrescue just does a dd with large blocks, then if it finds an error in that block, goes back and tries with smaller blocks all the way to 1 sector to try to get as much as possible instead of large block gaps... |
| [13:17:21] | drussell_: | If the drive can't read at all after a power down reset, it's probably not even loading the firmware from the firmware area on the negative sectors and never coming ready |
| [13:19:02] | drussell_: | I've got a 640GB here full of videos that if I could just get it to come ready one more time I could copy, but I didn't catch it in time and won't come ready again... Never got around to trying putting it in the freezer for 20 mins first as a hail-mary... That rarely works, though... |
| [13:19:25] | stichnot: | adding conv=sync,noerror gives me data, but it appears to be all zeros |
| [13:20:22] | drussell_: | The sync means fill unreadable parts with nulls and the noerror tells it not to stop on error, so in this case, since it can't read anything, you'll just get zeroes.. |
| [13:21:01] | drussell_: | If you can get it to read — just once... you can usually copy straight from beginning to end, esp. if some of the problem is in the positioner... |
| [13:21:03] | stichnot: | fortunately that drive has only recordings – no pictures, DVD rips, source code, etc., so in theory it can all be "recovered" over time |
| [13:21:27] | drussell_: | If it can't read at all, you're hosed... Was it working normally then just suddenly died completely? |
| [13:21:39] | drussell_: | Yeah, still annoying, though :-) |
| [13:22:58] | stichnot: | I believe it suddenly stopped working. There is evidence of a failed recording the night before, though. |
| [13:24:43] | drussell_: | Many HDA (head-disk-assembly) problems show up gradually and give some warning, some are terminal instantly though... PCB problems are usually instant failures... you MIGHT be able to swap boards but you don't have an identical *IDENTICAL* drive, do you? |
| [13:25:40] | drussell_: | Older drives you just had to have the same model family, modern drives there's lots of stuff coded from one board to the one HDA so swaps almost never work, even on identical drives... |
| [13:26:38] | stichnot: | nope, that drive was one-off |
| [13:26:42] | drussell_: | I still always try, though, if I have others from the same production run when I have several in an array or whatever reason have ones that all came off the line together |
| [13:26:49] | drussell_: | Yeah, thought not... |
| [13:27:39] | drussell_: | Probably back to the "good luck :-(" category... |
| [13:28:35] | anykey_ (anykey_!~anykey@46-126-243-153.dynamic.hispeed.ch) has quit (Ping timeout: 252 seconds) | |
| [13:29:26] | Goga777 (Goga777!~Goga777@128-71-159-119.broadband.corbina.ru) has joined #mythtv | |
| [13:33:15] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [13:39:06] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [13:40:13] | anykey_ (anykey_!~anykey@46-126-243-153.dynamic.hispeed.ch) has joined #mythtv | |
| [13:40:44] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [13:40:54] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has quit (Client Quit) | |
| [13:41:16] | stoffel (stoffel!~quassel@pD9E43ADA.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [13:41:22] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [13:51:54] | neufeld: | I did once have a laptop drive that failed because it wouldn't spin up. It was one that I rarely turned off, and I had noticed that it ran hot, so I actually put the drive in the oven, not the freezer, on the assumption that that would help unseize the bearing. Got it to spin up and copied everything off it. Another time, a cell phone on a hip holster caught on some clothes I was moving into a filling washer, |
| [13:51:55] | neufeld: | snapped loose, did a triple-gainer at eye height, then dove into the basin of soapy water. Baked that one too, I did, and got years more service out of it. The General Electric automated electronics repair system and pizza cooker, available at fine hardware stores near you. |
| [13:55:32] | dekarl1 (dekarl1!~dekarl@p4FE85B54.dip.t-dialin.net) has joined #mythtv | |
| [13:56:20] | dekarl (dekarl!~dekarl@p4FE844C0.dip.t-dialin.net) has quit (Ping timeout: 255 seconds) | |
| [13:57:40] | Steve-Goodey (Steve-Goodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [14:36:56] | deepee (deepee!~dp@dpdpkpcom3.plus.com) has quit (Ping timeout: 255 seconds) | |
| [14:38:36] | dekarl1 is now known as dekarl | |
| [14:43:52] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [14:46:48] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [14:49:24] | joki (joki!~joki@p5486239A.dip.t-dialin.net) has quit (Quit: c ya!) | |
| [14:50:03] | joki (joki!~joki@p5486239A.dip.t-dialin.net) has joined #mythtv | |
| [14:50:27] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [14:51:24] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [14:54:53] | dekarl: | is anybody attached to StreamID::toString returning nice text for TableID::CENSOR? I'd prefer it to return nice text for StreamID::EAC3 :) |
| [14:56:50] | skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8) | |
| [15:08:28] | Sharky-AFK is now known as Sharky112065 | |
| [15:52:31] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [15:58:30] | stichnot: | neufeld: good news with respect to my PVR-150 and DISH receiver. Seems that if the receiver is not burning in captions, I do get VBI captions in the recording. |
| [16:10:26] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [16:55:16] | petres (petres!~petre@scheie.homedns.org) has joined #mythtv | |
| [17:05:08] | joki (joki!~joki@p5486239A.dip.t-dialin.net) has quit (Ping timeout: 245 seconds) | |
| [17:06:06] | joki (joki!~joki@p5486239A.dip.t-dialin.net) has joined #mythtv | |
| [17:41:10] | Steve-Goodey (Steve-Goodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv | |
| [18:10:41] | stichnot: | danielk22: http://pastebin.com/4FV1FpcR is a sample frontend stack trace in the middle of the attempt to start PVR-150 live TV. It's looping inside the for(;;) look in avformat_find_stream_info(). I'll look into it more, but if you have any ideas why finding stream info would fail for live TV as opposed to a recording... |
| [18:12:01] | sphery_ (sphery_!~mdean@mythtv/developer/sphery) has quit (Remote host closed the connection) | |
| [18:12:04] | drussell_: | neufeld: Yes, heating can work too (especially for stiction)... It's just the termal change whichever way you need it but in his case I thought it was spinning and already warm, so cold is the only thing to try... (I've dried out many a cell phone too :-) ) |
| [18:16:23] | sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [18:17:40] | Goga777 (Goga777!~Goga777@128-71-159-119.broadband.corbina.ru) has quit (Ping timeout: 248 seconds) | |
| [18:27:44] | peper03 (peper03!~peper03@port-92-203-2-32.dynamic.qsc.de) has joined #mythtv | |
| [18:30:10] | skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv | |
| [18:32:33] | frankster (frankster!~frankster@host86-177-210-247.range86-177.btcentralplus.com) has joined #mythtv | |
| [19:34:17] | neufeld: | stichnot: good news for you on the VBI front. Bug 11328 sometimes causes trouble with the timing in the HD-PVR captioning scripts, but I figure that bug's either already fixed, or will be imminently. My software upgrade policy makes it hard for me to test patches to the backend, but it's reproducible by jpoet, so I doubt he needs my help testing. |
| [19:39:13] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [19:51:50] | jpabq: | neufeld: yes, #11328 is near the top of my priority list. |
| [19:51:50] | ** MythLogBot http://code.mythtv.org/trac/ticket/11328 ** | |
| [20:12:31] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [20:17:32] | len (len!~quassel@75-161-183-113.mpls.qwest.net) has joined #mythtv | |
| [20:17:56] | len is now known as Guest55744 | |
| [20:18:51] | skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has quit (Ping timeout: 272 seconds) | |
| [20:22:56] | Steve_Goodey (Steve_Goodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv | |
| [20:22:59] | Steve-Goodey (Steve-Goodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Read error: Connection reset by peer) | |
| [20:44:17] | skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8) | |
| [21:11:13] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [21:15:23] | Guest55744 (Guest55744!~quassel@75-161-183-113.mpls.qwest.net) has quit (Read error: Connection reset by peer) | |
| [21:20:04] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 248 seconds) | |
| [21:33:06] | len (len!~quassel@75-161-183-113.mpls.qwest.net) has joined #mythtv | |
| [21:33:30] | len is now known as Guest59917 | |
| [21:38:14] | peper03: | Analyzing a playback issue with Cars 2 DVD. Video playback freezes every so often for a few seconds with VDPAU playback. It appears to be because the audio timestamp resets to ~0 at a cell boundary and this causes us to buffer video frames constantly until the maximum has been reached. |
| [21:38:19] | peper03: | See https://github.com/MythTV/mythtv/blob/master/ . . . er.cpp#L4587 |
| [21:39:15] | peper03: | I *think* the problem in this case is just that the audio packet comes before the video packet but I'm not sure of the best course of action. |
| [21:40:31] | peper03: | I tried adding an additional condition to that 'if' – (lastapts > lastvpts – 400) – which does seem to work but I'm not convinced it's a clean solution and I've no idea if that's liable to cause playback issues elsewhere. |
| [21:42:01] | Steve_Goodey (Steve_Goodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:42:26] | SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:42:57] | peper03: | If I add that, we appear to empty the frames from 'storedPackets' and the first video frame read in afterwards has (if I'm not mistaken) a 'matching' timecode also, which leads me to suspect that we normally get the video packet before the audio packet but that's presumably just luck. |
| [21:47:35] | peper03: | I'm also curious about why the maximum number of video frames we buffer is 220. Doesn't that mean that we handle video and audio packets arriving more than 7 seconds (at 29.97fps) apart . Or nearly 9 seconds at 25fps? |
| [22:01:56] | stuartm: | it's mostly for high latency streams, e.g. internet content I believe |
| [22:03:58] | peper03: | stuartm: Ok. I found this commit from jya that increased it from 180 to 220 frames: https://github.com/MythTV/mythtv/commit/041ec . . . 8e5cd4d92aab |
| [22:04:37] | peper03: | The sample file referenced in that ticket has the audio packets lagging video by about 3.5 seconds! |
| [22:11:19] | peper03: | Actually, not sure about that. My test code might have been screwing up some of the results there. It certainly screwed up playback of that file. |
| [22:21:57] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Remote host closed the connection) | |
| [22:23:17] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [22:30:27] | peper03: | Seems the maximum number of packets to buffer has been rising over time. It seems it was first introduced in [6ba14bf] due to #5749 – just makes me all the more wary of fiddling too blindly here. |
| [22:30:27] | ** MythLogBot http://code.mythtv.org/trac/ticket/5749 ** | |
| [22:33:25] | peper03: | Does MythLogBot only provide URLs for tickets or will it link to commits as well? |
| [22:34:28] | wayne__ (wayne__!~wayne@codeworks.gen.nz) has quit (Ping timeout: 248 seconds) | |
| [22:35:25] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Remote host closed the connection) | |
| [22:35:34] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [22:40:01] | tonsofpcs: | peper03: no idea. |
| [22:41:58] | tonsofpcs: | would be nice if someone could build an a/v sync test video (if necessary, I could) and then somehow encode it with various packet drifts (I can't do this) |
| [22:45:05] | peper03: | tonsofpcs: In this instance, I can't even produce a sample DVD that demonstrates the problem using the assets ripped from the original disc. Probably the same problem – no control over where or how far apart the packets appear. |
| [22:51:57] | tonsofpcs: | right, which is why a carefully crafted file is necessary |
| [22:52:36] | tonsofpcs: | I have analysis tools at my disposal but I don't have stream crafting tools available... |
| [22:52:41] | tonsofpcs: | (other than standard encoders) |
| [22:54:59] | peper03: | I would have thought there'd be some option in ffmpeg but then I've hit that brick wall before now. Doesn't matter how big your Swiss army knife is, there'll always be at least one thing it's missing :) |
| [22:56:04] | tonsofpcs: | I think the swiss army knife is a hex editor and patience. |
| [22:56:58] | tonsofpcs: | if your audio packets are always the same size and you know their boundaries, you should be able to slip them no problem for a file of arbitrary length and then just truncate the beginning and end a bit |
| [22:57:11] | tonsofpcs: | easier said than done, I know |
| [22:57:56] | peper03: | Why afford yourself the luxury of a hex editor? Just enter the binary with switches and a latch button :) |
| [22:59:03] | tonsofpcs: | I wanted a swiss army knife, not an entire swiss army. |
| [23:00:27] | peper03: | You need to think bigger. Don't restrict yourself :) |
| [23:01:11] | tonsofpcs: | k, now I'm thinking about a large dinner. cya ;) |
| [23:02:45] | peper03: | I think the only problem with creating test files with varying drifts is where do you stop? In the end, you need to handle 'normal' files found in the wild. The problem is that you end up chasing them but there'll always be a limit on the amount of drift you can handle. |
| [23:03:13] | tonsofpcs: | why would there be? |
| [23:03:22] | tonsofpcs: | this is not an unbounded problem, there is no halting problem here. |
| [23:03:33] | tonsofpcs: | analyze the whole file and see how much it drifts. Buffer that much plus your required overhead. |
| [23:03:53] | peper03: | And then the next file comes in with a bit more drift. |
| [23:04:22] | tonsofpcs: | and that file is analzed and you knw how much and buffer that much |
| [23:04:36] | tonsofpcs: | (of course, you'd really do statistical analysis and 'guess' at the probably buffer required) |
| [23:04:57] | peper03: | Exactly. You're always chasing. At some point you have to say enough. |
| [23:05:03] | tonsofpcs: | why are you chasing? |
| [23:05:26] | peper03: | Because every time you increase the buffer, someone else comes along with another example that has bigger drift. |
| [23:05:49] | tonsofpcs: | and? dynamically allocate tthe buffer. |
| [23:06:16] | tonsofpcs: | if you don't have enough RAM, yell that you don't have enough RAM and slam your fists on the table (or, ya know, degrade gracefully and suggest transcoding before playback) |
| [23:06:40] | tonsofpcs: | alternatively, couldn't you read the audio and video separately? |
| [23:07:01] | peper03: | That buffer's going to end up very big if someone decides to split audio and video by an hour (just as an example). |
| [23:07:19] | peper03: | Audio and video are already handled separately. The problem is syncing them. |
| [23:07:30] | tonsofpcs: | if you know the start and stop timecode of both, you know how long each is and how much overlaps, you can start playing back the one that leads and then start playing back the one that lags at the appropriate moment |
| [23:07:39] | tonsofpcs: | you then only need to buffer a standard amount (say a video frame or two) |
| [23:08:24] | tonsofpcs: | then your buffer problem is just one of 'drift' which I'm sure is specified by some standard (or can be statistically analyzed and dynamically allocated, as above) |
| [23:08:51] | peper03: | In worst case, you could have all the audio packets followed by all the video packets (or the other way round). I'm not saying that makes much sense, just that it's theoretically possible. |
| [23:09:36] | tonsofpcs: | it is. And it is very possible. It was common at one time. And you can read teh file with a pointer reading video at the start and a pointer reading the audio where it starts and just move them ignoring the other packets. |
| [23:10:48] | tonsofpcs: | heck, they still purposely offset audio from image with film since the playback devices are different but the same piece of film runs through both |
| [23:11:10] | peper03: | But not if it's streaming. |
| [23:11:11] | tonsofpcs: | the 'pointers' (playback head/light and lens) just get moved about so that they're playing the right thinggs in sync. |
| [23:11:26] | peper03: | Although with film the distance is fixed and known. |
| [23:11:28] | tonsofpcs: | a reel of film is essentially a stream. |
| [23:11:44] | peper03: | and manageable. |
| [23:12:29] | tonsofpcs: | this distance is fixed (within reason, there's jitter due to the way packets are stored not due to external forces) and known (PTS/DTS) |
| [23:13:11] | tonsofpcs: | suggestion: go visit your friendly neighborhood projectionist :) |
| [23:13:42] | peper03: | I did. A friend used to do it :) |
| [23:14:23] | peper03: | Not that I'm claiming I know all there is to know about it, though :) |
| [23:14:27] | tonsofpcs: | with multiple types of film and multiple different audio playback mechanisms and each reel labeled with the proper offsets (and other gritty detaails) |
| [23:14:47] | tonsofpcs: | because that "audio is 7 inches ahead of video" [or whatever] label is the same as your PTS/DTS |
| [23:15:11] | tonsofpcs: | (only your PTS/DTS are *much* more precise and accurate) |
| [23:15:49] | peper03: | We were always impressed that Dolby could not only to put the audio data between the sprocket holes but that they had the bandwidth to add their logo in the middle of each packet :) |
| [23:16:01] | tonsofpcs: | heh, ah... Dolby Digital.... |
| [23:16:33] | tonsofpcs: | AC-3 also can be carried inside PCM, it looks about the same (except they don't manage to get their logo into the waveform ;) |
| [23:16:51] | tonsofpcs: | ____||_____||_____||_____||______ |
| [23:16:52] | peper03: | They should try harder :) |
| [23:16:55] | tonsofpcs: | and it sounds like a machine gun ;) |
| [23:17:30] | tonsofpcs: | it's realtively easy for someone to route AC3 into a PCM decoder that feeds speakers at work... I *run* to shut it off when it happens, can hear it down the hall |
| [23:17:35] | tonsofpcs: | so annoying. |
| [23:17:41] | tonsofpcs: | (and bad for the equipment) |
| [23:18:46] | peper03: | If it's hitting the speakers with a full-on, full-off, I can imagine it doesn't do them much good in the long run. |
| [23:19:07] | tonsofpcs: | well, cable has capacitance so it's not quite... but it was before it hit that circuit |
| [23:19:45] | tonsofpcs: | anyway, for your problem, if you can buffer the next /n/ PTSs, you can simply 'play' each section [audio and video] that much and buffer that much |
| [23:21:12] | peper03: | I hope danielk22 or whoever else likes (?) to play around in AVFormatDecoder is taking notes (or can explain exactly what is happening). |
| [23:22:46] | peper03: | In my particular case, I think the video frames are being buffered before they've been looked at. Audio is considered 'master' (as I understand it) so if that resets its timecode first, we just keep buffering the video frames until the audo 'catches up'. |
| [23:23:11] | peper03: | Which can take a long time depending on the timecodes. |
| [23:24:47] | peper03: | I think it may be simplest (with the current implementation) just to wave a flag saying 'audio timecode has reset' and then process the buffered video. Once that's gone, we read the next video frame and suddenly realise that it's reset its timecode too. |
| [23:25:18] | jpabq: | For #11334, most of the time we have processed a PAT *before* DTVSignalMonitor::SetProgramNumber() is called. However, once in a while, SetProgramNumber() is called before we have seen a PAT, and when that happens we end up resetting the "program number" to -1, so when we finally do see the PAT we no longer no longer can match it. |
| [23:25:18] | ** MythLogBot http://code.mythtv.org/trac/ticket/11334 ** | |
| [23:30:08] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 245 seconds) | |
| [23:30:19] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [23:32:18] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [23:32:19] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [23:44:41] | petres (petres!~petre@scheie.homedns.org) has quit (Quit: Leaving) | |
| [23:47:46] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds) | |
| [23:52:05] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 260 seconds) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.