| Tuesday, February 12th, 2013, 00:00 UTC | ||
| [00:00:51] | Seeker`: | jya: easiest way of doing it is selecting the mythfrontend from the iDeveice, starting something playing, then selecting the iDevice again |
| [00:01:00] | jya: | Seeker`: I do that daily, never had a crash |
| [00:01:23] | jya: | having said that, I haven't tried with master in a while |
| [00:01:25] | Seeker`: | stuart suggested that it was something to do with a namespace clash with netsreams? |
| [00:01:40] | jya: | does this occur with something else than netstream? |
| [00:01:50] | jya: | it seems to be crashing in the netstream destructor |
| [00:01:55] | Seeker`: | I'm not sure what you mean |
| [00:02:07] | jya: | you say you use netstream |
| [00:02:16] | jya: | i don't have netstream setup.. |
| [00:02:29] | jya: | so does it crash with say playing a standard recording |
| [00:02:34] | Seeker`: | I think stuart's suggestion was that you have a NetStream class defined in mythraop-something-or-other.cpp |
| [00:02:50] | jya: | ahhh |
| [00:02:59] | jya: | i do remember fixing something like that |
| [00:03:01] | Seeker`: | and there is another class in libmythtv called NetStream |
| [00:03:11] | jya: | someone created a class that was the same name as one I was using internally |
| [00:03:18] | jya: | but that caused a compilation error |
| [00:04:26] | Seeker`: | jya: well, my backtrace seems to suggest that it thinks it is calling the destructor in netstream.cpp |
| [00:05:51] | jya: | that make sense… but I thought I changed that a while back (and my class was there first :) ) |
| [00:06:40] | Seeker`: | hehe |
| [00:06:55] | Seeker`: | maybe you just didn't commit the change? I couldn't see anything in the history of mythraopconnection |
| [00:08:22] | neufeld: | jpabq: testing your latest patch on 0.25.2 now. Results in a couple of hours... |
| [00:09:08] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 248 seconds) | |
| [00:10:35] | Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has quit (Quit: Wolfgang2) | |
| [00:12:05] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [00:30:33] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 252 seconds) | |
| [00:33:24] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [00:33:58] | drussell_ (drussell_!~drussell@d50-93-49-135.abhsia.telus.net) has quit (Quit: Leaving) | |
| [00:35:08] | Kevin`_ is now known as Kevin` | |
| [00:42:38] | jhall_: | BTW I am trying to use the NetStream class in netstream.cpp (libs/libmythtv) |
| [00:42:57] | jhall_: | my code checks to see if the uri is http uri |
| [00:43:35] | jhall_: | if (m_tuning.GetURL(0).scheme().toLower() == "http") { |
| [00:44:06] | jhall_: | qString url = m_tuning.GetURL(0); |
| [00:44:14] | jhall_: | sorry |
| [00:44:39] | jhall_: | QString url = m_tuning.GetURL().toString(); |
| [00:44:49] | jhall_: | and here is where it crashes |
| [00:45:47] | jhall_: | m_httpstream = new NetStream(m_tuning.GetURL(0), NetStream::kNeverCache); |
| [00:46:01] | jhall_: | the segv occurs when it tries to connect a socket |
| [00:46:09] | jhall_: | I mean a slot |
| [00:46:45] | jhall_: | netstream.cpp:109 |
| [00:47:11] | drussell_ (drussell_!~drussell@d50-93-49-135.abhsia.telus.net) has joined #mythtv | |
| [00:47:29] | jhall_: | 109 this, SLOT(slotRequestStarted(int, QNetworkReply*)), Qt::DirectConnection ); |
| [00:48:07] | jhall_: | the URL appears to be in tact, I did a print right before the constructor |
| [00:51:25] | jhall_: | hmm |
| [00:51:29] | jhall_: | it says right before this |
| [00:51:35] | jhall_: | receive requests from NAMThread |
| [00:51:50] | jhall_: | what is the NAMThread and should I have obtained a lock to verify it is ready to receive requests? |
| [00:59:38] | danielk222: | jya: For most TV resolutions the pixels aren't square. Really it is only 1280x720 and 1920x1080 that have square pixels. |
| [01:01:23] | danielk222: | 1440x1080 is a 16:9 format I've seen. |
| [01:26:15] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [01:49:46] | neufeld: | jpabq: First test of the 0.25.2 patch for #11328 doesn't look right on my end. ffprobe on the resulting file dumps a handful of errors, and the reported duration and bitrates are way off (0.76 second duration for a 5 minute recording). I'm going to revert for the evening, one of my wife's favourite shows is coming on in 10 minutes and I don't want unpleasant surprises. I'll do some more checking tomorrow. |
| [01:49:46] | ** MythLogBot http://code.mythtv.org/trac/ticket/11328 ** | |
| [01:49:46] | neufeld: | Meanwhile, I'll post the ffprobe output to the bug. |
| [01:52:26] | taylorr: | jpabq: the latest v4 patch seems to be working fine for me so far |
| [01:58:00] | joki (joki!~joki@p548644F0.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [01:59:33] | joki (joki!~joki@p54864467.dip.t-dialin.net) has joined #mythtv | |
| [02:25:24] | jpabq: | neufeld: can you try a newer version of ffprobe? |
| [02:28:55] | jpabq: | neufeld: very strange that the PAT/PMT are showing up *after* that garbage. I don't see how that is possible with the patch applied. |
| [02:29:30] | jpabq: | Unless, the recording glitched and had to restart, maybe? |
| [02:31:00] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds) | |
| [02:55:01] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [03:16:49] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [03:26:33] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds) | |
| [03:45:26] | taylorr: | jpabq: how to you check for the PAT/PMT? the recordings with your patch has a 188 byte packet to start followed by an IDR frame |
| [03:47:51] | neufeld: | jpabq: you're right, it glitched. Invalid test, I'll check it again in the morning. |
| [03:48:18] | sybodebo (sybodebo!~sybolt@dhskadaj.xs4all.nl) has joined #mythtv | |
| [03:50:48] | sybodebo (sybodebo!~sybolt@dhskadaj.xs4all.nl) has quit (Client Quit) | |
| [03:58:57] | jpabq: | neufeld: That was actually good. It made me think about what should happen in a case like that. While it will not completely get rid of the garbage, I can make a change that will minimize it. |
| [03:59:13] | tonsofpcs: | taylorr: all pakets should be 188 bytes... (or 204) |
| [04:00:11] | jpabq: | taylorr: I believe that when ffprobe spits out "Stream #0:0[0x1011]: Video: h264 (Main) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc" that is coming from parsing the PMT |
| [04:01:52] | Goga777 (Goga777!~Goga777@95-30-39-181.broadband.corbina.ru) has joined #mythtv | |
| [04:04:24] | neufeld: | jpabq: looking at the logs, it was a recurring failure to latch over the entire recording interval. The STB I have to use has a way of doing that bad things sometimes, that's why I have a script to power-cycle it after every recording! Well, I'm off for the evening, I'll test again in the morning. Thank you again for your work on this. |
| [04:04:26] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [04:04:26] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [04:04:26] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [04:04:37] | neufeld is now known as neufeld_AFK | |
| [04:09:03] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.3.8) | |
| [04:09:19] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has joined #mythtv | |
| [04:09:19] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has quit (Changing host) | |
| [04:09:19] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [04:23:48] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has quit (Read error: Connection reset by peer) | |
| [04:25:26] | taylorr: | jpabq: ok, looks like I'm getting valid PAT/PMT info for back-to-back recordings... thanks |
| [04:25:59] | mad_enz (mad_enz!~Enz@173.206.174.151) has joined #mythtv | |
| [04:43:40] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds) | |
| [04:44:28] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:53:04] | mad_enz (mad_enz!~Enz@173.206.174.151) has quit (Read error: Connection reset by peer) | |
| [04:54:45] | mad_enz (mad_enz!~Enz@173.206.174.151) has joined #mythtv | |
| [04:58:26] | jhall_: | wow |
| [04:58:47] | jhall_: | somehow in my connect call, NetStream is being destroyed |
| [04:59:05] | jhall_: | What might call an object that is connecting to be destroyed? |
| [04:59:13] | jhall_: | That would certainly cause a segv |
| [05:12:17] | wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has quit (Ping timeout: 252 seconds) | |
| [05:27:44] | Kevin` (Kevin`!~kevin@etmalec.net) has quit (Remote host closed the connection) | |
| [05:27:52] | Kevin` (Kevin`!~kevin@etmalec.net) has joined #mythtv | |
| [06:22:44] | Goga777 (Goga777!~Goga777@95-30-39-181.broadband.corbina.ru) has quit (*.net *.split) | |
| [06:23:41] | Goga777 (Goga777!~Goga777@95-30-39-181.broadband.corbina.ru) has joined #mythtv | |
| [07:00:56] | SteveGoodey (SteveGoodey!~steve@86.144.3.137) has joined #mythtv | |
| [07:10:20] | SteveGoodey (SteveGoodey!~steve@86.144.3.137) has quit (Quit: Konversation terminated!) | |
| [07:39:06] | Cougar (Cougar!~cougar@2a03:5880:104:10:cec:656d:f6e0:a965) has quit (Ping timeout: 264 seconds) | |
| [07:50:35] | Cougar (Cougar!~cougar@2a03:5880:104:10:2045:8f19:ee2c:53ee) has joined #mythtv | |
| [08:34:59] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:e951:a95c:fde7:6929) has joined #mythtv | |
| [08:40:10] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:e951:a95c:fde7:6929) has quit (Read error: Connection reset by peer) | |
| [08:40:28] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:e951:a95c:fde7:6929) has joined #mythtv | |
| [09:00:05] | dekarl1 (dekarl1!~dekarl@p4FE84FD8.dip.t-dialin.net) has joined #mythtv | |
| [09:00:42] | Goga777 (Goga777!~Goga777@95-30-39-181.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [09:00:54] | dekarl (dekarl!~dekarl@p4FCEFADF.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [10:07:13] | mad_enz (mad_enz!~Enz@173.206.174.151) has quit (Ping timeout: 245 seconds) | |
| [10:08:49] | mad_enz (mad_enz!~Enz@173.206.174.151) has joined #mythtv | |
| [11:41:23] | henkpoley (henkpoley!~henkpoley@2001:980:1241:1:944b:11eb:93ad:c7ce) has joined #mythtv | |
| [11:41:26] | VManiac16 (VManiac16!~Unknown@69.4.155.83) has quit (Ping timeout: 255 seconds) | |
| [11:49:56] | poptix (poptix!poptix@poptix.net) has joined #mythtv | |
| [11:49:58] | poptix- (poptix-!poptix@poptix.net) has quit (Ping timeout: 240 seconds) | |
| [11:49:58] | Heikki_ (Heikki_!~heikki@94-76-207-56.static.as29550.net) has quit (Ping timeout: 240 seconds) | |
| [11:50:24] | Heikki_ (Heikki_!~heikki@94.76.207.56) has joined #mythtv | |
| [12:22:27] | henkpoley (henkpoley!~henkpoley@2001:980:1241:1:944b:11eb:93ad:c7ce) has quit (Remote host closed the connection) | |
| [12:33:46] | Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has joined #mythtv | |
| [12:36:05] | Sharky112065 is now known as Sharky-Sleep | |
| [12:36:17] | IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [12:37:53] | IReboot_ (IReboot_!~doug@99.234.145.236) has joined #mythtv | |
| [12:42:32] | Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has quit (Quit: Wolfgang2) | |
| [13:24:49] | kenni (kenni!~kenni@mythtv/developer/kenni) has quit (Read error: Connection reset by peer) | |
| [13:35:32] | wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has joined #mythtv | |
| [14:32:13] | MythBuild: | build #312 of master-debian-wheezy-64bit is complete: Failure [4failed git] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/312 |
| [14:36:18] | stuarta: | please ignore that |
| [14:41:05] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [14:57:14] | Goga777 (Goga777!~Goga777@95-30-39-181.broadband.corbina.ru) has joined #mythtv | |
| [15:09:23] | MythBuild: | build #313 of master-debian-wheezy-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/313 |
| [15:18:06] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has quit (Remote host closed the connection) | |
| [15:18:44] | MythBuild (MythBuild!~MythBuild@140.211.167.130) has joined #mythtv | |
| [15:47:31] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [16:14:55] | neufeld_AFK is now known as neufeld | |
| [16:23:50] | neufeld: | jpabq: OK, my observations with version 4 of the patch. I applied it to v0.25.1, and then built and replaced only libmythtv. The bug #11328 seems to be fixed by this patch. I'll run a few more recordings, including some back-to-back, but it looks good. My issue last night was that I applied the patch to v0.25.2 instead of v0.25.1. When applied to v0.25.2, it makes the HD-PVR fail, even when I do a full install |
| [16:23:50] | ** MythLogBot http://code.mythtv.org/trac/ticket/11328 ** | |
| [16:23:50] | neufeld: | from the 0.25.2 build (so it's not an interaction between 0.25.1 and 0.25.2 binaries/libraries). |
| [16:35:02] | MythBuild: | build #1704 of cppcheck-master is complete: Failure [4failed git] Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . /builds/1704 blamelist: Stuart Auchterlonie <stuarta@squashedfrog.net > |
| [16:36:50] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:41:17] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [16:54:32] | jpabq: | neufeld: while I will probably back-port to 0.26/fixes, I have no intention to back-port all the way to 0.25. That being said, I do have to wonder what changed between 0.25.1 and 0.25.2 that would cause a different behavior with this stuff. |
| [17:05:11] | neufeld: | jpabq: I think it's a patch offset issue, the patch program applied part of it to the wrong place (there was an offset notice, but I didn't investigate it at the time). I'll look it over, since the 0.25.1 library causes problems with my mythfrontend binary. |
| [17:06:30] | neufeld: | jpabq: I understand the backporting issue, I was pleasantly surprised that you went to all that effort to make a 0.25 version of the patch, and I thank you for that, it was an unexpected bonus. |
| [17:08:34] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [17:14:50] | MythBuild: | build #1705 of cppcheck-master is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . /builds/1705 |
| [17:21:11] | skd5aner: | jpabq: every hd-pvr recording I get has a glitch... could be from the STB, could be from the recorder- just saying, I don't know if I've ever had a completely glitch free one from the HD-PVR |
| [17:21:43] | jpabq: | skd5aner: yeah I know — you are a problem child ;-) |
| [17:29:26] | skd5aner: | well, true... |
| [17:29:58] | skd5aner: | but does anyone ever get 100% reliabilty with the HD-PVR? |
| [17:31:28] | jpabq: | skd5aner: My recordings are generally perfect, without any glitches at all. Only about once every few months does my STB get in a bad state which causes problems until I reboot it. |
| [17:31:44] | skd5aner: | I would almost expect that the HD-PVR would, by nature, almost need to be considered a device that could produce glitchy content at any point |
| [17:32:53] | jpabq: | Yup, that is why the HD-PVR "recorder" automatically re-starts if needed. |
| [17:33:27] | neufeld: | skd5aner: My recordings are almost always good. I get glitching often on one particular channel, I blame the provider or STB, not the HD-PVR. Barring that one channel, glitches appear only infrequently. I use TOSLink, fixed resolution set in the STB, and firmware version 0x15 |
| [17:34:30] | neufeld: | I also power-cycle it as soon as it's idle after it finishes a recording |
| [17:35:34] | stichnot (stichnot!~stichnot@216.239.45.73) has joined #mythtv | |
| [17:35:34] | stichnot (stichnot!~stichnot@216.239.45.73) has quit (Changing host) | |
| [17:35:35] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:36:07] | jpabq: | The HD-PVR is /very/ sensitive to "garbage in". It would be nice if it was a bit more tolerant. My STBs seems to be pretty good, so I feel lucky. |
| [17:37:03] | skd5aner: | jpabq: but, instead of blaming the STB (even if it is to blame) – ultiatemly, it's the nature of the device... |
| [17:38:04] | skd5aner: | so, a player that knows it is likely to encounter recordings from an HD-PVR should build in a bit a resiliency in handling content that /could/ be slightly corrupted |
| [17:38:12] | jhall_: | hi all |
| [17:38:21] | skd5aner: | instead of saying "well, the recording shouldn't be corrupt" |
| [17:38:31] | jhall_: | I am experiencing a slot problem with the NetStream class |
| [17:38:33] | jpabq: | skd5aner: good luck making that argument with the ffmpeg group ;-) |
| [17:38:38] | jhall_: | the one that is in libs/libmythtv/ |
| [17:38:52] | jhall_: | the other one I renamed because I was having object referencing problems |
| [17:38:56] | skd5aner: | jpabq: real world vs spec sheets :/ |
| [17:38:57] | stichnot: | skd5aner: My HD-PVR recordings never have a glitch, afaict. Once in a while mythcommflag segfaults on a recording (which may be from the use of CODEC_FLAG2_FAST, which I am testing out). Every month or two I have to power-cycle the HD-PVR. |
| [17:39:06] | jpabq: | jhall_: sorry, I have no experience with that part of the code. |
| [17:39:23] | jhall_: | in the .h file for netstream, it has a signal ReadyRead() defined |
| [17:39:34] | jhall_: | I have an object defined as well |
| [17:39:42] | jhall_: | however when I try to do the connect |
| [17:40:10] | skd5aner: | stichnot: amazingly, I no longer have to re-power the device once I finally replaced the faulty wallwart |
| [17:40:48] | jhall_: | connect(m_stream, SIGNAL(ReadyRead()), this, SLOT(ReadPending())); |
| [17:41:12] | jhall_: | an error log appears in the log that says NetStream::ReadyRead() does not exist |
| [17:41:21] | jpabq: | jhall_: danielk22 is probably the most familiar with that stuff, but stuartm might be able to help. I plan on getting more familiar with that stuff, but it will be a while yet before have the time. |
| [17:41:47] | jhall_: | / well |
| [17:41:55] | jhall_: | I am sure it is a simple thing |
| [17:42:17] | jhall_: | so if yo uhave a sec maybe you can just look? |
| [17:42:33] | jhall_: | not meaning to be a pest, but this has been way more frustrating htan I had ever hoped or dreamed. |
| [17:42:33] | stichnot: | skd5aner: wow. I suspect most of my resets come from some funky testing of the backend. |
| [17:44:09] | skd5aner: | stichnot: I was requiring resets on a daily basis near the ned |
| [17:44:10] | skd5aner: | end |
| [17:44:43] | skd5aner: | called Hauppauge, they sent me a new one for free – that was 6 months ago – only had to power cycle it maybe once or twice? |
| [17:44:46] | jpabq: | jhall_: okay. I am in the middle of something right now, but I will try to take a look in a little bit. |
| [17:44:55] | skd5aner: | Have to power cycle my STB more than that |
| [17:45:18] | jhall_: | thank you I appreciate it |
| [17:46:12] | taylorr: | jpabq: fyi, you v4 patch for 0.25 patches perfectly clean on the latest 0.25-fixes |
| [17:47:31] | taylorr: | I think there may have been some devicereadbuffer changes at some point during the 0.25-fixes branch... so maybe that could be something causing an issue |
| [17:48:58] | taylorr: | skd5aner, jpabq: I replaced the power supply for my primary hd-pvr with a 3A d-link one and I haven't had a single issue since... only time will tell |
| [17:49:51] | taylorr: | I'm not convinced that some of the random, infrequent problems aren't power supply problems |
| [17:50:23] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:e951:a95c:fde7:6929) has quit (Read error: Connection reset by peer) | |
| [17:53:05] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [17:55:03] | skd5aner: | I think the 0-byte recordings are almost certainly power supply issues |
| [17:55:14] | skd5aner: | not every time, but a key contributor |
| [17:59:11] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: meeting) | |
| [18:06:32] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has quit (Remote host closed the connection) | |
| [18:08:26] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [18:08:36] | dekarl1 (dekarl1!~dekarl@p4FE84FD8.dip.t-dialin.net) has quit (Read error: Operation timed out) | |
| [18:09:26] | resno (resno!~bryan@cpe-065-190-075-215.nc.res.rr.com) has left #mythtv () | |
| [18:13:44] | dekarl (dekarl!~dekarl@p4FCEEFA1.dip.t-dialin.net) has joined #mythtv | |
| [18:16:20] | skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has quit (Ping timeout: 248 seconds) | |
| [18:17:34] | skd5aner (skd5aner!~skd5aner@50-90-30-141.res.bhn.net) has joined #mythtv | |
| [18:21:19] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [18:32:05] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [18:33:53] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:35:16] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [18:38:16] | jhall_: | has anybody else noticed ustream penalizes IP addresses that connect for a long time? |
| [18:40:42] | nephyrin (nephyrin!~neph@nat/mozilla/x-tilcwoiafojvujec) has joined #mythtv | |
| [18:58:02] | Goga777 (Goga777!~Goga777@95-30-39-181.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [19:17:48] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [19:18:50] | steve__ (steve__!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [19:18:51] | natanojl_ (natanojl_!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [19:24:54] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (*.net *.split) | |
| [19:24:54] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has quit (*.net *.split) | |
| [19:24:54] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (*.net *.split) | |
| [19:43:28] | neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has quit (Quit: ERC Version 5.3 (IRC client for Emacs)) | |
| [19:55:28] | neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv | |
| [20:02:09] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [20:17:56] | steve__ is now known as Steve-Goodey | |
| [20:19:27] | peper03 (peper03!~richard@port-92-203-127-75.dynamic.qsc.de) has joined #mythtv | |
| [20:20:44] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has quit (Remote host closed the connection) | |
| [20:23:27] | IReboot_ (IReboot_!~doug@99.234.145.236) has quit (Remote host closed the connection) | |
| [20:28:30] | IReboot_ (IReboot_!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [20:33:45] | sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [20:33:45] | sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Client Quit) | |
| [20:34:18] | sl1ce (sl1ce!~johnathan@100.0.73.123) has quit (Ping timeout: 245 seconds) | |
| [20:35:10] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [20:55:43] | gigem: | Does anyone know if Jarod Wilson is still at RedHat? I've been having an lirc driver problem and sent him an email on Sunday to his redhat.com address, but haven't heard anything back. He could just be very busy, but in case he left RedHat, I'll resend to his personal email address. |
| [21:00:29] | rsiebert (rsiebert!~quassel@g226061013.adsl.alicedsl.de) has joined #mythtv | |
| [21:01:14] | Sharky-Sleep is now known as Sharky112065 | |
| [21:02:27] | stuartm: | I don't know, but I had noticed he'd been very quiet lately, no traffic (or none that I noticed) to the various mailing lists I see him on, no signoffs on kernel commits and no sign of him on IRC :/ |
| [21:03:32] | rsiebert_ (rsiebert_!~quassel@g225053103.adsl.alicedsl.de) has quit (Ping timeout: 252 seconds) | |
| [21:07:33] | stuartm: | stuarta: any chance you know the answer, or could answer that? ^^ I know you are in completely different departments (and continents) |
| [21:12:27] | jpabq: | LinkedIn still shows him at RedHat |
| [21:12:43] | stuarta: | gigem: stuartm he's still there, i can see him on the internal irc server |
| [21:13:01] | stuarta: | clearly being kernel maintainer is keeping him very busy |
| [21:16:28] | stuartm: | stuarta: thanks |
| [21:16:49] | joki (joki!~joki@p54864467.dip.t-dialin.net) has quit (Quit: c ya!) | |
| [21:20:14] | gigem: | stuarta: Thanks. I'll be patient then and keep trying to debug on my own in the meantime. |
| [21:20:31] | joki (joki!~joki@p54864467.dip.t-dialin.net) has joined #mythtv | |
| [21:22:05] | MythBuild (MythBuild!~MythBuild@140.211.167.130) has quit (Remote host closed the connection) | |
| [21:22:22] | MythBuild (MythBuild!~MythBuild@alcor.mythtv.org) has joined #mythtv | |
| [21:24:39] | stuarta: | gigem: you look hard enough, he's on freenode ;-) |
| [21:38:06] | gigem: | stuarta: If he's busy, I'd rather not pester him, at least while I still have few more straws to grasp at. |
| [21:38:48] | natanojl_ (natanojl_!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds) | |
| [21:42:59] | gigem: | Regarding my lirc problem, is anyone successfully using the mceusb driver (with or without lirc) from a somewhat recent kernel (e.g. >= 3.2) and be willing to share some kernel debug logs? My receiver acts like it's working properly in that no out right errors are reported, but nothing gets decoded properly. If I know what "good data" looks like, I might be able to figure out what's going wrong. |
| [21:47:53] | peper03 (peper03!~richard@port-92-203-127-75.dynamic.qsc.de) has quit (Read error: Connection reset by peer) | |
| [21:49:53] | superm1: | gigem: sure i've got mine using lirc on 3.2 working, what logs are you looking for? |
| [22:02:36] | gigem: | superm1: That would be great. The simplest thing to do is the following. Unplug the receiver. Run 'echo 1 > /sys/module/mceusb/parameters/debug'. Plug the receiver back in. Briefly press a button on the remote. Then email me the recent part of your kernel log. The ir-core and decoder logs might also be useful, but those require enabling the DYNAMIC_DEBUG kernel option which typically isn't enabled and |
| [22:02:39] | gigem: | would require a kernel recompile. |
| [22:04:55] | superm1: | gigem: okay here you go, this is with pressing a few buttons: http://paste.ubuntu.com/1640912/ |
| [22:05:16] | bas-t: | gigem: I'm using the mceusb driver with lirc with a workaround to my full satisfaction. It involves sed -i '$ i\ |
| [22:05:16] | bas-t: | modprobe -r ir_rc6_decoder' /etc/rc.local |
| [22:05:16] | bas-t: | But if you don't mind that, I can show you the rest of the details |
| [22:06:48] | Steve_Goodey (Steve_Goodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:09:18] | gigem: | superm1: Thanks. |
| [22:09:56] | superm1: | gigem: hmm um suddenly mine isn't working properly either, not sure you should trust that |
| [22:10:19] | superm1: | did you recently upgrade a kernel and something broke? i hadn't rebooted in a bit since some kernel upgrades |
| [22:10:27] | gigem: | bas-t: I'll take all samples. Thanks. BTW, if you only want the lirc decoder to be used (iow, not the rc6 nor any other decoder), you can run 'ir-keytable -p lirc'. |
| [22:14:49] | gigem: | superm1: No, I haven't used this receiver and remote in a very long time. I know the remote works — it's compatible with the imon receiver in my main frontend and works there. I now want to use this receiver with another frontend and am having the problems. I'm right now building some 2.6.3x kernels from shortly after Jarod added the ir code to Linus' kernel. I see in the mceusb driver git log that it |
| [22:14:52] | gigem: | was later updated with help from Microsoft. I'm wondering if that "help" didn't break non-MS branded stuff. |
| [22:15:54] | jams: | gigem i have it working on 3.6..but blasting/transmitting has been broken for some time |
| [22:16:12] | jams: | will have the debug stuff for you shortly |
| [22:19:06] | gigem: | jams: Thanks. |
| [22:22:14] | jams: | gigem, whats the email address? |
| [22:22:51] | bas-t: | gigem: http://paste.ubuntu.com/1640983/ |
| [22:32:44] | jams: | http://paste.ubuntu.com/1641041/ |
| [22:34:04] | gigem: | bas-t, jams: Thanks again, guys. |
| [22:46:58] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat) | |
| [22:52:22] | skd5aner: | Since most of the devs don't subscribe to the -users ml, I thought it might be nice to share this here: http://www.gossamer-threads.com/lists/mythtv/users/538841 |
| [23:01:01] | danielk221 (danielk221!~danielk@exchange.wgen.net) has left #mythtv () | |
| [23:19:30] | stichnot: | Devs don't subscribe to the -users list? How do they keep their finger on the pulse of how bad Live TV is? |
| [23:20:05] | nephyrin: | (oh man it's so bad) |
| [23:21:01] | nephyrin: | I tracked some of the issues down to some ancient code that was assuming no video would have a bitrate of >512k |
| [23:21:26] | nephyrin: | But my cable company is fond of 20mbit mpeg2 streams sooo |
| [23:21:27] | stichnot: | Really? What code is that? |
| [23:22:15] | nephyrin: | stichnot: https://github.com/MythTV/mythtv/blob/HEAD/my . . . fer.cpp#L362 |
| [23:24:09] | nephyrin: | Another part of the issue is constant fsyncing files then wondering why the HDD can't keep up |
| [23:24:33] | stichnot: | nephyrin: I think that code says that if the estimated bitrate is >18Mb/s, then fetch from the backend in 512KB chunks. And it should be the same for recordings and live TV. |
| [23:26:01] | nephyrin: | stichnot: Is estbitrate KiB here? I didn't look into the sanity of this but I recall thinking that pseudo array was outdated |
| [23:26:06] | stichnot: | Is the fsync behavior different between live TV and prerecorded? |
| [23:26:58] | nephyrin: | stichnot: I'm not sure. Apparently some systems do poorly without fsyncing because kernel decides to do a flush at inopportune times and blocks reads for half seconds |
| [23:27:16] | nephyrin: | But I don't think that's an issue with modern kernels |
| [23:27:26] | stichnot: | nephyrin: Well, line 382 multiplies by 1000, so I'm assuming KiB |
| [23:27:58] | nephyrin: | I just got an hdhr tuner so I was digging into this like a week ago, I've not actually *fixed* anything though :-P |
| [23:28:49] | nephyrin: | But the combination of network tuner + 20mbit channels just murders liveTV |
| [23:29:09] | stichnot: | One issue I know about with live TV is the LiveTVChain management, which has race conditions which can leave you locked into the "dummy" recording until things time out. |
| [23:29:38] | stichnot: | Another issue seems to be a segfault when re-initializing the OSD during a channel change, which is puzzling. |
| [23:30:00] | nephyrin: | stichnot: I've not had any major stability issues, just stuttering. Oh god the stuttering. |
| [23:30:48] | stichnot: | nephyrin: try pausing for ~5 seconds then resuming, and see if that fixes the stuttering. |
| [23:31:54] | stichnot: | There is definitely something weird going on with live TV and in-progress recordings, with respect to stuttering. It's on my list. |
| [23:34:42] | nephyrin: | stichnot: If I achieve any significant improvements Ill be sure to put in a pull request |
| [23:34:44] | stichnot: | The thing I'd like to see with live TV is to let the backend continue recording for a minute or two after the frontend quits live TV, and give the frontend a chance to rejoin the LiveTVChain. Frontend failures, crashes, and accidental user exits would then become just minor annoyances. |
| [23:35:19] | stichnot: | nephyrin: that would be good, thanks. |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.