| Monday, July 25th, 2011, 00:35 UTC | ||
| [00:35:29] | danielk22: | xris + any sysadmin: It looks like maybe our unsubscribe mechanism is broken, see "[mythtv-users] Unable to unsubscribe from mailing list." |
| [00:35:48] | xris: | hmm |
| [00:35:51] | ** xris pokes Beirdo ** | |
| [00:36:52] | Beirdo: | that is a direct result of not sending that address to mailman. I forget who told us that would be a good plan to reduce spam, but I do remember disagreeing at least mentally |
| [00:37:07] | Beirdo: | I've removed the person there taht complained though |
| [00:37:28] | xris: | I think the comment was in the original aliases file |
| [00:37:54] | xris: | maybe something Snow-Man set up, or was told to do… probably lost in the past now. |
| [00:38:09] | xris: | so it basically boils down to unsub works through the web interface, but not via the address? |
| [00:38:18] | Beirdo: | AFAIK |
| [00:38:34] | Beirdo: | we should just turn that back on anyways |
| [00:39:25] | Beirdo: | meanwhile, I'm deep in the bowels of mpegts.c |
| [00:48:50] | wagnerrp: | thats the way its always been |
| [00:49:06] | wagnerrp: | has there ever been anything to indicate you could email the manager to get unsubbed? |
| [00:49:41] | wagnerrp: | the only thing that seemed odd was that he needed authentication to unsub |
| [00:49:44] | Beirdo: | emails to -request is teh standard way to unsub |
| [00:50:02] | wagnerrp: | the only reason i would think that might happen is he forgot his sub password |
| [00:50:10] | Beirdo: | probably |
| [00:50:53] | wagnerrp: | IMHO, anyone experienced enough to know of a standard method of unsubbing from a mailing list, should know to read what the page says |
| [00:51:17] | wagnerrp: | not to say we shouldnt be able to do it that way |
| [00:51:36] | wagnerrp: | just that i dont understand the periodic people who to to do so |
| [01:03:47] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [01:04:16] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [01:25:44] | xris: | shouldn't need pw to unsub. it sends a confirmation message |
| [01:27:42] | Snow-Man: | huh? |
| [01:28:11] | Snow-Man: | the idea that I set something up is preposterous |
| [01:28:19] | Snow-Man: | I hardly set anything up |
| [01:28:19] | Snow-Man: | :D |
| [01:28:43] | Snow-Man: | I don't recally that being a configurable thing, fyi. |
| [01:29:13] | Snow-Man: | wagnerrp: people are dumb. that is all. |
| [01:29:48] | wagnerrp: | seriously, 4–5 times a year, theres someone posting to the list 'unsub me' |
| [01:30:03] | xris: | Snow-Man: you're the only one I know of who would have done anything to that bad that long ago. :) or would at least know who to blame from back then. |
| [01:32:50] | Snow-Man: | wow, 4–5 times *a year* |
| [01:32:56] | Snow-Man: | gee, we should JUMP RIGHT ON THAT |
| [01:32:59] | Snow-Man: | *cough* |
| [01:33:52] | Snow-Man: | xris: I would guess it's a mailman per-configured setup from ages past and that it was changed at some point but the debian maintainers didn't want to force-change existing settings |
| [01:33:57] | Snow-Man: | or something along those lines |
| [01:34:28] | Snow-Man: | I don't recall there being any specific reason to disallow it, so if there's an obvious option for it to be 'fixed', I'm all for doing so. |
| [01:34:39] | wagnerrp: | Snow-Man: no, i mean several times a year, people who have used enough mailing lists to know a common way to unsub is to post to the manager to be unsubscribed, but cant figure out to read the documentation page |
| [01:34:59] | Snow-Man: | of course, if you think that'll reduce the number of idiots posting to the list asking to be unsub'd.. you're sadly mistaken.. |
| [01:35:18] | wagnerrp: | its a disturbing dichotomy |
| [02:00:01] | Beirdo: | heh |
| [02:00:18] | Beirdo: | this mpegts.c sure is hard of the brains |
| [02:00:35] | Beirdo: | on the brains ratither |
| [02:00:46] | Beirdo: | OK, I give up. ECANTTYPE |
| [02:01:53] | Snow-Man: | hahaha |
| [02:05:32] | xris: | Snow-Man: higher priority would be reducing the number of idiots posting to the list… ;) |
| [02:05:50] | Beirdo: | declare it open season on morons? |
| [02:09:53] | wagnerrp: | first to go, anyone who insists on running their backend on an ARM or virtual machine? |
| [02:10:10] | Beirdo: | careful there... |
| [02:10:23] | Beirdo: | markk was playing with an ARM :) |
| [02:10:29] | wagnerrp: | as a backend? |
| [02:10:33] | Beirdo: | and several devs use vms for debugging :) |
| [02:10:44] | wagnerrp: | let me preface that with 'production' |
| [02:10:50] | Beirdo: | hmm, I think he was playing for frontend |
| [02:11:00] | Beirdo: | heh, OK, now you've got it. |
| [02:11:12] | wagnerrp: | ive got no problem with a ARM (beagleboard in his case) as a frontend |
| [02:11:21] | wagnerrp: | if someone ever gets around to writing decoder support for it |
| [02:11:32] | Beirdo: | hand me a crossbow, it's not sporting to shoot that kinda moron with a gun |
| [02:11:43] | wagnerrp: | and ive got no problem with using a VM for debugging and testing |
| [02:11:59] | Beirdo: | yeah, but as production.... kinda lame |
| [02:12:06] | wagnerrp: | but to use it in production, and then complain you cant get your PCIe tuner card to work? |
| [02:12:15] | wagnerrp: | ... GAH! |
| [02:13:19] | Beirdo: | heh, yeah |
| [02:19:28] | kth1 (kth1!~kth@dyndsl-085-016-232-101.ewe-ip-backbone.de) has joined #mythtv | |
| [02:20:56] | iamlindoro: | dblain: http://pastebin.com/Skw7wvMH If you've got a second |
| [02:21:34] | iamlindoro: | dblain: I can't figure out what I'm doing wrong here-- I get nothing abck and the backend logs: MethodInfo::Invoke – An Exception Occurred |
| [02:22:42] | kth (kth!~kth@unaffiliated/kth) has quit (Ping timeout: 276 seconds) | |
| [02:22:54] | iamlindoro: | AFAICT it's never even getting as far as the new method-- I've distcleaned everything, and it doesn't recognize it as an invalid method, just returns nothing and logs that |
| [02:32:02] | iamlindoro: | hmm... never mind, I seem to have gotten it, though I'm not sure how-- took out the error checking, initialized the artworktype variable, and that's it |
| [02:32:34] | Beirdo: | iamlindoro: looking at the video form #9926 |
| [02:32:40] | Beirdo: | from rather |
| [02:33:03] | Beirdo: | it seems it has a PMT, but it looks like it's thinking it's incomplete |
| [02:33:35] | Beirdo: | i.e. we have 183 bytes, and we need 382 |
| [02:33:50] | iamlindoro: | Beirdo: Any idea what upstream ffmpeg does differently? |
| [02:34:01] | Beirdo: | not yet :) |
| [02:34:11] | Beirdo: | and we really have no upstream for mpegts.c |
| [02:34:28] | iamlindoro: | right, though obviously we're insisting on something it doesn't |
| [02:34:32] | Beirdo: | it's been customized significantly from upstream over the years |
| [02:34:34] | Beirdo: | yeah |
| [02:34:42] | Beirdo: | that's the next thing I'm gonna look into |
| [02:35:10] | Beirdo: | I did a dvbsnoop and dumped the entire structure to text file, that was fun |
| [02:35:18] | iamlindoro: | heh, yeah, I imagine |
| [02:47:04] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [02:48:38] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [02:52:15] | Beirdo: | iamlindoro: I have a hack to make this work |
| [02:52:27] | Beirdo: | but I'm still trying to find why it's needed |
| [02:52:48] | Beirdo: | if I don't care that teh PMT is shorter than it says it should be, it works fine |
| [02:54:52] | Beirdo: | and now, I need to find an OLD upstream to see if it's coded differently for the version I have ffmpeg precompiled for |
| [02:55:45] | Beirdo: | I wonder if it's not something stupid in parsing the length |
| [02:59:38] | taylorr: | Beirdo: so can I just use "E" instead of "LOG_ERR"? |
| [02:59:52] | Beirdo: | no |
| [03:00:08] | Beirdo: | E is what is output when you put something as LOG_ERR |
| [03:00:20] | taylorr: | ah... gotcha |
| [03:00:23] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has joined #mythtv | |
| [03:02:58] | taylorr: | it'd be nice to have a shorter name... sometimes saving a few characters on a debug line keeps it below 80 characters |
| [03:06:08] | Beirdo: | the name LOG_ERR is from syslog (i.e. we use the same name, but defined separately) |
| [03:06:29] | Beirdo: | (as are the levels available, BTW) |
| [03:08:34] | taylorr: | Beirdo: I don't see that... syslog.h doesn't define them |
| [03:09:15] | Beirdo: | they do on my system |
| [03:09:27] | Beirdo: | well /usr/include/sys/syslog.h does |
| [03:09:37] | Beirdo: | which is included by /usr/include/syslog.h |
| [03:11:00] | taylorr: | ok... I see that... the is another syslog.h in the kernel headers that doesn't define them |
| [03:11:25] | Beirdo: | yeah, they try to confuse us :) |
| [03:11:48] | taylorr: | how is your hdpvr killer working? |
| [03:12:01] | Beirdo: | pretty well, actually |
| [03:12:13] | Beirdo: | gotta build out a few more in the next couple days too |
| [03:14:04] | taylorr: | I figure you setup a factory in China to do that for you :) |
| [03:14:44] | Beirdo: | hehe, if you make enough, sure |
| [03:15:41] | taylorr: | that surface mount IC looks like a pain to solder |
| [03:16:12] | Beirdo: | just a bit, but you get used to it. It's a royal PITA if you get it diagonal though, and not on the pads |
| [03:16:25] | Beirdo: | just need lots of liquid flux :) |
| [03:16:56] | Beirdo: | and steady hands... which is a challenge on days when I've had too much/not enough coffee |
| [03:18:16] | taylorr: | do you have your system setup to automatically restart your hdpvr if it fails? |
| [03:19:03] | Beirdo: | yeah, pretty much. I have a script that triggers on REC_STARTED that waits a bit and looks for 0-byte files |
| [03:19:18] | Beirdo: | if it's 0-bytes and from the HDPVR, it gets power cycled |
| [03:19:34] | Beirdo: | seems to work fairly well, most of the time |
| [03:20:02] | taylorr: | what really is needed is a driver for the Colossus card :) |
| [03:20:24] | Beirdo: | it also fires on REC_FINISHED (for use in livetv) to cancel a previous check |
| [03:20:33] | Beirdo: | heh, yeah, that would be nice too |
| [03:27:01] | Beirdo: | iamlindoro: our scan is totally different from the code for the ffmpeg version I have installed |
| [03:27:17] | Beirdo: | they used a scan for SDT, and went from there |
| [03:27:22] | Beirdo: | that's been removed in ours |
| [03:27:30] | Beirdo: | and we use PAT/PMT |
| [03:29:53] | Beirdo: | and the current libav code only checks PAT at startup, it seems |
| [03:30:01] | Beirdo: | still lookin |
| [03:34:45] | iamlindoro: | Beirdo: Perhaps a fallback-fallback to PAT only? |
| [03:35:09] | Beirdo: | I think the problem is that we need the details from the PMT |
| [03:36:00] | Beirdo: | but the PMT we are being given has a bad length, it seems. It works if we allow it to just take the first packet's worth... at least in this case |
| [03:37:18] | Beirdo: | I'll clean this up some more and see if I can post it as a potential patch to try other recordings against |
| [03:38:33] | Beirdo: | yet another hack in a pile of hacks... in this case, seemingly caused by a bad recording, not giving all the data for the PMT. sigh |
| [03:46:30] | highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 260 seconds) | |
| [03:46:48] | highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv | |
| [03:48:31] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:57:50] | Beirdo: | OK, I guess I can add this gracefully |
| [03:58:35] | Beirdo: | such that it will try allowing the full PMT to arrive... if it can't find any, try again with discarding at the end of the TS packet as a last gasp effort |
| [03:58:58] | Beirdo: | that way it shouldn't affect any current recordings from other sources |
| [04:13:32] | bill6502 (bill6502!~bill6502@2002:d850:4778:7cd3:9ef4:32ea:c6ea:200) has left #mythtv () | |
| [04:30:57] | kth1 (kth1!~kth@dyndsl-085-016-232-101.ewe-ip-backbone.de) has quit (Quit: Leaving.) | |
| [04:35:11] | Beirdo: | OK, I'm comfortable with that as a fallback |
| [04:35:13] | Beirdo: | committed |
| [05:04:48] | stuartm_ (stuartm_!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has joined #mythtv | |
| [05:04:48] | stuartm_ (stuartm_!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has quit (Changing host) | |
| [05:04:48] | stuartm_ (stuartm_!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [05:05:06] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Ping timeout: 240 seconds) | |
| [06:12:00] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 246 seconds) | |
| [06:25:27] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [07:36:57] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [07:38:35] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 250 seconds) | |
| [08:53:00] | jya (jya!~jyavenard@2a01:e35:2423:dd10:60c:ceff:fed2:908e) has joined #mythtv | |
| [08:53:00] | jya (jya!~jyavenard@2a01:e35:2423:dd10:60c:ceff:fed2:908e) has quit (Changing host) | |
| [08:53:00] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:57:02] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [09:20:52] | stuartm_ is now known as stuartm | |
| [09:24:55] | Beirdo: | stuartm: to warpme's db related hang... |
| [09:25:28] | Beirdo: | that maybe another place where we are misusing QSqlQuery and friends |
| [09:26:27] | Beirdo: | QSqlQuery is only supposed to be used from the same thread that created it, etc etc. We create the connections in one thread, use them everywhere, and delete them in the core context dtor |
| [09:26:43] | Beirdo: | we are likely screwing ourselves in some situations by misusing them |
| [09:27:15] | Beirdo: | in case you were thinking of looking at what he'd posted (-users ML) |
| [09:27:48] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [09:28:54] | Beirdo: | See http://doc.qt.nokia.com/latest/threads-module . . . e-sql-module |
| [09:29:49] | Beirdo: | the same core issue that causes our "mysql threads" issue on shutdown. |
| [09:30:08] | Beirdo: | although that one is fairly benign as we are shutting down anyways |
| [09:30:33] | Beirdo: | and with that disturbing thought, I *will* go to bed :) |
| [09:41:27] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Ping timeout: 255 seconds) | |
| [09:43:49] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv | |
| [10:00:32] | stuartm: | Beirdo: are the trac commit hooks something we control? It would be helpful to know who the commits were made by in the body of the ticket comment and that information is currently missing |
| [10:04:34] | stuartm: | iamlindoro: there's no harm in using the maximum compression for png, it's lossless so the quality is the same, it just takes a fraction of a second longer to open the image |
| [10:05:02] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:59] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:07:06] | stuartm: | the difference in size *might* be worth having when multiplied against 4 images for every video and hundreds of videos, iirc we use full compression for the theme image cache |
| [10:09:58] | stuartm: | http://code.mythtv.org/trac/ticket/9941 is why we have screenstacks, maybe they should have been used for the OSD |
| [10:26:22] | stuartm: | s/should have been/should be/ |
| [10:53:52] | jya (jya!~jyavenard@glg95-4-88-168-24-143.fbx.proxad.net) has joined #mythtv | |
| [10:53:52] | jya (jya!~jyavenard@glg95-4-88-168-24-143.fbx.proxad.net) has quit (Changing host) | |
| [10:53:52] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [11:57:45] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [11:59:39] | jya (jya!~jyavenard@glg95-4-88-168-24-143.fbx.proxad.net) has joined #mythtv | |
| [11:59:42] | jya (jya!~jyavenard@glg95-4-88-168-24-143.fbx.proxad.net) has quit (Changing host) | |
| [11:59:42] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [12:03:51] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [12:04:16] | davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [12:04:16] | davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [12:04:16] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [12:44:46] | foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has quit (Remote host closed the connection) | |
| [12:45:40] | foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has joined #mythtv | |
| [12:59:44] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [13:05:07] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:08:36] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [13:15:59] | Captain_Murdoch: | stuartm, RE: closing 9484/PLAY_UNPAUSED. thanks... |
| [13:16:53] | stuartm: | Captain_Murdoch: hope that I did good :) |
| [13:19:15] | stuartm: | xris, kormoc: is there anyone you feel could be given commit access to work on mythweb? It seems like it could use an injection of new blood to help with all the tickets and to keep things moving |
| [13:20:59] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:28:45] | skd5aner: | !seen janneg |
| [13:28:45] | MythLogBot: | janneg was last seen 111 days 23 hours 8 minutes 2 seconds ago |
| [13:32:13] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [13:32:21] | stuartm: | !seen jannau |
| [13:32:21] | MythLogBot: | jannau was last seen 73 days 5 hours 11 minutes 21 seconds ago |
| [13:32:39] | wagnerrp: | !seen janne |
| [13:32:39] | MythLogBot: | janne has not been seen here |
| [13:33:23] | danielk22: | janneg left, he's spending his time on libav these days. |
| [13:34:20] | wagnerrp: | yeah, explained that in the other channel |
| [13:37:39] | taylorr: | he hasn't been active with libav in a while |
| [13:38:02] | taylorr: | at least I don't see any posts in the past 2/3 months on the libav-devel mailing list |
| [13:43:20] | danielk22: | Beirdo: [a849a0b99] is odd.. The delete operator shouldn't crash on NULL pointers with a modern C++ |
| [13:48:50] | Captain_Murdoch: | paul-h, iamlindoro, the test videos issue was a typo on my part. it's fixed for now, but I want to rename another dir at some point (video -> videos) to make things consistent. |
| [13:49:14] | iamlindoro: | Captain_Murdoch: thanks for the fix |
| [13:50:24] | j-rod|afk is now known as j-rod | |
| [13:53:27] | stuartm: | danielk22: right, it's a no-op |
| [13:53:27] | skd5aner: | yea, I was just goofing around in Ohloh and his contribution graph was looking pretty good, then... blam, nothingness – just curious if he still hung out in here since then or not |
| [13:56:30] | stuartm: | danielk22, Beirdo: the backtrace doesn't show it segfaulting on deleting the pointer, it shows it faulting in QList following begin() |
| [13:57:57] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [14:01:16] | ** Captain_Murdoch catches up with scrollback ** | |
| [14:01:56] | Captain_Murdoch: | stuartm, I didn't even look at the commit, just loaded the ticket to see what you were talking about. it was simple enough and figured you tested so I trust you. :) |
| [14:17:51] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 260 seconds) | |
| [14:18:18] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [14:19:38] | jya (jya!~jyavenard@2a01:e35:2e47:b970:60c:ceff:fed2:908e) has joined #mythtv | |
| [14:19:42] | jya (jya!~jyavenard@2a01:e35:2e47:b970:60c:ceff:fed2:908e) has quit (Changing host) | |
| [14:19:43] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [14:25:44] | iamlindoro: | stuartm: I am looking in mythuihelper for the caching stuff, and the only spot I see save called on a mythimage, it doesn't have an argument for the quality parameter-- do you know if QImage uses max compression for PNG by default? That's how I had it originally but the scaled images were still a bit large |
| [14:26:50] | bill6502 (bill6502!~bill6502@2002:d850:4778:7cd3:9ef4:32ea:c6ea:200) has joined #mythtv | |
| [14:27:19] | iamlindoro: | stuartm: I was trying to write the APIs in such a way that they were appetizing to the MythWeb folks (and/or future mythweb folks) for use in spicing up the display of recordings and videos |
| [14:27:35] | iamlindoro: | (eg, as I hacked together last night: http://www.fecitfacta.com/upcoming.png) |
| [14:30:38] | stuartm: | iamlindoro: I mis-read the commit, I thought you were saying that it would default to uncompressed png, not that it previously used png |
| [14:31:15] | iamlindoro: | ahh |
| [14:31:34] | iamlindoro: | yeah, was saying that if one wants the unchanged version, they can just not pass a parameter that would make it scale |
| [14:42:06] | stuartm: | I believe QT defaults to 'best compression' for pngs, the docs used to specify but I can't seem to find the reference anymore |
| [14:46:43] | sphery: | stuartm: re: http://code.mythtv.org/trac/ticket/5863#comment:4 , can we do something about the "don't skip long commercial breaks" setting? Any ideas? |
| [14:49:20] | stuartm: | this is a setting that already exists? We could instead modify the commercial flagger to assume that any commercial over a certain length is a mistake and to discard that data |
| [14:50:08] | stuartm: | but eliminating the existing setting is a little more work than rejecting a patch to prevent a new one being added |
| [14:51:12] | stuartm: | I'm suprised that the flagger doesn't already have sanity checks for commercials which are too short/too long and which are therefore likely to be mistakes |
| [14:54:58] | stuartm: | I know it lacked some basic checks when I last used it, it would flag commercials which were seconds long, others 10–15 minutes long and commercials breaks which were just a minute or two after the last break |
| [14:55:26] | stuartm: | sphery: I have plenty of ideas, but no motivation to work on implementing them ;) |
| [14:56:39] | stuartm: | still it should be very easy to do a post-flagging review of the map and discard flags which appear to be in error |
| [14:56:44] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has joined #mythtv | |
| [14:57:15] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [15:02:35] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 258 seconds) | |
| [15:05:29] | sphery: | stuartm: yeah, already exists... Maximum commercial skip (secs): MythTV will discourage long manual commercial skips. Skips which are longer than this will require the user to hit the SKIP key twice. Automatic commercial skipping is not affected by this limit. |
| [15:06:31] | sphery: | I really want to get rid of it--I think it's a waste. It's just as easy to hit skip back if you skip and notice that you've gone too far as it is to hit skip, have it not skip, then hit skip again, then notice you've gone too far. |
| [15:07:07] | sphery: | and I think the setting is really a lot less interesting, now, since Capt M fixed commercial skip so it doesn't skip when it would take you to the end of the recording |
| [15:08:10] | sphery: | There's also a "Merge short commercial breaks (secs)", which borders on related to the #5863 one |
| [15:08:47] | sphery: | but, like you, I think we should trust the data in the DB--and if it's wrong, fix the code that's adding that data (i.e. better commercial detection) |
| [15:10:28] | VManiac16 (VManiac16!~Unknown@69.4.155.83) has quit (Read error: Connection reset by peer) | |
| [15:21:29] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [15:31:31] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [15:36:33] | sphery: | stuartm: just figured out what you meant by, "Beirdo: are the trac commit hooks something we control? It would be helpful to know who the commits were made by in the body of the ticket comment and that information is currently missing". You mean since it now just says, "Changes (by Github):". That was changed because some people were concerned about, "Changes (by <person without commit access>):" showing up when we commit with --author . |
| [15:36:52] | sphery: | but I agree that it makes it harder to see--especially when reviewing tickets--who did what when. |
| [15:41:21] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 276 seconds) | |
| [15:45:30] | Unhelpful (Unhelpful!~quassel@rockbox/developer/Unhelpful) has quit (Ping timeout: 255 seconds) | |
| [16:07:54] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [16:15:59] | Beirdo: | yes, we control that script. wagnerrp's modified it a few times. |
| [16:17:20] | wagnerrp: | sphery: we used to have the committer listed as the person making the changes on trac |
| [16:17:49] | wagnerrp: | but since the committer might not match up with a trac account, or may even be a non-dev, it was decided it was just too confusing |
| [16:18:06] | wagnerrp: | i can alter the hook so it adds the committer to the bottom, with the commit and branch |
| [16:19:29] | Beirdo: | danielk22: I thought it was odd too. The root of that crash though is brought on by freeing a NULL pointer, something we can easily avoid doing. Why it's NULL, and why it causes that particular crash, hard to say. Could be something smashing the heap or stack, I guess |
| [16:19:47] | Beirdo: | as I said, it was not a fix for the cause, but for the symptom |
| [16:19:57] | Beirdo: | feel free to completely redo it :) |
| [16:31:41] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has quit (Ping timeout: 252 seconds) | |
| [16:34:57] | foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has quit (Read error: Operation timed out) | |
| [16:38:19] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [16:39:33] | foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has joined #mythtv | |
| [16:41:29] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [16:45:27] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
| [16:56:36] | andreax (andreax!~andreaz@p57B9422D.dip.t-dialin.net) has joined #mythtv | |
| [17:02:50] | andreax1 (andreax1!~andreaz@p57B93E32.dip.t-dialin.net) has joined #mythtv | |
| [17:03:42] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [17:03:46] | andreax (andreax!~andreaz@p57B9422D.dip.t-dialin.net) has quit (Ping timeout: 264 seconds) | |
| [17:04:13] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [17:22:22] | andreax1 (andreax1!~andreaz@p57B93E32.dip.t-dialin.net) has quit (Ping timeout: 264 seconds) | |
| [17:22:55] | andreax (andreax!~andreaz@p57B93469.dip.t-dialin.net) has joined #mythtv | |
| [17:26:30] | andreax1 (andreax1!~andreaz@p57B944D5.dip.t-dialin.net) has joined #mythtv | |
| [17:28:00] | andreax (andreax!~andreaz@p57B93469.dip.t-dialin.net) has quit (Ping timeout: 250 seconds) | |
| [17:30:18] | danielk22: | Beirdo: As stuartm mentioned it's not segfaulting when handling the delete operator, but inside m_ChildrenList.begin() ; the code you committed should be harmless but doesn't actually address the segfault which probably has something to do with m_ChildrenList being invalid. |
| [17:31:21] | Beirdo: | which happened as a result of freeing a null value, or did I read it completely wrong? |
| [17:31:47] | Beirdo: | but yeah, it was probably pointless. |
| [17:32:02] | danielk22: | It looks like the it being null is red herring. |
| [17:32:06] | Beirdo: | sorry, it looked so easy late at night :) |
| [17:32:25] | Beirdo: | yeah, something else squashed the list, probably |
| [17:32:56] | Beirdo: | something like putting a stack pointer in there, maybe? instead of a heap pointer? |
| [17:36:06] | Beirdo: | anyways, I wouldn't be offended if ya rip that back out. At best, it's a band-aid |
| [17:39:12] | Mousey (Mousey!~wtfisme@ross154.net) has joined #mythtv | |
| [17:40:27] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [17:44:19] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer) | |
| [17:44:47] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [17:45:53] | andreax1 (andreax1!~andreaz@p57B944D5.dip.t-dialin.net) has quit (Ping timeout: 258 seconds) | |
| [17:46:33] | andreax (andreax!~andreaz@p57B92FF5.dip.t-dialin.net) has joined #mythtv | |
| [18:03:51] | danielk22: | Beirdo: It looks like the instance that m_ChildrenList is in is corrupted.. but I don't see how that is happening. |
| [18:07:56] | foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has quit (Remote host closed the connection) | |
| [18:08:13] | foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has joined #mythtv | |
| [18:08:24] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Quit: Leaving.) | |
| [18:17:39] | _gunni_ (_gunni_!~Gunni@koln-4db460d6.pool.mediaWays.net) has joined #mythtv | |
| [18:20:06] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat) | |
| [18:27:02] | wagnerrp: | stuartm: check out the second and third logs |
| [18:28:29] | wagnerrp: | track 12 on Laika Come Home fails at roughly 5:25 on the same file |
| [18:29:14] | wagnerrp: | the last timed log entries put are within a few seconds of that from when playback started |
| [18:29:40] | stuartm: | if it's memory corruption then it's an ffmpeg bug |
| [18:29:53] | stuartm: | but it's difficult to be sure of that without a sample |
| [18:30:32] | wagnerrp: | but yeah, i was confused by all three log files and both backtraces showing completely different errors |
| [18:32:21] | Unhelpful (Unhelpful!~quassel@rockbox/developer/Unhelpful) has joined #mythtv | |
| [18:34:15] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [18:44:40] | Beirdo: | paul-h: I just saw your comments on #9523. This is confirmed to be bad? I'll try to test some tonight to see if I can trace that down. At worst, I guess, a revert isn't out of the question if I can't find the issue. |
| [18:46:46] | kth (kth!~kth@unaffiliated/kth) has quit (Read error: Connection reset by peer) | |
| [18:51:16] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [18:55:18] | andreax1 (andreax1!~andreaz@p57B9308E.dip.t-dialin.net) has joined #mythtv | |
| [18:55:55] | andreax (andreax!~andreaz@p57B92FF5.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [18:56:13] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [19:07:34] | paul-h: | Beirdo: Definitely breaks things here I've had to revert that change on all the systems I maintain |
| [19:08:59] | Beirdo: | OK |
| [19:09:23] | Beirdo: | I'm sorry I missed it for so long. I'll look at it tonight, and one way or the other, it should be fixed :) |
| [19:10:01] | Beirdo: | not sure HOW that change would have the effect you are seeing, but it's gotta be fixed for sure |
| [19:18:31] | abqjp: | sphery: so, I take it that I am supposed to use QTextStream instead of std::stringstream ? |
| [19:19:30] | sphery: | kormoc: warpme posted a SHOW ENGINE INNODB STATUS at http://www.mythtv.org/pipermail/mythtv-users/ . . . /318469.html . Do you see anything of interest there. (My understanding is that would have shown us if, for example, the recorded table were locked, right?) |
| [19:20:52] | sphery: | abqjp: not sure... Makes sense to me (would use the Qt-detected locale/codec settings and all?) |
| [19:21:55] | _gunni_ (_gunni_!~Gunni@koln-4db460d6.pool.mediaWays.net) has quit (Quit: KVIrc KVIrc Equilibrium 4.1.1, revision: 5829, sources date: 20110403, built on: 2011-05-08 08:20:36 UTC 5829 http://www.kvirc.net/) | |
| [19:22:12] | abqjp: | sphery: looks like it. QTextStream does not provide a peek function, so I would have to change the logic a bit. |
| [19:22:38] | sphery: | stuartm: Looking at http://code.mythtv.org/trac/ticket/9936 , the problem is that lastScreen is false (because GetMythMainWindow()->GetMainStack()->TotalScreens() == 3) after we change themes. Any idea why that would be? |
| [19:25:41] | stuartm: | no, I haven't a clue |
| [19:28:58] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [19:29:42] | foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has quit (Quit: leaving) | |
| [19:30:31] | iamlindoro: | Beirdo: Know anything about this? |
| [19:30:32] | iamlindoro: | mythbackend |
| [19:30:32] | iamlindoro: | Unknown log level: unknown |
| [19:30:35] | iamlindoro: | and no start |
| [19:30:39] | iamlindoro: | maybe I need a distclean? |
| [19:30:49] | Beirdo: | worth a try |
| [19:31:08] | Beirdo: | I haven't seen it do that, but I did change some of the logic around over the weekend |
| [19:31:08] | iamlindoro: | giving it a shot |
| [19:31:17] | Beirdo: | if it still does it, let me know |
| [19:33:18] | iamlindoro: | Beirdo: same thing after a distclean |
| [19:33:26] | iamlindoro: | No init of mythcontext or anything, just that one line |
| [19:33:31] | Beirdo: | OK, one sec |
| [19:33:46] | Beirdo: | what's the commandline? just mythbackend? |
| [19:34:02] | iamlindoro: | but mythbackend alone, and mythbackend --logfile /foor/bar/blah.log |
| [19:34:09] | Beirdo: | OK, one sec |
| [19:39:03] | Beirdo: | what does mythbackend --help show as the default for -v? |
| [19:39:31] | Beirdo: | err, for --loglevel, rather |
| [19:41:37] | Beirdo: | ooooh |
| [19:41:43] | Beirdo: | heh, one moment. |
| [19:41:59] | ** Beirdo had a light bulb moment, please hold. ** | |
| [19:42:27] | iamlindoro: | Sorry, stepped away |
| [19:43:10] | iamlindoro: | I am not sure how to see default values |
| [19:43:27] | stuartm: | --help |
| [19:43:29] | iamlindoro: | oh, "defaults to unknown" |
| [19:43:30] | Beirdo: | should be in the text of --help |
| [19:43:43] | Beirdo: | yeah, it's that I hadn't initialized the map yet. |
| [19:43:46] | Beirdo: | fixing that |
| [19:44:07] | stuartm: | err, -v help |
| [19:44:36] | Beirdo: | the --loglevel one is in --help :) |
| [19:46:49] | Beirdo: | there. |
| [19:47:53] | Beirdo: | -v help still needs some help, I should look at that one after danielk's tweak. |
| [19:48:07] | iamlindoro: | Beirdo: Yeah, that seems better, thanks |
| [19:48:22] | sphery: | Captain_Murdoch / stuartm : The problem for #9936 is that the Theme Chooser calls the Reload Theme jump point with the pop argument set to false. All other uses of Reload Theme jump point use the default value of pop, which is true. Captain_Murdoch, I'm assuming that "false" meant you wanted it to stay on the Theme Chooser screen after it loaded the new theme, but it's not doing that--it's actually ending up on the Main Menu (which explains ... |
| [19:48:28] | sphery: | ... the extra screens on the stack). I don't know if it's going to the Main Menu is how it originally worked or if this is something that was broken in mythui or in mythfrontend's reloadTheme() (though no changes in there from this year look like they could be related). |
| [19:48:32] | Beirdo: | sorry about that silliness :) I always seem to use --loglevel debug and missed that |
| [19:48:44] | Captain_Murdoch: | stuartm, in the U.S., during sports events, we often have commercial breaks just minutes after a previous break (think timeouts near the end of a game). also, we already have a 'MaximumCommercialSkip' setting which is the longest break to skip in one SKIP command. we also have the 'CommDetectMaxCommBreakLength' setting which defaults to 395 seconds which should be the max commercial length detected. since we use weights, it |
| [19:48:44] | Captain_Murdoch: | could be that that is being overruled by other indicators though, so we could start enforcing that value in other locations in the code. |
| [19:48:52] | sphery: | Changing the false to a true (at https://github.com/MythTV/mythtv/blob/master/ . . . ser.cpp#L619 ) makes it go to the main menu and allows exit |
| [19:49:23] | Captain_Murdoch: | I'd be fine with getting rid of hte 'max commercial skip (secs)' setting that I just mentioend (and I see sphery mentioned in scrollback). |
| [19:51:35] | sphery: | Captain_Murdoch: so that means, I can remove max commercial skip (secs) and we can instead make teh CommDetectMaxCommBreakLength setting (not user-facing, right?) so that it's enforcing any min/max we feel is appropriate? |
| [19:52:06] | Captain_Murdoch: | sphery, actuall, I want it to go to the main menu. I thought there was another reason for that argument, but can't recall off the top of my head. |
| [19:52:13] | sphery: | but if we are going to suggest users set that value, I want to add a UI widget for it rather than have them edit it directly |
| [19:52:56] | Captain_Murdoch: | CommDetectMaxCommBreakLength is a hidden setting, only in the code, there's no UI to edit it. |
| [19:53:20] | Captain_Murdoch: | that was mainly for my testing, but we could expose it to users in favor of the other setting. |
| [19:53:36] | Captain_Murdoch: | I think some users are editting it, but I set it pretty high to try to prevent that. |
| [19:54:19] | Captain_Murdoch: | I think some countries actually have commercials longer than 6 minutes 35 seconds during movies |
| [19:54:45] | Beirdo: | I think I've seen longer than that occasionally in movies in US/Canada |
| [19:54:53] | Beirdo: | like a triple commercial break |
| [19:55:16] | Beirdo: | 10 minutes of mind-numbingness |
| [19:55:45] | Captain_Murdoch: | or 20 hits to the SKIP-30-second button. :) |
| [19:56:15] | Beirdo: | it works for a bathroom and make more popcorn break |
| [19:56:24] | sphery: | ok, github's blame says that the line "GetMythMainWindow()->JumpTo("Reload Theme", false);" was last modified by stuartm at changeset 1055e580 , but when I go to that changeset ( https://github.com/MythTV/mythtv/commit/1055e580 ), the code is "GetMythMainWindow()->JumpTo("Reload Theme");" |
| [19:56:33] | sphery: | how could someone have put the false in there without it showing in blame? |
| [19:56:57] | sphery: | Captain_Murdoch: that's what jump or # INFO is for :) |
| [19:58:02] | Beirdo: | sphery: line #? |
| [19:58:09] | sphery: | 619 |
| [19:58:13] | stuartm: | and according to that commit I didn't even touch that line |
| [19:58:21] | sphery: | yeah, this is why I'm so confused |
| [19:58:45] | stuartm: | github is matching up commits against the wrong lines? |
| [19:59:47] | stuartm: | caea1c7d (Chris Pinkham 2011-06–22 00:32:17 -0400 620) GetMythMainWindow()->JumpTo("Reload Theme", false); |
| [19:59:54] | stuartm: | according to git blame |
| [20:00:17] | stuartm: | https://github.com/MythTV/mythtv/commit/caea1c7d |
| [20:00:59] | Captain_Murdoch: | sphery, I think at one point, the way we are pushing ESCape key events to 'pop' windows was causing an issue on the theme chooser screen. I thought that when a theme reloaded we reinitialized everthing anyway, so that's why I think I remember passing 'false', to not bother popping if we were reinitializing anyway. |
| [20:01:36] | sphery: | yeah, stuartm found the commit where you put in the false... |
| [20:01:37] | Captain_Murdoch: | yeah, 'blame' here shows both of those lines as mine. |
| [20:02:24] | Captain_Murdoch: | it seems that a theme reload would have to pop all windows whether you want to or not. |
| [20:02:38] | sphery: | mine still says, "Not Committed Yet" changes--even though I backed out my changes... |
| [20:03:43] | Beirdo: | yeah, it was off by one line on the line number |
| [20:04:02] | Beirdo: | a git blame from the command line shows the JumpTo on line 620, |
| [20:04:21] | sphery: | So that's just a crazy github issue... guess I can't trust github for blames, either :) |
| [20:04:40] | Beirdo: | they trimmed the blank line a tthe top of the file |
| [20:04:43] | Beirdo: | argh! |
| [20:04:51] | sphery: | heh |
| [20:04:52] | Beirdo: | that's a bug, and should be reported to github |
| [20:05:15] | Beirdo: | of course, we don't NEED that blank line, but they should track it properly |
| [20:05:57] | sphery: | you want the honors? I think they don't like me--they moderated out my report of their javascript key bindings breaking for users with certain firefox settings because they don't want to allow you to disable their stupid keybindings |
| [20:06:18] | Beirdo: | my brain hurts too much to deal with them right now :) |
| [20:06:49] | sphery: | so, how long 'til we're on our own server and can make our repo the main one and have it just push changes to github? |
| [20:07:00] | sphery: | :) |
| [20:07:19] | Captain_Murdoch: | sphery, so that screen works fine for you without the 'false' in there? might have been an interaction with old code on our end or a specific Qt version issue. I added the false because the jumpto wasn't executing correctly when it tried to pop the ThemeChooser window out from under the user. |
| [20:07:44] | sphery: | it works fine, but I'm on a single combined frontend/master backend system |
| [20:07:52] | sphery: | no clue how it works with remote backends |
| [20:08:03] | Captain_Murdoch: | and I figured (wrongly) that everything was initialized again when we (re)loaded a theme. |
| [20:08:25] | Captain_Murdoch: | shouldn't matter local vs remote. by the time we jumpto, we already have the theme local and ready to use. |
| [20:09:36] | sphery: | OK, if that's the case, I'll push the change to remove the false arg (from both (using github's numbers) lines 619 and 799?) |
| [20:10:05] | sphery: | I'm not sure how to test the later one--with the THEME_INSTALLED message (is that for remote frontends?) |
| [20:10:22] | sphery: | or maybe that's only when it downloads a new theme |
| [20:10:30] | Beirdo: | I get that event :) |
| [20:10:39] | Captain_Murdoch: | yeah, that's triggered by the downlaod and install. |
| [20:11:01] | Beirdo: | I will be using it (still haven't coded it) to override background images |
| [20:11:14] | Captain_Murdoch: | and that was the case I think I was trying to fix specifically, so please test that before you commit anything that changes that line. |
| [20:11:26] | sphery: | ok, I'll test the download and install case, too |
| [20:12:37] | Captain_Murdoch: | thanks. |
| [20:13:22] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 264 seconds) | |
| [20:24:40] | Captain_Murdoch: | iamlindoro, how hard would it be to put in a check into the python grabbers to see if they work at all before we try to run grabbers for all recordings when each and every time it fails because of missing dependencies. in my case, it's not a new enough libxml2, but the housekeeper job is churning away getting an error message each and every time it tries to run the grabber. I assume this would happen every day as well looking |
| [20:24:40] | Captain_Murdoch: | at the housekeeper task setup. |
| [20:25:28] | iamlindoro: | Captain_Murdoch: I'll look into that, I believe there's a define for the python bindings |
| [20:26:14] | Captain_Murdoch: | ok, just something I noticed when starting up my dev MBE w/out the --nohousekeeper option for the first time in a while. |
| [20:26:47] | wagnerrp: | meaning if the deps to run the bindings and the grabbers are missing, ifdef out the code to run the housekeeper lookup? |
| [20:26:49] | Captain_Murdoch: | need to upgrade the MBE/fileserver sometime. |
| [20:27:05] | Captain_Murdoch: | wagnerrp, I just mean check that the grabber runs before trying to run it hundreds of times. |
| [20:27:24] | wagnerrp: | well iamlindoro was talking about the configure define, it sounded like |
| [20:27:36] | iamlindoro: | Captain_Murdoch: Can you try enclosing the run for the job in #ifdef CONFIG_BINDINGS_PYTHON ? |
| [20:28:15] | iamlindoro: | If the bindings are installed, it's because we have the deps, and if we have the deps, the job can run |
| [20:28:17] | Captain_Murdoch: | does that check for the version of libxml2, etc..? |
| [20:28:22] | Captain_Murdoch: | sorry, hit enter too soon. |
| [20:28:43] | wagnerrp: | we require lxml2, not libxml2 |
| [20:28:44] | Captain_Murdoch: | is that configure #define set based on whehter we find the new enough libxml2? |
| [20:28:55] | wagnerrp: | lxml may in turn require libxml |
| [20:29:02] | Captain_Murdoch: | ! Error – The installed version of the "lxml" python library "libxml" version is too old. |
| [20:29:05] | Captain_Murdoch: | yeah. |
| [20:29:06] | iamlindoro: | It's defined based on whether or not the bindings are installed, which is contingent upon new enough deps, yes |
| [20:29:23] | iamlindoro: | configure won't install the bindings without the deps being met |
| [20:29:50] | wagnerrp: | it tries to import 'lxml' during configure, and if it fails, refuses to install them |
| [20:30:07] | iamlindoro: | Realistically, though, it would be nice if we could require the python bindings to be installed at this point |
| [20:30:14] | iamlindoro: | We're building a lot of functionality around them |
| [20:30:16] | stuartm: | did we ship mythffplay in 0.24? |
| [20:30:21] | iamlindoro: | stuartm: yes |
| [20:30:27] | stuartm: | thanks |
| [20:30:35] | iamlindoro: | stuartm: At least... I think we did :) |
| [20:30:39] | wagnerrp: | i still cant figure out why i dont have one of those |
| [20:32:17] | stuarta: | iamlindoro: well if you do that you have to make sure configure can find them if you pass a prefix to it |
| [20:33:32] | stuarta: | ie. i build with --prefix=/usr/local/myth-0.24 or myth-svn and iirc the plugins can't find them |
| [20:34:02] | iamlindoro: | stuarta: pretty sure we have an argument to specify which python to use, which in turn would know where to look for its libs |
| [20:34:24] | Captain_Murdoch: | --python=/usr/bin/python2.6 |
| [20:34:33] | stuarta: | it's not where to find python |
| [20:34:41] | stuarta: | it's where to find where we install our libs |
| [20:34:58] | wagnerrp: | eh? |
| [20:35:04] | iamlindoro: | python doesn't work that way |
| [20:35:35] | wagnerrp: | if you set prefix to /usr or /usr/local, the bindings will ignore the setting and install where they want to |
| [20:35:54] | wagnerrp: | if you set it elsewhere, they will install elsewhere, and its up to you to configure python to know about the new path |
| [20:36:43] | wagnerrp: | it was decided if the user wants to install outside the standard paths |
| [20:36:50] | wagnerrp: | we shouldnt be doing tinkering to ensure it works |
| [20:37:05] | stuarta: | hmmm, i only pass a prefix, not tinker with the python paths |
| [20:37:41] | stuarta: | wagnerrp: btw. are our libs versioned. ie. can the 0.24 and master libs coexist? |
| [20:38:09] | sphery: | stuarta: pretty sure it wasn't shipped with 0.24, but was added to -fixes, and is shipped with 0.24.1 |
| [20:38:10] | wagnerrp: | depends on the distro i think |
| [20:38:48] | stuarta: | when building from source |
| [20:39:06] | sphery: | er, wrong stuart... |
| [20:39:10] | Captain_Murdoch: | iamlindoro, needed a #ifdef CONFIG_BINDINGS_PYTHON since that is always defined as either 0 or 1 |
| [20:39:12] | wagnerrp: | actually no, the trunk bindings are still listed as 0.24.0, so they will overwrite previous bindings regardless |
| [20:39:14] | sphery: | stuartm: pretty sure it wasn't shipped with 0.24, but was added to -fixes, and is shipped with 0.24.1 |
| [20:39:21] | Captain_Murdoch: | odd, that didn't paste correctly. |
| [20:39:37] | stuarta: | hmmm, no idea which python libs i'll end up with then |
| [20:39:40] | Captain_Murdoch: | it needed "#if CONFIG_BINDINGS_PYTHON |
| [20:39:50] | ** stuarta has co-habiting installs of 0.24 and master ** | |
| [20:39:52] | iamlindoro: | Captain_Murdoch: OK... if that works for you, feel free to commit |
| [20:40:01] | wagnerrp: | stuarta: if you are installing them outside of /usr or /usr/local, you will get neither |
| [20:40:25] | wagnerrp: | configure your backend init script to alter the environment and tell it where to pull additional modules from |
| [20:40:39] | stuarta: | so after having a quick look |
| [20:40:45] | wagnerrp: | with the PYTHONPATH environmental variable |
| [20:41:06] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [20:41:12] | stuarta: | 0.24 stuck it into /usr/local/myth-0.24/lib/python..... |
| [20:41:36] | wagnerrp: | i.e. PYTHONPATH=/usr/local/myth-0.24/lib/python2.6 mythbackend |
| [20:42:41] | wagnerrp: | i could add a line to the bottom of configure to warn that the modules are being installed to a non-standard location |
| [20:42:47] | stuarta: | no idea where it went in master |
| [20:42:49] | wagnerrp: | and that users will have to update their system to match |
| [20:43:05] | stuarta: | i'll check it wasn't missing a lib at build time as this is a new box |
| [20:45:14] | Captain_Murdoch: | iamlindoro, committted. (also tested by changing the 0 to a 1 in the config .h file and verifying that it tried to run the grabber after recompiling/reinstalling. |
| [20:45:19] | iamlindoro: | Captain_Murdoch: Of course this now introduces the assumption that grabbers will always be python, and will always require the python bindings (versus perl, or a python script which doesn't use the bindings) |
| [20:45:37] | iamlindoro: | Captain_Murdoch: Sure I can't convince you it's a good idea to just require the bindings? |
| [20:45:37] | Captain_Murdoch: | now ya tell me. :) |
| [20:46:00] | iamlindoro: | Well, I think this works for now, there's only two mythtv-compatible grabber scripts, and both require the bindings |
| [20:46:04] | Captain_Murdoch: | IMHO, I think that if the script fails once, we should remember that and not try to run it again. |
| [20:46:28] | Captain_Murdoch: | if it fails for dependency reasons. in fact, this is probably an old version of the script anyway, so I probably shouldn't have it installed I guess. |
| [20:46:31] | wagnerrp: | did we ever remove those additional requirements picked up by smolt? |
| [20:47:18] | iamlindoro: | Captain_Murdoch: I really don't have any visibility on why grabbers fail-- It could just as easily be that the conneciton was down, the API on the far side was malfunctioning, etc... how would you forsee me handling all that? |
| [20:47:46] | iamlindoro: | And why, in an otherwise working system that has an intermittent problem, would we want to give up forever on looking up an item, or even worse, everything? |
| [20:47:48] | Captain_Murdoch: | iamlindoro, I know, that's why I asked my original question. wondering if grabbers should return some specific value to indicate that they'd never ever work, so why run them again. |
| [20:48:03] | wagnerrp: | iamlindoro: you have a trio of babies from drug addled mothers in a tank in your basement |
| [20:48:08] | Captain_Murdoch: | it's one thing if the site is down or the internet is down, those will recover (hopefully). |
| [20:48:29] | iamlindoro: | That would only be of value in a single run of the script... how would we handle when the user fixed the problem? |
| [20:48:51] | Captain_Murdoch: | hence the comment saying these may be old scripts installed since configure doesn't set it up to install python bindings currently. I may be on old bindinds. |
| [20:49:01] | Captain_Murdoch: | restart MBE, continue. |
| [20:49:28] | Captain_Murdoch: | or else just rmemeber it for that running sequence. if it fails the first time out of 200, because of some reason, then it will probably fail the other 199. |
| [20:49:52] | iamlindoro: | I dunno, I have had a failure or two in a large run before, it happens |
| [20:49:56] | Captain_Murdoch: | if the internet is down when the artwork housekeeping job starts, it will probably still be down when the 200th grabber is run a few minutes later. |
| [20:50:11] | iamlindoro: | This begins to sound worryingly like mindreading |
| [20:50:22] | Captain_Murdoch: | that's why I said it's one thing if the internet is down, but it's another if the script won't run at all. |
| [20:50:24] | iamlindoro: | or where we tryi to cover a corner case and end up hobbling the dominant case |
| [20:50:40] | Captain_Murdoch: | and why I said it's probabl due to my old bindings installed. |
| [20:50:56] | iamlindoro: | You are starting a lot of sentences with "that's why I said" |
| [20:51:09] | wagnerrp: | iamlindoro: is the housekeeper set up that you can postpone a task until later? |
| [20:51:32] | iamlindoro: | I am just expressing that I see a lot of cases where trying to handle a single failure sould hobble an otherwise working system |
| [20:51:37] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [20:51:53] | wagnerrp: | you could add another query to the grabber format to 'test connection to data source' |
| [20:51:57] | iamlindoro: | wagnerrp: I don't believe so |
| [20:52:04] | wagnerrp: | if that fails, postpone the task an hour or so |
| [20:53:46] | iamlindoro: | wagnerrp: don't think we have a facility for doing so right now |
| [20:55:11] | iamlindoro: | wagnerrp: Alternately, could add an argument to mythpython which tests everything and returns a known value |
| [20:55:29] | iamlindoro: | I could easily run that at the top of a mythmetadatalookup run |
| [20:55:53] | wagnerrp: | it could test for availability of dependencies |
| [20:55:59] | wagnerrp: | but it wouldnt know anything about the grabber scripts |
| [20:56:06] | iamlindoro: | A failure at the sources will time out-- we already handle that, so I don't think we need the deferral necessarily |
| [20:56:17] | sphery: | for delaying, you could modify the wantToRun() period values (since they're hard coded to 0/24, it wouldn't be messing with anyone's settings/desired config) |
| [20:56:39] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: Dog + 10 hours alone = Carpet Cleaning Duty.) | |
| [20:57:21] | Captain_Murdoch: | wouldn't it make sense to have a 'test mode' for each grabber to see if that grabber worked? with 3rd party grabbers, will we assume they work and just run them over and over when they're failing because of a missing dependency, etc..? |
| [20:57:37] | iamlindoro: | Captain_Murdoch: Something occurs to me, also... if you don't want the housekeeper job to run, why don't you just turn it off using the UI control? |
| [20:57:52] | iamlindoro: | Setup->Artwork and Data Sources, turn off the checkbox |
| [20:58:04] | Captain_Murdoch: | why can't it automatically detect? :) we're trying to reduce settings... |
| [20:58:20] | Captain_Murdoch: | you're one of the main proponents of that. :) |
| [20:58:32] | iamlindoro: | For all the good it does me |
| [20:58:56] | Captain_Murdoch: | I think mine is a broken system, but think that we should autodetect whether a grabber works before running it 1000 times every day for a user's 1000 recordings. |
| [20:59:33] | iamlindoro: | I honestly have myface in my hands right now |
| [20:59:45] | iamlindoro: | If it's a broken system, you fix the system |
| [20:59:55] | iamlindoro: | you don't write a bunch of code to avoid annoying the user with a broken system |
| [21:00:18] | Captain_Murdoch: | if (testcommandresult != 1) then return; |
| [21:00:18] | sphery: | Captain_Murdoch: OK, I think the reason you added false was because with pop = true, it pops the theme chooser screen and goes to the main menu as shown for the old theme, then eventually updates to the new theme. with pop = false, it stays on the theme chooser page until it flips to main menu of new theme. |
| [21:00:41] | sphery: | so if we want to allow that, maybe we need to rework the reload theme to pop all screens? |
| [21:00:45] | Captain_Murdoch: | sphery, sounds like that might have been the case. I don't recall, it was a while ago and a late night I believe. |
| [21:00:53] | iamlindoro: | Captain_Murdoch: So now we bog the whole system down even more running unnecessary commands on what is acknowledged to be a broken system? |
| [21:01:10] | Captain_Murdoch: | I think reload theme needs to pop all by default since the underlying screens would be totally hosed I'd think if we're using a new theme. |
| [21:02:17] | sphery: | yeah, that sounds like a better fix, anyway, so that we don't get this same problem some other way in the future |
| [21:02:20] | Captain_Murdoch: | iamlindoro, run a test command once vs running the grab command 1000x? forget about it. my system is broken. I'm just trying to eliminate user issues after release. not all users are on 24x7, not all will know about the new automated artwork grabber. not all will want the new automated artwork grabber even if most of us like it. |
| [21:02:33] | Captain_Murdoch: | s/users are on/users are online/ |
| [21:03:16] | iamlindoro: | Captain_Murdoch: Each of those is a disparate issue-- But to address not every user wanting it, they *do* have the capacity to turn it off |
| [21:03:48] | Captain_Murdoch: | right, and autodetecting is a simple check. "does the test command work", if not, then abort the housekeeper job, if it does work, then continue. |
| [21:04:19] | ** Captain_Murdoch goes to think about other things like having to changing a dirty diaper, etc.. :) ** | |
| [21:04:39] | iamlindoro: | Captain_Murdoch: Well, setting aside the fact that it's not just one command that you can test and run, the decision about what grabber gets run is deep in the metadata classes, so minimally it would have to run through all configured scripts and test them |
| [21:05:24] | iamlindoro: | That said, fine, I'll implement it, but since I have no python capabilities at all, someone is going to have to write a test command into each of the grabbers |
| [21:06:10] | iamlindoro: | wagnerrp: If you are game to scratch the itch of others, -t is probably the sensible choice of switch-- I can add code to test all the grabbers to the metadata classes |
| [21:07:22] | wagnerrp: | sure, ill look through the APIs and see if there is a real way to test the servers |
| [21:07:34] | wagnerrp: | otherwise, ill just try to pull the main page |
| [21:07:54] | iamlindoro: | wagnerrp: Well, I'd rather just test the local functionality |
| [21:08:26] | iamlindoro: | otherwise, we will fail for *all* grabbers if even one is intermittent |
| [21:08:37] | iamlindoro: | since I need to be able to test the whole environment in one step |
| [21:09:23] | iamlindoro: | I really don't want to have to build in some half baked functionality where we try to guess what grabber we're going to use, and only handle that content |
| [21:10:34] | wagnerrp: | so just check to see if all dependencies are available? that should be easily doable |
| [21:12:10] | iamlindoro: | sigh, I just know that if we do it this way, someone will still complain that we don't test connectivity... so whatever, might as well add that in too |
| [21:12:19] | iamlindoro: | Doesn't mean we have to check for it everywhere |
| [21:12:23] | iamlindoro: | just where we do batch jobs |
| [21:16:20] | stuartm: | ok, the flac crash isn't an upstream bug :( |
| [21:18:45] | stuartm: | it's a shame janneg isn't around |
| [21:19:38] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [21:20:02] | iamlindoro: | wagnerrp: I assume we'll communicate this through return codes... know of the top of your head how to get the return code with MythSystem? |
| [21:23:56] | wagnerrp: | should be whatever returns from .wait() |
| [21:24:34] | iamlindoro: | as an int? |
| [21:24:43] | iamlindoro: | uint, looks like |
| [21:24:47] | wagnerrp: | Wait(), uint |
| [21:24:48] | wagnerrp: | right |
| [21:25:22] | iamlindoro: | What do you want to return for good v bad? |
| [21:25:55] | wagnerrp: | just the normal, 0 for good, anything else for bad |
| [21:26:13] | wagnerrp: | actually |
| [21:26:18] | wagnerrp: | cant you just use -v for that? |
| [21:26:56] | wagnerrp: | just make sure -v loads everything it might need |
| [21:27:07] | wagnerrp: | if it fails to load, it errors out |
| [21:29:18] | foobum (foobum!~mythtv@78-105-15-213.zone3.bethere.co.uk) has joined #mythtv | |
| [21:30:43] | iamlindoro: | wagnerrp: I suppose so, and had been thinking that, but it does introduce the kink that -v must now import/include all deps |
| [21:30:52] | iamlindoro: | which is not an expected requirement |
| [21:31:16] | iamlindoro: | We have at least one perl grabber script (for games) that simply echos the correct version XML |
| [21:31:33] | iamlindoro: | that's not an unreasonable way of doing it, and I expect that other grabber authors might do the same |
| [21:33:48] | iamlindoro: | It also requires that it connect to and test the site if we're going to do that |
| [21:34:10] | iamlindoro: | which means you can't even configure the script in the UI (which requires -v output) if the site isn't up |
| [21:36:21] | okolsi: | Beirdo: reg #7118, just about to go for a trip, i'll try to find an example file after ~5–6 days |
| [21:38:08] | Beirdo: | OK, that's fine :) |
| [21:38:24] | Beirdo: | thanks. It's sat a long time anyways, another week won't kill it |
| [21:38:49] | wagnerrp: | jams: patch committed |
| [21:42:45] | iamlindoro: | wagnerrp: Added code to the metadata classes to test each grabber with -t. Can always change it if you want to do things a different way. It's not actually tested anywhere but the infrastructure exists when you are done with the scripts |
| [21:42:51] | paul-h (paul-h!~paulh@mythtv/developer/paul-h) has quit (Remote host closed the connection) | |
| [21:52:56] | paul-h (paul-h!~paulh@5adce259.bb.sky.com) has joined #mythtv | |
| [21:52:56] | paul-h (paul-h!~paulh@5adce259.bb.sky.com) has quit (Changing host) | |
| [21:52:56] | paul-h (paul-h!~paulh@mythtv/developer/paul-h) has joined #mythtv | |
| [21:57:14] | j-rod is now known as j-rod|afk | |
| [22:03:34] | jams: | thx..the server side is ready to go. Just waiting on the new mythtv server to be reimaged/account setup. |
| [22:05:26] | iamlindoro: | wagnerrp: http://pastebin.com/5zE1vtrH |
| [22:05:41] | iamlindoro: | That, on top of the stuff to master just now, should test the movie and tv grabbers with -t |
| [22:06:23] | ** xris wonders if it's worth preordering a hauppauge WinTV-DCR-2650 ** | |
| [22:06:45] | wagnerrp: | dont do it from amazon |
| [22:07:51] | xris: | heh |
| [22:07:57] | xris: | no. would be straight from hauppauge |
| [22:08:08] | xris: | they're giving a $20 discount on it now. $130 vs $150 |
| [22:09:02] | iamlindoro: | xris: Per the Hauppauge guys, it will work with libhdhomerun |
| [22:09:08] | xris: | well, $10 off if you take the $10 shipping into account. |
| [22:09:17] | xris: | iamlindoro: yeah, just reading your reply on -users |
| [22:09:19] | xris: | + |
| [22:09:28] | iamlindoro: | yeah, should be nice-- suddenly we have all these options |
| [22:09:38] | jams: | but only for the exclusive club of hauppauge facebook friends |
| [22:09:42] | xris: | hard to beat the price on the hauppauge one. |
| [22:10:00] | xris: | jams: the discount link is in google's index... |
| [22:10:20] | xris: | granted, I think I liked them on Facebook, but wouldn't have a cookie on their site. |
| [22:10:26] | jams: | was just reading whats on their page |
| [22:10:43] | xris: | yeah |
| [22:10:52] | iamlindoro: | wagnerrp: Captain_Murdoch: http://pastebin.com/HJSsCKQt |
| [22:11:06] | xris: | then will come the difficulty of getting a cable card from Comcast... |
| [22:11:23] | xris: | (mostly an inconvenient drive up north to their office) |
| [22:12:19] | stuartm: | xris: they won't deliver it? |
| [22:12:46] | xris: | stuartm: not for free.. at least not when I've ordered/exchanged cable boxes. |
| [22:18:10] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit (Ping timeout: 252 seconds) | |
| [22:22:17] | xris: | nice. cable card cost is WAY less than a cable box. |
| [22:26:13] | xris: | then again, they won't let me self-install a cable card. wtf. $25 fee for them to come out and plug a card into the slot. |
| [22:26:51] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv | |
| [22:28:45] | sphery: | xris: http://www.gossamer-threads.com/lists/mythtv/users/477956#477956 (not sure which day in July, but there aren't many left) |
| [22:29:29] | sphery: | xris: might also want to read this thread: http://www.gossamer-threads.com/lists/mythtv/users/486214#486214 |
| [22:29:45] | xris: | ah, nice |
| [22:30:40] | stuartm: | "Either the server is down or the master server settings in mythtv-settings does not contain the proper IP address" |
| [22:30:49] | stuartm: | shouldn't that be mythtv-setup? |
| [22:32:15] | iamlindoro: | definitely |
| [22:43:40] | xris: | sphery: local office knows more than the online people. they have them at the store, and will someday ship, but can't at the moment. |
| [22:44:29] | xris: | now to decide if $25 install fee is worth not driving 30–40 minutes each way out of my way to go to the comcast store. |
| [22:45:21] | iamlindoro: | For me I'd take the drive to avoid having to fight with some installer about what Linux is, and whether it's okay to install the card in the system, and explain that Windows doesn't live here |
| [22:46:55] | xris: | heh |
| [22:47:04] | xris: | I can always boot win7 up in vmware |
| [22:47:31] | mrand: | hahaha |
| [22:47:54] | xris: | .. which lives on the mac. not the mythtv box. that'll surely help avoid confusion. :) |
| [23:00:45] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [23:04:31] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit (Read error: Connection reset by peer) | |
| [23:08:54] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
| [23:15:10] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv | |
| [23:57:35] | stuartm: | Beirdo: mythpreviewgen no longer seems to be respecting the fact that the backend is daemonized and it's logging to the console |
| [23:58:25] | stuartm: | it was working a couple of days ago |
| [23:58:49] | Beirdo: | I was afraid that would happen |
| [23:59:27] | Beirdo: | sigh, that's due to the request danielk had to allow logging to the console when we are in quiet mode (for LOG_ERR and above) |
| [23:59:49] | Beirdo: | I'll hit it again with a clue-by-4 and get it back into submission |
| [23:59:58] | Beirdo: | sorry about that. |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.
){kind=link}