MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (72):

aloril, Anssi, brfransen, cesman, Chutt, clever, coling, Cougar, danielk22, dblain_, dekarl, drussell_, ElmerFudd, fetzerch, foobum, frankster, ghoti, gracent, gregL, GreyFoxx, IReboot, J-e-f-f-A, jams, jarle, jarryd, jaug0rd0r, jheizer, joe___, joki, jpabq, jpabq_, jpharvey, jst, jwhite, kc, Kevin`, knightr_, kurre2, kwmonroe, laga, lentferj, mad_enz, Merlin83b, mrand, MythBuild, MythLogBot, neufeld_AFK, Peitolm, Peps, petefunk, poptix, purserj, rsiebert, saintd3v, seld, Sharky-AFK, skd5aner, SmallR2002_, sphery, sraue, SteveGoodey, superm1, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang1, XDS2010_, _charly_
Saturday, January 26th, 2013, 00:06 UTC
[00:06:56] gigem: tonsofpcs: Please let me know how it works for you. I'm confident fo the changes, otherwise, I wouldn't have pushed them, but more testing never hurts.
[00:07:45] tonsofpcs: it's running now, got the frontend on 46.1. Hopefully will know more tonight but, as mentioned, tonight is light on records so I might not see anything useful til mon or tues
[00:08:44] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds)
[00:10:34] gigem: tonsofpcs: I think one of the cases that wasn't handled correctly was when more than one recording was scheduled to start at the same time. If you have enough extra tuners, please try to make sure that happens some.
[00:12:36] tonsofpcs: yea, I'm going to test a 4-at-once recording at some point
[00:12:58] tonsofpcs: cus another issue I was seeing (maybe related?) was that it would push recording #4 away if I tried 4 channels at once
[00:12:58] ** MythLogBot http://code.mythtv.org/trac/ticket/4 **
[00:13:07] tonsofpcs: I have 2x HDHR Duals so it shouldn't be an issue
[00:13:31] mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has joined #mythtv
[00:21:38] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[00:30:01] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Read error: Operation timed out)
[00:34:24] stichnot (stichnot!~stichnot@199.189.98.185) has joined #mythtv
[00:34:24] stichnot (stichnot!~stichnot@199.189.98.185) has quit (Changing host)
[00:34:24] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[00:54:36] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds)
[00:58:25] DJDan_ (DJDan_!~djdan@115-64-177-188.static.tpgi.com.au) has quit (Remote host closed the connection)
[01:21:37] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Quit: leaving)
[01:22:01] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv
[01:27:05] joki (joki!~joki@p54864E5F.dip.t-dialin.net) has quit (Ping timeout: 255 seconds)
[01:27:20] joki- (joki-!~joki@p5486267B.dip.t-dialin.net) has joined #mythtv
[01:27:28] joki- is now known as joki
[01:27:45] tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Read error: Operation timed out)
[01:30:51] rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (Ping timeout: 245 seconds)
[01:34:46] rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:e9c8:210a:8fc6:758d) has joined #mythtv
[01:34:46] rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:e9c8:210a:8fc6:758d) has quit (Changing host)
[01:34:46] rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv
[01:34:54] tgm4883` (tgm4883`!~tgm4883@2001:4968:202:3:e9c8:210a:8fc6:758d) has joined #mythtv
[01:44:23] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[01:59:26] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[02:05:02] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 252 seconds)
[02:08:42] lentferj (lentferj!~lentferj@p579B7B11.dip.t-dialin.net) has quit (Ping timeout: 252 seconds)
[02:09:41] lentferj (lentferj!~lentferj@p57981C3F.dip.t-dialin.net) has joined #mythtv
[02:15:24] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has joined #mythtv
[02:15:25] stichnot (stichnot!~stichnot@adsl-69-110-235-166.dsl.pltn13.pacbell.net) has quit (Changing host)
[02:15:25] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:19:58] wayne__ (wayne__!~wayne@codeworks.gen.nz) has quit (Ping timeout: 244 seconds)
[02:38:24] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds)
[03:00:52] tonsofpcs: gigem: doing good so far. still on the channel I set it on :)
[03:57:27] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[04:12:04] gigem: tonsofpcs: Good to hear.
[04:59:56] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 252 seconds)
[05:02:25] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds)
[05:03:51] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[06:39:59] rsiebert (rsiebert!~quassel@g224249131.adsl.alicedsl.de) has joined #mythtv
[06:43:18] rsiebert_ (rsiebert_!~quassel@g226061214.adsl.alicedsl.de) has quit (Ping timeout: 264 seconds)
[07:02:12] Sharky-AFK is now known as Sharky-Sleep
[07:42:10] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv
[07:56:20] Goga777 (Goga777!~Goga777@128-71-116-108.broadband.corbina.ru) has joined #mythtv
[09:31:05] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv
[09:32:00] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!)
[09:39:39] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 244 seconds)
[09:47:24] gracent (gracent!~Thunderbi@87.127.165.150) has joined #mythtv
[09:54:10] jaug0rd0r (jaug0rd0r!~jaug0rd0r@gateway/tor-sasl/trisquelwithtor) has quit (Remote host closed the connection)
[09:55:05] jaug0rd0r (jaug0rd0r!~jaug0rd0r@gateway/tor-sasl/trisquelwithtor) has joined #mythtv
[09:56:25] aloril (aloril!~aloril@84.249.126.153) has joined #mythtv
[11:23:40] Nallic (Nallic!~ph@3605ds4-ksa.0.fullrate.dk) has joined #mythtv
[11:24:01] Nallic: im a little confused about xmltv id's
[11:24:46] Nallic: whats the correct "flow" to 1: scan channels 2: select guide grapper 3: associate channels and xmltvids ?
[11:25:35] Nallic: right now mythfilldatabase just runs fast and says : No channels are configured to use grabber.
[11:26:01] Nallic: but i did run the setup inside mythtv-setup and selected all the channels to download guide data from
[11:31:52] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[11:35:09] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv
[12:44:19] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[12:48:42] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[12:49:18] aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 245 seconds)
[12:55:06] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!)
[13:05:24] aloril (aloril!~aloril@84.249.126.153) has joined #mythtv
[13:07:51] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 276 seconds)
[13:10:22] kvarley (kvarley!~kevin@unaffiliated/kvarley) has joined #mythtv
[13:14:36] dekarl: nallic, you have to run the grabber configuration and put it in ~mythtvbackenduser/.mythtv/<name of the videosource>.xmltv
[13:14:55] dekarl: either by running the grabber configuration in mythtv-setup or by running it manually, doesnt matter
[13:15:40] dekarl: notice that mythtv-setup might put it in ~loggedinuser/.mythtv/<name of the videosource>.xmltv which must be linked or copied to the right place :/
[13:16:30] dekarl: btw, the question fits better to #mythtv-users
[13:21:00] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[13:24:23] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[13:27:27] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[13:56:23] dekarl (dekarl!~dekarl@p4FE85321.dip.t-dialin.net) has quit (Ping timeout: 256 seconds)
[13:58:04] dekarl (dekarl!~dekarl@p4FE85B88.dip.t-dialin.net) has joined #mythtv
[14:01:42] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8)
[14:13:48] stuartm: stichnot: noticed some DVD menus are being rendered at 4:3 instead of 16:9 in master
[14:22:57] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 276 seconds)
[14:24:12] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has quit (Quit: Konversation terminated!)
[14:38:52] Goga777 (Goga777!~Goga777@128-71-116-108.broadband.corbina.ru) has quit (Quit: Leaving)
[14:43:15] peper03 (peper03!~peper03@port-92-203-8-57.dynamic.qsc.de) has joined #mythtv
[14:43:59] peper03: stuartm: I noticed that too, but I'm pretty sure it's also in 0.26-fixes, too. Should only be still menus, right?
[14:46:27] peper03: I think it came in as a consequence of the clean-up in DVDRingBuffer. Previously we'd started to play video. Since the title and menus *usually* have the same aspect ratio, it had already been set by the time we reset and showed the still menu.
[14:47:33] peper03: That's my theory, anyway. It was a bug that existed before and was just highlighted by the cleanup. I haven't looked into it more as it was only cosmetic.
[14:48:34] stuartm: iirc the aspect ratio detection code waits until is sees a few frames before changing, to avoid unsightly flickers if there happens to be a couple of frames around ad breaks which are a different ratio
[14:48:59] stuartm: s/is/it/
[14:49:16] ** stuartm 's typing is getting worse **
[14:50:23] stuartm: I'll work on a fix
[14:51:01] peper03: Yeah, we probably need to explicitly check the aspect ratio on a still, which I guess we're not doing at the moment.
[14:52:45] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[14:53:50] peper03: Of course, that'll probably cause the aspect ratio to be wrong for the last few frames of video if it's different (e.g. feature in 4:3, menu in 16:9) as the IsInStill query will be true before we actually display the frame.
[14:54:12] peper03: Or is the aspect ratio applied at render time rather than display time?
[14:56:57] peper03: Still working on how we can store that information synchronously with the video frames. Doesn't look like we can inject our own packets in DVDRingBuffer::safe_read as it seems that ffmpeg filters out data packets, so they never get seen again.
[15:00:22] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Remote host closed the connection)
[15:00:47] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[15:03:18] stuartm: we store the aspect ratio per frame in the VideoFrame struct/class
[15:03:47] stuartm: see AvFormatDecoder::ProcessVideoFrame()
[15:11:22] peper03: Ah, ok. I guess that should work ok then.
[15:16:06] stuartm: I can't actually find the behaviour I thought existed, where we ignore aspect ratio changes that only last a couple of frames so either it never worked that way or it was changed
[15:17:24] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 252 seconds)
[15:22:02] peper03: Actually, ProcessVideoFrame doesn't called until the frame is processed (oddly, considering the name :) ). So if we're using extra buffering (like when using VDPAU), there could be some lag. On ther other hand, when we change to a still, we empty the buffers anyway, so it might still work ok.
[15:25:01] peper03: Do you know if we can use the 'side_data' or 'priv' fields in AVPacket freely? Potentially we could store some status data there that could be used (like 'inStill', 'InMenu' etc.) when we actually process the frame.
[15:25:07] stuartm: as long as ProcessVideoFrame is called before display we're OK :) The change in aspect ratio is made when DisplayFrame() is called in mythplayer
[15:25:37] stuartm: peper03: no idea :/
[15:25:40] stichnot: stuartm: peper03: There's a small chance that my fix to #10829 would affect the behavior here.
[15:25:40] ** MythLogBot http://code.mythtv.org/trac/ticket/10829 **
[15:30:19] stuartm: stichnot: maybe a good chance, would moving that to DisplayPauseFrame() not work?
[15:33:00] kvarley (kvarley!~kevin@unaffiliated/kvarley) has left #mythtv ()
[15:36:34] stuartm: something like http://pastebin.com/PhG2kfmP
[15:38:21] peper03: stichnot: That commit didn't make any difference (positive or negative). I tried it a couple of days ago..
[15:38:29] SteveGoodey (SteveGoodey!~steve@host86-149-167-13.range86-149.btcentralplus.com) has joined #mythtv
[15:39:03] peper03: Didn't make any difference in this scenario is what I meant, of course.
[15:40:40] peper03: stuartm: If I remember correctly, PaletteTest.iso has a 4:3 menu and a 16:9 title (or the other way round) so might be a useful test.
[15:47:45] stuartm: fwiw that patch fixes the issue on the DVD I just tried, but doesn't work properly when seeking while pausing – forward seeks produce the correct aspect ratio, reverse seeks don't
[15:53:23] RDV_Linux_ (RDV_Linux_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[15:55:17] RDV_Linux_ (RDV_Linux_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[15:55:39] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat)
[15:55:56] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[15:56:22] stichnot: stuartm: I don't really know what I'm doing in that code so if you find a better solution then that's great. :)
[16:05:58] aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 245 seconds)
[16:11:57] stuartm: I don't know what I'm doing either :)
[16:15:57] stichnot: stuartm: what if you don't remove the code in ReleaseNextVideoFrame() and keep the new code in DisplayPauseFrame()?
[16:18:14] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[16:28:23] stuartm: might work, I need to test some more, I reverted the patch and found I was unable to reproduce the DVD issue :/
[16:29:38] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat)
[16:29:58] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:31:40] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:32:19] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:33:42] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:34:00] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:34:35] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:34:53] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:34:55] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:35:20] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:41:43] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat)
[16:42:08] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:42:28] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:42:57] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:42:57] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:43:23] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:43:43] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:44:08] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:45:48] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:46:14] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:46:54] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:47:28] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:53:09] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat)
[16:53:33] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:53:34] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[16:53:54] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[16:54:33] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Client Quit)
[16:54:58] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[17:02:31] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat)
[17:07:49] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[17:08:26] peper03: danielk22: (or anyone else) Any objections (or better ideas) to creating a structure/class to wrap around an AVPacket pointer and some generic metadata pointer and put *that* into AVFormatDecoder::storedpackets instead of the current AVPacket pointer? That way we could add metadata to a packet in a derived class (in this case AVFormatDecoderDVD) without too much hassle and keep it synchronized without AVFormatDecoder having to care about
[17:08:28] peper03: *what* is stored there.
[17:11:37] peper03: It doesn't look like we can use the 'side_data' or 'priv' fields safely under all scenarios. I can't find too much information on them, but they do seem to be used by certain parts of ffmpeg (e.g. AAC), and I don't want to crow-bar the extra data into an existing structure and have it bite me.
[17:20:03] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 276 seconds)
[17:24:10] tgm4883` is now known as tgm4883
[17:24:22] tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:e9c8:210a:8fc6:758d) has quit (Changing host)
[17:24:22] tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv
[17:32:01] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[17:44:39] tgm4883: stuartm, wagnerrp said to talk to you about what we can do to diagnose why the description field isn't getting updated using the qt painter on mythbuntu themes 0.26+
[17:44:52] tgm4883: is there extra logging we can turn on for that?
[17:45:50] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 244 seconds)
[17:49:47] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv
[18:02:35] aloril (aloril!~aloril@84.249.126.153) has joined #mythtv
[18:09:01] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 246 seconds)
[18:27:39] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving)
[18:28:02] tonsofpcs: peper03: what sort of metadata?
[18:31:51] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[18:33:23] peper03: tonsofpcs: Things like 'should we start the timer for a still frame?', 'is this the start of a menu?' and so on. It's information we have now but in a different place. The problem is that the point at which we're querying it nearly always lags the point at which it's set because of buffering.
[18:35:40] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has quit (Read error: Connection reset by peer)
[18:35:59] skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has joined #mythtv
[18:37:01] peper03: Let's say you have a video intro to a still menu and we're buffering 10 frames before displaying. We ask 'are we in a still frame?' at the point at which we display the frame, but the class that answers is giving the current state, which is 10 frames ahead of what is being displayed. That means we think we've got a still frame 10 frames before we actually have.
[18:38:25] peper03: Or if you ask 'how far through the title are we?', you get an answer that's 10 frames off, or at the moment in the case of audio DVDs, the answer might be as much as 12 seconds off.
[18:39:16] peper03: The idea is to attach this information to the video frames themselves so that it's synchronized.
[18:39:55] tonsofpcs: oh, you're talking about stuffing it in the buffer with the frames as they flow through the decode/playout/etc sequences, not with the files.
[18:40:47] Sharky-Sleep is now known as Sharky112065
[18:41:47] tonsofpcs: we used to do silly things like that (in the electrons on wires world) by stuffing data into the VBI, just outside the visible frame. We moved to doing it in VANC/HANC, same concept...
[18:43:25] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[18:43:29] tonsofpcs: that said, you have audio flowing next to video and you're using PTS to make it decode/display at the same time, right? Why not construct a data track with PTS, you could then even store it if necessary (a proper decoder that doesn't recognize it should treat it as nulls)?
[18:44:57] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Remote host closed the connection)
[18:45:19] ** tonsofpcs looks up SCTE-35 to see how they send cues **
[18:45:40] tonsofpcs: I mean, basically you want an in-band reference that appears out-of-band, right?
[18:47:20] tonsofpcs: (SCTE-35 is frame-accurate ad-insertion cues)
[18:48:42] peper03: tonsofpcs: Sort of. On the DVD itself there are navigation packets just like audio, video and subtitle packets. These packets don't have everything we'd need but still, they're there. Unfortunately we don't seem to be able to pass them through because ffmpeg strips out any non-media packets.
[18:49:28] tonsofpcs: I suppose you could also catch when the data you want to know occurs in your pre-buffer section and tell your post-buffer section "hey, in 1 buffer length this is happening" or more specifically "hey, at pts X dts Y tc Z frame type B this is happening"
[18:50:35] ** tonsofpcs isn't too familiar with how DVD actually stores those things, only with the creation of them... **
[18:50:52] tonsofpcs: I've got somewhere to be soon, but I might dig into DVD specs this evening (it's laundry night and I'll need something to do)
[18:51:48] tonsofpcs: there has to be a way to pass 'non-media packets' from ffmpeg though as vlc has a way to clone elementary streams. The only issue might be if they're actually flagged as null packets...
[18:53:03] peper03: Yes, there are also certainly data packets in DVB streams so I'm not sure why they're not getting through.
[18:54:43] peper03: One side of the problem is passing the data through, the other is storing it. At the moment, only video frames are buffered. Potentially it could be advantageous to buffer subtitle packets too as in the case of DVDs, that's how the highlighting is done in menus.
[18:57:24] peper03: If we changed that behaviour, then generating our own data packets and adding them would not be much additional work. At the moment the size of the buffer is the same as the number of video frames, which is checked to make sure it doesn't get too large. That would have to be altered too, which means keeping a separate track of the video frames count.
[18:57:52] peper03: All do-able but it's just the trick of not overcomplicating things.
[19:03:06] peper03: tonsofpcs: If you want to dive into the DVD specs, first make sure you've got a stiff drink and then start looking at places like http://www.dvd-replica.com/DVD/ or http://dvdnav.mplayerhq.hu/dvdinfo/
[19:06:04] peper03: There are also any number of inscrutable patents that describe different aspects of DVD structures and/or their handling. Particularly good are the ones with terms that have obviously been lost in translation. Patents are hard enough to understand at the best of times without them using words that obviously don't mean what they thought they did!
[19:21:40] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 248 seconds)
[20:07:57] saintd3v (saintd3v!~saint@unaffiliated/saintdev) has joined #mythtv
[20:13:35] saintd3v: What is the preferred method for a frontend client to discover available backends? SSDP, MDNS-SD/Avahi, something else?
[21:22:40] Sharky112065 is now known as Sharky-AFK
[21:41:03] stuartm: tgm4883: there are two jumppoints, 'Toggle Show Widget Borders' and 'Toggle Show Widget Names', if you bind those e.g. Ctrl+Alt+z, then use them in the watch recordings screen it should show the outline of the description text area, that might reveal something
[21:42:24] stuartm: tgm4883: "-v gui --loglevel debug" may also help
[21:44:26] tgm4883: stuartm, ok, good to know. I'll have the next user I see do that
[21:44:29] tgm4883: thanks
[21:45:32] stuartm: normally in these cases the problem is that the area defined for the text is either missing or the textarea is positioned outside it's parent, e.g. <group><area>0,0,50,50</area><textarea name="background"><area>-100,-100,100,100</area></te xtarea></group> is invalid for two reasons, it's entirely not within the 'group' area and the group would be too small anyway
[21:46:55] tgm4883: stuartm, hmm ok, but we were seeing this on QT themepainter and not openGL (we're using that as a workaround). I'd expect if it was that, for it to be consistantly broken
[21:48:19] stuartm: the opengl painting doesn't use clipping, it's fast enough that it doesn't need to, instead it always redraws the whole screen which means invalid positions/areas won't cause the same problems
[21:48:58] tgm4883: ah
[21:49:14] stuartm: the QT painter will only update the area of the screen that has actually changed, but one of the areas is invalid it just gets ignored instead
[21:49:44] stuartm: but if
[21:49:52] tgm4883: ah that makes sense, I'll check my theme for that
[21:50:12] tgm4883: stuartm, did you see my question in the theming channel?
[21:54:14] peper03 (peper03!~peper03@port-92-203-8-57.dynamic.qsc.de) has quit (Quit: Konversation terminated!)
[21:59:46] jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has joined #mythtv
[21:59:46] jya (jya!~jyavenard@CPE-60-224-1-106.srql1.win.bigpond.net.au) has quit (Changing host)
[21:59:47] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[22:53:11] Nallic (Nallic!~ph@3605ds4-ksa.0.fullrate.dk) has quit (Quit: leaving)
[22:53:40] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8)
[23:40:53] monkeypet69 (monkeypet69!~quassel@c-24-6-135-62.hsd1.ca.comcast.net) has quit (Remote host closed the connection)

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