| Friday, August 30th, 2013, 00:20 UTC | ||
| [00:20:18] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [00:23:40] | xris (xris!~xris@mythtv/developer/xris) has quit (Excess Flood) | |
| [00:24:03] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [00:48:57] | CiscOH|Away is now known as CiscOH | |
| [00:54:41] | gigem: | jya: Which case should cause a crash? |
| [00:55:01] | CiscOH is now known as CiscOH|Away | |
| [01:09:45] | CeilingKitten (CeilingKitten!~CeilingKi@206-248-165-145.dsl.teksavvy.com) has joined #mythtv | |
| [01:40:31] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [02:11:33] | Sterling (Sterling!~chatzilla@c-68-81-16-166.hsd1.pa.comcast.net) has joined #mythtv | |
| [02:12:03] | Sterling is now known as Maddog301 | |
| [02:13:20] | Maddog301 (Maddog301!~chatzilla@c-68-81-16-166.hsd1.pa.comcast.net) has left #mythtv () | |
| [02:35:18] | nyloc (nyloc!~quassel@p57B4FB8B.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:39:30] | _nyloc_ (_nyloc_!~quassel@p57B4FFC8.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [02:43:20] | wagnerrp: | stuartm: yeah, i really need to get those updated |
| [02:43:26] | wagnerrp: | i've been meaning to for some time |
| [02:43:37] | wagnerrp: | stuartm: the issue is that quotes don't matter |
| [02:43:47] | wagnerrp: | it's not even passing the command through the shell for quotes to mean anything |
| [02:45:34] | wagnerrp: | were passing "Unter uns" and "- Bitte beachten Sie, dass in der Schweiz und Österreich stattdessen zwischen 8" as arguments into the script |
| [02:46:18] | wagnerrp: | the python argument parser sees the leading "-", assumes it's a pre-defined option, and tries to process that entire second string |
| [02:46:53] | wagnerrp: | it's not anything the script can sensibly handle without writing a completely custom argument parser |
| [02:47:21] | wagnerrp: | its not something MythSystem should handle, since it really has no reason to know when some user of the library is trying to pass a script bad data |
| [02:47:27] | wagnerrp: | it's just bad data |
| [02:48:39] | wagnerrp: | that's why i dropped the ticket a year and a half ago, since there's no reasonable way to handle it properly on the receiving side |
| [02:50:27] | CiscOH|Away is now known as CiscOH | |
| [02:51:17] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Read error: Operation timed out) | |
| [02:51:57] | wagnerrp: | stuartm: to be fair, much of the confusion comes from poor logging, not making it clear what we are actually running |
| [02:53:01] | wagnerrp: | since we're passing arguments directly into execv |
| [02:56:01] | wagnerrp: | dekarl: the hardware profiler should only be called from active frontends and backends, using the same user environment as that frontend/backend, meaning it should be pulling the same config.xml as that frontend/backend, and should be able to access the database and master backend just the same |
| [02:56:32] | wagnerrp: | further, nothing from those runs gets logged, so if they're receiving that error, it's probably because they're running it manually on the command line |
| [02:56:43] | wagnerrp: | and thus running it with a botched environment or the wrong user accoutn |
| [02:57:09] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:01:02] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [03:01:02] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [03:01:02] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [03:09:15] | jya: | stuartm: with the removal of the { } to the upnp id; that leaves corrupted name left in the config.xml... should update the name if it currently contains { } and remove them |
| [03:24:30] | joki (joki!~joki@p5486380C.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [03:29:08] | joki (joki!~joki@p548634BE.dip0.t-ipconnect.de) has joined #mythtv | |
| [03:33:28] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [03:34:48] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:10:36] | CiscOH is now known as CiscOH|Away | |
| [04:13:54] | CiscOH|Away is now known as CiscOH | |
| [04:20:09] | CiscOH is now known as CiscOH|Away | |
| [04:27:11] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [04:49:10] | CiscOH|Away (CiscOH|Away!~CiscOH@cpe-174-101-188-36.cinci.res.rr.com) has quit (Quit: ZNC - http://znc.in) | |
| [04:50:54] | CiscOH|Away (CiscOH|Away!~CiscOH@cpe-174-101-188-36.cinci.res.rr.com) has joined #mythtv | |
| [04:51:10] | CiscOH|Away is now known as CiscOH | |
| [05:04:34] | CiscOH is now known as CiscOH|Away | |
| [05:37:43] | CiscOH|Away is now known as CiscOH | |
| [05:40:46] | CiscOH is now known as CiscOH|Away | |
| [05:42:46] | CiscOH|Away (CiscOH|Away!~CiscOH@cpe-174-101-188-36.cinci.res.rr.com) has quit (Quit: ZNC - http://znc.in) | |
| [05:44:38] | CiscOH|Away (CiscOH|Away!~CiscOH@cpe-174-101-188-36.cinci.res.rr.com) has joined #mythtv | |
| [05:45:03] | CiscOH|Away is now known as CiscOH | |
| [06:03:07] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [06:06:43] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [06:08:34] | CiscOH is now known as CiscOH|Away | |
| [06:12:09] | CiscOH|Away (CiscOH|Away!~CiscOH@cpe-174-101-188-36.cinci.res.rr.com) has quit (Quit: ZNC - http://znc.in) | |
| [06:13:52] | CiscOH|Away (CiscOH|Away!~CiscOH@cpe-174-101-188-36.cinci.res.rr.com) has joined #mythtv | |
| [06:14:07] | CiscOH|Away is now known as CiscOH | |
| [06:18:50] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [06:18:50] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [06:18:50] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [06:32:11] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Ping timeout: 260 seconds) | |
| [07:00:58] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [07:11:23] | stuartm: | jya: it doesn't, the patch corrects the name in the config.xml the next time the frontend is started |
| [07:11:48] | stuartm: | it checks for "{" in the name and replaces it |
| [07:47:13] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has joined #mythtv | |
| [08:01:46] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has joined #mythtv | |
| [09:07:58] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Quit: Gone) | |
| [09:12:17] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [09:13:10] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [09:23:10] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [09:23:10] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [09:23:10] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [09:36:50] | stuarta: | oh running mythtv-setup via Xnest tunnelled over ssh is painfully slow |
| [09:39:05] | jya: | stuartm: ah cool... i still had the { } in mine.... but I checked again and they are gone.. |
| [09:40:20] | stuarta: | oh running mythtv-setup via Xnest tunnelled over ssh is painfully slow |
| [09:40:24] | stuarta: | doh doh doh |
| [09:45:22] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [10:10:02] | dekarl-work: | stuarta, yes you are making sense. I hacked up the patch quickly before hitting sack. I think its good enough for now if someone can peer-review or even better test it. For a proper solution I'd still prefer to encapsulate the special cases inside the PAT class |
| [10:14:37] | jya: | stuartm: every time I've seen Qt crash in things like QList::begin() , has always been due to an object being used after being deleted. In MythVideo it was not uncommon to have the parent being deleted, and then a method calling m_parent which was no longer valid.. i fixed heaps of those when i went over libmythmetadata |
| [10:16:27] | jya: | stuartm: for tickets like #9607, i'm very keen on closing them as works for me.. otherwise we are drowned into so many bugs and will never het ahead |
| [10:16:27] | ** MythLogBot http://code.mythtv.org/trac/ticket/9607 ** | |
| [10:17:20] | stuartm: | jya: yeah generally that's the case whenever a BT ends somewhere improbable, but at least in the case of that bug I couldn't see where the real cause lay |
| [10:19:27] | stuartm: | and yes, I'm happy to close as "Needs more Info" or "Works for me" when there just isn't enough information to figure out the issue |
| [10:19:57] | jya: | good... |
| [10:20:02] | stuartm: | I didn't do so in that case because Daniel had commented on it without just closing it |
| [10:20:43] | stuartm: | wanted to find out if he had a good reason for keeping it open |
| [10:21:33] | jya: | it was so long ago, probably unlikely he remembers why :) |
| [10:21:58] | paul-h (paul-h!~Paul@176.253.149.19) has joined #mythtv | |
| [10:22:00] | stuarta: | it would be nice if the debug variant would poison deleted memory |
| [10:22:05] | stuartm: | besides which, mrand is usually pretty active and I reasoned I'd get a quick reply back about whether it was still reproducible |
| [10:22:15] | stuarta: | like the kernel does, then it's easy to see wot broke |
| [10:23:07] | jya: | so are we going to branch 0.27 anytime soon? reason I ask is that I have fixes I'm a tad scared to commit some fixes now without longer use... so was intending to have them in master bake a little while, and cherry-pick them into 0.27 after |
| [10:23:39] | jya: | paul-h: did you get the chance to test the ThreadedFileWriter fixes? |
| [10:24:01] | paul-h: | just about test it now |
| [10:24:15] | jya: | i've made some logging improvement |
| [10:25:10] | paul-h: | I need to patch both the FE and BE? |
| [10:25:23] | stuartm: | jya: backend has segfault three times in the last three days here, after several months without a single crash, I'm hoping that it's just a build glitch or memory issue but I want to wait a couple of days to be sure |
| [10:25:23] | jya: | it depends. |
| [10:25:43] | stuartm: | Sunday/Monday at the latest |
| [10:26:27] | stuartm: | besides which, while I'm still going through the open tickets, it's a lot easier to push fixes/patches to just one branch instead of two |
| [10:27:06] | jya: | paul-h: the patch is for libmythbase; if you do myth://blah as --outfile that's the backend calling it, if its destination is a local file, then it's mythutil that will call it |
| [10:27:25] | jya: | stuartm: no worries... |
| [10:27:26] | stuartm: | repeating phrases again, good sign that I'm exhausted :) |
| [10:29:12] | jya: | paul-h: http://pastebin.com/4eLQzWFN |
| [10:29:38] | jya: | stuartm: do you have backtraces for the backend crash? |
| [10:30:05] | jya: | I've had similar things happening to me with #10867 |
| [10:30:05] | ** MythLogBot http://code.mythtv.org/trac/ticket/10867 ** | |
| [10:30:32] | jya: | with crashes due to deleting a QMutex while in lock mode and a mthread being deleted while not stopped |
| [10:32:55] | jya: | i saw this happening heaps when I did a loop calling mythavtest on the flac audio samples... |
| [10:33:25] | jya: | it crashes, but that's when exiting so haven't given it a high priority... |
| [10:35:50] | stuartm: | jya: I have one, the first two times core dumps weren't enabled |
| [10:36:14] | jya: | stuartm: can you post it somewhere? |
| [10:37:40] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 264 seconds) | |
| [10:37:47] | jya: | re #10867: what is myth shutdown supposed to do? stopping the backend ? i run it here and it appears to do nothing when run with --lock |
| [10:38:27] | stuartm: | http://pastebin.ca/2440858 |
| [10:39:33] | jya: | http://code.mythtv.org/trac/attachment/ticket . . . own-5417.txt can you see which thread is crashing? can't see it :( |
| [10:39:36] | jya: | thanks |
| [10:40:11] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [10:40:40] | jya: | stuartm: same in your backtrace, which thread crashed? |
| [10:41:51] | stuartm: | jya: gdb says thread 1 (for both of them) |
| [10:42:29] | jya: | stuartm: there's a lot of EIT scanner running in the BT. 3 in total, is that expected? |
| [10:42:51] | stuartm: | one per physical card, yes I believe that's normal |
| [10:43:44] | jya: | ok |
| [10:44:32] | stuartm: | to me 10867 looks like a memory error, corruption maybe |
| [10:44:53] | stuartm: | crashes dynamically loading the mysql driver |
| [10:45:04] | stuartm: | in a malloc specifically |
| [10:46:17] | jya: | don;t see anything obvious in your bt :( |
| [10:46:18] | stuartm: | when I see /usr/lib/nvidia-current/libGL.so.1 in a trace where it clearly doesn't belong that always worries me |
| [10:47:47] | stuartm: | jya: aye, it's pretty useless, which is why I wiped everything, rebuilt from scratch and rebooted the machine in the hope that if it's bad memory, at least it shouldn't align to the same area |
| [10:48:03] | stuartm: | we'll see if that helps |
| [10:48:30] | jya: | pretty rare for memory to go bad like that though |
| [10:48:51] | stuartm: | it is |
| [10:49:00] | stuarta: | stuartm: do you know if we respond to XEpose events? |
| [10:50:06] | stuartm: | stuarta: we used to ... but that may have changed, it's handled through QT, which turns those into it's own expose event |
| [10:57:28] | stuarta: | hmm, i wonder if it's an Xnest issue. |
| [10:58:07] | ** stuarta is running mythtv-setup under Xnest, and it doesn't redraw the screen when it's brought to the front ** | |
| [10:59:23] | paul-h: | jya: I patched both the BE and FE, first test looks good going from the BE -> FE. The logging is very verbose with lots of 'Maximum buffer size exceeded' messages but md5sum gives the same checksum for both files :). I'll try a few more tests after I have a bite to eat |
| [11:00:23] | jya: | yes.. the warning is still there.. it will pretty much show up whenever input is faster than output and we overflow the buffer |
| [11:00:52] | jya: | except that now instead of exiting mid way, it waits for the writer to have some space |
| [11:01:06] | jya: | that's what it used to do in 0.25 |
| [11:01:40] | jya: | i'm keen on getting tested with plain recording though... |
| [11:02:03] | jya: | threadedfilewriter is used by the ring buffer to write to the disk |
| [11:07:38] | jya: | weird... HLS recorder writes 0 bytes file now :( even without my changes. seems to be happily feeding data.. but can't see anything written to disk |
| [11:09:46] | stuarta: | do we have any unit tests on TFW? |
| [11:10:38] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [11:12:07] | jya: | no. |
| [11:36:56] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [11:53:11] | jya: | ok... it's a regression... i went back a week, and recorder works fine :( |
| [11:55:01] | CiscOH is now known as CiscOH|Away | |
| [11:57:27] | CiscOH|Away (CiscOH|Away!~CiscOH@cpe-174-101-188-36.cinci.res.rr.com) has quit (Quit: ZNC - http://znc.in) | |
| [12:32:59] | maddog301 (maddog301!~chatzilla@65.197.242.18) has joined #mythtv | |
| [12:47:17] | stichnot: | Any chance of getting an updated Coverity report before the branch? |
| [12:55:26] | stuarta: | stuartm: ^^^ |
| [12:58:46] | stuartm: | yeah, planning to do one tonight |
| [13:04:03] | stichnot: | cool, since 2 of the 3 red items are mine :) (but should be fixed by now) |
| [13:26:46] | stuartm: | anyone looking for work? The comment by Beirdo at the end of http://code.mythtv.org/trac/ticket/10720 – "This ticket will remain open for the moment to remind me to look at adding a check for OpenGL painter on VAAPI." |
| [13:29:16] | stuartm: | seems like something simple that really should go into 0.27 – Disallow the use of VAAPI with OpenGL, log the issue, add a comment to the playbackprofile mentioning the requirement, maybe even force the GL painter when vaapi is select |
| [13:29:34] | stuartm: | one or any of the above would be better than the status quo |
| [13:33:39] | sphery: | don't disallow it--force it |
| [13:33:52] | sphery: | based on http://code.mythtv.org/trac/ticket/10720#comment:4 |
| [13:35:00] | stuartm: | well forcing the UI painter means restarting/reloading the frontend |
| [13:35:23] | sphery: | of course, if you try to force opengl painter, you'll have the same problem our auto-detect-painter-to-use code did--that people's broken drivers/opengl installs will cause it to not work and they won't be able to use the UI |
| [13:35:53] | sphery: | just saying that according to that ticket vaapi only works if you use the opengl ui painter |
| [13:36:13] | sphery: | so we don't want to "Disallow the use of VAAPI with OpenGL" |
| [13:36:22] | sphery: | we can disallow the use of vaapi without opengl |
| [13:36:32] | stuartm: | sphery: that was a typo, should have bee without |
| [13:36:35] | stuartm: | been |
| [13:36:36] | sphery: | ok |
| [13:37:04] | stuartm: | hence the contradictory "maybe even force the GL painter when vaapi is select" |
| [13:37:07] | stuartm: | ed |
| [13:37:20] | stuartm: | it's going to be a day of typos :) |
| [13:39:00] | jya: | stuartm: AFAIK, you can only use VAAPI with OpenGL... the video playback profile forces opengl |
| [13:39:31] | stuartm: | it can't do that though |
| [13:39:46] | stuartm: | a video playback profile has no control over the UI painter |
| [13:40:23] | sphery: | jya: are you talking about the video renderer being forced? |
| [13:40:30] | sphery: | versus ui painter |
| [13:40:56] | jya: | renderer (and deinterlacer) |
| [13:41:18] | jya: | does the painter matters then? |
| [13:41:35] | stuartm: | yep, apparently it won't work with the QT painter |
| [13:42:36] | jya: | i'll have a play with it.. already done some fix on vaapi... not sure how you could add a mechanism to force OpenGL painter... unless we just put a big message at start of playback |
| [13:42:48] | jya: | or display a notification: won't work unless you select OpenGL |
| [13:42:57] | jya: | something like that |
| [13:44:27] | jya: | simple, but easy enough to understand |
| [13:45:02] | dekarl-work: | what is the problem with requiring working OpenGL (ES)? And do we want it to be our problem? XBMC states "For end-users the recommended minimum requirement is an x86-based computer, with a 3D GPU (...) that at least supports Shader Model 3.0 and OpenGL 2.0 (...)." |
| [13:45:34] | dekarl-work: | from http://wiki.xbmc.org/?title=XBMC_for_Linux_sp . . . nts_for_XBMC |
| [13:45:46] | stuartm: | dekarl-work: nothing, but that's not something we can require for 0.27 this late in the day |
| [13:45:56] | stuartm: | maybe for the next release |
| [13:46:54] | stuartm: | I'm already planning to switch over to the newer gl painter that Mark wrote at the start of the next cycle, I want to give it wider testing to see whether it has any issues (been using it here for months) |
| [13:47:04] | dekarl-work: | stuartm: while I agree with that I'm wondering if we should announce this for the release after 0.27. |
| [13:47:52] | stuartm: | I'm all for that |
| [13:48:06] | wagnerrp: | it got shot down last time we tries |
| [13:48:08] | wagnerrp: | *tried |
| [13:49:26] | stuartm: | wagnerrp: no harm in trying again, the world has moved on since then, we've already managed to drop XvMC, no reason we can't do the same for QT (and XV) |
| [13:50:26] | stuartm: | in fact, dropping XV is a higher priority for me, it would simplify so much of the code |
| [13:51:09] | jya: | stuartm: which new gl painter? |
| [13:51:53] | stuartm: | jya: Mark wrote a replacement, 'opengl2', which is better in a number of ways, uses more of opengl to render stuff like shapes |
| [13:52:01] | jya: | last I played with an ATI system, i had no choice but using Qt painter. When using the OpenGL once it crashed often, and video playback gave me a black screen |
| [13:53:27] | stuartm: | I believe the opengl2 painter may also be more ES friendly, but I'd have to check back to the commit message |
| [13:56:41] | sphery: | as for opengl vs opengl es, if you compile Qt with opengl support, you have to use opengl; but if you compile Qt with opengl es support, you have to use opengl es |
| [13:56:51] | sphery: | i.e. we can only use the opengl that Qt uses |
| [13:57:06] | dekarl-work: | I have testing with "the new opengl painter" on "the list" but its not at the top :/ though its likely a needed step to move forward with support for smaller systems (no, not the RPi) |
| [13:57:25] | sphery: | there's currently a check in configure that makes sure you get support compiled in for the right one (and only the right one), so it's not something the end user has to worry about |
| [13:57:50] | stuartm: | https://github.com/MythTV/mythtv/commit/bd8132c531 https://github.com/MythTV/mythtv/commit/b3266afb96 https://github.com/MythTV/mythtv/commit/287de3d43 https://github.com/MythTV/mythtv/commit/50f2a5530 |
| [13:58:14] | stuartm: | are the most interesting commits relating to the 'new' OpenGL painter |
| [13:58:53] | sphery: | and, yes, as jya said, many drivers (including the ATI ones) had (have?) serious problems with our OpenGL code--which is why Auto is no longer the default for UI painter |
| [13:59:24] | stuartm: | except on distros that have changed it back to Auto |
| [14:00:32] | stuartm: | e.g. Ubuntu |
| [14:00:55] | sphery: | that said, especially with newer Qt, where starting in 4.8 and especially in 5.x which are using low-level (in Qt) GL even if you choose the Qt painter, I don't see a problem with just saying, "You have to have working OpenGL on your system." |
| [14:03:43] | jya: | all right.. time for git bisect.. why is it the recorder stopped working here :( |
| [14:04:14] | jya: | sphery: I'm all for only having OpenGL |
| [14:04:34] | jya: | we need to fix whatever needs fixing so it *always* work with existing OpenGL libs |
| [14:05:07] | dekarl-work: | superm1: can you see if https://launchpad.net/bugs/1030563 has a proper backtrace? its crashing with a package from this month, so it might still be relevant |
| [14:05:24] | jya: | even on my mac there are issues when using OpenGL. the screen asking you to update the database, or select a language: doesn't display when you select OpenGL... |
| [14:05:46] | jya: | as a work around, I start myth with the qt painter and only once the main menu has been loaded it switches back to opengl |
| [14:09:09] | sphery: | jya: FWIW, those screens are old non-mythui screens and that may also explain why some settings pages don't work for you and Nigel--some of those are also non-mythui (actually most, so if it's only one settings page that doesn't work, maybe it's something specific about what's shown in them or how it's drawn) |
| [14:09:38] | sphery: | actually, the language selection one is mythui |
| [14:09:48] | sphery: | but the db update one isn't |
| [14:11:26] | stuartm: | they are both bootstrapped though, and maybe something about the bootstrapping process is nitialising the gl painter differently on OSX |
| [14:11:48] | sphery: | that makes sense |
| [14:14:59] | stuartm: | and yes, that's abusing the term 'bootstrap' but that's just what we've called the minimal environment created when we have no database access and need to display these screens |
| [14:26:40] | ** stuarta starts saving for new hardware ** | |
| [14:27:06] | wagnerrp: | for something that does opengl? |
| [14:27:21] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [14:28:02] | stuarta: | yeah, my prod frontend doesn't. i don't think my really old mac mini runnning f19 does, only my ancient dev box which i don't use much these days does, and that only because of nvidia drivers |
| [14:28:37] | stuarta: | actually i need to check the mini, it may do |
| [14:29:25] | wagnerrp: | assuming it's not a G4, it should do it |
| [14:30:01] | wagnerrp: | although whether or not an old GMA950 is up to snuff for the opengl renderer, i don't know |
| [14:31:27] | ** stuarta fiddles ** | |
| [14:32:05] | dekarl-work: | stuarta: might as well take the motivation to make it run on one of the new Ubuntu ARM boxen :) |
| [14:32:35] | stuarta: | wagnerrp: dmidecode reports its a mac mini v1 |
| [14:32:43] | stuarta: | tis a core duo cpu |
| [14:33:56] | wagnerrp: | opengl might be iffy on that one, performance wise, not presence wise |
| [14:45:58] | paul-h: | wagnerrp: is this the correct way to save a local setting using the python bindings http://code.mythtv.org/cgit/mythtv/tree/mythp . . . burn.py#n881 |
| [14:47:44] | wagnerrp: | looks fine |
| [14:48:10] | wagnerrp: | if you want to save globally, use NULL as the hostname |
| [14:48:56] | paul-h: | So it will use the LocalHostName if set otherwise use the hostname? |
| [14:49:16] | wagnerrp: | yeah |
| [14:49:58] | jpharvey (jpharvey!~jpharvey@host109-148-115-200.range109-148.btcentralplus.com) has quit (Ping timeout: 246 seconds) | |
| [14:50:32] | paul-h: | I couldn't get it to use the LocalHostName when I tried to do it from the python interpreter, maybe I was doing something wrong |
| [14:53:16] | wagnerrp: | it should work in any version after we changed the config.xml format |
| [14:53:29] | wagnerrp: | the bindings did not previously read that value out of the old mysql.txt |
| [14:59:10] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [15:00:40] | paul-h: | wagnerrp: how do I turn turn the logging on in the bindings? where does it go to |
| [15:01:51] | jpharvey (jpharvey!~jpharvey@host109-148-115-200.range109-148.btcentralplus.com) has joined #mythtv | |
| [15:02:38] | paul-h: | After changing config.xml I did in the python interpretor – import MythTV; DB = MythTV.MythDB(); print DB.gethostname() but it still prints the hostname not the LocalHostName |
| [15:03:27] | paul-h: | print DB.dbconfig.profile also shows the hostname |
| [15:07:41] | wagnerrp: | you've got two options |
| [15:08:18] | wagnerrp: | you can either use the _setlevel, _setmask, _setfile, _setpath, _setfileobject, and _setsyslog methods directly |
| [15:08:56] | wagnerrp: | or use loadOptParse or loadArgParse to inject the necessary options into those command line parsers |
| [15:09:24] | wagnerrp: | checking the LocalHostName thing... |
| [15:15:32] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [15:18:19] | paul-h: | Each time I use the python bindings it seems the config.xml gets reset back to some default values loosing the edits I'm making |
| [15:18:40] | wagnerrp: | ok, found it |
| [15:21:04] | wagnerrp: | one down... |
| [15:21:17] | wagnerrp: | now it still shouldn't be rewriting it each time |
| [15:25:52] | davidshay_ (davidshay_!~davidshay@cpe-107-10-21-164.neo.res.rr.com) has joined #mythtv | |
| [15:26:01] | maddog301 is now known as md301 | |
| [15:33:04] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection) | |
| [15:33:06] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Read error: Connection reset by peer) | |
| [15:34:07] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [15:39:00] | peper03: | paul-h: What was the ffmpeg issue you said had been fixed wrt MythArchive? mythffmpeg from master gets stuck in an infinite loop on my machine when I try to create an ISO. |
| [15:43:48] | superm1: | dekarl-work: unfortunately nothing useful there |
| [15:43:51] | superm1: | just closed it |
| [15:45:24] | paul-h: | peper03: it was a problem calling av_estimate_timings() which was causing a segfault. I just commented it out at the suggestion of jya and everything worked again for me |
| [15:46:32] | paul-h: | wagnerrp: still not working for me but I think it's because config.xml is being clobbered every time the bindings are run |
| [15:49:45] | stichnot (stichnot!~stichnot@207.198.105.23) has joined #mythtv | |
| [15:49:45] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [15:49:45] | stichnot (stichnot!~stichnot@207.198.105.23) has quit (Changing host) | |
| [15:54:08] | paul-h: | gigem: re: ticket #11666 I just tried on 2 separate FE's and they both go to 100% cpu after the FE is restarted |
| [15:54:08] | ** MythLogBot http://code.mythtv.org/trac/ticket/11666 ** | |
| [15:55:41] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [15:55:43] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [16:07:06] | paul-h: | wagnerrp: if I disable upnp on the BE with --noupnp config.xml doesn't get clobered and everything works OK |
| [16:07:37] | wagnerrp: | that sounds like it's not working at all |
| [16:07:52] | dekarl1 (dekarl1!~dekarl@p4FCEF6C5.dip0.t-ipconnect.de) has joined #mythtv | |
| [16:08:00] | wagnerrp: | my only guess is that for whatever reason, it cannot read the file, pulls data from upnp, and writes that to the file |
| [16:08:32] | dekarl (dekarl!~dekarl@p4FCEEBD2.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [16:12:31] | sphery: | paul-h: are you sure your LocalHostName override is in the right place? I think the config.xml "upgrade" code leaves in the old UPnP element and its children. The LocalHostName should be directly under Configuration, now, as in https://github.com/MythTV/mythtv/blob/master/ . . . s/config.xml |
| [16:13:04] | sphery: | it's possible that the old garbage that gets left in may prevent the bindings from reading it properly, so it falls back on upnp detection |
| [16:13:43] | paul-h: | It did have some old garbage but I deleted it and when the FE was started it was recreated |
| [16:13:51] | wagnerrp: | but that should only happen once |
| [16:14:10] | wagnerrp: | once the bindings rewrote the file in the new format, it should have no trouble parsing it back out |
| [16:14:42] | wagnerrp: | looking at my existing config.xml, versus the one i just had the bindings print out, the only difference is "PingHost" defaults back to 1 |
| [16:14:50] | wagnerrp: | apparently I never read it in the bindings |
| [16:16:10] | sphery: | ah, yeah, I guess <UPnP> element is created by frontend, but it now only contains <UDN> and its child <MediaRenderer>, it seems |
| [16:17:43] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:27:11] | rsiebert (rsiebert!~quassel@g225059085.adsl.alicedsl.de) has joined #mythtv | |
| [16:30:01] | rsiebert_ (rsiebert_!~quassel@g225052117.adsl.alicedsl.de) has quit (Ping timeout: 245 seconds) | |
| [16:36:56] | Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving) | |
| [16:46:54] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit (Quit: tgif!) | |
| [16:55:25] | gigem: | paul-h: OK. I'll reopen it. |
| [17:14:38] | davidshay_: | I see that 11318 is now marked as closed. So the issue I was having where as soon as a SBE recording started the MBE crashed is "fixed", but only sort of… it doesn't crash, now I just get UNKNOWN COMMAND errors. |
| [17:15:31] | davidshay_: | Seems like the code that was put in sort of just treats the symptom... |
| [17:15:45] | davidshay_: | (and nicely prevents the crash...) |
| [17:22:15] | davidshay_: | I know that before most of the devs didn't have a MBE/SBE with record device configuration — let me know if I can help debug in any way. |
| [17:22:44] | wagnerrp: | i do, but the SBE hasn't been on in several months, and hasn't recorded in several years |
| [17:29:11] | davidshay_: | So, I take it I should open up a new ticket for this behavior now? |
| [17:29:23] | davidshay_: | hard to know if 11316 is somewhat the same or not... |
| [17:29:40] | davidshay_: | or, if THAT gets fixed, if it will go away... |
| [17:30:08] | davidshay_: | advice on that wagnerrp? |
| [17:30:21] | wagnerrp: | no idea. haven't been paying attention to that ticket |
| [17:38:38] | paul-h: | wagnerrp: just removed the config.xml restarted the BE with upnp re-enabled, started the FE to recreate the config.xml and now the bindings are working OK. I'm completely baffled what was going on there |
| [17:42:56] | stichnot: | stuartm: regarding 10788, one of these days I'd like to track down all the potentially long or blocking operations that happen in the OSD and offload the work into a helper thread. Opening and navigating the program guide has always been an issue, and same for bringing up INFO during playback (though the latter may be the same image loading issue for the channel logo) |
| [17:44:03] | stichnot: | Simply bringing up the OSD menu is another potential issue, since a nontrivial amount of work needs to be done to determine how to populate the menu. |
| [17:47:26] | stuartm: | moving the image loading to another thread wouldn't help, it's already in another thread anyway, the problem seems to be the protocol/socket usage – while we're streaming video, using the same socket to request other information/files from the backend causes interruptions |
| [17:48:16] | stuartm: | the best solution would be to moving the playback stuff to it's own socket entirely, managed by a different thread on the backend |
| [17:49:41] | stuartm: | well, I think that's the issue here, there's a bit of guesswork involved :) |
| [17:50:18] | stuartm: | the underlying issue dates back years, I remember discussing it with Isaac |
| [17:50:51] | wagnerrp: | or, make the socket communications asynchronous |
| [17:51:05] | stichnot: | oh, that's interesting. |
| [17:51:06] | wagnerrp: | i'd rather see that |
| [17:51:46] | stuartm: | that might do the trick |
| [17:52:00] | wagnerrp: | it wouldn't be all that difficult, just requiring a message number be sent with the message |
| [17:52:25] | wagnerrp: | but that would mean a complete break with the previous format |
| [17:53:41] | stuartm: | it would remove the restriction on SendReceive* being used in the UI thread, which would make life a little easier |
| [17:55:57] | wagnerrp: | that's one of the reasons for the thread i started two months back, take that break as an opportunity to address a number of deficiencies in it |
| [17:57:27] | stuartm: | breaking previous format has never been an issue before, that's why the protocol is versioned |
| [17:57:42] | wagnerrp: | in this case, it would break the versioning |
| [17:58:16] | wagnerrp: | unless the version check was synchronous with no message id |
| [17:58:23] | stuartm: | not if the ANNOUNCE is kept synchronous |
| [17:59:27] | stuartm: | with the services API there's also no reason it should affect third party clients either, might even encourage more of them to migrate over |
| [17:59:53] | wagnerrp: | actually, the version check comes before the announce |
| [18:00:31] | stuartm: | it does? |
| [18:01:07] | stuartm: | huh, thought it was the other way around, or in fact that the version spoken by the client had to be part of the announce |
| [18:01:39] | ** stuartm shrugs ** | |
| [18:03:05] | wagnerrp: | first step that happens on a connection... http://code.mythtv.org/cgit/mythtv/tree/mytht . . . ext.cpp#n268 |
| [18:03:44] | wagnerrp: | now that i think about it, we could have a command like the FTP PORT/PASV to tell the server how to behave |
| [18:04:18] | wagnerrp: | let clients choose on their own whether to rewrite their code to support it |
| [18:04:32] | stuartm: | so it does ... |
| [18:04:57] | stuartm: | all this time I thought it was part of the annouce :) |
| [18:05:04] | stuartm: | announce |
| [18:06:01] | stuartm: | Captain_Murdoch: do you intend to work on http://code.mythtv.org/trac/ticket/10700 ? It's a feature request, but one which you've accepted |
| [18:14:09] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [18:14:09] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has quit (Changing host) | |
| [18:14:09] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:14:27] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [18:18:05] | wagnerrp: | stuartm: i'm going to add a task to trac detailing that change |
| [18:20:33] | stuartm: | jpabq: any reason why you've not yet committed your patch in http://code.mythtv.org/trac/ticket/10930 ? |
| [18:22:30] | jpabq: | stuartm: sorry, I need to close that ticket. It is not necessary with a *very* recent kernel. |
| [18:23:42] | stuartm: | no need to apologise :) helps to get out ticket count down |
| [18:24:41] | stuartm: | fwiw, there are several open "Patch – Bug Fix" tickets with a milestone of 0.27, most of them are assigned which is why I've only just started to go through them |
| [18:35:57] | jya: | could close quite a few bugs if we disabled mythlogserver by default... would increase the thread counts for all running apps; not sure if that would be a problem |
| [18:37:16] | wagnerrp: | as i understand it, logging was only moved externally to aide with debugging |
| [18:38:35] | stuartm: | ironic that it should cause so many problems |
| [18:38:58] | stuartm: | stuarta: http://code.mythtv.org/trac/ticket/11021 |
| [18:40:51] | jya: | wagnerrp: well, Beirdo logic is that you can catch logs when the app is crashing which would have been lost otherwise... |
| [18:41:01] | wagnerrp: | right, debugging |
| [18:41:24] | jya: | with it, you only have one thread doing the logging. without it, and to simulate it, you have up to 4 threads ! |
| [18:41:48] | jya: | the logger, the log server, the log forward, and the database db thread |
| [18:42:03] | wagnerrp: | what i'm getting at is that if a crash is reproduceable, you can always reproduce it with log server running |
| [18:42:05] | jya: | could reduce it by one without much work |
| [18:42:18] | wagnerrp: | if it's not reproduceable, there's not really anything we can do about it anyway, logs or not |
| [18:42:51] | jya: | agreed... plus i found in case of a crash, the logs serve little purpose... |
| [18:44:45] | gigem: | wagnerrp: Here's some food for thought. Only add asynchronous support for service API calls. If the client command/response handling needs to changed anyway, why not take the opportunity to also switch it to the service API? |
| [18:45:06] | wagnerrp: | aren't the service api calls already asynchronous? |
| [18:46:52] | gigem: | Yes. :) Though, we have talked very briefly about trying to run service calls over persistent connections and/or Myth protocol. |
| [18:46:55] | wagnerrp: | my issue with the service api is that each such query is going to have to occur in a new connection, with all that socket/http overhead |
| [18:48:12] | gigem: | Already noted, along with solutions. |
| [18:48:59] | wagnerrp: | i would love to convert all that stuff over, but that's a fairly large change that's going to break a lot of stuff, and a topic that never really reached any decision |
| [18:50:16] | wagnerrp: | just making the existing protocol asynchronous is a lot less heartache |
| [18:50:26] | gigem: | That's why I suggested starting with any asynchronous changes. IOW, instead of adding asynchronous support to the Myth protocol and the client handling, just change the client to use the service API. |
| [18:50:58] | dblain: | wagnerrp: I thought I wrote the built-in http server to support persistent connections. |
| [18:51:03] | stuartm: | jya, wagnerrp: I can count on one hand how many crashes I've solved with the aid of the logs, and out of those, the logs only helped when the user was unable to articulate exactly what they were doing when the crash occurred |
| [18:51:52] | wagnerrp: | dblain: i've never actually tested it |
| [18:53:23] | stuartm: | now, an external app that monitors for crashes in myth* apps, then captures a proper backtrace which is automatically uploaded to a ticket ... *that* might be worth the effort |
| [18:53:52] | wagnerrp: | dblain: does it do pipelining as well? |
| [18:54:13] | stuartm: | but only if it includes some smarts to distinguish between crashes caused in unmodified code and those produced on systems with patches |
| [18:54:30] | jheizer: | Regarding persistent connections, I can say last night workig on MobileMyth that it was throwing errors about losing its persistent connection. BUT my wifi has been flaky and I have never seen this error in the year of developing off it. |
| [18:54:43] | jheizer: | So unless something broke it in .27, it should be working |
| [18:55:31] | jya: | jpabq: it's your commit that broke IPTV/HLS recording: f077d230c3819ee1ebfd15a878aada78d7a5a224 |
| [18:55:41] | dblain: | wagnerrp: I don't remember the status of pipelining. |
| [18:55:52] | jya: | it never writes anything to disk ; only creating 0 bytes recordings |
| [18:59:09] | wagnerrp: | without pipelining, that would just put us right back in the same position |
| [19:00:16] | wagnerrp: | at least once all functionality was migrated over |
| [19:04:14] | dblain: | wagnerrp: I vaguely remember testing pipelining when I was testing the upnp stack (5+ years ago). I don't see anything in the code that stops it, and I wrote the http server to work with 1.1 spec which requires pipelining request support (even if responses aren't pipelined). |
| [19:07:56] | wagnerrp: | seems pipelining is not truly asynchronous |
| [19:08:05] | jheizer: | Is it easy to see from a wireshark summary? |
| [19:08:07] | wagnerrp: | you can send multiple queries without waiting, but they still have to come back in order |
| [19:21:32] | dblain: | Yes, if you need something truely asyncronous, you just send multiple request on seperate connections. (which I know you were trying to avoid) |
| [19:27:22] | stuartm: | stuarta, dekarl1: simple two year old patch attached to http://code.mythtv.org/trac/ticket/10136 |
| [19:28:30] | stuartm: | whether the patch is any good I'll leave you to decide, but if not the the ticket can be closed as an upstream bug, we can't really do anything about providers who transmit completely broken guide data |
| [19:34:49] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has joined #mythtv | |
| [19:43:09] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [19:47:39] | gigem: | dblain, wagnerrp: We just need to create a connection pool on the client side like we already do for DB connections. |
| [19:50:48] | md301 (md301!~chatzilla@65.197.242.18) has quit (Read error: Connection reset by peer) | |
| [19:55:18] | gigem: | paul-h: FWIW, the time I was able to reproduce #11666, the runaway thread looked like it was in a tight poll loop where some event was ready to be handled, but no one was handling it. |
| [19:55:18] | ** MythLogBot http://code.mythtv.org/trac/ticket/11666 ** | |
| [19:59:13] | stuartm: | from paul-h's backtrace it looks like an x event? Maybe it's arriving at the moment when we have an event loop up but no main window, although I'm not even sure whether that's possible and in the description of the issue there's no mention that the main window is missing |
| [20:02:05] | stuartm: | will people stop opening new tickets, I'm trying to get the ticket count down and you're pushing it back up again! :p |
| [20:07:37] | ** tonsofpcs still moves to open tickets for PSIP cahcing and manual PID selection for channels ** | |
| [20:08:55] | paul-h: | stuartm: When the FE restarts there is a period with no visible window at all so maybe you are onto something there |
| [20:12:31] | paul-h: | jya: I've done a few recordings with your patch in place as well as a few file transfers in both directions with no problems |
| [20:12:46] | stuartm: | paul-h: IF that's somehow the cause, then we need to disable the event loop, or otherwise signal that we wish to ignore x events until we have the main window running again |
| [20:12:59] | stuartm: | but this is pure speculation |
| [20:13:07] | md301 (md301!~chatzilla@65.197.242.18) has joined #mythtv | |
| [20:14:51] | SteveGoodey (SteveGoodey!~steve@host217-42-221-180.range217-42.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [20:18:26] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 256 seconds) | |
| [20:24:47] | stuartm: | who here is using an HDPVR and can test a patch for me? |
| [20:25:09] | jpabq: | I could in about 30 minutes. |
| [20:25:22] | dekarl1: | stuartm, #8770 is a nice mashup with no reply in years, might as well close it ;) |
| [20:25:22] | ** MythLogBot http://code.mythtv.org/trac/ticket/8770 ** | |
| [20:26:54] | dekarl1: | should have been infoneeded 14 months ago |
| [20:26:56] | stuartm: | jpabq: http://pastebin.com/Wt9jyqdZ |
| [20:27:29] | stuartm: | jpabq: shoudl fix memory leak reported in http://code.mythtv.org/trac/ticket/11529 |
| [20:28:27] | jpabq: | stuartm: Ah, got it. Okay. to be sure there are not any unexpected consequences, I will run that over night. I will let you know as soon as I notice any issues — if there are any. |
| [20:29:20] | stuartm: | jpabq: great, thanks |
| [20:30:19] | stuartm: | it seems straightforward, but it's not my area of the code so I'd rather play safe :) |
| [20:30:57] | jpabq: | looks fine to me, but jya says I broke HLS, so who am I to say ;-) |
| [20:31:20] | stuartm: | dekarl1: I'll give it 24 hours for someone to come back |
| [20:32:03] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [20:32:46] | stuartm: | I'm not expecting replies to many of the tickets I've tagged 'infoneeded', but at least we can't be faulted for not giving people a chance to comment before we close the tickets |
| [20:35:10] | md301 (md301!~chatzilla@65.197.242.18) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]) | |
| [20:55:01] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 245 seconds) | |
| [21:03:38] | gigem: | jya: Do you intend to include your TFW change in 0.27? If so, I need to make sure I test it myself on my non-standard setup. |
| [21:08:31] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [21:12:07] | stuartm: | jpabq: would you prefer to be know as DN27 from now on? |
| [21:14:56] | stichnot: | stuartm: Are you ok if I grab #11786 ? The fix will affect code that I'm working in at the moment. I likely wouldn't put it into the initial 0.27, as it hasn't bothered anyone in years. |
| [21:14:56] | ** MythLogBot http://code.mythtv.org/trac/ticket/11786 ** | |
| [21:15:24] | stuartm: | stichnot: it's all yours :) |
| [21:24:03] | stichnot: | thanks :) |
| [21:28:04] | jpabq: | stuartm: Heh. Ever since I started getting deeper into the recorder stuff, I have found that the easiest way to test stuff is to have separate logins on my machine, each with their own mythconverg DB, and paths. That way I can test stuff without messing up my production environment. I just forgot to set the git user name for that login. Thanks for pointing it out ;-) |
| [22:17:48] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [22:25:06] | jya: | gigem: my plan was to push it once the 0.27 branch is made, and push it to 0.27 after it's been thoroughly tested... I'm highly confident that the new code in TFW is sound. What I'm unsure is how the caller will handle the fact that it can now be blocking |
| [22:25:06] | dekarl1 is now known as dekarl | |
| [22:27:29] | jya: | it used to be blocking pre 0.25.. but as danielk posted the changes to TFW at the same time he pushed all the other recorder changes. I'm worried the recorder may not like it. Having said that, before it wouldn't have blocked, but you would have ended up with a broken written file. So we only trace a behaviour with a another catastrophic one |
| [22:30:32] | jya: | jpabq: I think the test that check if an external changer is in place shouldn't be up to the channel to answer that question, but where IsExternalChannelChangeSupported is called |
| [22:31:15] | jya: | would be more elegant, and make IsExternalChannelChangeSupported do what its name suggest |
| [22:32:25] | jpabq: | jya: that was my first instinct as well. Unfortunately, it is harder to answer the question in the signalmonitor. When I have more time to invest in it, I will look at it again, but for now that change should work. |
| [22:34:06] | paul-h: | jya: I've been running with your patch on the BE all day and all recordings have completed OK with nothing in the log to suggest any problems |
| [22:35:00] | paul-h: | The only minor fault is the excessive logging when using mythutil to copy a file from the BE to the FE |
| [22:42:25] | paul-h (paul-h!~Paul@176.253.149.19) has quit (Quit: Konversation terminated!) | |
| [22:42:36] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [23:05:17] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [23:19:17] | poptix (poptix!poptix@poptix.net) has quit (Quit: leaving) | |
| [23:19:53] | poptix (poptix!poptix@precious.net) has joined #mythtv | |
| [23:32:14] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.