MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (87):

aloril, Anssi, anykey_, Beirdo, brfransen, bsilvereagle, CaCtus491, Captain_Murdoch, cesman, Chutt, clever, coling, coredumb, Cougar, danielk22, dblain, dekarl, dmfrey, eharris, ElmerFudd, f33dMB, foobum, foxbuntu, ghoti, gigem, gregL, GreyFoxx, IReboot, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe___, joki, jpabq, jpharvey, jst, jwhite, kenni, knightr, kurre2, kwmonroe, laga, lvmer, mag0o, Merlin83b, monkeypet, moodboom, mrand, MythBuild, MythLogBot, neon__, neufeld_AFK, Peitolm, Peps, petefunk, poptix, purserj, rsiebert_, Seeker`, seld, shadowone, Sharky112065, skd5aner, sl1ce_2g, Slasher`, SmallR2002, sphery, sraue, stuarta, stuartm, sutula, taylorr, tgm4883, ThisOneGuy, toeb, tonsofpcs, tris, Vernon_at_work, wagnerrp, wahrhaft, wolfgang1, xavierh, XDS2010_, xris, _charly_
Sunday, December 2nd, 2012, 00:06 UTC
[00:06:10] sl1ce (sl1ce!~johnathan@c-66-31-34-71.hsd1.ma.comcast.net) has quit (Ping timeout: 246 seconds)
[00:19:37] natanojl: danielk22: What I meant was calling disconnect in the slot connected to the destroyed signal, I'm sorry if I was unclear
[00:23:31] natanojl: I noticed I had several gigs of core dumps similar to #10924 and thought that that disconnect in nzmqt was the issue
[00:23:31] ** MythLogBot http://code.mythtv.org/trac/ticket/10924 **
[00:24:47] natanojl: http://code.mythtv.org/cgit/mythtv/tree/mytht . . . mqt.hpp#n703
[00:25:18] cecil is now known as cesman
[00:25:22] zombor (zombor!~zombor__@65.29.231.135) has joined #mythtv
[00:25:23] zombor (zombor!~zombor__@65.29.231.135) has quit (Changing host)
[00:25:23] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[00:25:29] cesman (cesman!~cesman@pool-108-0-54-134.lsanca.fios.verizon.net) has quit (Changing host)
[00:25:29] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[00:33:59] sl1ce (sl1ce!~johnathan@66.31.34.71) has joined #mythtv
[01:00:05] stichnot (stichnot!~stichnot@adsl-69-110-235-11.dsl.pltn13.pacbell.net) has joined #mythtv
[01:00:05] stichnot (stichnot!~stichnot@adsl-69-110-235-11.dsl.pltn13.pacbell.net) has quit (Changing host)
[01:00:05] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[01:09:08] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds)
[01:10:35] f33dMB (f33dMB!~f33dMB@97.107.139.62) has joined #mythtv
[01:27:15] stichnot (stichnot!~stichnot@adsl-69-110-235-11.dsl.pltn13.pacbell.net) has joined #mythtv
[01:27:15] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[01:27:15] stichnot (stichnot!~stichnot@adsl-69-110-235-11.dsl.pltn13.pacbell.net) has quit (Changing host)
[01:46:39] Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has joined #mythtv
[02:25:01] stichnot (stichnot!~stichnot@adsl-69-110-235-11.dsl.pltn13.pacbell.net) has joined #mythtv
[02:25:01] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:25:01] stichnot (stichnot!~stichnot@adsl-69-110-235-11.dsl.pltn13.pacbell.net) has quit (Changing host)
[02:30:07] stichnot: stuartm: I think MythUIEditBar::ClearImages() needs a SetRedraw() at the end. Otherwise residue of old cut/keep marks may be left on the screen when cut or keep regions are removed. (I'm seeing this on my frontend.) Would you agree?
[02:41:38] rsiebert_ (rsiebert_!~quassel@g224249198.adsl.alicedsl.de) has joined #mythtv
[02:44:22] rsiebert (rsiebert!~quassel@g225053187.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds)
[02:45:15] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 276 seconds)
[03:34:39] bsilvereagle (bsilvereagle!~bsilverea@osuosc/bsilvereagle) has joined #mythtv
[04:33:20] dmfrey (dmfrey!~dmfrey@64-121-93-243.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has quit (Quit: Ex-Chat)
[04:34:53] dmfrey (dmfrey!~dmfrey@64-121-93-243.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has joined #mythtv
[04:38:39] Goga777 (Goga777!~Goga777@95-30-247-207.broadband.corbina.ru) has joined #mythtv
[04:58:31] danielk22: natanojl: Hmm, that is interesting. On first blush that does not look correct.
[05:27:22] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[06:12:33] lvmer (lvmer!~Jimmy@c-76-124-164-143.hsd1.pa.comcast.net) has joined #mythtv
[06:52:50] stichnot: stuartm: on a similar topic, I'm having trouble figuring out the problem with this <editbar> portion of osd.xml – http://pastebin.com/vqYJHJDk – which comes from an older version of blue-abstract-wide (a 1280x720 theme). When I enter the editor with no marks or cut regions, the "keep" image looks fine, but as soon as something is added and the clipping code gets invoked, the cut/keep area...
[06:52:52] stichnot: ...seem to be shifted up and then clipped. Commenting out the cut/keep image definitions and replacing them with the commented out shape versions works fine. I see the same behavior with Qt and OpenGL painters.
[07:03:32] Goga777 (Goga777!~Goga777@95-30-247-207.broadband.corbina.ru) has quit (Remote host closed the connection)
[07:08:14] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[07:17:42] shadowone (shadowone!~shadowone@59.167.189.79) has joined #mythtv
[07:45:08] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[07:50:11] stoffel (stoffel!~quassel@pD9E41193.dip.t-dialin.net) has joined #mythtv
[08:11:56] aloril (aloril!~aloril@84.249.126.153) has joined #mythtv
[09:02:55] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[09:47:02] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[11:17:29] stoffel (stoffel!~quassel@pD9E41193.dip.t-dialin.net) has quit (Remote host closed the connection)
[12:02:47] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit ()
[12:08:16] SteveGoodey (SteveGoodey!~steve@86.148.172.139) has joined #mythtv
[12:31:14] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[13:07:25] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[13:11:23] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv
[13:30:07] sl1ce (sl1ce!~johnathan@66.31.34.71) has quit (Quit: Konversation terminated!)
[13:39:53] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[14:10:53] stichnot (stichnot!~stichnot@adsl-69-110-235-11.dsl.pltn13.pacbell.net) has joined #mythtv
[14:10:53] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[14:10:53] stichnot (stichnot!~stichnot@adsl-69-110-235-11.dsl.pltn13.pacbell.net) has quit (Changing host)
[14:21:03] stuartm: stichnot: I'll take a look later today
[14:22:03] stuartm: danielk22: when do we want to cut 0.26.1? I was hoping that all the livetv bugs would be fixed first, but we're seemingly not making progress on those
[14:22:28] stuartm: there have been some important fixes made since the release though
[14:28:58] sl1ce (sl1ce!~johnathan@66.31.34.71) has joined #mythtv
[14:43:17] stichnot (stichnot!~stichnot@adsl-69-110-144-173.dsl.pltn13.pacbell.net) has joined #mythtv
[14:43:17] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[14:43:17] stichnot (stichnot!~stichnot@adsl-69-110-144-173.dsl.pltn13.pacbell.net) has quit (Changing host)
[14:47:00] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[15:18:31] danielk22: stuartm: I hadn't really thought about it. The patch you applied didn't help with the Analog LiveTV issues? Are there also DTV LiveTV issues?
[15:19:36] danielk22: (Other than the signal monitor not showing up for the first livetv channel causing trouble if it fails to tune. That bug has been with us for several releases now.)
[15:21:09] stichnot: How is Analog TV defined? Is HD-PVR analog or digital?
[15:21:11] stuartm: it helped with recordings and livetv with ivtv cards, but there are still people having trouble with other devices like the HD-PVR
[15:22:07] stuartm: and then stuff like http://code.mythtv.org/trac/ticket/11262
[15:22:12] danielk22: stichnot: yep anything that uses the V4L2 drivers.
[15:23:12] stuartm: the patch I backported fixed a bug which apparently existed from 0.25, the other livetv issues reported started with 0.26
[15:23:32] stichnot: I always cross my fingers when I try live TV, but the hdpvr has been as reliable for me as the hdhr.
[15:23:39] danielk22: stichnot: The API calls have remained the same but the meanings of the calls and their return values keep changing with each kernel release causing instability.
[15:24:01] stuartm: in addition there are some playback related problems that seem connected to the ffmpeg resync
[15:24:08] danielk22: right
[15:24:27] stuartm: skd5aner is one user who has been hitting a lot of these issues
[15:28:49] stuartm: http://svn.mythtv.org/trac/ticket/11268  – sigh
[15:29:35] danielk22: heh, we did lose the ticket how to link on the last trac upgrade. ;]
[15:30:01] zombor (zombor!~zombor__@65.29.231.135) has joined #mythtv
[15:30:01] zombor (zombor!~zombor__@65.29.231.135) has quit (Changing host)
[15:30:01] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[15:34:13] IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Read error: No route to host)
[15:36:34] stuartm: the 'log' is from mythweb btw, it ticks all the boxes for this weeks WTF? award
[15:39:14] stichnot: danielk22: How are the kernel APIs used differently between live and recorded TV?
[15:39:21] IReboot (IReboot!~doug@99.234.144.14) has joined #mythtv
[15:52:30] danielk22: stichnot: There is a channel being recorded just before we record a different channel.
[15:53:52] danielk22: This can be a problem for DTV too. When we stop recording the previous channel the driver starts shutting down the hardware for power savings and then we immediately start using it again which some drivers can't cope with.
[15:54:56] stuartm: kenni: beat me to it
[15:55:46] danielk22: Sometimes the driver waits a few milliseconds before shutting down the hardware but that can cause even worse problems. Say we stop using the DTV side of the card and start watching TV on the analog side, then a few seconds later the signal goes away because the DTV shutdown timer expired and shut down the tuner.
[15:57:22] kenni: :)
[15:57:25] stichnot: And on the topic of live TV, it seems that there's a fairly significant infrastructure for finding free tuners and such which is only used from live TV. This code is usually the culprit in bugs involving inability to change channels, and probably others. Could that be more tightly integrated with the scheduler such that starting live TV or changing channels goes through the existing...
[15:57:25] stichnot: ...scheduler code path? Or are incremental reschedules too slow?
[15:59:12] stichnot: danielk22: is that scenario dealt with properly if there are back-to-back scheduled recordings on the digital and analog sides of the card?
[16:00:06] stichnot: stuartm: a preemptive ticket lock, nice :)
[16:00:33] sl1ce (sl1ce!~johnathan@66.31.34.71) has quit (Ping timeout: 245 seconds)
[16:04:58] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds)
[16:05:51] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:08:14] stuartm: if Paul keeps submitting patches I'm just going to give him his commit perms back
[16:11:17] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[16:27:49] skd5aner: danielk22, stuartm: Yup... primary Live TV tickets to follow would be #11229 and #11211. #11262 is likely a dupe of those...
[16:27:49] ** MythLogBot http://code.mythtv.org/trac/ticket/11229 **
[16:27:49] ** MythLogBot http://code.mythtv.org/trac/ticket/11211 **
[16:27:49] ** MythLogBot http://code.mythtv.org/trac/ticket/11262 **
[16:29:37] skd5aner: also, I was going to report the fact that the "Allow live tv to move recordings" setting didn't work anymore after 0.26, but it was alreayd reported in #11207...
[16:29:37] ** MythLogBot http://code.mythtv.org/trac/ticket/11207 **
[16:29:59] skd5aner: recordings will want to overtake a tuner leveraged by Live TV even if there are tons of free tuners available it could use
[16:31:32] skd5aner: Also, while on the subject, might I propose that this is a classic example of a setting that should probably just go away and be a default... it's reasonable to assume that if a user is leveraging Live TV, and they have tuners available that a recoridng to use, they shouldn't be interupted...
[16:31:43] skd5aner: I think that's pretty much how any commercial DVR works
[16:31:49] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds)
[16:32:56] skd5aner: Plus, sphery would get a win with a setting removal... :)
[16:33:48] skd5aner: danielk22: anyway, back to the live tv issues – I'm willing spend ANY ammount of time I can to help troubleshoot, because it's really causing some strife in my household right now...
[16:34:06] stichnot (stichnot!~stichnot@adsl-68-125-52-183.dsl.pltn13.pacbell.net) has joined #mythtv
[16:34:06] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:34:06] stichnot (stichnot!~stichnot@adsl-68-125-52-183.dsl.pltn13.pacbell.net) has quit (Changing host)
[16:37:05] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit ()
[16:37:10] skd5aner: I do have "instability" when trying to leverage the HD-PVR for live tv and I've talked a bit with jpabq and stichnot about that...
[16:37:13] skd5aner: and taylorr
[16:37:24] ** skd5aner the "name dropper" **
[16:38:31] skd5aner: but, that instability has been getting slightly better and better over the last 3 releases... the issue is, that 0.26 I switched to using the internal firewire channel changer rather than external scripts... therefore, I can't leverage a sleep in my script ot give it time to stabilize
[16:39:34] skd5aner: btw, this is what I'm referring to... http://code.mythtv.org/trac/changeset/d49f3f2 . . . 70407/mythtv
[16:40:07] skd5aner: it works great, but of course, is basically a "hidden" feature since their's no way to really do this via the UI...
[16:40:28] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (Quit: leaving)
[16:40:40] skd5aner: but, I digress, lots of issues, and the HD-PVR stability used to be my only live tv issue – now it's like 4'th on the list, at the bottom
[16:46:41] stichnot: skd5aner: Long ago I managed to converge on a fairly reliable combination of hdpvr firmware, stb video output (forced 720p), stb audio output (analog), etc. which may help explain why I don't see the same sorts of problems
[16:48:01] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv
[16:52:05] tgm4883: Is there any reason this fix can't be backported to 0.25 since 0.25 is what shipped with Ubuntu 12.10? Is there a technical limitation (eg. does it break php < 5.4)?
[16:52:11] tgm4883: http://code.mythtv.org/trac/ticket/10504
[17:09:43] skd5aner: stichnot: yea, very possible... I've had 3 different STB makes/models over the last year... all exhibited the same issue, so that leads me to believe it's limited to the HD-PVR, linux, and mythtv...
[17:10:09] skd5aner: stichnot: I still allow the STB to determine the ouput format, and I use spdif digital audio
[17:11:45] stuartm: I think it's a problem with the driver/API, if sleeps etc are needed to get MythTV to work then that seems to point to a design flaw in the API which should be telling MythTV when it's ready to provide the data not leaving Myth to play guessing games
[17:14:22] stichnot: skd5aner: with my DISH STB, I run into audio drift unless I use analog audio and a specific firmware. That and the fact that the resolution is never changing probably keeps things relatively solid
[17:14:37] stichnot: and since it's the production system, it's a bad idea to mess with it...
[17:26:11] skd5aner: stichnot: looks like my firmware is a few revisions old – firmware version 0x12 dated May 7 2009
[17:26:31] skd5aner: wiki states that 0x15 is pretty stable
[17:28:12] stichnot: from dmesg, mine appears to be firmware version 0xf
[17:28:26] stichnot: but since it ain't broke...
[17:29:40] stuartm: skd5aner: it might be a useful data-point if you are unable to upgrade the firmware and see if the problems are still reproducible
[17:30:21] skd5aner: stichnot: heh – that's older than mine – http://www.mythtv.org/wiki/Hauppauge_HD-PVR#Firmware_Versions
[17:30:40] skd5aner: stichnot: wiki also says that some of the older versions can cause serious hardware issues
[17:30:47] stuartm: 0xf is older than 0x12??
[17:30:59] skd5aner: stuartm: guess so
[17:31:30] stuartm: oh right, yeah, brain was on holiday – interpreted that as 0xf0
[17:33:08] skd5aner: stuartm: are you saying I should or should not upgrade?
[17:33:10] skd5aner: (the firmware)
[17:33:23] stuartm: might be interesting to get all HD-PVR using devs to indicate what firmware versions they are using, might shed some light on why no devs have had problems
[17:34:42] stuartm: skd5aner: upgrade, iff we discover that some firmware are more stable then we could see about testing for the firmware version in MythTV and complaining loudly – if we are making changes in the code to make one version more stable but causing it to destablise with other revisions then the sanest solution is to get all users on the same firmware
[17:35:45] skd5aner: yea, gotcha
[17:37:51] stuartm: that page indicates that the resolution switching instability was fixed in 1.7.1
[17:38:24] skd5aner: yea, but I'm still not sure if the color saturation was ever fixed...
[17:38:46] skd5aner: I believe that was a kernel issue, but not sure when the driver was fixed in the kernel
[17:38:52] skd5aner: I'm sure devin would know
[17:39:25] stuartm: skd5aner: the way I read it, they changed the output and simply submitted a patch upstream to the kernel to compensate?
[17:40:03] skd5aner: when did it go in to the kenel
[17:40:06] skd5aner: kernel
[17:40:08] stuartm: I wonder if that patch also kept backwards compatibility with older firmware
[17:40:25] stuartm: 3.3 according to the wiki page
[17:40:59] stuartm: 3.3.<what> it doesn't say
[17:41:19] skd5aner: //www.mail-archive.com/linux-media@vger.kernel.org/msg38318.html" rel="nofollow">http://www.mail-archive.com/linux-media@vger. . . . sg38318.html
[17:41:22] stuartm: skd5aner: you can downgrade the firmware ?
[17:41:56] skd5aner: stuartm: I believe so
[17:42:47] skd5aner: It also says this on the wiki: "The over-saturation and color issues that surfaced in version 1.6.29207 is still present (even with kernel 3.4.3)."
[17:42:54] stuartm: taylorr: ^^
[17:42:55] skd5aner: I'm running 3.5, so maybe it's worth a shot
[17:44:06] stuartm: skd5aner: I'll trust whatever taylorr has to say since it was his patch, I don't know how bad these saturation issues were – clearly evident to everyone or only a videophile
[17:44:13] skd5aner: yea
[17:44:25] skd5aner: I think they were pretty prevalent...
[17:44:46] skd5aner: lots of posts about it, so I don't think it was clearly visible to the average veiwer
[17:45:02] skd5aner: that said, I'm willing to upgrade to the latest version and see
[17:45:13] skd5aner: worst case, I create a script to adjust
[17:48:28] stuartm: hmm, that patch was submitted over a year ago but overlooked until at least Feb, but still no indication as to whether it was committed
[17:49:03] stuartm: all familiar faces involved in the discussion though, taylorr, Jarod, Janne and Devin
[17:52:06] skd5aner: yea, love it :)
[17:52:45] skd5aner: they moved the location in the tree for the hdpvr drivers at this commit, how do I look at the history of a file prior to the move – https://github.com/torvalds/linux/tree/0c0d06 . . . 206574ab86bd
[17:54:48] skd5aner: nm, found a way around it
[17:55:10] skd5aner: Here's the commit to the kernel – https://github.com/torvalds/linux/commit/8423 . . . 7ca4c2920783
[17:57:22] skd5aner: knowing a commit number, how can you reverse lookup and see what version of the kernel released with that commit?
[17:59:18] stuartm: no idea, but based on the commit date 3.3 or 3.4 – 3.3. was in March, the commit was in Feb
[18:05:38] skd5aner: Well, none of the 3.3 or 3.3's have it
[18:05:47] skd5aner: from manually searching each of the changelogs
[18:05:56] skd5aner: er, 3.3s or 3.4
[18:06:20] skd5aner: unless they don't put everyting in the changelog?
[18:06:47] skd5aner: none of the 3.5s
[18:08:50] skd5aner: none of the 3.6s... to the source we go!
[18:17:34] SteveGoodey (SteveGoodey!~steve@86.148.172.139) has quit (Quit: Konversation terminated!)
[18:18:06] seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (Remote host closed the connection)
[18:18:40] seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has joined #mythtv
[18:20:34] skd5aner: weird... it's in the source for 3.5, which is what I'm running, but not in the changelog after that commit...
[18:21:54] skd5aner: but, it's still in the old location. On 8/13 (sometime around 3.4.9), they moved the location from /drivers/media/video/hdpvr to /drivers/media/usb/hdvpr
[18:22:20] skd5aner: but, it's still in the original location in 3.5
[18:22:46] skd5aner: oh well, let's see if I can upgrade the hd-pvr's firmware in windows
[18:23:14] zombor (zombor!~zombor__@65.29.231.135) has joined #mythtv
[18:23:15] zombor (zombor!~zombor__@65.29.231.135) has quit (Changing host)
[18:23:15] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[18:24:30] seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (Remote host closed the connection)
[18:24:59] seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has joined #mythtv
[18:25:25] skd5aner: anndddddd – the tuner's in use, ha
[18:29:13] skd5aner: ah... not in it in 3.2.34, in at 3.3
[18:32:53] stuartm: they don't offer a linux flashing tool?
[18:35:05] skd5aner: nope :/
[18:35:30] skd5aner: Hauppauge doesn't offer anything – it was all reverse enginered
[18:36:50] stuartm: skd5aner: not everything, one or two of the driver devs work for Hauppauge e.g. stoth
[18:37:07] stuartm: and I believe Devin has done work for them on linux drivers under contract
[18:40:18] skd5aner: Yea, but my understanding was that this wasn't necessarily an officially funded effort
[18:40:25] skd5aner: from a conversation with him a few months back
[18:40:34] skd5aner: (him being Devin)
[18:41:24] skd5aner: or, should I say "not officially sanctioned"
[18:41:41] stuartm: I'm not saying he did the HD-PVR work under contract, just that he has done contract work
[18:42:50] stuartm: Hauppauge are just assembling parts designed by other manufacturers, so they do what they can, which is why I'm surprised there's no linux flashing app, even if it's a closed source one
[18:42:57] taylorr: skd5aner: the color controls fix was included with the 3.3 and newer kernel releases
[18:43:18] skd5aner: taylorr: up, finally found it – thanks for your work on that :)
[18:43:40] taylorr: if someone has issues with 3.3 or newer I'd say that they've mucked with the mythtv color control settings
[18:43:42] skd5aner: although, one user reports on the wiki that a version of 3.4 they are running didn't fix it??? not sure what that's about
[18:43:52] skd5aner: taylorr: yea, I was assuming that might have been their issue
[18:44:47] dekarl (dekarl!~dekarl@p4FCEEA73.dip.t-dialin.net) has quit (Ping timeout: 255 seconds)
[18:47:22] taylorr: the hd-pvr totally ignored color control changes for firmware <= 0x15, so a user may have tinkered with it and nothing changed then upgraded to a newer firmware which did apply the color control changes and thought they just needed to update the driver but forgot they had changed the default values
[18:48:32] stuartm: or they even installed the newer kernel, but weren't actually using it
[18:48:56] skd5aner: I'm updting the wiki now
[18:48:57] taylorr: it's not out of the realm of possibilities that there are issues with the driver or that a newer firmware has an issue... I only tested one version to get the driver updated
[18:48:59] dekarl (dekarl!~dekarl@p4FE850FA.dip.t-dialin.net) has joined #mythtv
[18:49:11] taylorr: stuartm: yep, that too :)
[18:49:59] skd5aner: what do you mean by, "weren't actually using it"? the color controls?
[18:50:41] taylorr: it's such a pain to update the firmware on the hd-pvr... of course, reverse engineering the USB data was a much bigger pain
[18:50:45] stuartm: the kernel, common mistake for people to install the packages but then forget to reboot
[18:53:59] taylorr: skd5aner: one thing to note is that when I tested the newer firmware recordings worked fine but livetv wouldn't start most of the time so for production I went back to 0x15
[18:54:10] taylorr: I was using 0.24, IIRC
[18:55:12] skd5aner: stuartm: oh, haha – yea...
[18:55:46] skd5aner: taylorr: ooooooh, interesting...
[18:55:54] taylorr: there is definitely something not right with mythtv code and it's been around for several releases... some get lucky which tells me it's something to do with a race condition
[18:56:20] skd5aner: taylorr: I'll try to test against 0.26, but of course I'm having significant issues with my ivtv tuners, so for me to test livetv on the hd-pvr in 0.26, I need to take the ivtv cards out of the mix
[18:57:03] taylorr: also, applying the recent DeviceReadBuffer patch has really helped with channel changing here
[18:57:35] taylorr: on average it knocks off about 4 seconds to change a channel
[18:57:50] joki (joki!~joki@p548651F6.dip.t-dialin.net) has quit (Ping timeout: 255 seconds)
[18:58:12] joki (joki!~joki@p548655D0.dip.t-dialin.net) has joined #mythtv
[18:58:13] skd5aner: that's sweet
[18:59:45] skd5aner: Honestly guys – as much noise as I've been making about how awful live tv is in 0.26, it's really been getting steadily better since about 0.20... and I pretty much thought mythtv was just approaching the quality of live tv on a commercial grade PVR
[19:00:14] skd5aner: just a misstep on 0.26, probably related to changes in drivers/kernel/firmware/ffmpeg, etc...
[19:00:18] skd5aner: lots of variables there
[19:00:36] skd5aner: so I'm not worried :)
[19:01:03] stuartm: taylorr: the pollhup patch?
[19:01:33] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Read error: Connection reset by peer)
[19:01:38] taylorr: yes, that one
[19:02:12] taylorr: skd5aner: the pollhup patch didn't help you... correct?
[19:03:04] stuartm: taylorr: that's a surprising and unexpected bonus
[19:03:06] skd5aner: sorry, I can't recall if that's the exact one I tried or not – do you have the ticket # handy?
[19:03:27] stuartm: skd5aner: it's in the latest 0.25-fixes, 0.26-fixes and master
[19:03:44] taylorr: stuartm: you mean Daniel committed it already?
[19:03:49] skd5aner: oh, then no... it didn't help me for my pvr-250/500 issues
[19:04:02] stuartm: at least the primary fix is, not the other changes in that patch
[19:04:12] stuartm: taylorr: I committed it because danielk22 was too busy to do so
[19:04:40] stuartm: taylorr: he's going to review and possible commit the other changes in that patch later
[19:04:46] taylorr: ah, that's why I missed it :)
[19:05:42] stuartm: the file transfer optimisation in master should also help with channel changes I'd imagine
[19:05:45] taylorr: skd5aner: ah, so maybe it will help with hd-pvr
[19:06:21] skd5aner: taylorr: perhaps... stuartm, do you know the ticket number that patch was attached to?
[19:06:24] stuartm: skd5aner: it didn't? Seemed to help everyone else with PVR- hardware :(
[19:06:27] taylorr: stuartm: I didn't think about channel changes... my seeks and startup are lightening quick already so I didn't think it'd help me much
[19:06:55] skd5aner: stuartm: sorry – I can't even get to my hd-pvr in live tv... it always wants to start up on my analog cards... I need to take them out of the equation to test anything else at this point
[19:07:22] skd5aner: stuartm: but I'm willing to check
[19:07:36] taylorr: skd5aner: all this suffering because your provider has pulled the analog plug yet :)
[19:07:50] skd5aner: *has not  ?
[19:07:54] taylorr: right
[19:08:02] stuartm: http://svn.mythtv.org/trac/ticket/10732
[19:08:43] skd5aner: taylorr: I pretty much avoid recording as much as possible from my analog tuners (not including hd-pvr, obviously)... because the vast majority can record in HD
[19:08:48] taylorr: skd5aner: my buddy upgraded to 0.25 recently and had issues with his analog cards... he just went ahead and pulled the plug himself... problem solved.. surely you don't like watching SD!
[19:09:11] stuartm: the pollhup fix from that patch was applied in https://github.com/MythTV/mythtv/commit/3d13d795b https://github.com/MythTV/mythtv/commit/11ef56385 and https://github.com/MythTV/mythtv/commit/cd9f7eb68
[19:09:21] stuartm: master/0.26/0.25 respectively
[19:09:39] taylorr: stuartm: btw, thanks for backporting those
[19:09:49] skd5aner: BUT... for live tv, it's never been fun to use the HD-PVR for multiple reasons (slow channel changes, instability at show transitions, the fact I have 1 so if something needs to record I've got to give it up, etc...)...
[19:10:09] skd5aner: so I'll frequently watch live tv on analog cable, because channel changes are really fast, and I don't have to worry about conflicts
[19:10:15] skd5aner: when it works, it works well
[19:10:50] skd5aner: and QAM works well, but I only get the broadcasts... so to watch the primary cable networks in live tv, I generally lean on my analog tuners
[19:10:52] taylorr: skd5aner: yes, it's ridiculous that I have to make sure livetv isn't in progress if a recording starts on that tuner because it always ends badly
[19:11:03] stuartm: why doesn't github show which _branch_ those commits were made on?
[19:11:12] skd5aner: stuartm: thanks... I'll try and provide some feedback later today
[19:11:57] taylorr: I'd rather it kick me out of livetv automatically and make sure that the scheduled program get recorded
[19:12:29] taylorr: it's incredibly bad end-user experience... I believe that if I was a new user these days I'd definitely give up
[19:12:41] skd5aner: taylorr: #11207 – this seems to no longer work for me either :(
[19:12:41] ** MythLogBot http://code.mythtv.org/trac/ticket/11207 **
[19:13:23] taylorr: right, it seems to fail in different ways for me... I haven't tried to dig on it... just avoid it :)
[19:13:40] skd5aner: yea, same here... best to avoid... too bad we have to
[19:13:40] taylorr: I'm running 0.25... so it's quite an old problem
[19:14:03] stuartm: I can't really think what changed in that area between 0.25 and 0.26 – except some work in the scheduler
[19:14:16] taylorr: part of the problem is that we have some vocal devs who seem to advocate that livetv is for idiots so it gets less priority
[19:14:18] skd5aner: well, I'm not 100% sure at this point, but I know that it used to work... in other words, I have 4 physical qam tuners, not including virtual...
[19:15:01] stuartm: taylorr: nah, it's more of a defensive stance because few of the devs actually use or care about livetv (I only ever touch it when testing stuff)
[19:15:04] skd5aner: and I can be watching live tv on one, and the 3 others are free fro the entire day... it'll prompt me and tell me that I either need to reschedule and continue to watch live tv, exit live tv and record, etc...
[19:15:42] stuartm: no-one would stop anyone else from working on or fixing livetv, but they aren't really interested in working on something they don't use
[19:15:46] skd5aner: stuartm: actually, in -users there have been many occasions when people were made to sound like babbling idiots for suggesting the use live tv
[19:15:59] skd5aner: some of those by devs... and some of my favorite devs at that
[19:16:19] taylorr: stuartm: no, they actually show up on the lists every time it's brought up with their "personal" views about the situation.. it only serves to alienate users
[19:16:50] taylorr: stuartm: in a nutshell they should shut up about it if it's not something they care about
[19:17:05] skd5aner: It's not as bad as it used to be – but there were years where the stance was "well, I guess you don't know what a DVR is then" – as if, live tv was a principle that should no longer apply and the suggestion of that otherwise was just ignorance :/
[19:17:38] stichnot (stichnot!~stichnot@adsl-69-110-144-76.dsl.pltn13.pacbell.net) has joined #mythtv
[19:17:38] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[19:17:38] stichnot (stichnot!~stichnot@adsl-69-110-144-76.dsl.pltn13.pacbell.net) has quit (Changing host)
[19:17:39] stuartm: skd5aner: right, but it's mostly because those devs are just tired of hearing complaints, often from people who can't themselves be bothered to work on fixes – telling people not to use livetv is easier than telling them to scratch their own itches
[19:19:08] stuartm: taylorr: I don't entirely disagree, but it's equally frustrating to see the same people complaining about it time after time but refusing to do anything themselves about it – different people respond in different ways to the situation
[19:19:08] skd5aner: well, fwiw – that attitude isn't as prevalent as it used to be – the scales are basically balanced at this point and I know some devs have stepped up over the last 2 years to make sure it was no longer a third class citizen
[19:19:14] skd5aner: so I'm thankful for that
[19:20:43] skd5aner: stuartm: and, I know I'm one of those that comes around when live tv breaks miserably and makes a bit of noise, but I try to be as considerate and helpful as possible and not come off as just someone complaining... because I know all I can do is provide info, not patches :(
[19:21:03] taylorr: stuartm: one of the issues is that myself, Mark and others spent a lot of time getting livetv to work half decent then the code gets rewritten and breaks livetv but that dev could care less
[19:21:47] taylorr: anyways, I'm done with my ranting for the day
[19:22:07] skd5aner: heh – no one is ranting...
[19:22:32] skd5aner: truth is truth... we're all on the same page here, it is what it is...
[19:29:13] stuartm: anyway, if we can get more data on the problems you're having it may help someone to discover the root cause
[19:29:29] skd5aner: yup – happy to provide :)
[19:30:12] stuartm: or at the very least we can try to target know good versions of the firmware, having so many versions which behave so differently makes it much harder to have code that works for everyone
[19:30:52] taylorr: yes, I'd say hd-pvr is probably the device with the most variables by far
[19:31:40] stuartm: but if you need Windows to upgrade the firmware then forcing users to use a particular version won't be so popular :(
[19:32:05] stuartm: I've not had a copy of Windows in this house for 10 years*
[19:32:23] stuartm: * Something like that anyway, I didn't mark the date in my diary :)
[19:33:46] skd5aner: stuartm: I'll try and test with the latest 0.26-fixes prior to firmware upgrade, and after
[19:33:53] taylorr: stuartm: one of the problems is that some people have to use a different firmware version because of compatibility with their STB... so it's impossible to get everyone on the same version
[19:34:20] taylorr: skd5aner: I'd like to hear if the color controls work properly with your experiment
[19:34:27] skd5aner: want me to apply the entire patch from #10732 or just the pieces already backported?
[19:34:27] ** MythLogBot http://code.mythtv.org/trac/ticket/10732 **
[19:34:48] skd5aner: taylorr: yea, absolutely...
[19:36:13] stuartm: taylorr: well that make the task almost impossible from our end, unless we have different code paths/behaviour keyed off firmware versions – much harder to test and maintain
[19:36:46] stuartm: I'd expect the driver to even out the experience, offer consistent behaviour no matter the firmware being used
[19:37:03] stuartm: so maybe that's where fixes need to go instead
[19:37:11] taylorr: stuartm: well the driver doesn't have any means to report the firmware version to the application :)
[19:38:02] stuartm: no? I could have sworn that it did :/
[19:38:41] stuartm: no wonder HD-PVR support is so fragile :(
[19:38:41] skd5aner: couldn't you just parse dmesg and pull it from there?
[19:39:06] skd5aner: and the driver has to be able to know the firmware version – it just doesn't have a way to output that I guess?
[19:39:08] stuartm: taylorr: it's not exposed somewhere in /sys ?
[19:39:34] taylorr: stuartm: actually I dunno about that
[19:40:23] skd5aner: stuartm: do you have one? or just dvb cards?
[19:47:31] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[19:50:38] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[19:50:56] stichnot (stichnot!~stichnot@68.127.102.108) has joined #mythtv
[19:50:56] stichnot (stichnot!~stichnot@68.127.102.108) has quit (Changing host)
[19:50:56] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[19:55:33] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds)
[20:10:54] stichnot (stichnot!~stichnot@69.110.144.195) has joined #mythtv
[20:10:54] stichnot (stichnot!~stichnot@69.110.144.195) has quit (Changing host)
[20:10:54] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[20:11:59] sraue_ (sraue_!~stephan@64-57-239-77-pool.cable.fcom.ch) has joined #mythtv
[20:12:20] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Disconnected by services)
[20:12:40] sraue_ is now known as sraue
[20:13:02] sraue (sraue!~stephan@64-57-239-77-pool.cable.fcom.ch) has quit (Changing host)
[20:13:02] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[20:16:35] stichnot: sorry for all the reconnects, this light rain wreaks havoc on the California infrastructure :)
[20:19:25] stichnot: Speaking of live TV. I understand that the LiveTVChain is broken, i.e. you can't jump back to a previous recording in the current live TV session. Quite possible that something I did a while back broke it. How does the live TV chain navigation usually work? Does it appear instantaneous and seamless, or is it more like the "Please Wait..." delay when you start a new playback?
[20:23:53] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds)
[20:25:11] skd5aner: well, I'd love to respond to him, except he's gone again
[20:29:50] stichnot (stichnot!~stichnot@adsl-69-105-238-244.dsl.pltn13.pacbell.net) has joined #mythtv
[20:29:50] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[20:29:50] stichnot (stichnot!~stichnot@adsl-69-105-238-244.dsl.pltn13.pacbell.net) has quit (Changing host)
[20:29:56] stichnot: please respond, I read the logs :)
[20:30:11] skd5aner: heh
[20:30:29] skd5aner: ok... well, are you asking about transitions between shows while watching live tv?
[20:30:54] skd5aner: the transition between shows issue usually seemless, with a very small glitch... no dialog, nothing like that...
[20:31:18] stichnot: not talking about that one. There's a recent ticket, I'll look it up
[20:31:19] skd5aner: well, that's the way it's supposed to work and has in the past, not sure about recently
[20:31:39] stichnot: #11174
[20:31:39] ** MythLogBot http://code.mythtv.org/trac/ticket/11174 **
[20:31:49] skd5aner: I guess you're asking more about, if you need to rewind to the previous show in the chain?
[20:33:19] skd5aner: ah... yea, you know... that's interesting, because the reporter makes a valid point – if he sees the same issue I see when playing back any form of corruption that you can only solve it by exiting, it'd basically means you're hosed if you are trying to use live tv
[20:33:25] skd5aner: and encounter the corruption
[20:35:12] skd5aner: stichnot: so, if I recall what it did, but not having actually done it in months... if you rewind before the start of the current program into the end of the previous program in live tv, it would actually just pause for a very very short bit, but nothing like the "please wait" dialog
[20:35:29] skd5aner: that is, if my memory serves me correct
[20:36:03] stichnot: I've never used the live TV chain navigation, but there are OSD elements in the code iirc and the whole idea of maintaining the chain would be huge overkill otherwise
[20:36:32] stichnot: If you set up a playlist, I'm pretty sure you get the explicit "Please Wait" between recordings
[20:37:15] stuartm: skd5aner: just dvb
[20:38:38] skd5aner: stuartm: gotcha... I can remember back in 2005, I had an issue with a pair of cards – I remember shipping them to Jared and having him play around with them – he shipped them back and they've worked ever since... not sure why they never worked for me the first time
[20:39:08] skd5aner: er, Jarod
[20:39:08] stuartm: the livetv transitions should be seamless, they were always that way when I tested livetv more thoroughly but that was 2–3 years ago now
[20:39:45] skd5aner: well, pretty much seamless, yea – that was my experience as well...
[20:39:46] stuartm: sorry for not responding earlier, I went to do some reading (insane backlog of books on my Kindle)
[20:40:16] skd5aner: stuartm: heh – no worries, glad you stepped away :)
[20:40:52] skd5aner: I'm actually stepping away from my house renovation today... back hurts from last 2 days of work
[20:45:43] skd5aner: stuartm: not sure if this is reported anywhere, or if you feel I should via a ticket... but one thing I've noticed is that 0.26 will now show the main menu between channel changes
[20:47:11] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[20:47:19] skd5aner: testing the HD-PVR right now prior to firmwre upgrade... getting the "cann't open jump file" and "video fram buffering failed too many times" errors
[20:47:20] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[20:48:28] skd5aner: works sometimes, sometimes it doesnt... usually only if I'm starting livetv on the same channel I want to watch – but frequently doesn't work on a channel change
[20:49:41] skd5aner: running fixes – v0.26.0-39-g17c0c77-dirty
[20:50:08] stichnot: stuartm: there may be a tiny glitch at live TV transitions but danielk22 has mentioned that at least part of that may be from events being processed inside the main video loop
[20:52:03] skd5aner: stuartm: going to upgrade to latest fixes since mine doesn't have those backported features, even though I think I manually patched them
[20:52:44] skd5aner: is there a git command to undo any patches I've applied so that I can just ensure that the latest pull is just the clean, vanilla branch?
[20:52:52] stuartm: skd5aner: you did mention it, I've not been able to reproduce
[20:53:29] skd5aner: stuartm: ok, might just be a subsymptom... I have no idea how to provide you any useful details other than to just let you know that it does it for whatever reason
[20:55:36] stuartm: I don't really know enough about the video rendering to begin to make sense of that symptom, we should be keeping the last decoded frame up on screen until the channel change completes
[20:55:51] skd5aner: yea, it typically did that – or at least blacked the screen
[21:05:43] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[21:05:55] stuartm: huh, this blu-ray I just bought is mpeg2 – first I've ever seen like that, and only 18GB too instead of the usual ~30GB
[21:09:53] stuartm: in fact this makes it the first HD mpeg2 I've ever seen
[21:10:41] sl1ce (sl1ce!~johnathan@100.0.73.123) has joined #mythtv
[21:11:21] sl1ce (sl1ce!~johnathan@100.0.73.123) has quit (Client Quit)
[21:12:59] sl1ce (sl1ce!~johnathan@100.0.73.123) has joined #mythtv
[21:14:29] sl1ce (sl1ce!~johnathan@100.0.73.123) has quit (Client Quit)
[21:16:10] sl1ce (sl1ce!~johnathan@100.0.73.123) has joined #mythtv
[21:21:10] skd5aner: heh – I have lots of HD mpeg2s, thanks to ATSC :)
[21:23:32] sl1ce (sl1ce!~johnathan@100.0.73.123) has quit (Remote host closed the connection)
[21:24:24] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[21:37:27] jpabq: I started up LiveTV on one of my HD-PVRs 1.5 hours ago. It has is now transitioned to it's 3rd half-hour show without any problems at all. I don't have a pvr 2250, to try. I think I have a PVR-350 on a shelf somewhere — but I don't have a slot to plug it into.
[21:38:27] skd5aner: you know... I have 2 extra PVR-250's I'm not using... I'd be willing to loan them to any dev that would want to test with them
[21:38:48] skd5aner: Require PCI slots
[21:48:37] sl1ce (sl1ce!~johnathan@100.0.73.123) has joined #mythtv
[21:48:39] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 256 seconds)
[21:49:25] skd5aner: stuartm: not sure it'd do you any good, but if you're interested I'd be willing to ship it your way, as long as you send it back sometime in the future when you're done with it
[21:55:31] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 246 seconds)
[21:56:04] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[22:07:39] skd5aner: ok, upgraded to latest .26-fixes... started live tv on my hd-pvr, started up fine... switched the neighboring channel via guide... went to main menu for ~8 seconds, then black for 1–2 seconds, then back to the main menu with "Error opening jump program file"
[22:07:46] skd5aner: this is pre-firmware update
[22:08:46] skd5aner: stuartm, taylorr ^
[22:13:07] jpabq: skd5aner: I just tried what you just described. After selecting the new channel from the guide, it showed the "theme background" for less than a second, then tuned the new channel which took about 4 seconds. I tried that four times, and it worked every time.
[22:13:33] jpabq: The fact that it works so well for me, makes it very hard for me to figure it why it doesn't work for others (you).
[22:14:47] skd5aner: jpabq: heh – yea... do you mind if I ask what you're tuning from/to in terms of source?
[22:15:49] jpabq: Directv. I am using USB to change channels via a script.
[22:16:03] skd5aner: ok, so all HDPVR?
[22:16:13] jpabq: Yes.
[22:16:28] jpabq: Are you going from ATSC to HD-PVR or visa-versa?
[22:16:57] skd5aner: stuartm: tried to tune to an analog (ivtv – pvr-500) channel and live tv and it's hanging the frontend, just as before
[22:17:39] skd5aner: QAM works best... let me see what happens when I tune between channels there
[22:18:36] skd5aner: ok, in QAM, channel changes are taking like 1 second... it's super fast, but I still see the main menu for about .5 second, then black for about .2 seconds, then the next channel starts
[22:18:46] skd5aner: QAM to QAM that is
[22:18:48] jpabq: I just bounced from HD-PVR -> HDhomerun -> HD-PVR, and it is now wedged on a black screen.
[22:19:00] skd5aner: completely hung?
[22:19:20] jpabq: "Player(0): Waited 10ms for decoder lock"
[22:19:27] jpabq: repeated
[22:19:35] skd5aner: yea...
[22:20:31] skd5aner: nice
[22:20:50] jpabq: I will have to look up what that error message means.
[22:21:27] jpabq: But, not right now. I have other things I am supposed to be working on, away from Myth.
[22:22:13] skd5aner: yea, no worries – thanks for looking
[22:23:50] skd5aner: from QAM to HDPVR... ~1 second of going to main menu, then .2 seconds black, then ~12 seconds of OSD, then ~30+ seconds of just black, then kicked back to the main menu with "Video fram buffering failed too many times"
[22:24:08] skd5aner: s/fram/frame
[22:25:25] jpabq: I assume you have a relevant backend log with "-v channel,record" on one of your tickets?
[22:26:39] aloril (aloril!~aloril@84.249.126.153) has quit (Ping timeout: 260 seconds)
[22:26:55] skd5aner: However, if I relaunch live tv, and it launches on the station it was attemtping to change to on the HDPVR – then it starts up in less than 3–4 seconds
[22:27:09] skd5aner: jpabq: yes, and backtraces for the frontend hangs
[22:29:11] skd5aner: from HDPVR to analog NTSC (PVR-500 recording analog cable), instant hang... no menu, no black screen, etc...
[22:29:16] aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv
[22:29:27] skd5aner: have to killall mythfrontend (twice) to reset
[22:31:04] skd5aner: From HD-PVR to HD-PVR channel change – stick in guide for 2 seconds, then full screen video frame for 5 seconds, then kicked back to the main menu with "Error Opening jump program file"
[22:32:24] skd5aner: ok – enough scenario testing for now... I'll go update the firmware on the HD-PVR now and see if I get any better results... jpabq, do you know what version of firmware dmesg is reporting on your hd-pvrs? are they all the same?
[22:35:12] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[22:47:55] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[22:51:07] skd5aner: Post hdpvr firmware update...
[22:51:23] sl1ce (sl1ce!~johnathan@100.0.73.123) has quit (Ping timeout: 245 seconds)
[22:51:42] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[22:52:08] skd5aner: no issues with hue/saturation on latest firmware 0x1e and 3.5 kernel (ubuntu 12.10)
[22:52:13] skd5aner: taylorr: ^
[22:52:37] skd5aner: also, can start live tv on hd-pvr ok, ~10–12 seconds before playback starts
[22:53:30] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 264 seconds)
[22:53:35] skd5aner: I can change channels from a 1080i channel, to another 1080i channel, ~3 seconds on main menu, ~8 seconds on still frame from previous show, then next channel appears
[22:55:08] skd5aner: however, if I try to switch from a 1080i channel on the hd-pvr, to a 720p channel on the hd-pvr, I get ~3 seconds of main menu, ~8 seconds of black, then kicked back to the main menu with an "error opening jump program file buffer"
[22:55:46] skd5aner: I could potentially try and force the output on the STB to either just 720p or 1080i, but that's just a band-aid
[22:55:47] stuartm: that's an improvement though?
[22:56:46] stuartm: or not?
[22:56:56] skd5aner: stuartm: well, hard to say... so to speak... it's an improvement in that it's a tiny bit more reliable in launching in to live tv on the HD-PVR, but it's about the same otherwise
[22:57:15] neon__ (neon__!~neon@bzq-109-67-207-7.red.bezeqint.net) has joined #mythtv
[22:57:17] neon__: hi
[22:57:28] neon__: I try to set up, but it fails to connect to db
[22:57:45] neon__: i need to reconfigure it or somethign?
[22:57:56] skd5aner: neon__: wrong channel, try #mythtv-users
[22:58:01] stuartm: neon__: support channels is #mythtv-users
[22:58:52] skd5aner: stuartm: I think it is a slightly be more stable, but ultimately, I think it's a bit of lucky timing waiting on the stb to stabilize enough that the HD-PVR finally stabilizes...
[22:58:55] stuartm: skd5aner: 12 seconds seems like a really long time for a channel change, but maybe that's standard for the HD-PVR
[22:59:29] skd5aner: also, these are not exact timings, just me counting out loud while doing it
[22:59:41] sl1ce_1g (sl1ce_1g!~johnathan@100.0.73.123) has joined #mythtv
[23:00:02] skd5aner: I'm a human metronome ;)
[23:00:04] stuartm: way back in the day my PVR-150 was a lot faster
[23:00:16] skd5aner: yea, QAM is great ~1 second on average
[23:00:20] skd5aner: QAM/ATSC
[23:00:26] stuartm: and it was doing much the same jobs, albeit in mpeg2 and SD
[23:00:30] skd5aner: NTSC to NTSC, usually pretty dang quick too
[23:00:41] skd5aner: when it worked
[23:01:16] skd5aner: that's why I always said people shouldn't really complain about channel changing speeds in livetv from 0.24 onward... with the excpetion of the hd-pvr...
[23:01:31] skd5aner: I do believe the HD-PVR could probably be tuned a bit better, but I never expect it to be fast...
[23:02:01] skd5aner: and then, I don't think people should complain about it, as much as just understand the limitation of the device itself, not myth
[23:02:20] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Ping timeout: 252 seconds)
[23:02:25] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[23:02:32] skd5aner: I can tell you, whne I click live tv, and it launches on the HD-PVR, here's the sequence...
[23:02:38] stuartm: switching resolutions on the fly is going to take longer, but otherwise it's hard to figure why it would be so slow
[23:03:18] skd5aner: 2 seconds of "Please Wait" on the main menu... 5 seconds of the OSD and black screen... then video starts
[23:03:54] skd5aner: 5 secoinds after initially launching livetv, the blue LED record light on the HD-PVR lights up...
[23:04:19] skd5aner: and 1.5 seconds later, that's when playback starts
[23:04:30] stuartm: it does seem to be a hardware thing, it shouldn't need to do anything when you change a channel on the STB (except when the resolution changes) but clearly it's being too clever for it's own good
[23:04:47] skd5aner: that's when it's starting up on the last channel it was tuned to (and the STB already tuned to that channel)
[23:05:03] skd5aner: now, if I do a channel change...
[23:05:27] sl1ce_2g (sl1ce_2g!~johnathan@100.0.73.123) has joined #mythtv
[23:05:33] sl1ce_1g (sl1ce_1g!~johnathan@100.0.73.123) has quit (Ping timeout: 245 seconds)
[23:06:06] stuartm: it should just keep encoding without skipping a beat, I wonder if that's our fault, we're telling it to stop/start encoding or whether it's all in the hardware
[23:06:44] skd5aner: ~2.5 seconds of seeing the main menu...~9 seconds of seeing a still frame of the last show, then a blip of black and then the next channel – that's between 2 1080i channels
[23:07:38] stuartm: I mean there may be practical reasons that I'm not aware of to stop/start encoding on every channel change, but if not I can see why that might cause delays and knock on problems with timeouts etc
[23:09:31] skd5aner: at the same time, here's what the device itself does...1 second later, the device recording light goes out...3 seconds after that the recording light comes back on... 3.5 seconds after that the recording light goes back off... 2 seconds later the light comes back on... 2 seconds later the playback begins
[23:09:40] stuartm: and yeah if it's taking that long before the LED lights up, then either the hardware is just that slow or ... what, the driver?
[23:09:49] skd5aner: so, that's what the stabilization of the device looks like
[23:10:27] stuartm: skd5aner: have you ever compared that start-up performance with windows? i.e. start capture in whatever software they provide and time how long it takes for the led to light up?
[23:10:53] skd5aner: btw – those are all sequential seconds... so, 1 second + 3 seconds = 4 total seconds, not just 3 seconds from the start
[23:11:10] stuartm: skd5aner: the double on/off again doesn't sound optimal to me
[23:11:17] skd5aner: stuartm: never hooked it up to windows until just now to do the firmware update
[23:11:55] skd5aner: I'd have to defer to taylorr and jpabq who know way more about the device stabilization than I do, but I think this was all the reason why jpabq wrote the signal monitor for the device
[23:12:04] stuartm: skd5aner: tbh it's something I'd expect those working the drivers to do, compare speed etc
[23:12:48] skd5aner: also, I almost never have an issue related to recordings unless its for a completely different reason – where I get 0byte recordings – usually the STB powered itself off, or the device needs to be physically hard cycled every couple of weeks, but that seems to be a different issue
[23:13:22] stuartm: I don't have the hardware, I don't know the drivers or how it's all supposed to work, I'm just making unhelpful remarks based on your observations :)
[23:13:31] skd5aner: hey... I'll take it
[23:13:36] skd5aner: I just want someone to listen, haha
[23:14:10] skd5aner: at least then, people can't say they "had no idea" which is pretty frustrating
[23:14:50] jpabq: if the HD-PVR is told to "start encoding" too soon, the first few seconds of the resulting H.264 will be "damaged". So, Myth 0.26 tests the video resolution, and will wait to "start encoding" until the HD-PVR reports a *stead* resolution for 2 seconds.
[23:15:24] jpabq: s/stead/steady/
[23:16:23] stuartm: it all seems wrong to me, the LED turning on/off is a red flag – might not be under our control, but with a device that clearly takes it's time responding to commands I'd keep it encoding across channel changes
[23:18:02] jpabq: stuartm: that might work on some STBs, but not all. The HD-PVR does not like it when the STB output is not stable. For example, switching from a 720p channel to a 1080i channel can cause problems
[23:19:08] skd5aner: my question is – how come it fails very frequrently for live tv, but doesn't fail for recordings?
[23:19:25] jpabq: Now, if the decoder was better at handling "damage", then we might be able to do that for all STBs.
[23:19:52] skd5aner: stuartm: I was able to work around this in 0.25 because I could put an extra 3–4 seconds sleep in my channel changing script before mythtv would proceed... which would ensure total stabilization of the STB, but obviously this slowed things down
[23:20:16] skd5aner: in 0.26, I switched to using the built in firewire channel changer, and there is no way, without modifying the code, to add a sleep... but again, just a band-aid
[23:20:18] stuartm: skd5aner: I assume we can afford to take more time when recording, we don't have a frontend waiting for video to decode and display
[23:20:28] skd5aner: yea
[23:20:52] skd5aner: but, I'd rather wait an extra 2 seconds and be able to eventually watch TV rather than error our 95% of the time ;)
[23:21:21] skd5aner: painfully long channel changes is at least a step up from not being able to use the device to watch live tv at all
[23:21:25] skd5aner: imho
[23:21:28] stuartm: tbh, it seems like you need that band-aid for the HD-PVR, it's an order of magnitude slower and less predicatable than other devices
[23:21:37] skd5aner: potentially, yea
[23:22:21] skd5aner: I'm just wondering if there's a way to do that withot impacting EVERYONE... for example, jpabq has set all his stbs to output at one resolution and they may be more efficient at stabilizing
[23:22:24] jpabq: One of the problems with the HD-PVR is the variability of the STB it is hooked up to.
[23:22:41] skd5aner: so, penalizing him with 2–5 extra seconds of a built in sleep would not be optimal
[23:23:10] skd5aner: jpabq: but, I can tell you... I've tested it on 3 different STBs on 3 completely different cable providers over the last year
[23:23:14] stuartm: it's sounding a lot like it was never really designed to be used for something like MythTV, but capturing from camcorders, the odd TV recording or games console
[23:23:23] jpabq: Actually, I have mine setup to switch. 1080i channels are 1080i, 720p channels are 720p.
[23:23:58] jpabq: I think there is a huge difference in how cable STBs work compared to Directv STBs comared to Dish STBs
[23:24:02] stuartm: it's taylorr who setup his not to switch
[23:24:07] skd5aner: TWC – SA3250HD, Comcast -Can't remember the unit, and BHN – Cisco 4742HD
[23:24:16] skd5aner: and they all reacted the same way
[23:24:22] jpabq: stuartm: the chip that Hauppauge is using *was* designed for camcorders.
[23:25:31] jpabq: I believe that 99% of the people complaining about the HD-PVR and LiveTV are cable users.
[23:25:34] stuartm: jpabq: makes sense, it's simply not designed for rapid switching
[23:26:25] stuartm: I suppose there is a good reason why broadcast encoders cost thousands, tens of thousands even
[23:26:32] jpabq: I will actually be getting Comcast cable — I need it for my new job. But, I was not planning on getting a STB — I will be using a cable card.
[23:26:33] skd5aner: jpabq: ah, maybe that was taylorr then, sorry... someone mentioned they lock it down to 720p because of these issues
[23:27:32] jpabq: I could probably get a Comcast STB for a month, just to see if I can debug some of this stuff.
[23:28:00] skd5aner: yea, I'd love to sit here and say it doesn't matter to me because I could use cablecard, but they lock it all down for me... I actually am paying for one right now for no good reason
[23:28:33] skd5aner: when I was on comcast, I only used my hd-pvr to test... the hdhr prime did everything I needed – awesome device – super fast in Live TV
[23:28:56] stuartm: wagnerrp: mouse works pretty well for me ...
[23:29:29] wagnerrp: you can't just click on something, you have to click once to highlight it, and then click again to select it
[23:29:50] wagnerrp: did you see the note i made last night about the IP dropdowns in mythtv-setup?
[23:31:13] stuartm: in the setup? Yeah I suppose that's true but maybe also by design for the same reason it works that way elsewhere in the UI, you usually want to see the description associated with an item before changing it's value, or playing a recording etc
[23:31:40] stuartm: wagnerrp: I didn't see the note, where was this?
[23:32:09] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Remote host closed the connection)
[23:32:11] wagnerrp: the list you use to populate the spinbox is the list of currently used addresses, not the list of available addresses
[23:32:35] stuartm: it is? umm
[23:33:04] wagnerrp: there is no existing list of available addresses
[23:33:40] skd5aner: jpabq: I'd be willing to chip in a bit if your work won't cover the expenses for the STB
[23:33:57] skd5aner: I'm guessing it's about $5/mo for a non-DVR STB?
[23:34:10] sraue_ (sraue_!~stephan@149-45-239-77-pool.cable.fcom.ch) has joined #mythtv
[23:34:34] wagnerrp: stuartm: don't worry about it, i'll see about replacing that whole mechanism in the next week or so
[23:34:45] sraue_ is now known as sraue
[23:34:55] sraue (sraue!~stephan@149-45-239-77-pool.cable.fcom.ch) has quit (Changing host)
[23:34:55] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[23:35:10] wagnerrp: leave the serverpool, but move address lookup to the backend rather than the database
[23:35:24] wagnerrp: so addresses do not need to be statically defined in the database
[23:35:58] wagnerrp: (and following that, backends don't need defined addresses)
[23:38:41] stuartm: wagnerrp: I must be mis-read the code where we built those lists from the lists obtained via QNetworkInterface::addressEntries()
[23:39:00] wagnerrp: the lists are built from those, but then filtered
[23:39:12] wagnerrp: if no IP address is listed, it's any private network or link local address
[23:39:27] wagnerrp: if an ip address is selected in the database, it's only that address and any link local address
[23:40:02] wagnerrp: in other words, if you ever select an address from that dropdown, that will be the only address ever in that dropdown
[23:40:18] wagnerrp: (plus link-local and loopback)
[23:40:37] wagnerrp: that list holds the addresses the server pool has decided as the default list to listen on
[23:41:10] stuartm: oops
[23:42:43] wagnerrp: it's not in any release, so don't worry about fixing it just yet
[23:43:11] stuartm: my original version used QT directly, since it appeared that the ServerPool was doing the same thing I switched to that instead, should have looked closer – mea culpa :)
[23:46:41] wagnerrp: well it just gives me the motivation to actually finish what i had planned from the start with serverpool
[23:53:51] skd5aner: ok, I'm going to step away for a while – will check in later – stuartm and jpabq , thanks for sticking in there with me
[23:56:45] taylorr: stuartm, skdaner: for the record, I allow the STB to switch between 720p and 1080i... there is no way I'd allow an STB to deinterlace!

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