| Monday, February 7th, 2011, 00:41 UTC | ||
| [00:41:21] | Valen (Valen!~Valen@ppp121-44-129-24.lns20.syd7.internode.on.net) has joined #mythtv | |
| [00:42:22] | Valen: | having some difficulty with a tuner that seems a bit flaky, is there anything "off the shelf" that will do something if it notices a recording is failing? |
| [00:42:29] | Valen: | run script, send email something? |
| [01:05:12] | wagnerrp: | nope |
| [01:30:13] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [01:30:39] | davide_ (davide_!~david@host137.12.intrusion.com) has joined #mythtv | |
| [01:30:40] | davide_ (davide_!~david@host137.12.intrusion.com) has quit (Changing host) | |
| [01:30:40] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [01:32:50] | sphery: | Valen: hop into #mythtv-users and you'll likely get some suggestions |
| [01:32:59] | Valen: | thanks |
| [02:07:49] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [02:10:46] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 265 seconds) | |
| [02:18:17] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [02:31:22] | andreax1 (andreax1!~andreaz@p57B91EDB.dip.t-dialin.net) has joined #mythtv | |
| [02:33:14] | andreax (andreax!~andreaz@p57B926D7.dip.t-dialin.net) has quit (Ping timeout: 240 seconds) | |
| [02:55:16] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [02:58:37] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 265 seconds) | |
| [03:07:06] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [03:09:44] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds) | |
| [03:34:25] | elmojo: | abqjp: nice to see you finally got #9410 working completely – did it improve HD-PVR at all? |
| [03:35:21] | elmojo: | jpabq: ^^^ what's your preferred name? |
| [04:02:56] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [04:05:47] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 255 seconds) | |
| [04:09:30] | j-rod|afk (j-rod|afk!~jarod@static-72-93-233-2.bstnma.fios.verizon.net) has quit (Read error: Operation timed out) | |
| [04:11:16] | abqjp: | elmojo, Doesn't really make any difference with HD-PVR material that the user can tell. The keyframe offsets may be a tiny bit more accurate... |
| [04:13:11] | abqjp: | jpabq is my primary, but my IRC will sometimes switch to the backup of abqjp after a network hick-up. Meanwhile, I use abqjp on my laptop since I have not figured out how to make ZNC work with multiple clients but the same nick. |
| [04:15:32] | j-rod|afk (j-rod|afk!~jarod@static-72-93-233-2.bstnma.fios.verizon.net) has joined #mythtv | |
| [04:15:48] | elmojo: | abqjp: cool, thanks for taking that ticket on |
| [04:18:50] | elmojo: | heh, just looked at the final commit and that evolved into a quite a massive change :) |
| [04:29:42] | Valen (Valen!~Valen@ppp121-44-129-24.lns20.syd7.internode.on.net) has quit (Quit: Leaving.) | |
| [04:45:21] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [04:45:51] | Chutt (Chutt!~ijr@cpe-24-166-52-87.neo.res.rr.com) has quit (Ping timeout: 240 seconds) | |
| [04:47:51] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds) | |
| [04:56:33] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [04:59:27] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 265 seconds) | |
| [05:01:10] | Chutt (Chutt!~ijr@cpe-24-166-52-87.neo.res.rr.com) has joined #mythtv | |
| [05:33:30] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [05:36:41] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 264 seconds) | |
| [06:03:39] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds) | |
| [06:09:47] | andreax1 (andreax1!~andreaz@p57B91EDB.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [06:45:25] | GTswagger (GTswagger!~gts@unaffiliated/gtswagger) has joined #mythtv | |
| [06:46:14] | GTswagger: | Just upgraded hardware ... getting no audio on MythTV. Audio works on everything else. Not using Pulse, using ALSA:Default:CARD:Intel (which is correct) |
| [06:46:24] | GTswagger: | only clue when running mythfrontend -v audio |
| [06:46:43] | kormoc: | GTswagger, #mythtv-users |
| [06:47:04] | GTswagger: | ahhhhhh /topic ftw |
| [06:47:06] | GTswagger: | sorry about that |
| [06:47:13] | GTswagger (GTswagger!~gts@unaffiliated/gtswagger) has left #mythtv () | |
| [06:51:10] | vontrapp (vontrapp!~vontrapp@50.8.106.170) has quit (Ping timeout: 240 seconds) | |
| [06:57:49] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [07:15:39] | andreax (andreax!~Andreaz@tmo-109-33.customers.d1-online.com) has joined #mythtv | |
| [07:43:47] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 265 seconds) | |
| [08:07:43] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [08:18:27] | jya (jya!~jya@mythtv/developer/jya) has quit (Quit: jya) | |
| [09:06:55] | jya (jya!~jya@60-242-40-141.static.tpgi.com.au) has joined #mythtv | |
| [09:06:55] | jya (jya!~jya@60-242-40-141.static.tpgi.com.au) has quit (Changing host) | |
| [09:06:55] | jya (jya!~jya@mythtv/developer/jya) has joined #mythtv | |
| [09:20:20] | andreax (andreax!~Andreaz@tmo-109-33.customers.d1-online.com) has quit (Ping timeout: 260 seconds) | |
| [09:25:41] | jamesba (jamesba!~jamesba@gateb.kw.bbc.co.uk) has joined #mythtv | |
| [09:52:58] | kormoc is now known as kormoc_afk | |
| [10:03:09] | kth (kth!~kth@dyndsl-085-016-235-033.ewe-ip-backbone.de) has joined #mythtv | |
| [10:04:20] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [10:35:59] | MaverickTech (MaverickTech!~MaverickT@CPE-61-9-196-185.static.nsw.bigpond.net.au) has joined #mythtv | |
| [10:35:59] | MaverickTech (MaverickTech!~MaverickT@CPE-61-9-196-185.static.nsw.bigpond.net.au) has quit (Read error: Connection reset by peer) | |
| [11:05:02] | mike|3 (mike|3!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [11:05:52] | mike (mike!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [11:06:18] | mike is now known as Guest28654 | |
| [12:04:33] | rooaus1 (rooaus1!~cameron@ppp59-167-126-229.static.internode.on.net) has quit (Ping timeout: 276 seconds) | |
| [12:14:10] | nutron-home (nutron-home!~dserban@S0106001346beb5f3.ok.shawcable.net) has quit (Ping timeout: 240 seconds) | |
| [12:18:41] | rooaus (rooaus!~cameron@ppp59-167-126-229.static.internode.on.net) has joined #mythtv | |
| [12:27:03] | MaverickTech (MaverickTech!~MaverickT@CPE-61-9-196-185.static.nsw.bigpond.net.au) has joined #mythtv | |
| [12:29:19] | gigem_ (gigem_!~david@host137.12.intrusion.com) has joined #mythtv | |
| [12:29:19] | gigem_ (gigem_!~david@host137.12.intrusion.com) has quit (Changing host) | |
| [12:29:19] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [12:30:16] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Ping timeout: 240 seconds) | |
| [12:59:48] | MaverickTech (MaverickTech!~MaverickT@CPE-61-9-196-185.static.nsw.bigpond.net.au) has quit (Ping timeout: 248 seconds) | |
| [13:23:49] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (*.net *.split) | |
| [13:41:27] | andreax (andreax!~Andreaz@tmo-104-178.customers.d1-online.com) has joined #mythtv | |
| [13:42:33] | cocoa117 (cocoa117!~cocoa117@wk-29-215.guest.rdg.ac.uk) has joined #mythtv | |
| [13:55:57] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [14:05:35] | kth (kth!~kth@dyndsl-085-016-235-033.ewe-ip-backbone.de) has quit (Quit: Leaving.) | |
| [14:34:36] | j-rod|afk is now known as j-rod | |
| [14:44:40] | andreax (andreax!~Andreaz@tmo-104-178.customers.d1-online.com) has quit (Ping timeout: 260 seconds) | |
| [14:58:14] | vontrapp (vontrapp!~vontrapp@50.8.106.170) has joined #mythtv | |
| [15:17:22] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv | |
| [15:33:19] | hobiga (hobiga!~hobiga@173.210.255.195) has joined #mythtv | |
| [15:44:21] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has joined #mythtv | |
| [15:51:45] | vontrapp (vontrapp!~vontrapp@50.8.106.170) has quit (Ping timeout: 260 seconds) | |
| [16:00:46] | Jordack: | Marco! |
| [16:02:24] | andreax (andreax!~andreaz@p57B91EDB.dip.t-dialin.net) has joined #mythtv | |
| [16:16:56] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [16:20:37] | [Jordack] ([Jordack]!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv | |
| [16:21:32] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 240 seconds) | |
| [16:21:56] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit (Ping timeout: 240 seconds) | |
| [16:23:13] | andreax (andreax!~andreaz@p57B91EDB.dip.t-dialin.net) has quit (Quit: Leaving.) | |
| [16:28:20] | vontrapp (vontrapp!~vontrapp@50.8.106.170) has joined #mythtv | |
| [16:43:17] | Kunalagon (Kunalagon!~Kunalagon@212.200.241.117) has joined #mythtv | |
| [16:45:48] | [Jordack] is now known as Jordack | |
| [17:06:20] | nutron-home (nutron-home!~dserban@S0106001346beb5f3.ok.shawcable.net) has joined #mythtv | |
| [17:15:19] | andreax (andreax!~andreaz@p57B91EDB.dip.t-dialin.net) has joined #mythtv | |
| [17:17:44] | andreax (andreax!~andreaz@p57B91EDB.dip.t-dialin.net) has quit (Client Quit) | |
| [17:19:49] | andreax (andreax!~andreaz@p57B91EDB.dip.t-dialin.net) has joined #mythtv | |
| [17:23:14] | jamesba (jamesba!~jamesba@gateb.kw.bbc.co.uk) has quit (Quit: Leaving) | |
| [17:34:24] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Ping timeout: 250 seconds) | |
| [17:42:24] | Steve_Goodey (Steve_Goodey!~steve@host86-148-198-92.range86-148.btcentralplus.com) has joined #mythtv | |
| [17:46:38] | cocoa117 (cocoa117!~cocoa117@wk-29-215.guest.rdg.ac.uk) has quit (Quit: Leaving) | |
| [18:36:13] | sphery: | elmojo: I admit to having no clue about any of the code involved (player, ringbuffer, etc.), but the values just seem to be a little too-coincidental, so I thought I'd mention it. Anyway, I was wondering if you think your uncommitted short-socket-timeout patch that raises the timeout to 10s may be required due to https://github.com/MythTV/mythtv/commit/0651d1c9 (i.e. with the 10s kLiveTVOpenTimeout, if we have a socket timeout less than 10s, ... |
| [18:36:20] | sphery: | ... we may give up before Live TV ringbuffer open gives up, at least for remote Live TV recordings)? If not, feel free to ignore me. |
| [18:44:08] | stuartm: | Beirdo: there's two problems with making committing devs responsible for fixing build issues on other platforms – 1) Invariably we'll see multiple followup commits as people guess at a fixes which they cannot test 2) We'll definitely see the sort if half-arsed fixes that may fix compilation but leave the code in a bad state or worse horribly, even dangerously broken (strewing the code with ifdefs or commenting out previously working windows/osx |
| [18:44:10] | stuartm: | code entirely) |
| [18:45:08] | Beirdo: | yeah, but responsibility can include working with others to get the right fix too, but if I put in code, I shouldn't expect others to spearhead fixing my code |
| [18:45:45] | Beirdo: | if we are gonna be multi-platform, these are issues we need to work through |
| [18:46:21] | Beirdo: | I just don't wanna see the commit-and-forget mentality |
| [18:46:27] | Beirdo: | how we work around that, not sure :) |
| [18:49:48] | Beirdo: | I mean, almost all of us have done it to each other in the past (unintentionally, no doubt) and it has often been an issue |
| [18:49:56] | stuartm: | I favour the 'necessity is the mother of invention' philosophy, if everyone expects me to fix the windows build then they'll be waiting longer for a fix because I wouldn't know where to start – the guy with a broken build has both the access to the platform and the motivation to come up with a proper fix ASAP |
| [18:50:45] | Beirdo: | now that we have a tool that can alert us to problems, hopefully it should diminish, but the expectation should be there that we TRY to keep all the other platforms not-busted. |
| [18:50:56] | kormoc_afk is now known as kormoc | |
| [18:52:30] | Beirdo: | right, but I can remember when I busted the Windows build, just how irritating it was for iamlindoro to go and fix up my crap. Now, it may not always be possible to avoid, but as much as we can, we should attempt to not put work on others that can be avoided by us taking more care, etc. |
| [18:52:46] | Beirdo: | irritating for him more than for me :) |
| [18:54:00] | Beirdo: | an ideal solution, of course... would be to have buildhosts people could remotely log into... |
| [18:54:05] | Beirdo: | but we don't have that |
| [18:54:29] | Beirdo: | although with the cross-compiling Win32 script, the need for that for Win32 builds is decreased significantly |
| [18:58:10] | stuartm: | well there's a difference between compiling and working, simply attempting to make the win32 build compile won't mean that it works well, if at all – not sure which is better, a build which constantly crashes or one which doesn't compile |
| [19:00:54] | stuarta: | evening |
| [19:02:20] | Beirdo: | true enough. |
| [19:03:01] | Beirdo: | evening, sir |
| [19:03:35] | Beirdo: | I just don't like to see us committing stuff and then pretending we don't need to at least help with fixing what it broke |
| [19:07:27] | stuartm: | Beirdo: neither do I, if someone asked me for help with fixing something I just broke I would always give them the time |
| [19:08:22] | Beirdo: | right. I just would like to see the expectation for that be up front. |
| [19:08:23] | stuartm: | what I can't see working well is the committing dev trying to find someone in the Win32/OSX community willing to help them fix the issue in a timely manner |
| [19:08:33] | Beirdo: | ahh |
| [19:08:47] | Beirdo: | well, more of us will be OSX-capable, but good point |
| [19:09:20] | Beirdo: | if we don't have enough of a community there, it lends credence to the question: Why are we supporting it without enough developers to do so? |
| [19:09:59] | Beirdo: | I'm working on the assumption that we are keeping the non-Linux platforms |
| [19:10:13] | Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-57-109.hr.hr.cox.net) has joined #mythtv | |
| [19:10:13] | Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-57-109.hr.hr.cox.net) has quit (Changing host) | |
| [19:10:13] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [19:10:29] | stuartm: | if I'm unable to commit or work on anything else because I can't get someone to test a fix or answer a question (which is frequently the case, even with linux patches) then I'm rapidly going to become demotivated myself |
| [19:10:39] | Beirdo: | bringing them iteratively more into the mainstream in the dev community is the best way. |
| [19:11:01] | Beirdo: | well, that's always the truth, isn't it. |
| [19:11:33] | Beirdo: | it's rather demotivating not to have feedback on patches, etc. |
| [19:12:54] | stuartm: | Beirdo: we do have sufficient interest in those platforms, but very few skilled and motivated individuals actively working on those platforms, a month long delay on a critical fix is nothing for the Windows contributors but it's a different story for the linux devs |
| [19:13:12] | Beirdo: | true. |
| [19:13:26] | stuarta: | look at it as a learning exercise for us |
| [19:13:50] | stuarta: | i certainly am using it as a way of learning howto program on those alternative platforms |
| [19:14:02] | Beirdo: | hehe |
| [19:14:12] | Beirdo: | how's the OSX stuff coming, stuarta? |
| [19:14:20] | stuarta: | bah.... |
| [19:14:30] | stuarta: | great in my head |
| [19:14:44] | stuarta: | in practice, i've not spent a second on it |
| [19:14:48] | Beirdo: | heh. Been there... |
| [19:14:53] | stuartm: | I'm more than happy to continue supporting OSX/Windows, even BSD, but not to the detriment of linux development, if we can maintain those ports without slowing or hindering the latter then I'm all for it |
| [19:14:56] | stuarta: | but wifey is watching her trash afeter dinner |
| [19:15:03] | stuarta: | so i'll do battle with the mack |
| [19:15:41] | Beirdo: | stuartm: that's my feeling too, but I think we should still be aware of them... in my mind, mythtv still is primarily a Linux app |
| [19:16:24] | stuartm: | stuarta: it would be interesting to learn something about Windows/OSX, but that's more difficult without access to the hardware/software (cue an offer from someone with deep pockets to buy OSX/Windows laptops for the developers) |
| [19:16:35] | Beirdo: | and I think Nigel, et al, who support the other platforms would likely appreciate us being more careful not to create unnecessary work for them. |
| [19:17:03] | stuarta: | well for my sins i have had a windows desktop for years, although mainly dual boot and thus 99% linux |
| [19:17:06] | stuarta: | biab |
| [19:17:07] | stuarta: | wifer calls |
| [19:17:11] | stuarta: | wifey |
| [19:17:17] | Beirdo: | heh, seeya |
| [19:17:47] | stuarta: | back already |
| [19:18:06] | stuarta: | and i bought the mac because i could run mythtv on it |
| [19:18:12] | Beirdo: | me too. |
| [19:18:21] | stuarta: | i don't actually use it for anything else... |
| [19:18:29] | Beirdo: | I still haven't gotten even as far as you though. (Macbook) |
| [19:18:47] | stuarta: | it was my primary prod frontend 2yrs ago |
| [19:18:51] | Beirdo: | my intention is to set it up for test compile/frontend use |
| [19:19:54] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [19:22:40] | ** stuarta wanders off for dinner ** | |
| [19:25:50] | nutron-home (nutron-home!~dserban@S0106001346beb5f3.ok.shawcable.net) has quit (Ping timeout: 240 seconds) | |
| [19:31:04] | Mousey (Mousey!~wtfisme@ross154.net) has joined #mythtv | |
| [19:55:29] | elmojo: | sphery: So mythbackend now uses the 10 sec timeout to establish the ringbuffer – I'm not sure if the socket on the frontend gets opened in parallel or not – I would think it does so your reasoning to ups the short socket timeout would complement the change correctly |
| [19:56:12] | elmojo: | I just haven't felt compelled to commit the change because I agree with Daniel that we need to preferably fix the underlying issue |
| [19:58:35] | elmojo: | unfortunately the latest ticket I looked into the data never arrives to the frontend at all – there must be some type of race condition on the tear down of the old ringbuffer, creation of the new ringbuffer and creation the actual recording file |
| [19:59:02] | elmojo: | the problem is gnome42 is the only person who took the time to understand that code and he fixed a good number of issues with it |
| [20:09:01] | rigel (rigel!~yourmom@c-68-34-78-124.hsd1.md.comcast.net) has joined #mythtv | |
| [20:09:09] | rigel (rigel!~yourmom@c-68-34-78-124.hsd1.md.comcast.net) has left #mythtv () | |
| [20:31:02] | ** iamlindoro wonders if jannau misses the old days of simple mythtv arguments yet ;) ** | |
| [20:37:17] | elmojo: | [27420] |
| [20:37:17] | MythLogBot: | SVN 27420: (branch master) https://github.com/MythTV/mythtv/commit/3958daf4 |
| [20:38:02] | elmojo: | was that the last SVN commit to trunk? |
| [20:40:56] | iamlindoro: | date seems about right |
| [20:43:57] | stuartm: | hmm, I've about a dozen recordings here which are listed as being in the LiveTV group but which don't appear in Watch Recordings, some of them date back to early last year but they've not been expired |
| [20:45:29] | stuartm: | seems like they might be excluded from the list because they have filesize of zero – but that prevents them from ever being deleted |
| [20:46:24] | stuartm: | nope, that's not the link, only half have a filesize of zero |
| [20:48:34] | stuartm: | ah-hah, they all have deletepending == 1 but they were never deleted |
| [20:50:28] | stuartm: | ooh, that's a nasty bug, something like 25GB of space permanently lost to recordings which cannot be seen or deleted from the UI |
| [20:50:42] | Captain_Murdoch: | backend shutdown while they were marked that way? I thought we had a housekeeping job to pickup things like that but could be mistaken. |
| [20:51:48] | stuartm: | Captain_Murdoch: can't say how they came to be in the state, most recent examples are from the beginning of Jan and I can't remember back that far |
| [20:52:19] | stuartm: | they aren't all LiveTV recordings either, just the majority |
| [20:52:27] | stuartm: | 23 in total |
| [20:52:45] | stuartm: | SELECT title, basename, filesize FROM recorded WHERE deletepending=1; |
| [20:52:55] | stuartm: | if anyone else is interested in checking their database |
| [20:54:03] | Captain_Murdoch: | none here, but I'm still on older code. |
| [20:54:06] | iamlindoro: | I see, to have a couple too |
| [20:54:09] | iamlindoro: | er seem |
| [20:54:44] | iamlindoro: | just a few (because I only ever use live to test configuration, and only every once in a long while) |
| [20:54:55] | sphery: | elmojo: [27421] seems to indicate that, yes, 420 was the last :) ... As far as the timeout, is it possible that changing the kLiveTVOpenTimeout to 7s (same as short socket timeout) might help live tv just by virtue of equivalent expectations in the code? :) |
| [20:54:55] | MythLogBot: | No match for SVN revision 27421 |
| [20:54:58] | iamlindoro: | All from September 2010 |
| [20:55:42] | stuartm: | Captain_Murdoch: well the earliest examples date from April last year, so it's a long term bug |
| [20:56:08] | Captain_Murdoch: | do you guys think we could benefit from one or two Dell 6650 servers with 16GB of RAM each. these are older Dells with four single-core 32-bit Xeon MP 2.0Ghz processors, RAID, DRAC, and potentially a few 36GB or 73GB drives in each. |
| [20:56:37] | stuartm: | deleting them all now it's strange, as though I've got slow deletes enabled, they are disappearing from the filesystem but very slowly |
| [20:56:48] | Captain_Murdoch: | stuartm, I'm on older code than that in production. although the only thing preventing me from upgrading to latest 0.24-fixes now is to get LIRC working with my old serial based remotes on Fedora 14. |
| [20:58:39] | sphery: | I'm on latest 0.24-fixes (but only since Friday night--though I've deleted several shows since then, and another system I maintain has used Live TV in that time), with slow deletes enabled on ext3 file systems, and I don't have any deletepending recordings. |
| [21:04:50] | Beirdo: | Captain_Murdoch: what would ya wanna do with the servers? |
| [21:05:04] | stuartm: | it's probably as Captain_Murdoch said, exiting the backend before it's managed to delete the files – it seems to queue them up and delete sequentially so if you delete enough files and then exit the backend it's likely to cause the issue |
| [21:05:58] | Captain_Murdoch: | Beirdo, I don't know. just have a few that might be available and was wondering if I should try to snag them if we had a use. |
| [21:06:24] | Beirdo: | K. I guess we can consider it... ping xris in case he has wise ideas :) |
| [21:06:34] | stuartm: | Captain_Murdoch: I've considered that we might want dedicated servers under our direct control for build slaves, but there are probably other uses for additional hardware |
| [21:06:57] | sphery: | stuartm: with slow deletes enabled, it does the delete immediately (with files open), so if you're not using slow deletes, that would make sense--the "normal" deletes don't actually happen until any previous deletes complete... |
| [21:07:20] | sphery: | i.e. would explain why I've never seen the issue (since I always use slow deletes) |
| [21:07:38] | Beirdo: | yeah, one for a 32-bit build server might be not a bad idea |
| [21:07:41] | Captain_Murdoch: | not sure how they compare to our current one, or where we could host them, but I might be be able to snag up to three with that config if it was for the Foundation. |
| [21:07:58] | stuartm: | sphery: yeah, I thought it would be non-blocking, i.e. it wouldn't wait for the file to be deleted before deleting the next |
| [21:08:01] | Beirdo: | our current 32-bit build slave is a xen domU |
| [21:08:09] | Captain_Murdoch: | sphery, ditto here, slow deletes even if I don't absolutely need them. |
| [21:08:39] | stuartm: | since I reguarly restart this backend to test new patches etc, I'm more likely to interrupt a series of deletions |
| [21:09:13] | Beirdo: | and having it available for remote testing could be useful... too bad we don't have an OSX host we could stick in there somewhere for all of us to test-compile live on |
| [21:09:18] | Captain_Murdoch: | we need a deletepending cleanup in the housekeeper. |
| [21:09:19] | stuartm: | so what we need is for the backend to reload the list of 'deletepending' recordings and resume deletion when it's started |
| [21:09:35] | sphery: | we could easily add a check for deletepending on restart? (Seems doing it in a housekeeper job would be more complex--as we'd have to figure out if they're currently being deleted) |
| [21:09:46] | stuartm: | sphery: snap |
| [21:10:14] | Captain_Murdoch: | sphery, just check the timestamp col in recorded table. |
| [21:10:25] | sphery: | that makes sense |
| [21:10:34] | Captain_Murdoch: | just because we're restarting doesn't mean that a slave is still up and could be deleting something. |
| [21:10:42] | sphery: | would be easier to integrate that way... if timestamp > 1d, just re-delete? |
| [21:10:48] | Captain_Murdoch: | sphery, yeah. |
| [21:11:14] | sphery: | want me to throw together a patch for that? Should have some time after I finish upgrading a couple systems, here |
| [21:11:20] | stuarta: | right, lets see if i can actually get something done now.... |
| [21:11:38] | stuartm: | well ... 1 day is a little long, if we were auto-expiring to free up required space then we'll just end up deleting something else instead, something which didn't need to die |
| [21:11:53] | stuartm: | I don't actually live on the edge like that, but many users do |
| [21:13:41] | sphery: | stuartm: have the expirer prefer deletepending=1? |
| [21:13:51] | Captain_Murdoch: | housekeeper is only designed to run once a day I believe, so it would need modifying to run more frequently if we did it that way. |
| [21:13:59] | stuartm: | sphery: I'd be grateful if you did want to work on it, one less thing to worry about |
| [21:15:21] | Captain_Murdoch: | maybe autoexpirer just cleans up old entries. if lastmodified > 2 hours re-delete. probably should keep track of them though, if we can't delete the second time, we should reset deletepending back to 0. |
| [21:15:28] | stuartm: | sphery: auto-expirer should definitely give priority to files we've already scheduled for deletion, but I don't know how that would work with slave backends ... unless we stick entries in the inuseprograms table when queing for deletion |
| [21:16:16] | vontrapp (vontrapp!~vontrapp@50.8.106.170) has quit (Read error: No route to host) | |
| [21:16:57] | sphery: | that part will be easier with recordedfile schema since we'll know where each file lives, but we could always add code to the expirer, now, to check for deletepending=1 + autoexpire=1, then check location for each recording before doing normal autoexpire-queue processing |
| [21:17:38] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Ping timeout: 240 seconds) | |
| [21:18:43] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [21:21:01] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit (Quit: The 80's Called they want the word "Rad" back.) | |
| [21:31:48] | elmojo: | how do you tell if you have files that aren't listed in the recording group but should be deleteed? |
| [21:34:20] | wagnerrp: | like, orphaned files? |
| [21:38:43] | elmojo: | yes |
| [21:43:14] | stuartm: | elmojo: well specifically for the case I discovered, running the following query should display any orphaned recordings – "SELECT title, basename, filesize FROM recorded WHERE deletepending=1;" |
| [21:43:32] | elmojo: | cool, thanks |
| [21:43:47] | stuartm: | elmojo: but if you mean recordings with no record in the database there is a script in contrib, myth.find_orphans.pl iirc |
| [21:46:37] | sphery: | elmojo: actually, for finding orphaned recording metadata or orphaned recording files, it's now find_orphans.py ( http://www.mythtv.org/wiki/Find_orphans.py ), now (downloadable by running mythwikiscripts, as at http://www.mythtv.org/wiki/Category:Scripts ) . the legacy, unmaintained, broken, myth.find_orphans.pl has been retired. |
| [21:47:11] | jmartens1 (jmartens1!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [21:47:42] | sphery: | and, thanks to wagnerrp, the new one actually finds orphans on any backend and automatically deteremines necessary configuration--meaning you can't accidentally delete all your recordings by passing the wrong command-line args :) |
| [21:48:03] | sphery: | (it checks across the network--versus local only) |
| [21:49:14] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Ping timeout: 240 seconds) | |
| [21:50:39] | stuartm: | but if you do need to cleanup you have to do it manually |
| [21:51:26] | andreax (andreax!~andreaz@p57B91EDB.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [21:53:24] | sphery: | stuartm: it will now delete files or metadata for you |
| [21:54:17] | stuartm: | sphery: ok, that's new |
| [21:54:21] | sphery: | just doesn't attempt to add any fake recording records into the db, so if you have orphaned files and you want to play them, you can put them in MythVideo |
| [21:54:40] | stuartm: | fwiw, myth.find_orphans.pl will check and double check before deleting |
| [21:55:03] | stuartm: | or at least the version in the wiki will |
| [21:58:17] | Kunalagon (Kunalagon!~Kunalagon@212.200.241.117) has quit (Remote host closed the connection) | |
| [22:03:02] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [22:12:19] | elmojo: | sphery: one important fact that gets overlooked alot when debugging LiveTV problems with remote FE is that the clocks need to be synchronized – for instance, if the remote FE's clock was ahead of the backend then when it was time to switch the backend would not have even created the file yet |
| [22:15:41] | jmartens1 (jmartens1!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Quit: Leaving.) | |
| [22:16:13] | sphery: | elmojo: Yeah, we have a check that warns if clocks differ by > 20s and errors (with exit) if clocks differ by > 300s. (The 20s allows for some variance due to difference in time between when we checked locally and used network to check the MBE's time.) I think, though, that the 20s would still allow (and 4:30s would definitely allow) for problems in Live TV, though. :( |
| [22:20:52] | Steve_Goodey (Steve_Goodey!~steve@host86-148-198-92.range86-148.btcentralplus.com) has quit (Remote host closed the connection) | |
| [22:22:44] | elmojo: | sphery: in reality we shouldn't need more than 2 seconds to perform the transition for LiveTV – and AFAIK only the HD-PVR has long delay – of course I'd love for the stock code to work for all devices |
| [22:23:38] | elmojo: | I dunno what to do about it – I personally don't have the time to dig into the recorder area to figure out what's going on with the HD-PVR and ticket 9177 |
| [22:27:19] | elmojo: | on the positive side we do seem to be much more reliable than we ever have with LiveTV since the switch to using a file-based chain instead of a ring buffer file |
| [22:30:07] | sphery: | yeah, I just upgraded mine and another system to latest 0.24-fixes and the other guy said Live TV is working great with it |
| [22:30:13] | sphery: | so thanks for all the work on it |
| [22:34:32] | elmojo: | sphery: you use LiveTV – NO WAY! |
| [22:35:16] | sphery: | no, the user of the other system does--a friend with a wife/kids |
| [22:36:37] | ** Captain_Murdoch currently uses the DVR menu theme, so the wife and kids don't even know where to find LiveTV. :) ** | |
| [22:37:31] | elmojo: | I sure sphery would agree with teaching youngsters to not use LiveTV – it needs to be taught in school :) |
| [22:37:57] | sphery: | definitely... real world skills and all! |
| [22:38:39] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [22:39:22] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 252 seconds) | |
| [22:41:33] | stuartm: | there are still issues with LiveTV, it's a substantial improvement but I can reliably deadlock the frontend (backtraces/logs when I get time) |
| [22:41:54] | elmojo: | stuartm: on master? |
| [22:42:01] | stuartm: | elmojo: yup |
| [22:42:02] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [22:42:21] | elmojo: | try Jiri's fix and see if it helps or not |
| [22:43:04] | stuartm: | never even gets as far as showing the signal monitor when entering LiveTV, possibly related to pressing keys in that period – e.g. adjusting volume so that it doesn't blare out when it tunes |
| [22:44:05] | stuartm: | elmojo: will do – if I can figure out who Jiri is and where their fix can be found ;) |
| [22:44:43] | stuartm: | http://svn.mythtv.org/trac/ticket/9177 |
| [22:46:10] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 265 seconds) | |
| [22:47:24] | elmojo: | stuartm: don't think he has a patch for your issue anyways – there is some divergence now between fixes/0.24 and master – one major difference is how we hand the Eof condition |
| [22:49:10] | elmojo: | stuartm: this is one of the major differences -> https://github.com/MythTV/mythtv/commit/679b6 . . . 0ad11da0984e |
| [23:07:56] | stuartm: | elmojo: thanks, it's one of those things that I'll try and debug if I should remember, but since I don't routinely use LiveTV it doesn't top my list of priorities |
| [23:19:54] | Argilo (Argilo!~argilo@CPE002129c31aec-CM00194757b500.cpe.net.cable.rogers.com) has joined #mythtv | |
| [23:28:00] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Operation timed out) | |
| [23:28:26] | markk (markk!~mark@cm10.delta196.maxonline.com.sg) has quit (Ping timeout: 240 seconds) | |
| [23:29:20] | j-rod is now known as j-rod|afk | |
| [23:41:33] | markk (markk!~mark@srv120.dedicated.netrino.co.uk) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.