MythLogBot@irc.freenode.net :: #mythtv-bsp

Daily chat history

Current users (17):

Beirdo, Captain_Murdoch, ChanServ, danielk22, dlblog, elmojo, gigem_, janneg, joe____, jpharvey, kormoc, MythLogBot, pkendall, skd5aner, sphery, stuarta, wagnerrp
Saturday, September 11th, 2010, 00:08 UTC
[00:08:16] pkendall: stuartm: I just tested ticket 7955 and it is indeed fixed.
[00:24:35] Casper0082 (Casper0082!~Casper@unaffiliated/kc) has quit (Read error: Connection reset by peer)
[00:41:30] kormoc_afk is now known as kormoc
[00:43:44] wagnerrp: sphery: any suggestion on how to decide which milestone to put on trunk?
[00:44:57] wagnerrp: check for the first milestone without a -fixes branch?
[00:47:45] wagnerrp: check the most recent due milestone, check that for a fixes branch, and if so, bump one up?
[00:48:00] kormoc: wagnerrp, first non-closed milestone that's not a -fixes?
[00:48:49] wagnerrp: when 0.24 gets branched, that milestone will remain open until its actually tagged for release, wont it?
[00:49:52] kormoc: I don't kow
[00:50:48] sphery: or maybe even a file that has a value that we change when appropriate?
[00:51:23] wagnerrp: i could just hard-code it, and we remember to change it
[00:52:04] wagnerrp: right now, the 'release-major-minor-fixes' stuff gets handled automatically
[00:52:12] wagnerrp: but ive got nothing for trunk
[00:54:40] sphery: yeah, however... I was thinking of some mapping file (i.e. "release-0-23-fixes\t0.23\ntrunk\t0.24" etc.), but if you can auto-detect, instead
[00:54:55] sphery: s/however...//
[00:55:20] sphery: oh, that was "how ever you want to do it" not "however, here's another point"
[00:55:35] wagnerrp: for now, it autodetects the 'newest' milestone of the '<major>.<minor>' branch
[00:56:05] wagnerrp: 'newest' simply being the one last in order of python sorted()
[00:56:18] wagnerrp: which means 0.23-fixes would be older than 0.23.1
[01:01:32] danielk22: stuartm: around? on #8908 you mention a dbcheck update being needed, are you maybe thinking of some other flags? I don't know of any place where those are written directly to the DB & I did my best to eliminate raw access to the flags in the PI refactor so adding new flags in the future should be less of a problem.
[01:08:43] danielk22: sphery: Beirdo: I see that #7525 has a 0.24 milestone, but to my eyes this looks rather invasive to be committing now. Do you think the CPU usage savings are significant enough to take the risk? (frontend CPU usage is pretty low for me at the moment.)
[01:14:58] sphery: danielk22: I think that patch is very invasive and provides almost no benefit. I definitely think it should be post 0.24 (or we modify the whole animation and pulse infrastructure--which, IIRC, markk may be planning to do). I think for Beirdo the CPU usage went from 48% to 45% after applying the patch (and we still don't know why Beirdo's system takes ~45% to do the pulse in the first place).
[01:16:04] danielk22: sphery: ok, I'll push it then.
[01:16:12] sphery: danielk22: also, the Perl bindings are using the program flags, too, and need updating, like MythWeb was in http://svn.mythtv.org/trac/changeset/26206 . I can do it for you if you want, but it will be a bit (I'm just rebuilding with current trunk).
[01:17:06] sphery: wagnerrp: The Python bindings don't seem to use the program flags (that specify whether a recording is recording or being transcoded, etc--see http://svn.mythtv.org/trac/changeset/26206 ). Is that true?
[01:17:21] wagnerrp: i was looking at that, no
[01:17:54] sphery: OK. I'll make sure the Perl bindings are fixed and that the comment is updated to point to them, also.
[01:18:27] wagnerrp: currently, theyre treated a string value, and passed through directly
[01:20:12] sphery: you get the string value from the backend, then? not from the DB?
[01:20:24] sphery: if so, that's probably the approach the perl bindings should take
[01:20:45] wagnerrp: i wouldnt say that
[01:21:11] danielk22: iamlindoro: took me a while to repro #7760, but I finally realized that the cancellation has to be via hitting escape and not via hitting the "Stop Scan" button...
[01:21:40] iamlindoro: danielk22, Ah, so you managed to reproduce? Looks like transport_scan_items_t is an stl::list
[01:22:05] iamlindoro: and we appear to add items with push_back, which theoretically should add them to the end, so... weird
[01:22:37] danielk22: iamlindoro: yeah, but it should be an easy fix, just tie "ESCAPE" to whatever "Stop Scan" is tied to...
[01:22:46] iamlindoro: nice
[01:23:13] sphery: heh, I have one of those for the new cut list editor that gbee found
[01:23:59] Beirdo: #7525 – I concur... notneeded for 0.24
[01:38:42] Beirdo: OK, bugs... here come my size 12.5s
[01:40:30] Beirdo: got the Asia concert footage playing on the frontend... time to play whack-a-mole
[01:49:08] sphery: danielk22: I'm starting the the perl bindings programflags fix, now. (Just don't want us to both spend time on it.  :)
[01:50:28] danielk22: sphery: thanks, do you know if python has something similar?
[01:50:53] wagnerrp: not currently, no
[01:53:32] Beirdo: sphery: which file are you modifying exactly?
[01:54:16] Beirdo: just trying to be aware of where merge conflicts may arise :)
[01:54:57] Beirdo: I'm working #8772 right now (just started) and so far am in MythTV.pm
[02:01:08] sphery: Beirdo: bindings/perl/MythTV/Program.pm
[02:01:12] Beirdo: K
[02:01:22] Beirdo: we shouldn't collide :)
[02:01:28] sphery: it's lines 94–104
[02:01:37] sphery: ah, yeah, you said MythTV.pm
[02:07:00] Beirdo: also hitting dbcheck.cpp, but only for a comment
[02:07:08] Beirdo: in case you were curious
[02:11:10] danielk22: tying the "ESCAPE" action to the same thing as "Stop Scan" appears to be easier said than done..
[02:11:15] sphery: So has anyone else noticed ccache not doing so much since the Makefile/mythtv.pro changes?
[02:11:38] Beirdo: it works well for me most of the time
[02:11:55] sphery: oh, wait, this one is actually because I changed the comment in libs/libmyth/programtypes.h... sorry... this /was/ me
[02:11:59] sphery: (comment, though...)
[02:12:47] Beirdo: heh
[02:15:12] kormoc: I've had issues with clock skew on the files lately that have been killing my ccache
[02:20:50] Beirdo: iamlindoro: thanks for #5743. It was getting closed this weekend for sure
[02:22:55] iamlindoro: np
[02:23:18] Beirdo: I'll be sweeping through the remainders as well :)
[02:34:47] Beirdo: OK, perl bindings now check schema version
[02:39:19] danielk22: did anyone take note of the total number of tickets and the total number of 0.24 tickets before BSP started?
[02:39:36] wagnerrp: when did BSP start?
[02:40:02] Beirdo: I believe one of the stuarts did mention it in -users
[02:40:39] danielk22: wagnerrp: about 8 hours ago I think.
[02:42:58] wagnerrp: well there are 79 now, and there have been 9 closed and 2 opened since
[02:43:10] Beirdo: oooh, now that's pretty
[02:43:33] Beirdo: jump point fail while playing video
[02:49:01] iamlindoro: danielk22, 338 at start
[03:03:41] Captain_Murdoch: any 'nays' from those present about the concept of #8877 to add a version token string to the MYTH_PROTO_VERSION command to prevent 3rd party libs from randomly saying they comply with protocol version X without at least knowing the token. it's on the fuzzy side of a bugfix, so I'll want a 2nd approval from at least janneg or xris before it goes in since we're in FF.
[03:07:03] danielk22: Captain_Murdoch: heh, I thought that already went in :)
[03:07:17] wagnerrp: no, that was a mistake on my part
[03:07:35] Captain_Murdoch: would have if I hadn't been busy burping and feeding (the baby, not me)
[03:07:37] wagnerrp: manually reverted one of my files, and deleted the wrong import
[03:08:01] wagnerrp: so a bit of it accidentally went into the python bindings
[03:11:00] Beirdo: Captain_Murdoch: I'd be happy with it going in
[03:17:12] sphery: I also would like to see it in.
[03:20:39] iamlindoro: yarrrr
[03:22:50] sphery: danielk22 or Captain_Murdoch: It seems that right now we're not using either a recordedmarkup mark or recorded.editing to save the editing state in the DB. We should be doing one or the other, right?
[03:23:34] sphery: the confusing part, though, is figuring out what stuartm meant when he said the editing state isn't being unset (as it doesn't seem to be set, even)
[03:23:36] Captain_Murdoch: I think so unless we're using inuseprograms for that now somehow.
[03:23:41] ** Captain_Murdoch hasn't looked. **
[03:26:46] sphery: Doesn't seem we are, based on libs/libmyth/programtypes.cpp list--we would have player set for it from playing, but nothing additional for editing.
[03:28:27] danielk22: sphery: AFAIK we used to set some special token in recordedmarkup. Using inuseprograms makes more sense to me as it will expire after a while if the frontend crashes.
[03:29:17] Beirdo: OK, note to self... using jump points + vdpau playback... not good
[03:29:39] Beirdo: I had to power cycle to get it back
[03:30:24] Captain_Murdoch: danielk22, yeah, we just need to setup a timer or something to update it regularly while in edit mode in case someone leaves edit mode open.
[03:30:36] danielk22: sphery: I have been staying away from the editor though. Last three editing sessions I attempted ended with no edit list saved.. First there was the bug where it exited if you got too close to the end. That was fixed, but then it lost all my edits when I hit some key misc key like the info key while in edit mode.
[03:31:18] sphery: Yeah, either inuseprograms or recordedmarkup will also allow it to work when we support multiple files per recording. For now, though, I think I'll just populate recorded.editing, since there's code that does that (but now is only called when someone tries to edit a program that's already being edited), so it's better for during the freeze.
[03:35:38] sphery: danielk22: I'd have to know what key you hit to fix the exit without editing. Since the new OSD, it sometimes processes keys that shouldn't be allowed during editing (like the TOGGLEPAUSE key fix markk put in http://svn.mythtv.org/trac/changeset/25564/tr . . . /tv_play.cpp ). INFO would only have gone through, though, if you've remapped either INFO or INVERTMAP since INVERTMAP steals the "I" key from INFO by ...
[03:35:43] sphery: ... default (something I plan to change/fix later).
[03:35:48] sphery: er, exit without saving
[03:36:58] danielk22: sphery: I can probably find out what key it was, it was one of the color keys on my remote which I have mapped to different things depending on context.
[03:37:38] danielk22: I'd rather fix the problem wholesale though rather than on a key by key basis.
[03:38:25] sphery: That would be ideal. I haven't looked into why the player is processing non-edit-mode keys while in edit mode, but I assumed there was a reason markk went with the one-off fix for TOGGLEPAUSE
[03:43:31] Beirdo: surprised that #7731 is even necessary
[03:44:06] Beirdo: in UNIX-land, if someone has the file open, you can delete it under their feet and they are good as long as the file isn't closed
[03:46:00] Beirdo: but I guess the backend is branching into Windows-land more and more, so it's probably better anyways
[03:49:32] sphery: Beirdo: not to mention that the open/delete/truncate approach (Delete Files Slowly) ruins the whole UNIX-land protection for you :)
[03:49:39] Beirdo: heheh
[03:49:43] Beirdo: granted
[03:50:13] Beirdo: anyone here know what devices are in #8890?
[03:50:29] Beirdo: is that to plug in digital cameras?
[03:50:51] danielk22: I can't repro #8892 even with Terra.. Beirdo, you saw preview madness also?
[03:51:05] Beirdo: I believe so, yes
[03:51:52] Beirdo: it also requests a preview as soon as recording starts.. even if you are in playback at the time.
[03:52:03] danielk22: If you can produce the -vplayback,network,file logs for the front and backends that may help me locate the problem.
[03:52:04] Beirdo: this is causing playback glitches for me
[03:52:28] Beirdo: can do
[03:53:31] danielk22: Beirdo: Open a separate ticket for that. That problem should be easily fixed; though it really shouldn't cause playback glitches regardless.
[03:53:44] Beirdo: OK
[03:56:48] sphery: danielk22: I had an unmounted file system and got these about every 0.015s: 2010-09–10 23:10:46.863 PlaybackBoxHelper Error: CHECK_AVAILABILITY 'myth://192.168.1.5:6543/1351_20100728200000.mpg' file not found
[03:56:55] danielk22: That probably only happens when you are playing back a recording near the top of the All Recordings queue, or a recording from the same group you are playing starts recording. Then the new recording may be on screen as far as MythUI is concerned...
[03:57:58] danielk22: sphery: ok, that's a separate issue as well.. please open a ticket.
[03:58:40] sphery: hmmm... let me see if that continues--I see only 3 per file in this log
[03:59:39] sphery: seems it's 3 per file until you actually select a missing file, then it's continuous
[03:59:59] danielk22: CHECK_AVAILABILITY is the stuff that grays out recordings, it shouldn't be called all that often. It's unrelated to preview gens, but it's also in PBB so I might as well look at it.
[04:00:15] danielk22: (grays out recordings that are on unmounted volumes)
[04:00:27] sphery: ok, wasn't sure if it was related. I'll make a ticket
[04:00:46] Beirdo: hmm.
[04:00:59] Beirdo: danielk22: it didn't do it this time
[04:01:16] ** Beirdo scratches his head **
[04:01:56] Beirdo: I scrolled off it then back... it requested the cover art/fan art again, but I don't see it asking for a new preview
[04:03:29] Beirdo: which is how I read the bug, does that make sense?
[04:05:47] Beirdo: so I don't think this log will help much if that's the case
[04:07:37] Captain_Murdoch: Beirdo, I think with #7731, it's not just the file itself, but other aspects of the transcoding cleanup such as the DB updates.
[04:07:52] Beirdo: right
[04:09:22] danielk22: Beirdo: I'll wait for stuartm's reply maybe he can repro it.
[04:09:25] Captain_Murdoch: probably need to tweak that a little more as well since now that I think about it, he only checks for "player" and not the pip or pbp player strings.
[04:09:56] Beirdo: OK. was worth a try though :) I have so many logs here, it's getting crazy :)
[04:10:00] danielk22: Captain_Murdoch: I believe there is a convenience function that checks all of them.
[04:10:28] danielk22: Beirdo: yeah, thanks. I think I'll turn in and tackle more bugs tmrw..
[04:10:41] Captain_Murdoch: danielk22, ok, I'll look for that.
[04:12:24] Beirdo: OK :)
[04:15:22] Captain_Murdoch: danielk22, I see a ProgramInfo::QueryIsDeleteCandidate, but that too only checks "player" and not pip or pbp and it checks transcoder as well which would cause a deadlock in mythtranscode's use.
[04:17:22] Beirdo: danielk22: ticket #8911. Have a good sleep
[04:19:11] Beirdo: Captain_Murdoch: for #7893, segfaulting commflags should now give a non-zero return properly from myth_system.
[04:19:49] iamlindoro: danielk22, #8849 == perhaps mixing XML and EIT data sources?
[04:19:53] Beirdo: although now myself and one other ubuntu users seem to be cursed with an odd status value (byteswapped) for signalled exit
[04:20:47] Captain_Murdoch: Beirdo, yeah, I think you replied to that one on-list when I put that latest comment in the ticket. I'll probably close if I don't hear back in a few days.
[04:20:54] Beirdo: ah
[04:21:06] Beirdo: wasn't sure if it was that one or another like it :)
[04:21:50] Beirdo: #8889, I'd like to close
[04:23:08] Beirdo: he had a pathologically bad recording, it seemed
[04:25:11] Beirdo: gah, what resolve code...
[04:42:54] Beirdo: sphery: you can go through your tickets and close the orphan script ones, I guess
[04:43:26] sphery: yeah, that's the plan, now
[04:43:52] Beirdo: hehe
[04:43:57] Beirdo: well done
[04:52:16] Beirdo: Captain_Murdoch: do we store the letterbox/pillarbox detected widths in the db yet?
[04:52:25] Captain_Murdoch: not that I know of.
[04:52:41] Beirdo: K
[04:52:45] Captain_Murdoch: there was talk of it to allow the auto-zoom to work for any decoding method.
[04:53:15] Beirdo: yeah, I'd love to see it some day for nuvexport too. Was just a idle thought
[04:53:17] Beirdo: heh
[04:53:43] kormoc: Beirdo, I never got around to looking in on adding that code yet
[04:53:54] kormoc: but once it does, it's trivial to update the auto-zoom code
[04:54:03] Beirdo: nice
[04:54:03] Captain_Murdoch: I think kormoc said he might look into it sometime. I do detect those already in the flagger, but don't store that info in the DB.
[04:54:20] Beirdo: that should be trivial to add once the time comes
[04:54:24] Captain_Murdoch: yeah
[04:54:49] Beirdo: anyways, now I go look at #8903 :)
[04:55:17] sphery: do we have the funds to replace all the video cards kormoc will burn out when updating the auto-zoom code?
[04:55:32] Beirdo: heh, we could start a fund
[04:55:37] kormoc: sphery, my video card is integrated now! YAY!
[04:56:00] sphery: oh, so we need to replace whole motherboards... this could get expensive
[05:32:28] sphery: I guess I don't work on #8726 since xmltv site is down (and I have no clue how to install it these days)
[05:33:06] Beirdo: now... for the db server has gone away... I wonder if I should trigger off the error number or the text...
[05:33:27] sphery: ah, there, it's back
[05:33:44] kormoc: error number
[05:33:48] kormoc: text is internationalized
[05:34:14] sphery: isn't the error number still coming out of the text? (Qt doesn't provide it directly, does it?)
[05:34:56] sphery: They'd probably still have it in all the localized versions, though.
[05:35:13] Beirdo: it does
[05:35:25] Beirdo: QSqlError provides both
[05:35:33] sphery: yeah, I see it now
[05:35:55] Beirdo: and I agree with kormoc... I just hope mysql doesn't change the code :)
[05:50:15] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[05:53:45] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has joined #mythtv-bsp
[06:09:21] Beirdo: OK, compiling the first run at #8903
[06:15:51] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Quit: Coyote finally caught me)
[06:18:59] Beirdo: hmmm
[06:19:04] Beirdo: I just had a thought
[06:20:03] Beirdo: sphery: for the slow startup.... I wonder if it's related to having my sql files on a mirror, and one of the spindles being shared with the video recordings
[06:26:32] kormoc: Given during your freeze, you said there was no running queries, I'm not sold on the idea that it's a SQL slowdown
[06:27:40] Beirdo: heh, me neither
[06:28:08] Beirdo: we'll find it eventually
[06:28:12] Beirdo: but not tonight
[06:28:39] Beirdo: 2 more minutes and I can test my attempt to reconnect.
[06:28:48] Beirdo: got 3 recordings running :)
[06:32:55] Beirdo: OK, it reconnects...
[06:33:16] Beirdo: but while the db is down... need to deal with that possibility too
[06:33:32] Beirdo: it will retry once, then give up
[06:33:48] Beirdo: then the next time around, database not open
[06:35:35] sphery: kormoc: [Sat Sep 11 02:24:04 2010] [error] [client 192.168.1.5] PHP Fatal error: Cannot access private property MythFrontend::$connected in /srv/www/htdocs/myth/modules/remote/handler.php on line 89
[06:36:00] sphery: Anytime I use a remote key. Since that's more than a minor change, I'll leave it for you. Want a ticket?
[06:36:37] kormoc: nah, I'll hit it in a minute
[06:36:39] sphery: Seems PHP is like a vampire--can't access your private property without an invitation.
[06:36:46] kormoc: Yeah
[06:36:48] kormoc: it's nice like that
[06:36:52] sphery: :)
[06:38:24] sphery: kormoc: I've found that http://svn.mythtv.org/trac/ticket/8751 is definitely MythWeb (as it works fine in a telnet client). Seems the 0 key is getting eaten by one of the functions. I'm guessing you'd be able to find it quickly, but am willing to dig through the code if you'd like me to fix it.
[06:39:08] kormoc: Nah, I'll hit that up with the other issue too :)
[06:39:38] sphery: thx
[06:40:11] sphery: gotta say, though, the remote is sweet--first time I've used it
[06:40:21] kormoc: and another one goes, and another one goes and another one bites the dust
[06:40:26] kormoc: sphery, did you use the interactive mode?
[06:40:52] sphery: no, didn't do that, yet
[06:41:17] sphery: I was running my frontend over SSH, so didn't want to get into anything too much for it
[06:41:27] sphery: what's the interactive do?
[06:41:29] kormoc: So with interactive mode enabled, you just type and we intercept your keypresses and send them
[06:41:37] kormoc: so no point and clicking
[06:41:45] sphery: nice
[06:41:53] sphery: didn't try if that works with 0
[06:42:20] sphery: oh, and btw, you don't have to go to that single location mentioned in the ticket--0 is always eaten
[06:42:33] kormoc: hrm
[06:42:53] kormoc: anything special to dupe Cannot access private property?
[06:43:18] sphery: I got it with any remote button press (except 0 :)
[06:43:34] kormoc: Cause I don't :(
[06:43:59] sphery: FWIW, [11/Sep/2010:02:32:39 -0400] "POST /myth/remote/keys HTTP/1.1" 200 42 is a normal key press and [11/Sep/2010:02:32:56 -0400] "POST /myth/remote/keys HTTP/1.1" 200 4126 is a 0 key press
[06:44:12] sphery: 4126 almost seems like an error, but I didn't know how to view it
[06:45:05] kormoc: yeah, that's definitely an error
[06:45:14] kormoc: 26221 fixes your private issue (I think)
[06:45:27] sphery: maybe the disconnected is just my network setup: // Host disconnected on us?
[06:45:39] kormoc: could very well be
[06:45:56] kormoc: so the easiest way to view the page (I see it too) would be to use firebug for future reference
[06:46:34] sphery: I even went so far as to install firebug on the browser I was using--but then couldn't find the where :)
[06:46:41] kormoc: heh
[06:46:51] sphery: that's when I mentioned the ticket was a MythWeb issue :)
[06:46:54] kormoc: open up firebug, stay in the Console tab, press the 0 button
[06:47:01] sphery: oh, console tab
[06:47:08] sphery: there were like 6 tabs and it confused me
[06:47:09] kormoc: you'll see a new entry for "POST remote/keys"
[06:47:12] sphery: I went to the script tab
[06:47:25] kormoc: open that up when it's done and you can see all the gory details of the ajax request
[06:47:36] kormoc: yeah, kinda odd
[06:47:55] kormoc: fixed
[06:49:27] sphery: yeah, see a ton of stuff
[06:49:50] kormoc: 26222 should fix your 0 press being eaten
[06:50:19] sphery: heh, that's what I figured was happening, but couldn't find the right function
[06:52:37] sphery: verified... both fixes work for me
[06:52:43] sphery: and interactive is cool
[06:53:05] sphery: only thing missing is Ctrl and Alt :)
[06:58:00] kormoc: hrm
[06:58:07] kormoc: odd that it doesn't capture them
[06:58:40] kormoc: where's a good spot to test those?
[06:58:49] kormoc: oh, I see why
[06:58:55] kormoc: we don't have them mapped at all
[06:58:59] kormoc: are they used somewhere?
[06:59:12] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv-bsp
[06:59:34] sphery: some key bindings use them
[06:59:45] sphery: I dont' know if the network protocol even supports them
[06:59:54] sphery: I use Alt+Esc for exit
[07:00:28] sphery: yeah, I don't think the protocol allows it
[07:01:31] sphery: I stand corrected... key Alt+Esc worked
[07:01:35] sphery: (in telnet)
[07:02:01] sphery: not really worth the time, though
[07:02:18] kormoc: Kk, but feel free to add a ticket for 0.25
[07:03:39] sphery: I'm supposed to be closing tickets, not making new ones
[07:04:09] Beirdo: hehe
[07:07:34] sphery: kormoc: FWIW, I can't repro the power search thing, either
[07:07:47] sphery: (on 0.23-fixes /or/ trunk)
[07:09:44] kormoc: I really think something is really wrong with his database
[07:12:40] Beirdo: well, this is working... but the errors are... messy
[07:26:15] kormoc: two more tickets for this milestone....
[07:26:27] kormoc: anyone have any outstanding mythweb issues I don't know about?
[07:28:22] Beirdo: not that I can think of offhand
[07:28:36] Beirdo: other than just being too cool :)
[07:29:58] Beirdo: OK, I have this pretty much under wraps
[07:38:17] Beirdo: OK, done
[07:40:55] Beirdo: we are at 315 total
[07:43:50] Beirdo: I'm done for the night
[07:56:23] kormoc (kormoc!~kormoc@unaffiliated/kormoc) has quit (Ping timeout: 245 seconds)
[07:57:36] kormoc (kormoc!~kormoc@unaffiliated/kormoc) has joined #mythtv-bsp
[07:57:36] Mode for #mythtv-bsp by ChanServ!ChanServ@services. : +v kormoc
[08:25:07] kormoc: Beirdo, 26225 isn't quite correct
[08:25:43] kormoc: if you lose the database between the prepare and the exec, I believe the exec will fail
[08:29:51] Beirdo: yeah, that's fine, it will return an error "normally" that way though
[08:30:10] Beirdo: and the exec(query) has no prepare
[08:30:26] Beirdo: only exec()
[08:30:55] Beirdo: I realize it's not perfect, but it's effective
[08:31:18] Beirdo: if there's more tweaking to do, that's fine too
[08:31:54] kormoc: can't re-run prepare?
[08:32:03] Beirdo: hmmm, I guess so
[08:32:23] Beirdo: leave a comment on the ticket and reopen if ya want, I can take a look at that tomorrow
[08:32:32] Beirdo: that would apply to exec() only, I think
[08:32:52] kormoc: Yeah, only to exec
[08:33:18] Beirdo: to tired to do it justice tonight :)
[08:34:47] Beirdo: too even
[08:34:58] Beirdo: holy crap, I'm turning into a moron
[09:26:14] kormoc (kormoc!~kormoc@unaffiliated/kormoc) has quit (Ping timeout: 276 seconds)
[09:26:43] kormoc (kormoc!~kormoc@unaffiliated/kormoc) has joined #mythtv-bsp
[09:26:43] Mode for #mythtv-bsp by ChanServ!ChanServ@services. : +v kormoc
[10:28:19] martin_ (martin_!~martin@host86-143-199-126.range86-143.btcentralplus.com) has joined #mythtv-bsp
[10:32:35] martin_ (martin_!~martin@host86-143-199-126.range86-143.btcentralplus.com) has quit (Remote host closed the connection)
[10:53:11] Ian_Zeplin (Ian_Zeplin!~Ian_Zepli@host-84-9-37-206.dslgb.com) has joined #mythtv-bsp
[11:00:15] stuarta: you try and do some coding and the office has a meltdown :(
[11:15:49] stuarta: for reference there were 81 open 0.24 milestone tickets when i started looking last night
[12:15:58] Jog (Jog!~joghur@1908ds1-nivaa.0.fullrate.dk) has joined #mythtv-bsp
[12:44:39] ** stuarta curses valgrind for lying **
[12:45:24] stuarta: RecordingInfo::StartedRecording(QString) (recordinginfo.cpp:818) <- claims that is leaking
[12:45:53] stuarta: that's "record = new RecordingRule();" but there's a corresponding delete in the destructor
[12:46:49] ** stuarta checks RecordingRule destructor **
[13:24:10] Jog (Jog!~joghur@1908ds1-nivaa.0.fullrate.dk) has left #mythtv-bsp ()
[13:37:39] stuartm: stuarta: no explicit destructor for RR
[13:39:10] stuarta: there's an empty one
[13:39:41] stuarta: but correspondingly there's no new's in the constructor
[13:40:59] stuarta: unless i'm missing an implicit one
[13:41:26] ** stuarta needs more cpu **
[14:06:22] stuartm: stuarta: thanks for the RP leak fix, I've been meaning to look at that for months
[14:08:44] stuarta: np
[14:09:58] stuarta: that was the major definite leak showing up when valgrinding for the "EIT leak"
[14:10:38] stuartm: kept showing up in valgrind logs, but for some reason I never took a moment to look at it
[14:11:08] stuarta: don't understand yet how valgrind finds a leak in RecordingInfo::StartRecording
[14:11:09] stuartm: it's the leak Udo is still seeing
[14:12:43] stuarta: well at least something is consistent
[14:14:23] stuartm: probably worth back-porting to 0.23, especially since Ubuntu and other distros will still ship with 0.23 for another 6 months
[14:15:39] stuarta: i thought we generally stopped backporting things once we went into feature freeze
[14:16:41] stuartm: nah, we were still backporting stuff to 0.22 even after 0.23 was released, it's a question of how important the fix is vs the invasiveness
[14:26:39] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[14:31:41] Jog (Jog!~joghur@1908ds1-nivaa.0.fullrate.dk) has joined #mythtv-bsp
[14:32:14] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[14:34:12] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[14:37:06] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[14:48:49] danielk22: sphery: I think I may have #8910 licked..
[14:49:23] RogerM (RogerM!~chatzilla@212.247.248.179) has joined #mythtv-bsp
[15:24:25] stuartm: stuarta: guessing that you don't plan to work on http://svn.mythtv.org/trac/ticket/7881 before tomorrow?
[15:25:54] stuartm: fundamentally it's a straight-forward task, add a new table, change code to use it, schema update to migrate over existing recgroups/passwords
[15:26:49] stuarta: nope, you can steal it if you want
[15:27:12] stuarta: 8 months ago i thought i would have time to do some coding
[15:27:20] stuarta: i've had bugger all
[15:36:29] oobe (oobe!~thingo@unaffiliated/oobe) has quit (Ping timeout: 240 seconds)
[15:48:04] stuarta: stuartm: i doubt i'd even look at it tomorrow
[15:48:38] ** skd5aner came in to see how the progress is going, but assumes that all bugs have already been squashed by now **
[15:48:39] skd5aner: ;)
[15:49:09] stuarta: all bugs have been made into a soup, but nobody has had a bowl yet...
[15:49:34] skd5aner: yay... floor soup is the *best*
[15:52:52] stuarta: oh goodie. somebody fixed the OSD being stuck on
[16:14:59] sphery: danielk22: thanks for [26235
[16:22:21] stuartm: danielk22: backend log, to keep it short I grepped for the chanid, if that has cut out relevant info I'll try again – http://mythtv.pastebin.ca/1938326
[16:23:34] stuartm: to re-iterate, so long as the recording is in progress, refreshing the list, say leaving and re-entering watch recordings etc causes it to generate a new preview image
[16:27:27] stuartm: frontend, again, grepping for the chanid, http://mythtv.pastebin.ca/1938330
[16:34:19] sphery: stuartm: out of curiosity, did you check after [26235]?
[16:34:47] stuartm: sphery: yeah, this is with 26235
[16:35:16] sphery: oh, wait, nvm... I understand what you're saying now--the timestamp update on the recorded entry is causing it to re-request previews during recording, right?
[16:36:05] stuartm: sphery: I'm not certain that's the cause, I don't know what was changed in the preview gen re-write and whether it's refering to the timestamps, but that would be my guess
[16:50:35] stuartm: the preview it fetches always seems to be a new position for some reason, could be that it's seeking to the default offset in the first few minutes of the recording, but it still seems to come up with a new image when we're 60+ minutes in so that's strange
[16:54:36] stuartm: they appear to be within a few frames of each other, as though each time libav is seeking to a random point close to, but not exactly at the frame we requested, so I blame the lack of a seektable for that
[16:54:46] sphery: The default position changes as a result of the length of the recording with the "smart preview pixmap offset"--but nothing except the code that actually grabs the preview knows what position that is. So, each time we grab a new one, it would be from a different point, but, I'm pretty sure there's no way that's related to the decision to make a new one.
[17:17:06] Beirdo: OK, good morning.... time for another day of bug squashing
[17:20:17] kormoc: trac dead for anyone else?
[17:20:30] Beirdo: yep
[17:20:51] Beirdo: I just clicked on the timeline, still waiting
[17:20:55] Beirdo: been over a minute
[17:21:13] kormoc: try now
[17:21:39] Beirdo: much better
[17:25:03] Beirdo: danke :)
[17:25:11] stuartm: sphery: it's not related and I wasn't trying to relate them, if it appeared that way I apologise
[17:25:53] stuartm: I'd forgotten about the smart preview offset, that would explain why each image was taken at a different point
[17:26:12] stuartm: so the only issue is the repeated preview gen calls
[17:26:32] Beirdo: and that's when leaving PBB and re-entering?
[17:26:38] Beirdo: just catching up :)
[17:26:58] Beirdo: that's one way I didn't test it last night when trying
[17:28:18] RogerM_ (RogerM_!~chatzilla@212.247.248.179) has joined #mythtv-bsp
[17:29:20] stuartm: Beirdo: leaving and re-entering, but it's also triggered whenever there are full list updates, e.g. delete a recording, new recording starts and when the update events are recieved we'll request a new preview
[17:30:40] RogerM (RogerM!~chatzilla@212.247.248.179) has quit (Ping timeout: 265 seconds)
[17:30:42] RogerM_ is now known as RogerM
[17:31:25] sphery: stuartm: yeah, I didn't take it personally or anything--just wanted to make sure that didn't lead someone down the wrong path for debugging it :)
[17:32:31] Beirdo: gotcha
[17:33:10] Beirdo: well, if you have it well in hand, I'll carry on elsewhere, let me know if you need more logging of that, etc.
[17:33:48] sphery: stuartm: BTW, did you test the recording edit status change? We were setting the flags for the "current" programinfo, but no others. I don't see any way that the current one would have been left in the wrong state, so I figure it must have been the lack of DB updates and a programinfo reload or something? Anyway, just wanted to verify whether it's actually fixed, now.
[17:35:31] stuartm: sphery: the way I reproduced was to start with a recording with no cutlist, start playback, create a cutlist then exit back to watch recordings, the icon associated with the editing flag was visible, leaving watch recordings and re-entering to force an update didn't change it
[17:35:56] stuartm: I've not tested since the fix went in, I need to hack a theme to add the 'editing' icon
[17:40:25] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Quit: Coyote finally caught me)
[17:41:57] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[17:42:36] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has joined #mythtv-bsp
[17:43:59] kevink is now known as noah
[17:44:15] Beirdo: anyone have comments on the latest addition to #8872?
[17:44:24] noah (noah!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[17:44:35] Beirdo: I think I'd like to see that as a separate bug report if it's valid
[17:46:18] kevink is now known as noah
[17:49:48] sphery: Beirdo: it is already a separate bug
[17:50:29] Beirdo: K.
[17:50:35] sphery: http://svn.mythtv.org/trac/ticket/8854
[17:50:58] sphery: seems he's mentioning a different location for it in #8854, but...
[17:51:39] Beirdo: different location, same issue for sure
[17:52:06] Beirdo: I'm debating fixing it in the threadpool today
[17:53:03] kevink is now known as noah
[17:53:18] noah (noah!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[17:53:27] sphery: maybe just reference comment:21:ticket:8872 on #8854 if you want it to be handled all at the same time
[17:53:41] Beirdo: yeah
[17:54:29] sphery: I'm guessing whoever does #8854 will grep the code for other instances if they see reference to a second instance
[17:54:33] Beirdo: yeah
[17:54:44] Beirdo: done
[17:55:37] Beirdo: I'd like to mlock #8872, it keeps seeming to grow unnecessarily
[17:55:50] sphery: I'm wondering why you'd want to remove all listings data and then reschedule... Maybe this is for EIT users who get borked data (since mythfilldatabase --refresh-all/--dd-grab-all would clear and replace the listings)?
[17:58:22] Beirdo: yay, locked.
[17:58:26] sphery: Beirdo: ah, you didn't use my ref format... (It actually links directly to the comment with comment:21:ticket:8872 )
[17:58:38] Beirdo: sorry
[17:58:45] RogerM_ (RogerM_!~chatzilla@212.247.248.179) has joined #mythtv-bsp
[17:58:58] sphery: :) no big deal... I just don't see many of those comment refs, so I'm trying to make them catch on.
[17:59:52] Beirdo: there
[17:59:55] Beirdo: :)
[18:00:06] Beirdo: learn something new :)
[18:00:09] sphery: heh
[18:01:10] sphery: you could edit http://svn.mythtv.org/trac/ticket/8872#comment:22 , too, to say #8854 (instead of #8852 :)
[18:01:20] Beirdo: crap
[18:01:24] sphery: lol
[18:01:30] sphery: at least we can edit these mistake, now
[18:01:31] RogerM (RogerM!~chatzilla@212.247.248.179) has quit (Ping timeout: 265 seconds)
[18:01:38] Beirdo: done
[18:01:39] RogerM_ is now known as RogerM
[18:01:41] Beirdo: thank you
[18:02:29] sphery: only noticed because I tried to use that link to get to the ticket to see if you had just edited the existing one (since I didn't get an e-mail)--so I could learn that editing the existing comments doesn't spam the list
[18:02:45] sphery: so, thanks for teaching me something new about trac
[18:02:51] Beirdo: no problemo
[18:05:03] ** sphery considers editing http://svn.mythtv.org/trac/wiki/WikiFormatting to include information from (or link to) http://trac.edgewall.org/wiki/TracLinks **
[18:06:19] sphery: ah, it already links to TracLinks
[18:11:01] kevink (kevink!~chatzilla@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100723085541])
[18:11:03] Beirdo: moarcoffee!
[18:17:44] noah (noah!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[18:47:41] sphery: anyone around who can kick trac?
[18:51:12] stuartm: sphery: done
[18:52:07] sphery: thx
[18:52:10] wagnerrp: stuartm: any comment on the discussion in -users? i know you did some work on cleaning up the tuner pages
[18:52:36] stuartm: I don't read users, so let me check the archive
[18:52:43] wagnerrp: IRC channel
[18:52:55] stuartm: oh, hang on then
[20:13:10] danielk22: Is anyone else having trouble pulling up the guide "S" in LiveTV?
[20:13:46] stuarta: ooo, it's been ages since i tried livetv
[20:14:48] Beirdo: nigel isn't an IRC user, is he?
[20:15:41] stuarta: nope
[20:16:35] Beirdo: drats
[20:17:00] Beirdo: #7438 is one of his. I guess I'll put it infoneeded
[20:17:18] danielk22: stuarta: thx
[20:17:51] stuarta: i didn't do anything
[20:18:01] stuarta: perhaps i'd better test livetv guide
[20:18:48] stuarta: nope, came up fine
[20:22:27] stuartm: danielk22: which renderer?
[20:22:48] stuartm: works fine here
[20:23:24] stuarta: bloody OSD keeps getting stuck on every now and again watching recordings
[20:30:14] stuartm: stuarta: open a ticket where Mark will be able to see it since he's not been in IRC for the last few days
[20:31:09] stuarta: i'll see if i can narrow down when it happens
[20:47:55] stuarta: seems to be after skipping the OSD doesn't clear
[20:48:01] stuarta: can anyone else confirm?
[20:49:53] stuarta: and the i skip again and it does clear
[20:49:56] stuarta: then
[20:51:10] stuartm: I can't confirm, I can only say I haven't see it
[20:51:18] stuarta: :(
[20:51:34] stuartm: but it could be related to the osd painter, I'm using vdpau
[20:52:08] stuarta: i'm not
[20:54:33] kevink (kevink!~chatzilla@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Ping timeout: 260 seconds)
[20:56:49] danielk22: stuartm: XVideo renderer, but it could be something local, I'm compiling a clean copy to re-test.
[21:02:56] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Remote host closed the connection)
[21:03:24] Beirdo: for #8071
[21:03:59] Beirdo: I have a potential fix, but wanted to pass the concept past the mythui gods :)
[21:04:28] Beirdo: I'm thinking of making an event for the UI thread to handle to do the screenshot
[21:04:46] Beirdo: (mythfe XML screenshots)
[21:05:24] Beirdo: as it needs to be done in the UI thread. does that sound like a decent plan, stuartm?
[21:07:08] sphery: Beirdo: And then after 0.24, I could remove the SCREENSHOT key binding (leaving only a ScreenShot jump point) so we don't have the redundant code. Jump Point does more (works outside video playback, gets GUI/OSD/captions/subtitles/etc.). Having both causes confusion, though (since the keybinding writes to ~/.mythtv and the Jump Point writes to /tmp).
[21:07:47] sphery: Beirdo: also, if you're interested in fixing it, the Jump Point uses uncompressed PNG, but the key binding uses compressed PNG. IMHO, we should make the Jump Point use compressed.
[21:08:15] Beirdo: I could certainly look at it
[21:10:49] sphery: I think that should be a very minor change (probably a single argument to an already-existing function call), so I'd consider it a fix
[21:11:16] Beirdo: K
[21:11:29] Beirdo: well, I'll start with making this work, I guess
[21:12:18] sphery: (especially after I posted a bunch of OSD screenshots when we were deciding on which OSD to make the default for 0.22 and people laughed at my terribly slow connection--when the problem was having 70 or so 3MB images)
[21:12:29] Beirdo: I think one more cup of coffee may put me into a position where the headache's at bay enough to work this
[21:12:37] sphery: and, yeah, it's been on my todo since then :)
[21:12:37] Beirdo: yeah
[21:12:41] Beirdo: hehe
[21:12:53] Beirdo: I keep snaking your todos unintentionally :)
[21:12:55] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Remote host closed the connection)
[21:13:01] sphery: I'm not complaining :)
[21:13:25] sphery: Oh, and you could try vodka for the headache--though I can't guarantee it will allow you to work on the programming
[21:13:47] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Remote host closed the connection)
[21:15:17] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[21:15:32] sphery: anyone know how "tab order" works in the Qt GUI in setup?
[21:17:30] sphery: I'm actually able to reproduce the tab order issue of #8726 and #6637 , but I don't know why it's allowing tabbing to non-visible items, so I haven't figured out the fix, yet.
[21:19:08] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[21:19:23] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has joined #mythtv-bsp
[21:20:54] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Client Quit)
[21:21:13] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has joined #mythtv-bsp
[21:24:17] Jog (Jog!~joghur@1908ds1-nivaa.0.fullrate.dk) has quit (Ping timeout: 276 seconds)
[21:31:41] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Quit: Coyote finally caught me)
[21:31:56] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has joined #mythtv-bsp
[21:50:26] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Quit: Coyote finally caught me)
[21:50:45] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has joined #mythtv-bsp
[21:58:43] Beirdo: OK, compiling with an event to do a screenshot
[22:00:15] kevink (kevink!~kevink@c-67-188-35-72.hsd1.ca.comcast.net) has quit (Quit: Coyote finally caught me)
[22:12:12] danielk22: hmm, looking at channel browsing.. it looks like if you enable browsing across all tuners, it breaks channel changes in multirec and across tuners. :|
[22:12:30] stuarta: pnice
[22:12:34] stuarta: er nice
[22:13:06] danielk22: I'm pretty sure that when that first went in it didn't have that bug either :|
[22:19:53] Beirdo: ergh
[22:20:09] ** Beirdo scratches his head **
[22:20:25] ** stuarta scratches Beirdo's head **
[22:21:00] Beirdo: heh
[22:21:15] Beirdo: need to find the UI thread
[22:21:23] stuarta: coding--, jack daniels++
[22:21:37] ** stuarta suggests looking behind the couch **
[22:21:45] Beirdo: I put my event going to the mythmainwindow, and it's still whining... not thinking hard enough :)
[22:21:48] stuarta: all lost things end up there
[22:22:31] Beirdo: in the couch cushions if small enough
[22:22:47] Beirdo: but the UI thread's too big... gotta be behind the couch
[22:22:54] stuarta: definitely :)
[22:26:04] sphery: danielk22: IIRC, there are limitations to when that works--like it won't work within 2 minutes of a program change. That said, users have been saying exactly that for a long time, now.
[22:27:27] sphery: unfortunately with the plethora of related/relevant settings, no one has been able to figure out exactly what they're seeing and whether it's really an issue or just misunderstanding. So, it's good that you've figured out how to reproduce it, so it can get fixed (and people will quit complaining about the "locked on a mux" thing)
[22:28:50] danielk22: sphery: yeah, it kinda sort of works.. but it is exceptionally boneheaded.. like when browsing it checks every channel in turn to see if it is tunable; instead of say figuring out that it's a tuner that is not currently available.. plus it relies on channum's being unique across all tuners; an unlikely thing in and of itself.
[22:31:31] sphery: cool, it will be very nice to have that fixed to work properly
[22:38:14] stuarta: why do i have letterboxing on a 4:3 display with 4:3 content
[22:38:16] stuarta: ?
[22:38:33] Beirdo: pretty
[22:38:45] stuarta: not pretty, stretchy
[22:40:17] sphery: invalid X configuration (unless you're talking about a Mac OS thing, in which case I have no idea)
[22:40:22] sphery: ?
[22:40:58] stuarta: oh that thingamajig-whatsit-in-xorg.conf
[22:41:11] sphery: stuarta: if it's standard X: xdpyinfo | grep -B2 resolution
[22:41:24] sphery: your millimeter dimmensions /must/ be a 4:3 ratio
[22:42:03] stuarta: ah, it's picked up the dual head full res
[22:42:10] stuarta: dimensions: 2560x1024 pixels (684x271 millimeters)
[22:42:24] stuarta: it's 2x 1280x1024
[22:42:50] stuarta: missing a dot per inch tho... resolution: 95x96 dots per inch
[22:43:26] sphery: stuarta: yeah, with dual head, you almost definitely have to set Monitor aspect ratio in Appearance settings
[22:44:23] stuarta: last time i played this game i just had to sort out the stuff in xorg.conf
[22:44:37] stuartm: no longer necessary
[22:45:38] stuartm: just flip the display aspect ratio setting in myth as sphery suggests
[22:45:46] stuarta: anyway, this has nothing to do with squashing bugs so i'll shutup
[22:46:12] sphery: oh squashing bugs... I may have misunderstood the BS in this BSP
[22:46:16] sphery: :)
[22:47:23] ** stuarta plays hunt the settin **
[22:47:24] stuarta: g
[22:48:01] stuartm: Appearance settings, second page, Monitor Aspect ratio
[22:48:19] stuartm: same screen you would have set the screen to use
[22:48:56] stuarta: so it's already set to 4:£
[22:48:59] stuarta: 4:3
[22:49:00] sphery: stuarta: and if you don't see it, that means you don't need to set it.
[22:49:57] sphery: stuarta: it may be ignored if Display on screen is 0/All
[22:50:07] stuarta: display is on screen 1
[22:50:24] stuartm: hmm, odd
[22:52:03] sphery: that probably means UsingXinerama() is returning false
[22:52:31] sphery: stuarta: got a frontend log at important,general (the default)?
[22:53:03] stuarta: i'd have to restart as it's well gone from scrollback in that window
[22:54:11] stuartm: I'm also using a dual monitor setup but I'm not seeing the same issue
[22:54:37] stuarta: sphery: what are you looking for in the output?
[22:56:00] sphery: things like, "Physical size of display unknown..." or any GUI size info
[22:56:18] stuarta: after starting playback or before?
[22:56:28] sphery: at frontend startup actually
[22:56:45] sphery: it's possible it may just now work, anymore, for something in your configuration
[22:57:07] sphery: there have been some changes to that code since 0.23
[22:57:21] stuarta: Desktop video mode: 684x271 60.0197 Hz
[22:57:25] stuarta: max_width: 2560 max_height: 1024
[22:59:09] stuartm: the physical widths of your displays together are 68cmx27cm?
[22:59:39] stuarta: that's about right
[23:00:05] stuarta: ah, i think it's got to do with the broadcast resolution
[23:00:24] stuarta: 2010-09–11 23:55:30.238 Display Rect left: 0, top: 128, width: 1280, height: 768, aspect: 1.33333
[23:00:28] stuarta: 2010-09–11 23:55:30.238 Video Rect left: 0, top: 0, width: 544, height: 576, aspect: 1.77778
[23:00:31] stuarta: 2010-09–11 23:55:30.255 VideoOutput: Pixel dimensions: Screen 1280x1024, window 1280x1024
[23:00:34] stuarta: 2010-09–11 23:55:30.258 VideoOutput: Xinerama display dimensions: 361x271 mm Aspect: 1.3321
[23:00:37] stuarta: 2010-09–11 23:55:30.258 VideoOutput: Estimated window dimensions: 361x271 mm Aspect: 1.3321
[23:00:40] stuarta: scuse the paste
[23:01:03] stuartm: stuarta: so it's pillarboxed 4:3 in 16:9
[23:01:33] stuarta: virgin1
[23:01:47] stuarta: that's the channels standard broadcast res
[23:02:20] stuarta: so it may well be more correct now that it was before
[23:02:30] stuartm: I know it's the case with BBC stuff, e.g. Family Guy, it's irritating because I get borders on all sides because my displays are 16:10
[23:03:10] stuartm: I'm trying to think if I've got any 4:3 stuff recorded on Virgin
[23:03:21] stuarta: anything star trek
[23:03:29] stuarta: that'll do it
[23:04:10] stuartm: almost all channels now don't bother with proper aspect ratio changes, they assume everyone is using a widescreen tv and keep it all in 16:9
[23:04:25] stuarta: which is better overall
[23:04:33] ** stuarta need monitor upgrade **
[23:04:52] stuarta: i also need to go to bed. i'm on baby duty in the morning
[23:05:03] stuarta: and he get up in a bit over 6hrs
[23:05:21] stuarta: so nn all, back sometime tomorrow
[23:05:31] stuartm: I've scheduled a recording tomorrow morning, but I suspect it's just the same thing I see with other channels
[23:06:38] RogerM (RogerM!~chatzilla@212.247.248.179) has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716])
[23:18:34] Ian_Zeplin (Ian_Zeplin!~Ian_Zepli@host-84-9-37-206.dslgb.com) has quit (Quit: When two people dream the same dream, it ceases to be an illusion. KVIrc 3.4.2 Shiny http://www.kvirc.net)
[23:25:22] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 252 seconds)
[23:34:49] Beirdo: 2010-09–11 16:34:29.168 Scaling to 1920 x 1080 from 1920 x 1080
[23:34:49] Beirdo: 2010-09–11 16:34:29.310 MythMainWindow::screenShot succeeded
[23:34:55] Beirdo: woohoo, success
[23:35:37] stuartm: only a success if there is a good image produced :)
[23:35:46] Beirdo: there is
[23:36:01] Beirdo: I triggered it from chrome
[23:36:11] Beirdo: and there it is
[23:36:55] Beirdo: works at the menu... works during playback
[23:39:21] Beirdo: do we want to keep it as JPEG, or change it to PNG?
[23:48:39] iamlindoro: PNG fo' sho'
[23:50:08] Beirdo: I would tend to agree. and nothing is really depending on it being JPG, I'd think, since this was reported borked since 0.22-fixes

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.