| Wednesday, July 20th, 2011, 00:13 UTC | ||
| [00:13:22] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has joined #mythtv | |
| [00:18:12] | andreax1 (andreax1!~andreaz@p57B9456C.dip.t-dialin.net) has joined #mythtv | |
| [00:18:56] | andreax (andreax!~andreaz@p57B945B7.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [00:23:01] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [00:34:51] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has quit (Quit: abqjp) | |
| [00:48:00] | dblain: | danielk22: What's the purpose of adding mutable in 4bc5e52e023247b51b2d? |
| [01:04:06] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [01:04:32] | davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [01:04:40] | davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [01:04:40] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [01:11:33] | danielk22: | dblain: It looked like GetUDN() didn't really change the state of the class and could be const because m_sUDN was just a cache variable. Did I misread that? |
| [01:14:38] | andreax1 (andreax1!~andreaz@p57B9456C.dip.t-dialin.net) has quit (Quit: Leaving.) | |
| [01:24:58] | Ricky-Bobby (Ricky-Bobby!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [02:07:27] | _klk_ (_klk_!~Adium@208.90.215.163) has quit (Quit: Leaving.) | |
| [02:32:05] | Beirdo: | OK, finally time to head home. Stupid server must have known I wanted to go home early, and decided to die instead. |
| [03:00:32] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:19:48] | dblain: | danielk22: I missed the fact that you turned GetUDN() into a const function. I usually try to avoid the use of mutable, but it makes more sense now. |
| [03:54:12] | MaverickTech (MaverickTech!~MaverickT@dns2.arel.com.au) has joined #mythtv | |
| [04:07:45] | kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 276 seconds) | |
| [04:20:28] | kc (kc!~Casper@unaffiliated/kc) has joined #mythtv | |
| [04:27:13] | kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 240 seconds) | |
| [04:40:20] | kc (kc!~Casper@unaffiliated/kc) has joined #mythtv | |
| [05:11:25] | MaverickTech (MaverickTech!~MaverickT@dns2.arel.com.au) has quit (Ping timeout: 250 seconds) | |
| [05:12:31] | xris: | wagnerrp: haven't had a single recording get queued for commflag since your changes. wondering if I just have an odd db setting that is now getting checked correctly to disable them, but the db flags all look good to me. |
| [05:13:39] | dudz_ (dudz_!~dudz@123-243-44-131.static.tpgi.com.au) has joined #mythtv | |
| [05:15:11] | wagnerrp: | my changes wouldnt have made any difference for queuing |
| [05:15:25] | wagnerrp: | however i have noticed that the (few) recordings ive made since |
| [05:15:37] | wagnerrp: | commflagging live behind a recording does not return any results |
| [05:15:56] | wagnerrp: | and theres some other issue with seektables being build |
| [05:15:59] | wagnerrp: | built |
| [05:19:23] | Beirdo: | again? |
| [05:19:40] | Beirdo: | that just keeps coming back to boot us in the arse |
| [05:23:37] | xris: | wagnerrp: that could be... I have live commflag enabled. |
| [05:23:47] | xris: | though for the life of me I can't remember the name of the setting |
| [05:24:00] | Beirdo: | Oooh, didn't think of that one |
| [05:24:12] | xris: | ah. AutoCommflagWhileRecording |
| [05:24:19] | xris: | yeah, I hadn't thought of it either |
| [05:24:46] | Beirdo: | need the NeuralSettingsLinker class, I tell ya |
| [05:25:03] | xris: | heh |
| [05:25:56] | xris: | I wonder if there was some sort of change in balance that caused just enough delay for the live commflag job to think the recording wasn't there, and abort with no error |
| [05:26:24] | Beirdo: | quite possibly |
| [05:27:21] | xris: | line 3872 of mythtv/libs/libmythtv/tv_rec.cpp |
| [05:27:28] | xris: | that's where it would happen. |
| [05:27:35] | xris: | beyond that, I can't reallys ay. |
| [05:29:00] | Beirdo: | it's possible that the JOB_LIVE_REC ones are somewhat hosed |
| [05:29:23] | Beirdo: | with all the changes to the ring buffer and seeking, etc... |
| [05:30:11] | xris: | that could make sense. when it tries the live rec, it removes the commflag job from the queue mask |
| [05:30:15] | xris: | so they wouldn't get requeued |
| [05:30:37] | Beirdo: | yeah, so if the LIVE_REC doesn't work right or quits early or something... |
| [05:31:22] | xris: | then the normal queue process works properly, and has removed the commflag job from the work order, so to speak |
| [05:31:45] | Beirdo: | yeah |
| [05:31:58] | Beirdo: | that does narrow down what needs some love |
| [05:39:15] | xris: | what about this? http://pastebin.com/WpJrgrpS |
| [05:42:36] | Beirdo: | yeah, that's come up before... I didn't realize that it was only in the context of live commflag though |
| [05:43:02] | xris: | my backend log is full of that |
| [05:43:04] | xris: | no clue if it is. |
| [05:43:53] | Beirdo: | that's the GOP_BYFRAME marker |
| [05:43:56] | Beirdo: | so seek table |
| [05:44:25] | Beirdo: | heh, and in the recordedseek table, duh :) |
| [05:46:59] | jmartens (jmartens!~jmartens@109.232.42.33) has joined #mythtv | |
| [05:48:34] | xris: | anyway, that's the only error I see in my backend log |
| [05:48:54] | xris: | it happens all over the place, though.. and recordedseek has plenty of data about that show |
| [05:49:01] | xris: | os it obviously finished that much |
| [05:49:46] | xris: | always type=9, though |
| [05:51:49] | Beirdo: | yeah, if it's just a duplicate key issue, it *should* have the data already :) |
| [05:58:06] | wagnerrp: | right, but the question is... why is the commflagger generating that data |
| [06:01:58] | xris: | maybe it's not? |
| [06:03:09] | Beirdo: | well, that's the error in your logs |
| [06:03:42] | xris: | yeah, but does it say commflag/ |
| [06:04:04] | Beirdo: | Oooh look I can experiment again, recording finished |
| [06:04:08] | xris: | ok, found 2 log entries for commflg start. presumably one from live, and I'm pretty sure the second is from when I queued it manually (timestamp matches up with other recording queued at the same time) |
| [06:04:10] | kenni (kenni!~kenni@x1-6-00-00-24-c8-e2-a3.k456.webspeed.dk) has joined #mythtv | |
| [06:04:10] | kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv | |
| [06:04:10] | kenni (kenni!~kenni@x1-6-00-00-24-c8-e2-a3.k456.webspeed.dk) has quit (Changing host) | |
| [06:04:21] | Beirdo: | ah |
| [06:04:27] | andreax (andreax!~andreaz@p57B9456C.dip.t-dialin.net) has joined #mythtv | |
| [06:04:32] | xris: | would be nice if the log could differentiate between the types of flag jobs |
| [06:04:50] | Beirdo: | no reason it can't |
| [06:05:34] | xris: | what are the two [##/##] things in the log? |
| [06:05:45] | Beirdo: | pid and tid |
| [06:06:02] | Beirdo: | pid of the main process, pid of the thread, essentially |
| [06:06:50] | xris: | ok. just wanted to confirm |
| [06:07:03] | Beirdo: | 4 minutes left on playback, then I restart the backend and torture it a bit more |
| [06:07:41] | Beirdo: | nobody expects the Spanish Inquisition! |
| [06:07:55] | xris: | interesting. recording and db errors coming from the same thread... |
| [06:08:05] | Beirdo: | yeah |
| [06:08:10] | xris: | I wonder if this has something to do with commflag going faster than the recording happens. |
| [06:08:29] | xris: | commflag enters the seek table entry, then the rec can't do it. |
| [06:08:36] | Beirdo: | it's possible that got borked, yes |
| [06:13:16] | Beirdo: | so... the backend will crash with a Qt Warning/ABORT if you kill the DB while the BUSQ is running |
| [06:18:12] | wagnerrp: | that may also cause the screwy behavior that makes commflagging detect nothing |
| [06:19:46] | andreax (andreax!~andreaz@p57B9456C.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [06:24:56] | dudz_ (dudz_!~dudz@123-243-44-131.static.tpgi.com.au) has quit (Remote host closed the connection) | |
| [06:31:26] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [07:51:26] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.) | |
| [08:32:18] | mrand1 (mrand1!~mrand@cpe-76-184-144-133.tx.res.rr.com) has quit (Read error: Operation timed out) | |
| [08:53:37] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [09:09:46] | chainsawbike (chainsawbike!~chainsawb@chainsawbike-1-pt.tunnel.tserv25.sin1.ipv6.he.net) has quit (Ping timeout: 260 seconds) | |
| [09:11:22] | chainsawbike (chainsawbike!~chainsawb@chainsawbike-1-pt.tunnel.tserv25.sin1.ipv6.he.net) has joined #mythtv | |
| [09:30:49] | Captain_Murdoch: | normal commflagging should not be writing any seek table info to the DB unless someone changed it to do so. the --rebuild is the only thing that should write a seektable other than the recording process itself. |
| [10:05:01] | Guest22716 (Guest22716!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:55] | mike|3 (mike|3!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [12:04:48] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [12:05:16] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [12:31:04] | stuartm: | well the compile is much faster now, although it's still having to recompile a lot of stuff which adds a few seconds |
| [12:32:31] | stuartm: | somewhere between 15–30 seconds here |
| [12:47:07] | balor (balor!~balor@87.127.55.57) has quit (Ping timeout: 258 seconds) | |
| [12:48:06] | Ricky-Bobby (Ricky-Bobby!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:22:17] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:23:42] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 276 seconds) | |
| [13:29:26] | j-rod|afk is now known as j-rod | |
| [13:59:56] | MaverickTech (MaverickTech!~MaverickT@122.56.21.114) has joined #mythtv | |
| [15:13:22] | MaverickTech (MaverickTech!~MaverickT@122.56.21.114) has quit (Ping timeout: 264 seconds) | |
| [15:14:15] | jmartens (jmartens!~jmartens@109.232.42.33) has quit (Quit: Leaving.) | |
| [15:14:33] | jmartens (jmartens!~jmartens@109.232.42.33) has joined #mythtv | |
| [15:18:55] | jmartens (jmartens!~jmartens@109.232.42.33) has quit (Ping timeout: 258 seconds) | |
| [15:31:11] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [15:35:47] | stuartm_ (stuartm_!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has joined #mythtv | |
| [15:35:47] | stuartm_ (stuartm_!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has quit (Changing host) | |
| [15:35:47] | stuartm_ (stuartm_!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [15:36:21] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has joined #mythtv | |
| [15:36:22] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection) | |
| [15:51:58] | VManiac16 (VManiac16!~Unknown@69.4.155.83) has joined #mythtv | |
| [15:55:24] | Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has quit (Ping timeout: 255 seconds) | |
| [16:09:41] | kormoc is now known as kormoc_afk | |
| [16:17:01] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [16:58:31] | stuartm_ is now known as stuartm | |
| [17:00:24] | danielk22: | stuartm: I think to get back to the old recompile speeds we need to only update mythversion.h when absolutely necessary. |
| [17:02:29] | danielk22: | Captain_Murdoch: wagnerrp: I believe we are writing out an inferior keyframe map whenever mythcommflag is run, or at least when it is run while a recording is going. Otherwise I can't see what is causing all the db primary key collisions when the recorders try to update the keyframe map. |
| [17:03:17] | danielk22: | Captain_Murdoch: wagnerrp: As far as I can tell this is a recent regression, but then I don't look at the logs all that often.. |
| [17:04:57] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [17:05:23] | davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [17:05:23] | davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [17:05:23] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [17:08:30] | danielk22: | dblain: yeah, I normally only use mutable for mutexes. |
| [17:12:23] | danielk22: | dblain: I recall seeing a google C++ guide last year that pretty well listed all the C++ features I try to use sparingly and why, but I don't know the link. |
| [17:36:09] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [17:39:00] | SteveGoodey (SteveGoodey!~steve@host86-147-181-6.range86-147.btcentralplus.com) has joined #mythtv | |
| [17:39:49] | andreax (andreax!~andreaz@p57B9456C.dip.t-dialin.net) has joined #mythtv | |
| [17:47:46] | kormoc_afk is now known as kormoc | |
| [17:55:25] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [18:10:35] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [18:15:45] | stuartm: | does anyone know what ProgramDetail (libmythtv/programdetail.h) is all about? As far as I can tell it's only used by mythwelcome and I can't see why it's not using ProgramInfo instead |
| [18:18:53] | stuartm: | it's not like I don't have better things to do but that's going into the bin |
| [18:27:13] | sphery: | stuartm: I think danielk22 broke it out of programinfo when he did the refactor--to try to make programinfo more lightweight and let only those who needed extra info use the heavyweight class (which does more DB access or something) |
| [18:27:30] | sphery: | if we can get rid of it, it's probably even better |
| [18:28:42] | sphery: | then again, looking at it, it seems to be a less-detailed version of programinfo... anyway, he should be able to give you more info |
| [18:34:30] | stuartm: | it is a much reduced version of PI, but it populates that list by calling LoadFromScheduler which returns a list of PI objects ... so to create the 'simple' object you first have to create the full thing |
| [18:35:27] | stuartm: | there's no performance gain to be had there and it's duplicating code, plus we don't get access to things like ProgramInfo::ToMap() in mythwelcome |
| [18:36:32] | stuartm: | it seems to be a no-brainer, but I'll hold off committing until danielk22 has chimed in |
| [18:47:00] | danielk22: | Heh, ProgramDetail is not my doing. It's just one of a number of ProgramInfo type classes I didn't merge into ProgramInfo. |
| [18:51:50] | stuartm: | ok, I'm not putting myself out to refactor 'GetProgamDetailList' into something more generic I'm just renaming it and moving it into ProgramInfo and eliminating the ProgramDetail struct |
| [19:01:28] | Captain_Murdoch: | danielk22, RE: the seektable, that sounds like what wagnerrp and others were discussing last night. if so, it is a regression, because the flagger should never write out a seektable unless you run it with the --rebuild option. I think what wagnerrp was messing around with that bit of code recently, so it might be an unintentional change. |
| [19:08:14] | danielk22: | Captain_Murdoch: Yeah, I pointed it out to wagnerrp last week. I thought that's why he was looking at it.. :) |
| [19:09:40] | danielk22: | It could be a change somewhere else, like in the player code, but commflag changes seem to be a prime candidate.. |
| [19:15:11] | SteveGoodey (SteveGoodey!~steve@host86-147-181-6.range86-147.btcentralplus.com) has quit (Remote host closed the connection) | |
| [19:18:58] | stuartm: | TunerStatus is another similar struct which is only used by MythWelcome |
| [19:20:20] | stuartm: | rm -rf mythwelcome |
| [19:21:30] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Ping timeout: 255 seconds) | |
| [19:25:50] | danielk22: | heh, (JobQueue::GetJobFlags(jobID) && JOB_REBUILD) that may explain why nothing is getting commflagged either.. |
| [19:43:09] | danielk22: | wagnerrp: Captain_Murdoch: et all: I just pushed a "&&" -> "&" fix.. I don't know if that is sufficient, but it's a start. |
| [19:45:11] | jams: | any changes/additions for the mythtv_data tab? http://smolt.mythvantage.com/static/stats/stats.html |
| [19:48:46] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 264 seconds) | |
| [19:56:29] | stuartm: | jams: country from settings table |
| [19:57:14] | jams: | k |
| [19:57:41] | wagnerrp: | danielk22: yeah, that would do it |
| [19:57:59] | wagnerrp: | i had read through the code a couple times, but couldnt find anything wrong |
| [19:58:06] | wagnerrp: | figures it would be something stupid like that |
| [19:58:10] | Captain_Murdoch: | was that making it run rebuilds instead of flagging jobs? |
| [19:58:35] | wagnerrp: | live commflags have their flags set to 2, to denote that they should hook up to the recorder to get filesize updates |
| [19:58:53] | wagnerrp: | since it was !=0, it was instead building the seek table |
| [19:58:59] | danielk22: | It can be hard to see something like that reading your own code. |
| [19:59:11] | wagnerrp: | Captain_Murdoch: i added a new flag (8) to allow you to queue seektable rebuilds |
| [19:59:24] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [19:59:25] | stuartm: | jams: maybe number of tuners as well as number of sources |
| [20:00:11] | stuartm: | ah, I think that's already there |
| [20:00:21] | jams: | # of sources is there in "Schedule information" |
| [20:00:38] | wagnerrp: | danielk22: thanks, i doubt i would have ever seen that |
| [20:01:03] | stuartm: | jams: yeah, I saw that I just wasn't seeing # of tuners, but it's right there at the top |
| [20:01:06] | jams: | rearranging things is also possible. I just sort of grouped things as I went down the list |
| [20:01:07] | Captain_Murdoch: | wagnerrp, yeah, I know about the flag, that's my point. if that line above mentioned by daniel was "if ((JobQueue::GetJobFlags(jobID) && JOB_REBUILD) rebuild(); else flag();" then it would have been rebuilding instead of flagging everthing that hit that line of code. |
| [20:02:00] | stuartm: | or is that the total, not the breakdown of totals by submission? |
| [20:02:16] | Captain_Murdoch: | glad it's found... you can take a lot of heat from users for breaking flagging. :) |
| [20:02:29] | stuartm: | either way, we're clearly gathering that info and nothing else occurs to me |
| [20:02:37] | jams: | stuartm it's total |
| [20:04:02] | stuartm: | actually, it might be useful to know how many people aren't using vdpau or opengl (ui or video) when it's available to them – i.e. how many people missed or were stumped by that part of the configuration |
| [20:04:28] | jams: | for breakdowns I went with max/min/avg for some things. But a more robust breakdown can be had |
| [20:06:33] | stuartm: | I reckon that at least a percentage of users have a degraded experience because they aren't using the best options available to them, having stats to back up that hypothesis might make it easier to get a consensus on automating/simplifying setup |
| [20:08:12] | jams: | stuartm, this is the raw data that's collected. not all of it is used on the webpage. |
| [20:08:30] | stuartm: | ok |
| [20:08:32] | jams: | country will be there shortly =) |
| [20:08:45] | jams: | http://pastebin.tlhiv.org/r30QK7SX |
| [20:08:52] | jams: | forgot to paste |
| [20:11:29] | stuartm: | ok cool, video profile is there |
| [20:12:09] | jams: | yep..i had no idea what todo with it |
| [20:12:31] | jams: | but we are storing it |
| [20:14:04] | stuartm: | so long as we can later build a report from that, e.g. comparing the number of people with vdpau capable hardware who aren't using vdpau |
| [20:14:19] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [20:14:44] | dudz_ (dudz_!~dudz@123-243-44-131.static.tpgi.com.au) has joined #mythtv | |
| [20:15:01] | jams: | will take a few joins but it can be done |
| [20:29:41] | wagnerrp: | go7007? |
| [20:29:51] | wagnerrp: | youre actually using a plextor capture box? |
| [20:30:27] | jams: | i do have one |
| [20:30:36] | jams: | dont' use it that much though |
| [20:31:22] | jams: | considering the driver forces you to use ALSA, it's not really a good fit for me |
| [20:38:08] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [20:43:24] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [20:47:54] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Ping timeout: 255 seconds) | |
| [20:58:22] | Ricky-Bobby (Ricky-Bobby!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [21:03:37] | iamlindoro: | danielk22: mythccextractor: Very cool! |
| [21:09:48] | iamlindoro: | danielk22: So can we glean from the commit that Digital Nirvana uses Myth in their Broadcast monitoring product? |
| [21:16:11] | brfransen (brfransen!~brfransen@216.254.250.47) has quit (Read error: Connection reset by peer) | |
| [21:16:48] | brfransen (brfransen!~brfransen@216.254.250.47) has joined #mythtv | |
| [21:24:13] | wagnerrp: | is that what the ASI support is for? |
| [21:25:52] | iamlindoro: | That's DVEO, I thought |
| [21:30:26] | MaverickTech (MaverickTech!~MaverickT@122.56.21.114) has joined #mythtv | |
| [21:33:20] | j-rod is now known as j-rod|afk | |
| [21:34:39] | kormoc is now known as kormoc_afk | |
| [21:35:12] | kormoc_afk is now known as kormoc | |
| [21:36:47] | cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has joined #mythtv | |
| [21:44:07] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has quit (Remote host closed the connection) | |
| [21:47:33] | paul-h: | iamlindoro: I have a film that's been misidentified that I've tried to correct in the metadata options screen but every time I return to that screen it has reset itself to the old incorrect inetid. Any ideas how to fix it? |
| [21:48:17] | iamlindoro: | paul-h: Did you change the inetref, and then hit done, then save, then back all the way out of whichever screen? |
| [21:48:34] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Quit: Leaving) | |
| [21:48:38] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [21:49:17] | paul-h: | yes, back to the main schedule editor screen and pressed save from the watch recordings screen |
| [21:49:43] | iamlindoro: | paul-h: Ah, so edited in the PBB? (ie, the manual metadata editor?) |
| [21:49:56] | paul-h: | yes |
| [21:50:06] | jya: | could someone indicate to me which commit added a persistent A/V sync setting ? |
| [21:50:10] | iamlindoro: | OK, let me have a look when I get home, it's possible I broke it at some point after I added it |
| [21:50:15] | iamlindoro: | Thanks |
| [21:50:47] | iamlindoro: | paul-h: Oh, wait, wait |
| [21:50:58] | iamlindoro: | paul-h: The manual metadata editor only affects the recording, not the rule |
| [21:51:27] | iamlindoro: | So the rule will only change if you edit it in the rule itself, and then Done, Save, Back. |
| [21:51:41] | iamlindoro: | Though if it's a movie there's no reason to have to edit in both places-- just in the recording is good enough |
| [21:53:02] | iamlindoro: | So if I have what you're talking about correct, (ie, you are pressing MENU->Recording Options->Change Recording Metadta) that will change the contents of recorded, versus the schedule editor, which affects the contents of the rule, in record |
| [21:53:28] | stuartm: | yay, backend is not responding to clients, so either I restart the backend and interupt the in-progress recordings or I can't watch anything tonight |
| [21:55:02] | paul-h: | I just press edit in the pbb which show the schedule editor and the I select metadata options if that helps |
| [21:55:23] | stuartm: | I can't even see what recordings are in progress because that requires a connection to the backend, fun |
| [21:57:46] | paul-h: | iamlindoro: changing the inetref in Change Recording Metadata and then going to the metadata options screen fixes it |
| [21:59:00] | stuartm: | again?? At least it's reproducible not this is not cool |
| [21:59:07] | iamlindoro (iamlindoro!~iamlindor@mythtv/developer/iamlindoro) has quit (Ping timeout: 258 seconds) | |
| [21:59:22] | sphery: | jya: https://github.com/MythTV/mythtv/commit/9dbe19fb |
| [21:59:54] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has joined #mythtv | |
| [21:59:57] | stuartm: | the last line before it gets stuck is "ProcessRequest mainserver.cpp:1491 (HandleAnnounce) – Empty filename, cowardly aborting!" |
| [22:00:11] | sphery: | jya: see #4262 for more |
| [22:00:18] | jya: | thanks |
| [22:00:26] | jya: | I'd like to backport this to my branch |
| [22:01:49] | stuartm: | Beirdo: https://github.com/MythTV/mythtv/commit/7641f3d12 is causing the backend to stop responding on sockets |
| [22:02:01] | stuartm: | Beirdo: mind if I back that out for now? |
| [22:03:12] | Beirdo: | how could it? But sure |
| [22:03:38] | Beirdo: | might be better to fix it, but meh. nuke it, we'll fix the messy nonsense again later. |
| [22:05:10] | Beirdo: | I can't see how it would cause a problem, though. You did try a distclean? |
| [22:06:41] | Beirdo: | anyways, go ahead and revert. Worked just fine for me, something super-odd going on, but better to just take a step back and try again later. |
| [22:07:24] | stuartm_ (stuartm_!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has joined #mythtv | |
| [22:07:24] | stuartm_ (stuartm_!~stuartm@cpc4-derb9-0-0-cust534.8-3.cable.virginmedia.com) has quit (Changing host) | |
| [22:07:24] | stuartm_ (stuartm_!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [22:07:53] | Beirdo: | stuartm_: you catch my responses? :) |
| [22:08:24] | Beirdo: | go for it, revert. Beats me how it would cause failure in that way, but go for it, we can revisit it later. |
| [22:08:53] | stuartm_: | if there was an obvious fix I'd fix it before reverting, but since there isn't and the bug it causes is a lot more serious than the one it fixes ... |
| [22:09:09] | Beirdo: | one thing to try first if you haven't.. .distclean |
| [22:09:17] | Beirdo: | other than that, meh :) |
| [22:09:33] | stuartm_: | yeah, I'd already done a distclean to test the commit I just made |
| [22:09:40] | stuartm_: | the one before the revert :) |
| [22:09:43] | Beirdo: | K. Revert it is then |
| [22:10:07] | Beirdo: | odd stuff |
| [22:10:32] | stuartm_: | better that than have lots of users whinging (myself included ;) ) |
| [22:10:47] | Beirdo: | yeah, true |
| [22:10:53] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Disconnected by services) | |
| [22:10:56] | stuartm_ is now known as stuartm | |
| [22:11:06] | Beirdo: | and if it turns out not to be that or whatever, it can get redone later |
| [22:12:19] | Beirdo: | OK, this is a problem... I wanna finish my backend upgrades tonight, but I have a free ticket to the Seattle Sounders FC vs Manchester United game tonight... |
| [22:12:28] | stuartm: | I could reliably reproduce with that change in place, and not at all once it was reverted |
| [22:12:59] | Beirdo: | how odd. Well, fair enough. It will get revisited sometime later |
| [22:13:26] | Beirdo: | it only was needed in the case of a missing DB, which is a rare case |
| [22:13:27] | stuartm: | when the backend stopped communicating the last thing in the logs was always that message |
| [22:13:54] | kurre_ (kurre_!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 255 seconds) | |
| [22:13:54] | kurre_ (kurre_!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv | |
| [22:13:54] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@pool-108-20-43-12.bstnma.fios.verizon.net) has joined #mythtv | |
| [22:13:55] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has quit (Ping timeout: 255 seconds) | |
| [22:13:56] | Beirdo: | well, it shoulda kept going. Now the frontend may not be handling the error condition, though |
| [22:14:04] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has joined #mythtv | |
| [22:15:00] | stuartm: | frontend restart didn't help, couldn't connect to the backend at all from any app or on the http interface after that |
| [22:15:40] | Beirdo: | Odd... I'll try to reproduce it later on and see what the issue is. Sorry for the fun. |
| [22:15:40] | stuartm: | but interestingly if we can figure this out then it might finally help to solve the long standing bug with the same symptoms |
| [22:15:46] | Beirdo: | yeah |
| [22:15:54] | Beirdo: | that's what I was thinking too :) |
| [22:16:02] | Beirdo: | it it's easily repeatable... |
| [22:16:23] | Beirdo: | how did it hang, what were you doing when it crapped out? |
| [22:17:12] | paul-h: | Anybody else noticed a problem not being able to escape out of the frontend after changing themes using the theme chooser? |
| [22:17:15] | stuartm: | happened every time I browsed to a particular folder on mythvideo, immediately beforehand in the logs was "ERROR: LocalFilePath unable to find local path for 'No Cover'." but I don't think that's related |
| [22:17:43] | Beirdo: | hmm, it might be related somehow. But OK. good to know |
| [22:17:59] | stuartm: | well, actually it could be related since that error was on the backend and not the frontend |
| [22:18:29] | stuartm: | I'm just not sure why it would be looking for that 'image' remotely |
| [22:19:17] | stuartm: | especially since that's not a path, it's what gets inserted into the database when no path was specified |
| [22:19:37] | Beirdo: | yeah, that could be another good bug to get chased down |
| [22:24:21] | MaverickTech (MaverickTech!~MaverickT@122.56.21.114) has quit (Quit: Leaving) | |
| [22:25:07] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [22:27:06] | iamlindoro (iamlindoro!~iamlindor@mythtv/developer/iamlindoro) has joined #mythtv | |
| [22:28:15] | iamlindoro: | paul-h: Sorry, got disconnected-- I suspect this is a re-emergence of an issue where changes to metadata in the rec rule when done from the PBB fail (but work right from any other schedule editor view for some reason)... I don't understand why it is, but I'll see if I can figure it out |
| [22:28:38] | morxe (morxe!~martin@c-2a7370d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv | |
| [22:33:11] | paul-h: | iamlindoro: a workaround is to change the inetref, season and episode in Change Recording Metadata and then go to the metadata options screen to change the artwork |
| [22:33:38] | morxe (morxe!~martin@c-2a7370d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: Leaving) | |
| [22:33:42] | iamlindoro: | paul-h: ok, thanks |
| [22:37:11] | iamlindoro: | Anyone know if the PBB does some sort of zealous recording rule caching ref: the schedule editor that I need to work around |
| [22:38:51] | iamlindoro: | Edits done from the rule from the PBB take effect in the DB, but old versions seem to be kept in memory somewhere |
| [22:39:37] | iamlindoro: | ie edit a recording's schedule, change the inetref, save. check record table, inetref has changed. Re-enter rule, nothing has changed--- but go look at the rule from Manage Recordings->Recording Rules, and the edits are there |
| [22:40:05] | iamlindoro: | I can navigate between the PBB and any other rule edit screen and see one version with the changes, one without |
| [22:40:46] | stuartm: | Beirdo: the only explanation is that error handling is broken, your patch only triggers the problem because that particular error is more common than others, the interaction is probably subtle but I think it could be fun tracking it down |
| [22:41:16] | morxe (morxe!~martin@c-2a7370d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv | |
| [22:41:25] | Beirdo: | yeah, agreed |
| [22:41:51] | Beirdo: | what I added *in theory* should work, but is poking a problem elsewhere harder than usual |
| [22:42:32] | Beirdo: | fun. More to debug :) |
| [22:42:57] | Beirdo: | I have a qt3-less version of mpeg2fix.cpp in testing at home, BTW |
| [22:43:16] | stuartm: | Beirdo: oh, I forgot all about that |
| [22:43:18] | Beirdo: | I found that the current version in master is kinda borked for me |
| [22:43:29] | Beirdo: | and my replacement is borked in the same way |
| [22:44:03] | Beirdo: | if you make a cut so you have say 5min remaining at hte beginning of the show, and 5min at the end... the result is just the first 5min |
| [22:44:04] | stuartm: | how did you work around the built-in iterator behaviour? |
| [22:44:13] | Beirdo: | it somehow is missing the last chunk |
| [22:44:18] | iamlindoro: | paul-h: I think I found it, testing |
| [22:44:43] | stuartm: | fwiw I'll grab some fe/be logs tomorrow with -v network and spend some time looking at the issue |
| [22:44:46] | Beirdo: | stuartm: most places it didn't need to be done that way. in a few places, I put iterating by index |
| [22:44:54] | iamlindoro: | paul-h: Building the recordinginfo with the programinfo's inetref instead of the rule's... ergo the editing of the recording being the workaround |
| [22:45:08] | Beirdo: | but in a lot of places a normal iterator worked with a bit of massaging |
| [22:45:33] | Beirdo: | I need to finish that so others can try it, and find bugs that no doubt are still there :) |
| [22:45:44] | Beirdo: | stuartm: OK, cool |
| [22:45:50] | Beirdo: | let me know how that goes :) |
| [22:48:02] | stuartm: | Beirdo: ok, that's a little different to my approach which was to create an m_currentPosition member which was an iterator which had to be kept in sync with changes |
| [22:48:20] | jwhite_ (jwhite_!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has joined #mythtv | |
| [22:48:28] | kormoc is now known as kormoc_afk | |
| [22:48:30] | Beirdo: | I considered that, but in so many cases it just seemed unnecessary |
| [22:48:44] | Beirdo: | mind you, I'm not sure I've gotten all the wrinkles out yet either |
| [22:48:46] | stuartm: | Beirdo: as far as regression testing, have you been comparing the byte for byte output from transcodes? |
| [22:48:57] | Beirdo: | not yet, no |
| [22:49:14] | Beirdo: | once I find why neither will actually transcode as requested, I plan to |
| [22:49:29] | kormoc_afk is now known as kormoc | |
| [22:49:42] | J-e-f-f-A_ (J-e-f-f-A_!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has joined #mythtv | |
| [22:52:27] | morxe (morxe!~martin@c-2a7370d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: Leaving) | |
| [22:54:17] | Beirdo: | once it's acting more or less correctly, and I've fixed master to work correctly as well, then I'll go and make several identical cuts and A/B compare |
| [22:54:33] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has quit (*.net *.split) | |
| [22:54:34] | kurre_ (kurre_!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (*.net *.split) | |
| [22:54:34] | jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has quit (*.net *.split) | |
| [22:54:34] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (*.net *.split) | |
| [22:54:35] | J-e-f-f-A_ is now known as J-e-f-f-A | |
| [22:54:46] | Beirdo: | it's probably something simple... once it's found. |
| [22:54:49] | Beirdo: | it usually is |
| [22:55:06] | Beirdo: | finding it takes forever and then you go "well DUH!" once you find it |
| [22:55:40] | xris: | danielk22: I owe you a beer for https://github.com/MythTV/mythtv/commit/8bedb . . . 8b3a8c64f73e :) |
| [22:56:11] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 240 seconds) | |
| [22:56:29] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [22:56:47] | Beirdo: | speaking of "Well, DUH" bugs :) |
| [22:57:04] | Beirdo: | those are just sooo easy to miss |
| [22:59:30] | kurre_ (kurre_!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv | |
| [22:59:30] | jstenback (jstenback!~jstenback@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv | |
| [23:01:11] | michi3 (michi3!~Adium@188-194-93-11-dynip.superkabel.de) has joined #mythtv | |
| [23:04:31] | dudz_ (dudz_!~dudz@123-243-44-131.static.tpgi.com.au) has quit (Remote host closed the connection) | |
| [23:05:32] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [23:13:29] | stuartm: | I did something very similar not more than 2 days ago |
| [23:14:33] | stuartm: | a simple typo that reads fine at a glance and will compile without issue but which causes undesired behaviour |
| [23:14:45] | Beirdo: | yup, I think we all have |
| [23:18:08] | iamlindoro: | I call that "my commits" |
| [23:18:30] | wagnerrp: | I call that "hey, that really was my commit" |
| [23:18:36] | wagnerrp: | :) |
| [23:18:44] | Beirdo: | hhehe |
| [23:20:44] | michi3 (michi3!~Adium@188-194-93-11-dynip.superkabel.de) has left #mythtv () | |
| [23:23:29] | iamlindoro: | paul-h: Fixed, thanks for mentioning it |
| [23:28:24] | andreax (andreax!~andreaz@p57B9456C.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [23:28:55] | abqjp: | Remind me again, how to get myth to use Qt for the "painter" instead of OpenGL? |
| [23:29:13] | wagnerrp: | sphery? |
| [23:29:26] | stuartm: | abqjp: -O ThemePainter=qt |
| [23:29:28] | wagnerrp: | abqjp: talking about 0.25, right? |
| [23:29:39] | abqjp: | yes. |
| [23:29:42] | wagnerrp: | stuartm: that has changed in 0.25 |
| [23:29:53] | stuartm: | wagnerrp: huh |
| [23:29:59] | Beirdo: | feels weird to run my backend with one drive for the moment |
| [23:30:09] | wagnerrp: | mythtv automatically chooses opengl if it detects proper hardware support |
| [23:30:17] | wagnerrp: | and there is a separate override to force it back to qt |
| [23:30:30] | iamlindoro: | UIPainter |
| [23:30:52] | wagnerrp: | 'proper hardware support' meaning direct rendering is enabled |
| [23:31:38] | Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has quit (Quit: Leaving) | |
| [23:33:32] | Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv | |
| [23:35:27] | wagnerrp: | stuartm: https://github.com/MythTV/mythytv/commit/fb45eb9 |
| [23:35:37] | sphery: | abqjp: yeah, iamlindoro is right. -O UIPainter=qt --but if this is for anything other than testing themes/UI stuff with Qt painter, please let me know why it's misdetecting (I'm guessing it's for testing themes/UI stuff) |
| [23:36:00] | abqjp: | iamlindoro: thanks, that worked. |
| [23:36:05] | iamlindoro: | np |
| [23:37:06] | ** iamlindoro wonders if Taylor R will be coming back :( ** | |
| [23:37:17] | iamlindoro: | Looks like he's left and simultaneously unassigned his tickets |
| [23:37:40] | abqjp: | sphery: Just trying to run mythtv-setup inside of a VirtualBox. VirtualBox (on the mac) supports OpenGL emulation, but was giving me some grief. mythtv-setup would show the main menu, but when I tried to descend into a sub-menu, it would not actually draw the sub-menu so I could not see what I was doing. |
| [23:37:52] | kormoc: | iamlindoro, any reasons why? :( |
| [23:37:59] | iamlindoro: | nothing I know of |
| [23:38:13] | wagnerrp: | i imagine if he were leaving leaving, he would have said something |
| [23:38:41] | sphery: | abqjp: I'd very much appreciate a default-verbosity log of startup without the UIPainter override so I can see if we can autodetect the not-working config |
| [23:38:55] | iamlindoro: | tough to see it being a coincidence, but guess we'll see |
| [23:40:19] | iamlindoro: | especially given it represents 100% of his tickets |
| [23:40:27] | wagnerrp: | logs say hes been fairly quiet the last two months |
| [23:41:34] | stuartm: | kormoc: iirc he got a little upset the other day about the logging changes, I've no idea why, maybe it broke a lot of his patches, but he expressed that he'd had enough |
| [23:41:47] | kormoc: | Aww :( |
| [23:42:23] | abqjp: | sphery: http://pastebin.com/e4X5pBXD but, I suspect it is just a problem with VirtualBox's OpenGL emulation. |
| [23:43:45] | wagnerrp: | speaking of logging... beirdo, do we have any concept of a log directory? |
| [23:44:04] | Beirdo: | yes |
| [23:44:20] | Beirdo: | if you put -l followed by a directory rather than a file |
| [23:44:27] | Beirdo: | --logpath in full |
| [23:44:42] | Beirdo: | I'm thinking that later, we might even make that use a storage group |
| [23:44:59] | wagnerrp: | is there a way to detect that the log path is a directory rather than a file? |
| [23:45:03] | wagnerrp: | from outside the logger |
| [23:45:07] | sphery: | abqjp: thanks... I need to talk to markk and see if it makes sense to just fall back to Qt painter for one or more of those errors ("OpenGL: Multi-texturing not supported. Certain OpenGL features will not work" or "OpenGL: GL_EXT_vertex_array extension not supported. This may not work" --after all, it sounds like OpenGL shouldn't be the default if we know it might not work) |
| [23:45:32] | Beirdo: | wagnerrp: there is from the command line parser, I thought. I'd have to look into it again |
| [23:45:42] | Beirdo: | what are ya looking at doing? |
| [23:45:49] | wagnerrp: | yeah, but that would require doing separate processing of those values |
| [23:46:01] | abqjp: | I seem to remember there being a "dummy" capture card option being discussed. Is that the "Demo test recorder" ? |
| [23:46:10] | wagnerrp: | one of the things discussed with the jobqueue in regards to logging was breaking out each job into its own log file |
| [23:46:16] | Beirdo: | it's already being done, and split into several items |
| [23:46:27] | Beirdo: | ah, right |
| [23:46:50] | Beirdo: | won't the jobqueue be spawning other programs to do the actual work? |
| [23:46:59] | wagnerrp: | yes, it will |
| [23:47:18] | Beirdo: | right. Each of those will have its own log, if given a log directory |
| [23:47:41] | Beirdo: | that what the log propagation stuff does (along with setting the log level, etc) |
| [23:47:53] | wagnerrp: | assuming it is an internal application |
| [23:47:58] | wagnerrp: | or something else programmed with the same behavior |
| [23:48:03] | Beirdo: | correct |
| [23:48:03] | wagnerrp: | and then each application only gets one file |
| [23:48:16] | wagnerrp: | im talking about each job getting its own log file |
| [23:48:20] | Beirdo: | each application gets one file PER time it's run |
| [23:48:39] | sphery: | Beirdo / wagnerrp : I still think that for child processes, we should log to the same directory specified with the -l /path/to/file.log (so not just if they specify a directory)... :) |
| [23:48:44] | Beirdo: | like mythcommflag would get mythcommflag.20110720164500.pid.log |
| [23:48:56] | wagnerrp: | ah |
| [23:49:00] | Beirdo: | sphery: I still think that is a bad idea |
| [23:49:25] | Beirdo: | if they specify a specific file, there's no connotation that they want other files in that directory |
| [23:49:43] | Beirdo: | i.e. -l /var/log/mythbackend.log |
| [23:49:54] | wagnerrp: | ill likely want to write a logging wrapper for non-myth programs |
| [23:50:04] | Beirdo: | does not mean you want mythcommflag to also log in /var/log. It means use that exact file |
| [23:50:23] | sphery: | but that means it's impossible to get mythbackend log into a specific file and use a proper directory--other than by first changing to the directory into which you want other logs written (and I really dislike the idea of using cwd for anything) |
| [23:50:41] | Beirdo: | that is correct |
| [23:51:03] | Beirdo: | and I dislike that idea too :) |
| [23:51:14] | sphery: | that said, I have changed my start script appropriately--just figure that a lot of people/distros won't... |
| [23:51:27] | Beirdo: | we'll have to think it through to find how to do this the "right" way |
| [23:51:35] | sphery: | so, wait, you're saying we don't currently use current working directory for other logs? does that mean they don't get any logs? |
| [23:51:46] | sphery: | if I say -l /path/to/file.log |
| [23:51:53] | Beirdo: | the best for the distros would be to make a /var/log/mythtv/ that we use for everything |
| [23:51:56] | Beirdo: | correct |
| [23:52:12] | wagnerrp: | OH! |
| [23:52:21] | wagnerrp: | that would explain why job logs no longer show up in my log |
| [23:52:22] | Beirdo: | rather than spew unexpected logs everywhere, it will just not make a debug log |
| [23:52:41] | wagnerrp: | yeah, we really need to get that prominently documented |
| [23:52:52] | sphery: | well, that's definitely better than using cwd... though I think it will trip up a lot of users. I guess that's what re-education is all about. |
| [23:53:41] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has quit (Quit: abqjp) | |
| [23:53:53] | Beirdo: | yeah, the other option... which would get confusing... is similar to the old method... just pass the specific log to all subprocesses too |
| [23:54:50] | wagnerrp: | if were going to change behavior in such a manner |
| [23:54:57] | wagnerrp: | would it be better to do a completely clean break? |
| [23:55:04] | wagnerrp: | get rid of logfile entirely |
| [23:55:07] | wagnerrp: | make it log directory |
| [23:55:09] | sphery: | abqjp: now that you've done one thing for me (thanks for the logging output), I was wondering if you might be able to take a look at http://ubuntuforums.org/showpost.php?p=11019556&postcount=25 regarding the 0-byte/missing recording files. That post and at least one other user's post seems to indicate that the recording is starting before the tuning script is called or completed or something, so I was wondering if it might be related to the ... |
| [23:55:11] | Beirdo: | but yeah, the idea was to have separate logfiles. |
| [23:55:14] | wagnerrp: | and error if the path given is a file |
| [23:55:15] | sphery: | ... changes you made to use the signal monitor with the tuning scripts |
| [23:55:30] | Beirdo: | wagnerrp: yeah, we could remove -l and --logfile and force the use of --logpath |
| [23:55:51] | wagnerrp: | so rather than having users silently not get any logs from child processes |
| [23:55:59] | wagnerrp: | it simply doesnt run, and explains why they screwed up |
| [23:56:07] | sphery: | if we're doing that, why not just do it the "use the dir they specified for the log file" thing? |
| [23:56:28] | wagnerrp: | because we may not have write access to that dir |
| [23:56:32] | Beirdo: | sphery: because that would have unexpected results rather than error out |
| [23:56:37] | wagnerrp: | i.e. writing directly to /var/log |
| [23:57:08] | wagnerrp: | we could add additional checking to ensure we can write to that directory... |
| [23:57:43] | Beirdo: | I think the clean break is likely a less funky way to deal with this |
| [23:58:40] | sphery: | yeah, we'd need to check write permissions, but if we don't have write perms on the dir and the user is having us log to a file to which we do have write perms that's in that dir, the user has a broken config and we should error out |
| [23:58:49] | Beirdo: | wrong |
| [23:58:55] | Beirdo: | :) |
| [23:58:58] | wagnerrp: | superm1, mrand, tgm4883, other packagers: ^^^^ |
| [23:59:22] | Beirdo: | I have setup /var/log/blah.log without giving the user write perms on the dir, just on the file |
| [23:59:39] | Beirdo: | there's nothing wrong with that |
| [23:59:44] | wagnerrp: | yes, there is |
| [23:59:47] | sphery: | yeah, IMHO that's a broken config--no unprivileged user should ever write to a file in a "privileged" dir |
| [23:59:51] | wagnerrp: | because now child processes do not get logged |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.