| Wednesday, January 9th, 2013, 00:00 UTC | ||
| [00:00:32] | jpabq: | stichnot: I want to look and make sure that all the frames leading up to a keyframe, are flushed out to the previous recording, and that we start the new recording with a keyframe. I have not looked at that part yet, at all. |
| [00:00:54] | johnf (johnf!~johnf@Gi0-1-8-0.wan01.syd07.aunsw.bltprf.net) has left #mythtv () | |
| [00:00:58] | jpabq: | I also need to make sure I didn't break something with mpeg2, fixing the H.264. |
| [00:02:38] | zombor (zombor!~zombor__@65.29.231.135) has joined #mythtv | |
| [00:02:39] | zombor (zombor!~zombor__@65.29.231.135) has quit (Changing host) | |
| [00:02:39] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [00:04:50] | whyzzyrd (whyzzyrd!~grimreape@chon2-adsl.demon.co.uk) has quit (Quit: sleeps) | |
| [00:06:19] | jpabq: | stichnot: neufeld: Don't bother with that patch. It is not right. It looks for the first video payload packet, but the H.264 starts off with an audio packet. I knew that, but forgot. |
| [00:06:47] | jpabq: | Sorry, the HD-PVR starts off with an audio packet. |
| [00:15:54] | ExElNeT (ExElNeT!~exelnet@p5DDBB187.dip.t-dialin.net) has joined #mythtv | |
| [00:25:43] | stichnot: | peper03: http://pastebin.com/6FgFCu1j This provides the abstracted HasReachedEof() functionality for MythPlayer and its subclasses. |
| [00:30:12] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [00:33:48] | stichnot (stichnot!~stichnot@66.109.105.7) has joined #mythtv | |
| [00:33:49] | stichnot (stichnot!~stichnot@66.109.105.7) has quit (Changing host) | |
| [00:33:49] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [00:40:45] | xavierh_: | |
| [00:43:34] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds) | |
| [00:53:01] | joki (joki!~joki@p548656CC.dip.t-dialin.net) has quit (Read error: Operation timed out) | |
| [00:54:47] | joki (joki!~joki@p5486567B.dip.t-dialin.net) has joined #mythtv | |
| [01:40:49] | ggervasio (ggervasio!~gervasio@2601:9:4b00:5d:e575:5087:41db:920a) has left #mythtv () | |
| [01:46:18] | jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [02:08:56] | lentferj (lentferj!~lentferj@p579B792F.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [02:09:58] | lentferj (lentferj!~lentferj@p579B7BB4.dip.t-dialin.net) has joined #mythtv | |
| [02:25:33] | ExElNeT_ (ExElNeT_!~exelnet@p5DDB91A4.dip.t-dialin.net) has joined #mythtv | |
| [02:26:28] | ExElNeT (ExElNeT!~exelnet@p5DDBB187.dip.t-dialin.net) has quit (Ping timeout: 248 seconds) | |
| [02:29:38] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 255 seconds) | |
| [02:31:57] | stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [02:31:58] | stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [02:31:58] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [02:34:54] | jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 264 seconds) | |
| [02:44:04] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-171-28-68.hsd1.wa.comcast.net) has joined #mythtv | |
| [02:44:04] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-171-28-68.hsd1.wa.comcast.net) has quit (Changing host) | |
| [02:44:04] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [02:58:08] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-0.columbus.res.rr.com) has quit (Ping timeout: 256 seconds) | |
| [03:26:16] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Read error: Operation timed out) | |
| [03:41:44] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [03:46:16] | deschmit (deschmit!~deschmit@97-88-224-201.dhcp.roch.mn.charter.com) has joined #mythtv | |
| [03:46:41] | deschmit: | #mythtv-users |
| [03:46:54] | deschmit (deschmit!~deschmit@97-88-224-201.dhcp.roch.mn.charter.com) has quit (Client Quit) | |
| [03:47:24] | jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [03:53:55] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:54:56] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [04:03:17] | gigem: | whyzzyrd: I doubt you check the logs, but just in case. The scheduler already does that if it has sufficient guide data to tell the programs are the same. If you have a case that you believe is in error, please open a ticket at http://code.mythtv.org/. |
| [04:03:45] | ExElNeT_ (ExElNeT_!~exelnet@p5DDB91A4.dip.t-dialin.net) has quit (Ping timeout: 240 seconds) | |
| [04:21:07] | daniel6644 (daniel6644!~reap3r@ppp196-35.static.internode.on.net) has joined #mythtv | |
| [04:25:31] | daniel6644: | Hey Guys, Im running Feodra 17 fully updated. I recently installed mythtv and am trying to install a Sony PlayTV usb capture card. I have the firmware in the correct place and have been following this guide "http://www.linuxtv.org/wiki/index.php/How_to_ . . . ivers". I am recieving errors when running "make install" the errors are listed on the following |
| [04:25:32] | daniel6644: | paste site > "http://pastebin.com/Ec5wJScN" can anyone help me install the driver and get this card working? |
| [04:40:01] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds) | |
| [04:41:19] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:41:24] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 248 seconds) | |
| [04:54:37] | sraue_ (sraue_!~stephan@178-191-72-90.adsl.highway.telekom.at) has joined #mythtv | |
| [05:11:44] | jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 260 seconds) | |
| [05:56:54] | sraue_ is now known as sraue | |
| [05:57:00] | sraue (sraue!~stephan@178-191-72-90.adsl.highway.telekom.at) has quit (Changing host) | |
| [05:57:00] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [06:19:28] | jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has joined #mythtv | |
| [06:19:28] | jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has quit (Changing host) | |
| [06:19:28] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [06:22:19] | daniel6644: | Hey Guys |
| [06:22:21] | daniel6644: | anyone here |
| [06:22:46] | daniel6644: | nothing seems to be able to ocnnect ot my backend mythtv server |
| [06:22:51] | daniel6644: | Firewall is off. |
| [06:23:04] | daniel6644: | I added a caoture card and it scanned and found channels |
| [06:23:10] | daniel6644: | frontend says cant find backend? |
| [06:23:12] | daniel6644: | any ideas? |
| [06:23:28] | wagnerrp: | did you run the backend? |
| [06:24:43] | daniel6644: | Yes. If you mean run the setup. I ran it and changed the ip's to the machines local ip. It suggested I do that and not have 172.0.0.1. |
| [06:24:51] | daniel6644: | or is there a command to "Start" the backend |
| [06:24:55] | wagnerrp: | no, i mean the backend |
| [06:24:57] | wagnerrp: | did you run it |
| [06:24:59] | wagnerrp: | 'mythbackend' |
| [06:25:00] | daniel6644: | nope |
| [06:25:17] | wagnerrp: | can't find something that's not running |
| [06:25:33] | daniel6644: | OH MY GOD |
| [06:25:34] | daniel6644: | hahaha |
| [06:25:36] | daniel6644: | thankyou |
| [06:25:37] | daniel6644: | im an idiot |
| [06:25:38] | daniel6644: | hahahah |
| [06:25:51] | daniel6644: | wasted na hour on this |
| [06:39:11] | rsiebert (rsiebert!~quassel@g225058026.adsl.alicedsl.de) has joined #mythtv | |
| [06:42:12] | rsiebert_ (rsiebert_!~quassel@g224251145.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds) | |
| [07:09:35] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [07:38:53] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 255 seconds) | |
| [07:40:38] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [07:51:42] | Goga777 (Goga777!~Goga777@128-71-222-125.broadband.corbina.ru) has joined #mythtv | |
| [07:53:08] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [08:34:44] | toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (Quit: Lost terminal) | |
| [08:41:34] | Goga777 (Goga777!~Goga777@128-71-222-125.broadband.corbina.ru) has quit (Ping timeout: 240 seconds) | |
| [08:43:34] | toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv | |
| [09:00:01] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:1033:c081:bebe:c431) has joined #mythtv | |
| [09:25:05] | daniel6644 (daniel6644!~reap3r@ppp196-35.static.internode.on.net) has quit (Ping timeout: 276 seconds) | |
| [09:34:44] | ExElNeT (ExElNeT!~exelnet@p5DDB91A4.dip.t-dialin.net) has joined #mythtv | |
| [09:38:43] | rsiebert_ (rsiebert_!~quassel@g225058026.adsl.alicedsl.de) has joined #mythtv | |
| [09:42:47] | rsiebert (rsiebert!~quassel@g225058026.adsl.alicedsl.de) has quit (*.net *.split) | |
| [09:59:00] | wolfgang1 (wolfgang1!~wolfgang@178-27-144-160-dynip.superkabel.de) has quit (Ping timeout: 252 seconds) | |
| [10:00:41] | wolfgang1 (wolfgang1!~wolfgang@178-27-144-160-dynip.superkabel.de) has joined #mythtv | |
| [10:35:58] | rhce7320 (rhce7320!~gregc@59.167.200.141) has joined #mythtv | |
| [10:39:52] | xris (xris!~xris@mythtv/developer/xris) has quit (Ping timeout: 272 seconds) | |
| [11:10:02] | rhce7320 (rhce7320!~gregc@59.167.200.141) has quit (Quit: Leaving.) | |
| [12:34:17] | zombor (zombor!~zombor__@65.29.231.135) has joined #mythtv | |
| [12:34:18] | zombor (zombor!~zombor__@65.29.231.135) has quit (Changing host) | |
| [12:34:18] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [12:37:11] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [12:38:18] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [14:11:25] | stichnot: | stuartm: peper03: I suspect MythPlayer::framesPlayed isn't being reset on some DVD nav transitions, making it appear from the OSD that playback is N seconds ahead of reality. |
| [14:11:45] | stichnot: | and I think I've seen the same for live TV program transitions |
| [14:18:02] | Goga777 (Goga777!~Goga777@128-71-222-125.broadband.corbina.ru) has joined #mythtv | |
| [14:18:50] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [14:43:04] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-0.columbus.res.rr.com) has joined #mythtv | |
| [14:47:58] | zombor (zombor!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv | |
| [14:47:58] | zombor (zombor!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host) | |
| [14:47:58] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [15:08:25] | stichnot: | ok, perhaps I was too hasty in removing MythDVDPlayer::GetSecondsPlayed() ... |
| [15:10:21] | jheizer_ (jheizer_!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [15:12:49] | jheizer__ (jheizer__!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [15:13:31] | jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 260 seconds) | |
| [15:15:29] | jheizer_ (jheizer_!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 260 seconds) | |
| [15:28:49] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [15:30:14] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 240 seconds) | |
| [15:31:46] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [15:42:31] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [15:42:32] | knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Changing host) | |
| [15:42:32] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [15:52:21] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 276 seconds) | |
| [16:04:59] | Lomion0815 (Lomion0815!~androirc@194.24.138.3) has joined #mythtv | |
| [16:17:18] | Lomion0815 (Lomion0815!~androirc@194.24.138.3) has quit (Ping timeout: 244 seconds) | |
| [16:35:14] | stichnot (stichnot!~stichnot@199.189.96.66) has joined #mythtv | |
| [16:35:14] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:35:14] | stichnot (stichnot!~stichnot@199.189.96.66) has quit (Changing host) | |
| [16:47:41] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me) | |
| [16:52:05] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [16:55:57] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [17:21:35] | stichnot (stichnot!stichnot@nat/google/x-pcujjvatmtrliomz) has joined #mythtv | |
| [17:21:35] | stichnot (stichnot!stichnot@nat/google/x-pcujjvatmtrliomz) has quit (Changing host) | |
| [17:21:35] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:26:51] | SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv | |
| [17:39:57] | stuartm: | stichnot: fwiw, seeking is affected by this H.264 position issue, I've noticed that skipping forward can actually jump backwards if I've been watching long enough |
| [17:40:32] | stuartm: | that suggests that the seektable is fine, it's purely the current frame count that's wrong |
| [17:41:37] | stichnot: | interesting |
| [17:41:46] | stichnot: | do you have a sample I can look at? |
| [17:42:18] | stuartm: | uploading atm |
| [17:42:38] | stichnot: | I can't recall making changes to the way the frames are counted, at least not directly |
| [17:45:14] | jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [17:52:18] | jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 264 seconds) | |
| [18:00:17] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:1033:c081:bebe:c431) has quit (Read error: Connection reset by peer) | |
| [18:00:40] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [18:11:46] | stuartm: | upload stalled a couple of times :( |
| [18:12:11] | ExElNeT (ExElNeT!~exelnet@p5DDB91A4.dip.t-dialin.net) has quit (Quit: Lost terminal) | |
| [18:13:23] | stuartm: | I went with a 50MB sample, should be long enough to show the problem, but if necessary I can up that to 250MB which should definitely be long enough to see a clear mismatch between the reported position and the actual position |
| [18:14:44] | stuartm: | https://www.box.com/files/0/f/428372080/1/f_5524618108 |
| [18:23:11] | dekarl (dekarl!~dekarl@p4FCEF011.dip.t-dialin.net) has quit (Ping timeout: 255 seconds) | |
| [18:25:54] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [18:27:06] | stichnot: | can't get this infernal mythcommflag to actually rebuild the seek table :( |
| [18:28:41] | dekarl (dekarl!~dekarl@p4FCEFCD8.dip.t-dialin.net) has joined #mythtv | |
| [18:51:39] | peper03 (peper03!~peper03@port-92-203-31-106.dynamic.qsc.de) has joined #mythtv | |
| [18:53:01] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:53:50] | peper03: | stichnot: Your patch for HasReachedEOF seems to work ok. Just had a segmentation fault when trying one DVD but now I can't reproduce it. It's probably not related to the patch. |
| [18:55:02] | peper03: | stichnot: Presumably the loss of MythDVDPlayer::GetSecondsPlayed is what's stopping the OSD progress info updating during a still frame. |
| [18:56:42] | stichnot: | peper03: I re-added GetSecondsPlayed. Does that fix the still frame timer? |
| [18:59:28] | peper03: | stichnot: Ah, sorry. Missed that. I'll check now. |
| [19:01:09] | stichnot: | stuartm: calling m_h264_parser->use_I_forKeyframes(false) causes no keyframes to be found for your sample, though it seems to be necessary for accurate HD-PVR keyframe detection |
| [19:02:46] | stichnot: | so I broke mythcommflag --rebuild in 0.25 and 0.26 for those kinds of files |
| [19:03:13] | stuartm: | stichnot: hmm, that would explain why when I first ran rebuild it wiped the seektable, it produced a working seektable the second time I ran it but I'd forgotten that was after I reverted that change hoping it would fix the position bug |
| [19:03:53] | stuartm: | I didn't connect the two :) |
| [19:04:00] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv | |
| [19:04:06] | stichnot: | I guess I could retry with use_I_forKeyframes(true) if the first pass fails to find any keyframes |
| [19:05:10] | stichnot: | anyway, now that I finally have a seektable, I can continue on the actual problem... |
| [19:06:12] | stuartm: | what we need is a way to check for the presence of IDR keyframes |
| [19:06:50] | stuartm: | maybe count both in a single pass, but just discard one or the other list |
| [19:08:32] | peper03: | stichnot: Progress is now shown on still frames :) |
| [19:08:41] | stichnot: | cool. |
| [19:12:19] | stichnot: | stuartm: it would be hard for mythcommflagplayer to distinguish. The flag that controls this is I_is_keyframe, see the line "is_keyframe |= I_is_keyframe && isKeySlice(slice_type);" in H264Parser.cpp |
| [19:12:33] | stuartm: | then again, there may be samples where both ordinary I frames and IDR I frames are used, e.g. more I-frames around high motion scenes and IDR in slower scenes |
| [19:13:26] | stichnot: | What is the recorder putting in the recordedseek table? Anything? |
| [19:13:55] | stuartm: | something definitely |
| [19:14:13] | stuartm: | the recorder is producing a working seek table |
| [19:14:25] | stuartm: | so yeah, mythcommflag just needs to emulate the recorder |
| [19:17:19] | stichnot: | what does the recorder's keyframe distance appear to be? |
| [19:17:32] | stichnot: | in your sample, the non-IDR keyframes are 24 frames apart |
| [19:17:46] | stichnot: | after mythcommflag --rebuild, that is |
| [19:20:32] | stichnot: | stuartm: do you know which recorder class gets used? |
| [19:21:33] | stuartm: | should be dtv |
| [19:22:20] | stichnot: | DTVRecorder has a lot of subclasses. e.g. DVBRecorder |
| [19:23:37] | stichnot: | which recorder is created in RecorderBase::CreateRecorder()? |
| [19:26:46] | stuartm: | dvb |
| [19:27:59] | stuartm: | ok, keyframe distance is variable in the seektable generated by the recorder, I can't see a pattern to it, although it often hits 32–34 |
| [19:28:40] | stuartm: | 19, 24, 22, 30 |
| [19:28:58] | stuartm: | http://pastebin.com/fYGHpM3F |
| [19:30:05] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [19:30:14] | jpabq: | For broadcast H.264, the keyframe distance is often not consistent. |
| [19:30:17] | stuartm: | stichnot: this is DVB-S |
| [19:32:00] | jpabq: | stichnot: I will take a look at H264Parser, and see if I can make it work with BBC samples even when use_I_forKeyframes(false) is used. |
| [19:37:48] | jpabq: | stichnot: Actually, doing it at the app level is probably going to be required for the results to be accurate. At what point would H264Parser decided that it is not finding an IDR, so switch to using I frames? |
| [19:38:45] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Remote host closed the connection) | |
| [19:38:59] | jpabq: | The problem is, that the HD-PVR does produce I frames, but they cannot be used as keyframes, so it cannot be an OR situation. |
| [19:39:13] | stichnot (stichnot!stichnot@nat/google/x-vepapkjmnutlusfx) has joined #mythtv | |
| [19:39:14] | stichnot (stichnot!stichnot@nat/google/x-vepapkjmnutlusfx) has quit (Changing host) | |
| [19:39:14] | stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [19:39:41] | jpabq: | stichnot: The problem is, that the HD-PVR does produce I frames, but they cannot be used as keyframes, so it cannot be an OR situation. |
| [19:47:43] | stichnot: | I see, the recorder only invokes use_I_forKeyframes(false) for driver=="hdpvr" |
| [19:48:37] | stichnot: | My thought is for mythcommflag --rebuild to restart after ~1000 frames if no keyframes are detected |
| [19:51:24] | jpabq: | stichnot: that seems reasonable. Could probably even go with 500, but 1000 would be safer. |
| [19:56:59] | stichnot: | stuartm: with your sample, with a seektable built, I'm not seeing any inconsistencies. E.g. I pause, enter the editor, move to frame 900, exit the editor, exit the video saving the bookmark, restart playback from the bookmark, quickly press PAUSE before playback starts, enter the editor. I'm still at frame 900 and it looks like the same frame from the previous time. |
| [19:57:47] | stichnot: | though every frame in that sample is pretty similar, so I might be misled :) |
| [19:58:34] | sophusn (sophusn!~sophusn@1385163223.dhcp.dbnet.dk) has joined #mythtv | |
| [19:58:52] | sophusn (sophusn!~sophusn@1385163223.dhcp.dbnet.dk) has left #mythtv () | |
| [20:02:58] | stuartm: | stichnot: since the seek table is ok moving to frame 900 would work as intended |
| [20:03:32] | stuartm: | but if you let it play to that exact same point, exit saving bookmark and re-enter it won't be the same place |
| [20:05:15] | stuartm: | fwiw, you could also start a stopwatch and play from frame 0 then compare, though I'll grant that with just 40 seconds of video the deviation isn't going to be as great as it would be with say a 5 minute sample |
| [20:08:14] | stuartm: | guess you could try this, play back ~30 seconds, then pause, enter the editor and note the frame/time then exit the editor and without unpausing exit playback |
| [20:08:21] | Goga777 (Goga777!~Goga777@128-71-222-125.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [20:10:26] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [20:11:41] | stuartm: | for example, I just tried that here with another video, it reports that we're at frame 3818 and resumes at that frame, but the position in the video is 2 seconds behind where it was |
| [20:12:16] | stichnot: | ok, in that experiment, frame numbers and times agree, but after restart, clearly it has to play dozens more frames before getting to the point where it actually stopped the first time |
| [20:15:51] | stuartm: | yeah, I believe the seektable is accurate, if you seek to frame 100 it will take you to the correct offset, but if you just let it play the played frame count is wrong so it thinks we're at frame 345 but we're actually at something like 400 |
| [20:16:32] | stichnot: | In your sample, it plays to 0:32/0:38 before exiting on EOF |
| [20:17:47] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [20:22:51] | stichnot: | more evidence – enter the editor, seek forward or backward by 1 frame, see a large jump on the first seek |
| [20:25:05] | SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [20:28:45] | peper03: | I'm still getting terrible flickering on DVDs on master. It seems to be if I jump from a still to video. Not every time but easily reproduceable. Oddly, I can't reproduce it any more with VDPAU, only OpenGL (the other day it didn't seem to matter which I used). I can't reproduce it on 0.26 either (regardless of the display setting). |
| [20:29:31] | peper03: | If I turn on playback and timestamp logging, I see lots of lines like 'AVSync waitforframe -11761 0' when it flickers |
| [20:32:38] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Ping timeout: 256 seconds) | |
| [20:36:36] | stuartm: | peper03: I'm still seeing stuttering in some intros and menus, I've not had time to do any debugging |
| [20:39:20] | zombor (zombor!~zombor__@205.197.39.2) has joined #mythtv | |
| [20:39:20] | zombor (zombor!~zombor__@205.197.39.2) has quit (Changing host) | |
| [20:39:20] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [20:43:31] | stuartm: | it feels like the same issue with vdpau buffering, but what little debugging I did manage showed that we were enabling the extra buffering |
| [20:44:50] | jheizer__ is now known as jheizer | |
| [20:47:18] | peper03: | stuartm: This seems different. It seems like every other frame is black, so much more flickering than stuttering. When the menu highlight is shown, that *doesn't* seem to flicker. Just the underlying video. |
| [20:48:09] | stuartm: | hmm |
| [20:50:20] | peper03: | It's possible it's down to the video card. I think it's 'only' got 256MB on it. I had the same card in my main box and found I sometimes couldn't get playback to work because of a lack of memory. But that's not what I'm seeing here. Also, I can't reproduce it on 0.26. I've checked all the playback settings and as far as I can see, they're the same. |
| [20:51:03] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Read error: Connection reset by peer) | |
| [20:56:01] | IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [21:06:52] | stuartm: | stichnot: I've increased the size of the sample, doesn't sound like you'll need it, but it's there all the same |
| [21:07:04] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [21:07:21] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 245 seconds) | |
| [21:07:38] | stuartm: | I'll try to find time before the end of the week to pinpoint the commit that broke things |
| [21:12:29] | Chutt_ is now known as Chutt | |
| [21:16:44] | Mousey (Mousey!~r0dent_@ross154.net) has quit (Quit: Read Error: Connection reset by beer) | |
| [21:20:07] | peper03: | After comparing the logs, it seems that in the good case I always see 'detectInterlace(Detect Scan, Progressive Scan, 25, 576) ->Interlaced Scan' and in the bad case it's always 'detectInterlace(Detect Scan, Interlaced Scan, 25, 576) ->Interlaced Scan' |
| [21:21:45] | jheizer: | I just noticed something that I am not sure is worthy of a bug report since .27 is getting HLS rewrite but, HLS transcode progress on an in progress recording will go way over 100% Ex: Transcoding Progress (720p): 919% |
| [21:33:35] | stichnot: | stuartm: thanks. In the meantime, I'll look into why it's happening in the current code |
| [21:39:24] | wagnerrp: | peper03: 256MB of video memory is only a problem when trying to do things like VDPAU decoding |
| [21:40:44] | peper03: | wagnerrp: Yes, you're right. Sorry, I had it the wrong way round. I *wanted* to use VDPAU but kept having problems. Good, this shouldn't have anything to with too little memory then. |
| [21:45:23] | stichnot: | jheizer: this is because Transcode::TranscodeFile() calls GetTotalFrameCount() outside the loop, so for percentage calculations it's using the frame count that was correct when the transcoding started. |
| [21:46:42] | stichnot: | jheizer: if you're willing to test, look for the line "int percentage = curFrameNum * 100 / total_frame_count;" and add a new statement right before it: "total_frame_count = GetPlayer()->GetCurrentFrameCount();" |
| [21:46:46] | jheizer: | stichnot: I figured it was something along those lines. Again nothing I personally see as important, but if told to make a ticket for it I would. Just decided to test it out. |
| [21:48:04] | jheizer: | Not building from source or I would :( |
| [21:48:40] | jheizer: | 6870% hehe |
| [21:49:44] | jheizer: | Was actually looking at an old mobo I have sitting here earlier today thinking it would make a good master test machine for when the HLS changes take place. Going to use it as a test MBE. |
| [21:50:09] | jheizer: | Maybe I'll set it up to run either from source to be more helpful |
| [21:53:11] | stichnot: | jheizer: presumably it's reasonable to keep reporting 99% completion once it catches up to realtime? |
| [21:54:43] | jheizer: | stichnot: I was debating that and what I would put instead of >100%. Don;t want 100 as then wife will be like it was at 100% and wouldn't XYZ. (Got that earlier today when her Fire HD decided to drop the stream 2 times on a completed transcode) |
| [21:55:46] | jheizer: | I hope it was her wifi signal or the crappy player vs my new proxy code failing... I couldn'd decide what buffer sizes to use. |
| [21:55:49] | zombor_ (zombor_!~zombor__@205.197.39.2) has joined #mythtv | |
| [21:55:50] | zombor_ (zombor_!~zombor__@205.197.39.2) has quit (Changing host) | |
| [21:55:50] | zombor_ (zombor_!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [21:55:58] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat) | |
| [21:56:23] | jheizer: | I guess 99% is a good idea. I can;t come up with anything better. |
| [21:56:39] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Disconnected by services) | |
| [21:58:06] | zombor_ is now known as zombor | |
| [22:00:26] | stichnot: | With the change I suggested, it would naturally converge to 99% once it was just behind realtime. |
| [22:01:03] | stichnot: | Feel free to open a ticket, and if not I'll just try to remember the issue. |
| [22:04:15] | jheizer: | I shall. |
| [22:04:38] | jheizer: | Is HTTP Streaming category for HLS Streaming recorder of for HLS Streaming? |
| [22:06:29] | jya: | wagnerrp: Are you the one working on the metadata code in mythvideo? |
| [22:06:48] | jya: | jheizer: what do you mean? |
| [22:07:11] | wagnerrp: | i don't think anyone is doing significant work on it currently |
| [22:07:28] | jheizer: | jya: in trac. New ticket. Component: MythTV – HTTP Streaming |
| [22:07:29] | wagnerrp: | i'm intending to add some error codes to the grabber interface, but that's it |
| [22:07:46] | wagnerrp: | there was discussion a few days back about merging the people tables used for videos and recordings |
| [22:08:05] | wagnerrp: | but that's more something that will be picked up by sphery's schema change |
| [22:08:43] | wagnerrp: | i am working on rewriting the file scanner, which does involve some schema changes, but nothing directly related to metadata |
| [22:09:15] | jya: | wagnerrp: There's something I think the behaviour should be changed… When you do a scan, and it search for metadata, if it doesn't find anything, the file name becomes the title name. Now after I renamed the file so it could be found successfully; that particular file wasn't updated. I had to reset the metadata, and do a search once again |
| [22:09:22] | wagnerrp: | oh, and prefixes for the certain grabbers |
| [22:09:43] | wagnerrp: | so we don't keep getting into situations of pulling data from one source, using the inetref from another source |
| [22:09:45] | jya: | I think that if no metadata was first found, and it detects a file name change, the video title should be changed to the new name |
| [22:09:54] | wagnerrp: | i'm planning on fixing that in the near term |
| [22:10:09] | jya: | rather that keeping the old name that is no longer relevant |
| [22:10:19] | wagnerrp: | yeah, that could be incorporated into the file scanner |
| [22:10:31] | wagnerrp: | some mechanism that tracks whether the metadata was changed from the default values |
| [22:10:37] | wagnerrp: | and if not, updates them on a file name change |
| [22:28:29] | jheizer: | stichnot: Reported #11339 |
| [22:28:29] | ** MythLogBot http://code.mythtv.org/trac/ticket/11339 ** | |
| [22:33:14] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [22:37:23] | stichnot: | stuartm: in your sample, every 8th frame AvFormatDecoder::ProcessVideoPacket() returns early due to the !gotpicture condition. This causes it not to call ProcessVideoFrame() which would have incremented framesPlayed. The caller of ProcessVideoPacket() is GetFrame(), which if the kDecodeVideo flag is not set, unconditionally increments framesPlayed and doesn't call ProcessVideoPacket(). |
| [22:38:08] | stichnot: | The net effect is that framesPlayed gets out of sync with framesRead, and presumably framesRead is the actual value we want to use for position display. |
| [22:38:29] | stichnot: | I guess I don't understand the full meanings of framesPlayed and framesRead. |
| [22:38:57] | stichnot: | I assumed framesRead would have to do with a decoder thread readahead buffer |
| [22:46:44] | gigem: | stichnot: It's been years since I worked in that area, but yes, framesPlayed was essentially the frame number of the frame currently displayed and framesRead was the frame number of the last frame decoded and buffered for future display. |
| [22:51:54] | stuartm: | stichnot: interesting, that's definitely the root of the problem, and we can simply increment framesPlayed before returning in the !gotpicture block as a quick fix, but I wonder what changed recently to expose that |
| [22:52:46] | stichnot: | ffmpeg resync? |
| [22:52:47] | stuartm: | maybe the ffmpeg resync |
| [22:53:20] | peper03: | Snap! |
| [22:54:04] | stuartm: | begs the question, why would every eighth frame lack a picture, is it in fact a bug in ffmpeg? |
| [22:56:29] | skd5aner: | jya: ping, you around? |
| [22:56:49] | stuartm: | actually nothing so simple as that, "Returns the next available frame in picture. *got_picture_ptr will be 0 if none is available." |
| [22:58:11] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 265 seconds) | |
| [22:58:52] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [23:01:38] | stichnot: | I notice during slow pans of the map that there is a small stutter that is probably every 8th frame. Also, as playback approaches the end, the OSD position seems to accelerate. |
| [23:05:41] | stuartm: | think I'll try commenting out the gotpicture check, see what happens |
| [23:06:43] | stuartm: | I still think we should be incrementing framesPlayed even if gotpicture is zero, so I've already patched that and will push providing I find no regressions |
| [23:06:47] | stichnot: | I get odd behavior on that sample when seeking frame-by-frame while paused or in the editor. Trying to seek one frame back actually jumps a number of frames forward. |
| [23:06:53] | stuartm: | stichnot: thanks for doing the hard work on my behalf |
| [23:07:28] | stichnot: | stuartm: I wonder if it's the mythcommflag seek table that should be fixed instead of playback |
| [23:08:26] | stichnot: | stuartm: np, I'm already dug fairly deep in this area, so it wasn't a big stretch |
| [23:10:45] | stuartm: | stichnot: maybe, I'd need a deeper understanding of exactly what's happening – is this a packet/frame entirely without payload? Is ffmpeg wrong? Would ignoring it when building the seektable potentially lead to more complications? |
| [23:11:14] | stichnot: | yep |
| [23:12:02] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds) | |
| [23:12:18] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [23:12:20] | stuartm: | I mean would stepping forward by a frame in the editor be smart enough to in fact move by two frames if the first frame is effectively empty? |
| [23:13:52] | stichnot: | it actually does that now... |
| [23:14:32] | stichnot: | interestingly, vlc does not appear to have that stutter every 8th frame |
| [23:18:43] | skd5aner: | jya: ping me when you're back around, thanks |
| [23:18:55] | stuartm: | that's where removing the gotpicture check might reveal that the eighth frame isn't empty and that it's a ffmpeg bug, if the stuttering disappears and there are no errors ... |
| [23:20:11] | stuartm: | but it's just as likely that if ffmpeg is incorrectly setting got_picture_ptr than the AVFrame struct is not being populated either so it will prove nothing :) |
| [23:21:54] | peper03: | The flickering problem seems to be caused by MythDVDPlayer not unpausing the still frame, or at least not cleaning up properly. I think it depends on the timing, which matches the fact that sometimes it plays cleanly, sometimes with flickering. |
| [23:27:08] | stichnot: | stuartm: probably every 8th frame is a B-frame. Revealing writeup in https://github.com/mpenkov/ffmpeg-tutorial/issues/7 |
| [23:28:52] | peper03: | Incidentally, switching between interlacers on the fly can produce some pretty ugly results. |
| [23:33:08] | peper03: | *de*interlacers, of course :) |
| [23:33:52] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [23:42:29] | stuartm: | seeing the following in the logs from my recently updated production machine (0.26-fixes) – "ERROR: Master backend tried to connect back to itself!" – the comment in the code states "Should never get here unless there is a bug in the code somewhere. If this happens, it can cause endless event loops." |
| [23:46:21] | stichnot: | I'm not seeing any of those logs in my production Master backend |
| [23:47:48] | jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [23:48:45] | stuartm: | I'm not seeing with my devel backend and I wasn't seeing it before upgrading, I think it's something to do with the ubuntu upgrade or mythbuntu |
| [23:49:02] | peper03: | stuartm: I've seen that before but I can't remember whether it was when I was working on the patch for #11238 or when I was setting somehing up. |
| [23:49:02] | ** MythLogBot http://code.mythtv.org/trac/ticket/11238 ** | |
| [23:49:38] | stuartm: | I'm not seeing anything obviously wrong with the config, the master/backend ips are identical |
| [23:49:57] | peper03: | Sounds like the master backend is also somehow configured as a slave backend. |
| [23:51:47] | peper03: | But that's the local and master backend settings, isn't it? |
| [23:52:02] | stuartm: | think I'll just make a note to myself and push it to the back burner, got too many other jobs to tackle |
| [23:54:03] | stuartm: | peper03: yes, it's a single backend, no slaves, external address – there's nothing invalid in the config, it's not changed in year and is identical to my dev box (except the actual IP) |
| [23:55:28] | peper03: | stuartm: Maybe something like http://www.av8n.com/computer/mythtv-itself.txt ? |
| [23:57:17] | stuartm: | peper03: no, hostname hasn't changed either, so there's no possibility of something like that |
| [23:59:53] | jheizer_laptop (jheizer_laptop!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 252 seconds) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.