MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (70):

Anssi, brfransen, cesman, coling, Cougar, ElmerFudd, foobum, GreyFoxx, IReboot, joe___, joki, jpabq, jpabq_, jpharvey, kurre2, kwmonroe, mrand, MythLogBot, neufeld_AFK, Peps, poptix, purserj, rsiebert_, skd5aner, sphery, sraue, wolfgang1, _charly_, aloril, Chutt, ghoti, gregL, J-e-f-f-A, jams, jarle, jarryd, jheizer, jst, jwhite, Kevin`, laga, Merlin83b, MythBuild, Peitolm, petefunk, superm1, tgm4883, tonsofpcs, tris, wagnerrp, XDS2010_, kc, clever, Sharky-AFK, SteveGoodey, danielk22, sl1ce, peper03, Wolfgang2, lentferj, wahrhaft, mad_enz, seld, SmallR2002_, dblain_, drussell_, frankster, DJDan, fetzerch_, zentec
Sunday, January 27th, 2013, 00:13 UTC
[00:13:37] tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Read error: Operation timed out)
[00:16:34] tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:a06b:71f3:ed90:4006) has joined #mythtv
[00:16:35] tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:a06b:71f3:ed90:4006) has quit (Changing host)
[00:16:35] tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv
[00:52:54] knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[00:52:54] knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[00:52:54] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[00:53:15] knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Read error: Connection reset by peer)
[00:54:36] Sharky-AFK is now known as Sharky112065
[01:23:05] Sharky112065 is now known as Sharky-AFK
[01:24:34] tonsofpcs: shouldn't the size of the buffer for video be as defined by the incoming TS? (usually 2x maxGOP)
[01:26:36] tonsofpcs: also, wouldn't overloading the video 'stream' be an issue because the buffer would have to be larger and flushed at a different rate?
[01:28:43] tonsofpcs: oooo, it's because they're flagged as private maybe? (subpictures and navi)
[01:29:00] joki (joki!~joki@p5486267B.dip.t-dialin.net) has quit (Ping timeout: 256 seconds)
[01:29:16] joki- (joki-!~joki@p548656A3.dip.t-dialin.net) has joined #mythtv
[01:29:23] joki- is now known as joki
[02:08:58] lentferj (lentferj!~lentferj@p57981C3F.dip.t-dialin.net) has quit (Ping timeout: 252 seconds)
[02:10:27] lentferj (lentferj!~lentferj@p579B7218.dip.t-dialin.net) has joined #mythtv
[03:25:21] danielk22: https://github.com/mkrufky/libdvbtee <-- may be useful for MythTV devs...
[03:56:05] gigem: danielk22: I just skimmed the README, but it sounds very useful.
[04:24:01] skd5aner: I always find it amazing that all these various FOSS projects, that have so much overlap in objectives/interests and mutually beneficial to one another, rarely talk and collaborate... libdvd*/bluray, ffmpeg, libdvbtee, linuxtv, etc...
[04:24:58] skd5aner: You would think the folks who write all the stuff related to tuner support would naturally want to be involved at some level with MythTV, or at least some level of two-way collab...
[04:25:46] skd5aner: It's surprsing how walled off all these tangental projects really are
[04:29:18] aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 245 seconds)
[04:43:01] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[05:00:43] fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has joined #mythtv
[05:01:50] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds)
[05:11:26] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[05:28:42] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 256 seconds)
[06:39:59] rsiebert_ (rsiebert_!~quassel@g224249136.adsl.alicedsl.de) has joined #mythtv
[06:42:56] rsiebert (rsiebert!~quassel@g224249131.adsl.alicedsl.de) has quit (Ping timeout: 256 seconds)
[06:57:43] drussell_: tgm4883: When I updated to 0.26 on my FreeBSD main BE box I had difficulty with the UI not updating the watch recordings screen until I'd ALT-TAB away then it would update instantly... It fixed itself as soon as I actually started running a metadata update in the background, then started working once it started pulling in the series graphics, etc... Is this the problem you're describing? No previews or show description? Or someth
[06:57:43] drussell_: ing else?
[07:08:35] Goga777 (Goga777!~Goga777@128-71-116-108.broadband.corbina.ru) has joined #mythtv
[08:16:36] dekarl: skd5aner: i agree, yet another one-man-show :(
[08:28:33] Goga777 (Goga777!~Goga777@128-71-116-108.broadband.corbina.ru) has quit (Remote host closed the connection)
[10:19:54] Cougar (Cougar!~cougar@2a03:5880:104:10:6168:8820:59a2:900f) has quit (Ping timeout: 264 seconds)
[10:31:18] Cougar (Cougar!~cougar@2a03:5880:104:10:f800:4ebc:a5e:816e) has joined #mythtv
[11:09:53] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[11:46:17] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[11:56:39] Goga777 (Goga777!~Goga777@128-71-161-153.broadband.corbina.ru) has joined #mythtv
[12:08:37] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[12:11:14] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[12:23:25] peper03 (peper03!~peper03@port-92-203-87-125.dynamic.qsc.de) has joined #mythtv
[12:27:23] peper03: tonsofpcs: If you're referring to what I was talking about yesterday, the video buffer is the same one used regardless of whether we're reading from a DVD, from an MKV file or (as I understand it) playing streaming video, so there's no need for the input stream to be in MPEG format. Having said that, I've never looked at other video formats so I don't know whether they all effectively have GOPs (or similar) that could be used to
[12:27:25] peper03: determine the required buffer size. I suspect not.
[12:28:46] peper03: The idea I had was not to add data to existing packets but rather to define a structure that contains a 'normal' packet plus some other data but maintain them as two separate entities.
[12:31:40] peper03: That said, it *may* make more sense to store the metadata updates as separate packets (like the NAV packet on a DVD) as I don't think there's much data that changes with each video/audio frame that isn't already stored in those packets. The stuff I'm thinking of is more like what's in a NAV packet and comes once per GOP.
[12:32:09] peper03: I need to look at what information we need and try to work out which method makes more sense.
[13:21:33] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[13:22:23] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (Read error: Connection reset by peer)
[13:29:48] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[13:32:09] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv
[13:47:19] IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat)
[13:47:43] IReboot (IReboot!~doug@CPE10bf48e67915-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[13:48:13] stoffel (stoffel!~quassel@pD9E42709.dip.t-dialin.net) has joined #mythtv
[13:56:03] stoffel (stoffel!~quassel@pD9E42709.dip.t-dialin.net) has quit (Ping timeout: 276 seconds)
[13:56:42] dekarl (dekarl!~dekarl@p4FE85B88.dip.t-dialin.net) has quit (Ping timeout: 256 seconds)
[14:00:02] dekarl (dekarl!~dekarl@p4FCEFA57.dip.t-dialin.net) has joined #mythtv
[15:18:27] dekarl: hmm, whats the differentiation / relationship between libdvbpsi and libdvbtee? (the former is a VLC hosted team effort and the latter appears to be a one man show as far a I can see)
[15:23:46] danielk22: dekarl: different implementation. When debugging it's good to have a few implementations to choose from. Everyone makes different mistakes and everyone interprets the spec differently.
[15:25:05] danielk22: libdvdtee is written by one of the LinuxTV guys.
[16:00:02] zentec (zentec!~zentec@95.211.191.41) has joined #mythtv
[16:04:34] saintd3v (saintd3v!~saint@unaffiliated/saintdev) has left #mythtv ()
[16:07:32] gracent (gracent!~Thunderbi@87.127.165.150) has quit (Quit: gracent)
[16:35:17] stichnot: danielk22: The most striking thing I see so far with the PVR-150 live TV problem is that ffmpeg uses the MPEG2-PS code rather than MPEG2-TS which is how my HDPVR and HDHR recordings are encoded, combined with different initial seeking behavior with live TV versus completed or in-progress recordings.
[16:36:34] stichnot: Can you think of any way the backend could serve recordings differently depending on PS/TS or live/recorded?
[16:37:55] stichnot: Hopefully not, which lets me focus on the frontend.
[17:07:40] seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 252 seconds)
[17:08:58] seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has joined #mythtv
[17:18:29] jaug0rd0r (jaug0rd0r!~jaug0rd0r@gateway/tor-sasl/trisquelwithtor) has quit (Remote host closed the connection)
[17:52:58] stoffel (stoffel!~quassel@pD9E43511.dip.t-dialin.net) has joined #mythtv
[17:59:21] seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 252 seconds)
[18:00:41] seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has joined #mythtv
[18:05:41] DJDan (DJDan!~djdan@115-64-177-188.static.tpgi.com.au) has joined #mythtv
[18:19:01] stoffel (stoffel!~quassel@pD9E43511.dip.t-dialin.net) has quit (Remote host closed the connection)
[19:12:19] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[19:36:18] kenni: stuartm/jya: Do you have any plans to revert the 0.26-fixes backport of the temporary HD-PVR fix in order to fix #11356 for 0.26 users? I can see that there're quite a few affected 0.26-fixes users on the -users mailing list and I can confirm that the playback stuttering issue is not restricted to the BBC HD channels, I'm seeing stuttering issues (and incorrect calculation of current position) on multiple Danish H.264 channels with latest 0.26-fixes.
[19:36:18] ** MythLogBot http://code.mythtv.org/trac/ticket/11356 **
[19:36:32] kenni: IMHO, it doesn't seem like a fair tradeoff to fix playback for HD-PVR users and break it for non-HD-PVR users ;) At least not on the -fixes branch..
[19:41:44] stichnot: kenni: I agree with you. The BBC HD problem is constant with no workaround. The HD-PVR problem happens only at glitches and has a workaround (restart playback and skip past the glitch).
[19:43:15] jpabq: As an HD-PVR user, I am fine with reverting that band-aid. For the reasons that stichnot just mentioned.
[19:46:07] stuartm: the fix obviously wasn't correct, it just happened to work for the HD-PVR recordings, I'd be in favour of reverting but reluctantly because I know some HDPVR users (skd5aner) were finding 0.26 to be nearly unusable
[19:46:59] stuartm: I'd prefer that a proper fix was found for the HD-PVR issue first but I don't know that anyone has the time to work on that
[19:47:09] jpabq: skd5aner: You compile from source, don't you? If so, you could patch your local tree with d34833f2
[19:48:57] stuartm: jpabq: well that would work for skd5aner but not every user, for every user that actually complained about it I'm sure there were more who have suffered in silence or given up and switched to 0.25 or another application
[19:50:10] jpabq: danielk22 agreed to take a look, however he is still swamped with his new job, so it will likely be a while. Personally, I am more troubled by #11334 which I am hoping he will have a revelation about.
[19:50:10] ** MythLogBot http://code.mythtv.org/trac/ticket/11334 **
[19:54:27] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 256 seconds)
[20:00:49] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv
[20:07:44] kenni: Seems like the Swedish users are affected as well, Roger MÃ¥rtensson has just posted a message to -users one hour ago about "choppy HDTV 720p playback on SVT".
[20:11:55] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (Read error: Connection reset by peer)
[20:12:56] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8)
[20:18:50] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv
[20:20:22] kenni: stuartm: If the backport gets reverted, then the HD-PVR users will still be able to switch to the master branch in order to receive the "working-but-not-optimal" workaround – or manually compile 0.26-fixes with the patch. AFAIU the HD-PVR issue has been around since 0.26 was released, so 0.26 has never been usable for HD-PVR users – H.264 playback for non-HD-PVR users has on the other hand always worked correctly in 0.26-fixes.
[20:24:19] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8)
[20:30:56] dekarl: danielk22: thanks for the explanation. that wasn't really clear from the project descriptions.
[20:44:46] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv
[20:57:59] Goga777 (Goga777!~Goga777@128-71-161-153.broadband.corbina.ru) has quit (Remote host closed the connection)
[21:22:58] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[21:25:54] danielk22: stichnot: Those should be served the same way. The only difference on the recording side is a different code path for key frame detection and tuning (we don't look for PAT/PMT in PS streams).
[21:26:40] danielk22: jpabq: for #11334 have you tried reverting [e75fb21c45] to confirm if that is the issue?
[21:26:40] ** MythLogBot http://code.mythtv.org/trac/ticket/11334 **
[21:27:23] jpabq: danielk22: I just did that this morning. It will take at least a day for it to prove anything.
[21:27:50] jpabq: I should have done that a week ago. Oh well.
[21:42:03] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[21:43:28] wagnerrp: stuartm: any thoughts on what would be the best way to embed a theme within a larger, blank window?
[21:44:02] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat)
[21:44:14] wagnerrp: i want to get this external screen setup wizard finished, and i want to be able to show the finished size of it
[21:50:07] stuartm: wagnerrp: the best way, or the easiest way? The easiest way is a bit of a cheat but if you only want to show what the end result will look like then I'd use an image (the theme preview image probably) and simply scale that within an otherwise empty window
[21:50:41] wagnerrp: id rather not use the theme preview image, since that would make the directions hard to read
[21:50:41] stuartm: other advantages include it being very fast
[21:52:19] stuartm: I'm not following (probably not your fault, I can barely keep my eyes open atm)
[21:52:43] wagnerrp: the screen setup wizard has a bunch of text on screen, explaining how to use it
[21:56:59] stuartm: wagnerrp: well you could place that as a textarea in the foreground in front of the image? The text wouldn't scale but that maybe a good thing
[21:57:46] stuartm: I could fairly quickly knock up a demonstration of what I'm suggesting
[21:59:15] wagnerrp: nah, i should be able to figure it out
[21:59:16] stuartm: the alternative means some not so minor changes to the painters, the effort and complications to the code would probably not be worth it for this one wizard that most users will only see once
[21:59:20] jya: kenni: i had no plan one way or another… it's making the choice about people with HDPVR who can't use myth or some others.
[21:59:27] wagnerrp: headed out to dinner, i'll see if i can get something working when i get back
[21:59:37] wagnerrp: thanks
[22:01:00] jya: stuartm: the "fix" was reverting a change in reference frame calculation. Mind you, this is now back to the earlier version of ffmpeg as using in 0.25, it's also the same type of calculation found in LibAV project
[22:01:08] stuartm: fwiw, some theme preview images may be too low res atm, ideally they would be at a minimum 1920x1080 (or 1440x1080) – I'll probably make that a requirement for 0.27 anyway so that we can show full size previews in the theme downloader
[22:04:54] stuartm: jya: something is obviously not the same as 0.25 as BBC HD et al worked just fine in that release, with the fix in place it appears that certain frames, possibly B frames are not being decoded properly – for BBC HD every eighth frame decoded appears to no video data
[22:05:39] jya: stuartm: I'm not sayign "everything" is the same :)… Just that part of the code is
[22:05:42] stuartm: this then causes the flicker reported because we ignore those frames and render the next instead
[22:05:58] jya: though with the problem before only afftected the rendering code
[22:09:03] skrock (skrock!~skrock@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.8)
[22:09:07] stuartm: jya: so the problem was more with how we dealt with the frames received than how they were decoded?
[22:09:55] jya: i'm not sure what the problem is to be honest. All I've noticed is that when you aren't using VDPAU or OpenGL rendering: the problem doesn't occur
[22:10:20] jya: this leads me to believe that the issue isn't the decoding part as such.
[22:10:28] jya: for example, I don't see it on my mac either
[22:22:15] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds)
[22:29:14] stichnot: jya, stuartm, kenni: how about this uber-patch for 11159 and 11356. http://pastebin.com/CSTJQn97
[22:29:56] stichnot: it starts out in HD-PVR mode, and switches to BBC HD mode when it sees the first IDR keyframe
[22:30:04] stichnot: I meant to call it "uber-bandaid"
[22:30:17] jya: stichnot: I'll go against any patch to ffmpeg…. I don't see why we would need any when the ffmpeg code is fine for everyone else… It's obvious then to me that this would be just a work around our own bug
[22:31:11] jya: if the people with hdpvr issue are not that numerous, they can apply the 11159 patch, and others don't… simple as that until we figured it out… or they revert to 0.25
[22:33:31] stichnot: jya: I mean for 0.26, where stability and good playback across the board is needed
[22:33:46] jya: i do mean 0.26 too
[22:34:01] stichnot: Several tickets have been closed because "0.25 is unsupported", so that's not a great option either
[22:37:22] Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[22:41:02] neufeld_AFK is now known as neufeld
[22:45:55] neufeld is now known as neufeld_AFK
[22:46:00] tonsofpcs: stichnot: I'm not sure what you mean w.r.t PS and TS code... a PS is part of a TS...
[22:46:06] tonsofpcs: (well, can be)
[22:46:32] Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has joined #mythtv
[22:52:50] jheizer__ (jheizer__!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 260 seconds)
[23:14:30] gigem (gigem!~david@mythtv/developer/gigem) has quit (Ping timeout: 264 seconds)
[23:14:53] gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has joined #mythtv
[23:14:53] gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has quit (Changing host)
[23:14:53] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[23:35:27] dekarl (dekarl!~dekarl@p4FCEFA57.dip.t-dialin.net) has quit (Ping timeout: 257 seconds)

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