Back to Home / #mythtv / 2008 / 01 / Prev Day | Next Day
#mythtv IRC Logs for 2008-01-21

---Logopened Mon Jan 21 00:00:49 2008
00:05-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
00:11-!-Kazuhiro [] has left #mythtv ["Leaving"]
00:28-!-harminoff [] has quit [Remote closed the connection]
00:28-!-harminoff [] has joined #mythtv
00:44-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
01:13-!-ahbritto [] has quit [Client Quit]
01:15-!-greed [] has quit [Read error: 104 (Connection reset by peer)]
01:26-!-__gnome42 [] has quit [Remote closed the connection]
02:09-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Read error: 113 (No route to host)]
02:14-!-harminoff [] has quit [Remote closed the connection]
02:15-!-harminoff [] has joined #mythtv
02:23-!-Netsplit <-> quits: dekar1, janneg
02:23-!-dekarl [] has joined #mythtv
02:25-!-Netsplit over, joins: janneg
02:43-!-harminoff [] has quit [Remote closed the connection]
02:43-!-harminoff [] has joined #mythtv
03:15-!-harminoff [] has quit [Remote closed the connection]
03:16-!-harminoff [] has joined #mythtv
04:03-!-harminoff [] has quit [Remote closed the connection]
04:03-!-harminoff [] has joined #mythtv
04:07-!-grokky [] has joined #mythtv
04:09-!-johnp__ [] has joined #mythtv
04:11-!-onixian [] has joined #mythtv
04:18-!-joobie [n=joobie@] has quit ["This computer has gone to sleep"]
04:34-!-knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has joined #mythtv
04:53-!-gardz [] has quit []
05:17-!-xian__ [] has joined #mythtv
05:18-!-onixian [] has quit [Success]
05:35-!-xian__ [] has quit [Connection timed out]
05:41-!-MGisbers [n=mgisbers@] has joined #mythtv
05:57-!-rod_ [] has quit [Remote closed the connection]
06:03-!-BleedAway [] has quit [Read error: 110 (Connection timed out)]
06:25-!-leprechau [] has quit [Remote closed the connection]
06:29-!-leprechau [] has joined #mythtv
06:30-!-gardz [] has joined #mythtv
07:17-!-grokky_ [] has joined #mythtv
07:18-!-grokky [] has quit [Read error: 104 (Connection reset by peer)]
07:21-!-MrGandalf [] has quit [Read error: 110 (Connection timed out)]
07:27-!-Netsplit <-> quits: MaverickTech, gbee, tuppa, reynaldo, visit0r, rtsai, Captain_Murdoch, knowledgejunkie, `Spike, RaYmAn-Bx, (+64 more, use /NETSPLIT to show all of them)
07:39-!-Netsplit over, joins: jwhite
07:55-!-Anduin [] has joined #mythtv
07:55-!-loops [] has joined #mythtv
07:55-!-purserj [] has joined #mythtv
07:55-!-clever [] has joined #mythtv
07:55-!-laga [] has joined #mythtv
07:55-!-johnp__ [] has joined #mythtv
07:55-!-cal_ [] has joined #mythtv
07:55-!-kvandivo [] has joined #mythtv
07:55-!-htpcdvbs [] has joined #mythtv
07:55-!-lsobral [n=sobral@] has joined #mythtv
07:55-!-poptix [] has joined #mythtv
07:55-!-leprechau [] has joined #mythtv
07:55-!-briand [] has joined #mythtv
07:55-!-rtsai [n=rtsai@] has joined #mythtv
07:55-!-Dibblah [] has joined #mythtv
07:55-!-jams [] has joined #mythtv
07:55-!-GreyFoxx [] has joined #mythtv
07:55-!-Chutt [] has joined #mythtv
07:55-!-gbee [] has joined #mythtv
07:55-!-okolsi [n=mythtv@] has joined #mythtv
07:55-!-jmk_ [] has joined #mythtv
07:55-!-Hoochster [] has joined #mythtv
07:55-!-Agrajag- [] has joined #mythtv
07:55-!-ead [] has joined #mythtv
07:55-!-jamesd [] has joined #mythtv
07:55-!-hads [] has joined #mythtv
07:55-!-nemik [] has joined #mythtv
07:55-!-RaYmAn-Bx [] has joined #mythtv
07:55-!-Puhi [] has joined #mythtv
07:55-!-dlblog [] has joined #mythtv
07:55-!-visit0r [] has joined #mythtv
07:55-!-gardz [] has joined #mythtv
07:55-!-MGisbers [n=mgisbers@] has joined #mythtv
07:55-!-knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has joined #mythtv
07:55-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
07:55-!-Tanthrix [] has joined #mythtv
07:55-!-MaverickTech [] has joined #mythtv
07:55-!-xris [] has joined #mythtv
07:55-!-elmargol [] has joined #mythtv
07:55-!-jd86 [n=jdio@pdpc/supporter/student/jd86] has joined #mythtv
07:55-!-nordenm [] has joined #mythtv
07:55-!-onyxsoft__ [] has joined #mythtv
07:55-!-crichardson [n=crichard@] has joined #mythtv
07:55-!-mzb_d800 [] has joined #mythtv
07:55-!-Captain_Murdoch [] has joined #mythtv
07:55-!-rooaus [] has joined #mythtv
07:55-!-tuppa [] has joined #mythtv
07:55-!-harminoff [] has joined #mythtv
07:55-!-janneg [] has joined #mythtv
07:55-!-dekarl [] has joined #mythtv
07:55-!-mzb [] has joined #mythtv
07:55-!-Pumpernick [] has joined #mythtv
07:55-!-hachi [] has joined #mythtv
07:55-!-eharris [] has joined #mythtv
07:55-!-adante [] has joined #mythtv
07:55-!-reynaldo [] has joined #mythtv
07:55-!-otwin [n=otwin@] has joined #mythtv
07:55-!-`Spike [] has joined #mythtv
07:55-!-Cougar [] has joined #mythtv
07:55-!-kurre2__ [] has joined #mythtv
07:55-!-CDev [] has joined #mythtv
07:55-!-Internat [] has joined #mythtv
07:55-!-jk1joel [] has joined #mythtv
07:55-!-tomimo [] has joined #mythtv
07:55-!-splat1 [] has joined #mythtv
07:55-!-sphery [] has joined #mythtv
07:55-!-mdew-home [] has joined #mythtv
07:55-!-Vaelys [i=awong@slammer.cs.Dal.Ca] has joined #mythtv
07:55-!-anykey_ [] has joined #mythtv
07:55-!-Snow-Man [] has joined #mythtv
07:55-!-Honk [] has joined #mythtv
08:08-!-reynaldo_ [] has joined #mythtv
08:23-!-Netsplit <-> quits: gbee, MaverickTech, tuppa, reynaldo, rtsai, visit0r, Captain_Murdoch, knowledgejunkie, `Spike, lsobral, (+62 more, use /NETSPLIT to show all of them)
08:23-!-superm1_ [] has joined #mythtv
08:23-!-Netsplit over, joins: Honk, Snow-Man, anykey_, Vaelys, mdew-home, sphery, splat1, tomimo, jk1joel, Internat (+40 more)
08:24-!-Netsplit over, joins: reynaldo_, Anduin, loops, purserj, clever, laga
08:24-!-harminoff [] has quit [Remote closed the connection]
08:24-!-Netsplit over, joins: lsobral, poptix, leprechau, briand, rtsai, Dibblah, jams, GreyFoxx, Chutt, gbee (+5 more)
08:24-!-harminoff [] has joined #mythtv
08:25-!-reynaldo [] has quit [Connection timed out]
08:31-!-reynaldo_ [] has quit [No route to host]
08:31-!-superm1_ is now known as superm1
08:32-!-janneg [] has quit [Read error: 60 (Operation timed out)]
08:35-!-janneg [] has joined #mythtv
08:52-!-MrGandalf [] has joined #mythtv
08:56-!-rooau1 [] has joined #mythtv
09:08-!-harminoff [] has quit [Remote closed the connection]
09:08-!-harminoff [] has joined #mythtv
09:16-!-reynaldo [] has joined #mythtv
09:23-!-j-rod [n=njarod@nat/redhat/session] has joined #mythtv
09:30-!-MaverickTech [] has quit [Read error: 110 (Connection timed out)]
09:31-!-rooau1 [] has quit ["Leaving."]
09:33-!-cattelan [] has joined #mythtv
09:38-!-onyxsoft__ [] has left #mythtv ["Ex-Chat"]
09:38-!-onyxsoft__ [] has joined #mythtv
09:43-!-harminoff [] has quit [Remote closed the connection]
09:43-!-harminoff [] has joined #mythtv
09:54-!-Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:54-!-Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit [Read error: 104 (Connection reset by peer)]
09:55-!-reynaldo [] has quit [Read error: 110 (Connection timed out)]
10:00-!-jgarvey [] has joined #mythtv
10:10<gbee>what happened to the backend generating a preview when a recording finished?
10:12<MrGandalf>looks like it now kicked off another mythbackend with arguments.
10:15<gbee>yeah, but we were supposed to be generating a preview as a recording finishes, to reduce the load if a user goes into the frontend/mythweb and triggering it to generate 100 previews at the same
10:16<gbee>we don't seem to be doing that (anymore, if we ever implemented that idea, can't remember)
10:20<janneg>gbee: it was implemented
10:21<gbee>janneg: in that case I can't understand #4350
10:22<gbee>no that's not right, I just mean that the cause of #4350 isn't what we think it is
10:22<gbee>it's got to be a bug in the http/xml server
10:25<gbee>xris: you about?
10:27<janneg>gbee: I thought it tries to generate previews in a different size
10:28<gbee>janneg: I changed the xml preview generation to just resize the existing image instead, so it shouldn't touch the preview generator
10:30<gbee>if there is no existing image, then it will generate a new one, but as long as we generate a new image when a recording finishes, that means mythweb should never be triggering the preview generator unless it's for in-progress recordings
10:31<gbee>just tried it though and the original backend process is going to 96% and staying there, so it's nothing to do with the preview generator
10:33<janneg>it does:
10:36<janneg>gbee: there seems to be an error. I have one .png and an identicat .150.png
10:37<gbee>HttpComms::done() - NetworkOperation Error on Finish << that's the problem
10:46-!-MaverickTech [n=Maverick@] has joined #mythtv
10:50<gbee>debugging it now
10:56<gbee>looks like mythweb is falling back to using myth protocol to get a preview if the xml method fails?
10:57-!-elmargol [] has left #mythtv ["Ex-Chat"]
11:01-!-dekar1 [] has joined #mythtv
11:03<gbee>heh, maybe not - need to _install_ after patching/building
11:06-!-moodboom [] has joined #mythtv
11:06<janneg>the load comes from x threads waiting for data in in QSocketDevice
11:09-!-MGisbers [n=mgisbers@] has quit [Read error: 110 (Connection timed out)]
11:11-!-JoeBorn [] has joined #mythtv
11:16<gbee>yeah, though it doesn't seem to go away afterwards ...
11:16<gbee>found a bug in either mythweb or the xml stuff, just running it done now
11:17<janneg>now they won't go away but keep increasing
11:17-!-dekarl [] has quit [Read error: 110 (Connection timed out)]
11:18<MrGandalf>hmm, myth acts VERY oddly with dvb radio
11:20<gbee>Mythweb is requesting a file with the starttime: 2007-05-19T11:58:00 but the actual starttime is: 2007-05-19 12:58:00
11:20<MrGandalf>looks like it attemts to tune every channel on the same transport sequentially
11:20<gbee>looks like a daylight savings/BST error
11:21<MrGandalf>does anyone else get dvb radio they can test with?
11:21<gbee>xris: mind looking at this?
11:22<gbee>MrGandalf: yeah, I do, let me check
11:22<MrGandalf>gbee: thanks
11:23<gbee>MrGandalf: should the problem be obvious, what am I looking for?
11:24<MrGandalf>gbee: just change channels a few times between radio channels
11:24<MrGandalf>I just want to make sire it's not a bug I introduced
11:24<MrGandalf>but I can't imagine what this would be
11:24<gbee>err, that's weird
11:25<MrGandalf>did it tune a channel you didn't select?
11:25<MrGandalf>and attempt to tune a few in between?
11:25<gbee>no, not that I noticed
11:25-!-xris [] has quit []
11:25<MrGandalf>your tuning may be faster
11:25<gbee>5 seconds or so after tuning one channel it changed to another
11:26<MrGandalf>mine went right down the line and attempted like 4 or 5 before it finally locked on one
11:26<MrGandalf>ok, not my bug then :)
11:27<gbee>radio doesn't seem to be working well at all, half the time I don't get audio
11:27<MrGandalf>must be some residual code looking for a video pid
11:28<gbee>and I'm seeing the "one behind" problem as well, where every channel I tune, I'm get the last one I selected instead
11:29<MrGandalf>haven't seen that in awhile
11:29<gbee>I've seen that with normal livetv too since multirec was merged
11:29<gbee>never saw it before multirec
11:30<MrGandalf>I'm going to see if I can get a clean log and submit a ticket
11:32<GreyFoxx>grarrrr segfaults suck
11:32<gbee>yes ... yes they do
11:33<GreyFoxx>I keep getting a segfault in NuppelVideoPlayer::OpenFile when trying to start video playback under OpenBSD
11:34<GreyFoxx>But it makes no sense as it seems to be crashing before the routine actually does anything :)
11:36<gbee>are you looking at the backtrace, or log messages? If the backtrace is pointing to an illogical location then the symbol tables may be messed up
11:36<GreyFoxx>backtrace in gdb
11:36<janneg>MrGandalf: DVB Radio seems to work fine here
11:37<MrGandalf>janneg: of course, is always just me. :) well, now it's gbee too :)
11:37*janneg hates bugs espiecially when he can't reproduce them
11:38<MrGandalf>janneg: it almost seems that the frontend moves to the next channel if it doesn't get a lock quickly enough
11:38-!-Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
11:38<MrGandalf>sometimes it takes 2, sometimes 7 for me
11:39<MrGandalf>but I don't understand why the frontend would be attempting to tune channels I didn't select
11:39<sphery>Heh. The guy who made a comment at sure is brave posting as anonymous. Especially stupid submission when janneg's closure message (last paragraph) in the previous comment explains exactly how it works.
11:47<gbee>even more stupid because he left us his IP, so we can now ban him from the server (if we wanted to)
11:48<gbee> if anyone wants to do that
11:49<gbee>this stuff is why we need the user registration stuff in trac though
11:49<sphery>Besides the language, it just proves he didn't take the time to read/understand what was being said: store in latin1, but do conversions in code where necessary... Seems simple enough to understand. If he finds an issue, he should fix that location (or report that location) where the necessary conversion was forgotten.
11:50<janneg>japan, ntt probably only a dynamic ip
11:52<janneg>gbee: I wanted to answer after the immidiate urge to delete and lock
11:52<gbee>janneg: oh, sorry
11:53<janneg>I don't really care if someone makes a fool of himself
12:00-!-MGisbers [] has joined #mythtv
12:03<janneg>MrGandalf: is there something unusual mythbackend -v network
12:03<MrGandalf>janneg: I'm looking now
12:05-!-dynamicpulse [] has joined #mythtv
12:05-!-dynamicpulse [] has left #mythtv ["Leaving"]
12:06<justinh>why is somebody logging this channel in a public place indexed by google?
12:09<MrGandalf>janneg: what would the backend do if it got an error reading a table from the dvb device?
12:10<janneg>MrGandalf: failing but not changing the channel
12:10<gbee>justinh: !
12:10<laga>who does?
12:11<justinh> Greb, Michael
12:13-!-jmk_ [] has quit ["Leaving"]
12:13<gbee>not impressed, this channel is supposed to be unlogged ... that was my understanding
12:14<justinh>no big deal, but it'd have been nice to know sooner. I knew to watch my Ps & Qs in -users but expect to be able to talk freely here
12:14<janneg>mikegrb: publically logging a channel without notifying the users is rude
12:15<mikegrb>my logging of the channel was by request of devs back in 2002
12:15<justinh>nice to know. only found out by accident today
12:16<MrGandalf>janneg: what's really odd is that my other provider doesn't have this problem at all.
12:16<janneg>mikegrb: we didn't know and weren't around 2002
12:16*MrGandalf checks dtv_multiplex
12:16<gbee>I was told this channel wasn't logged a couple of years ago, by Chutt I thought but I might be remembering that wrong
12:18-!-gr8nash [n=anash@] has joined #mythtv
12:18<gbee>Beirdo has been logging -users all that time but has deliberately not logged this channel
12:20-!-cattelan_ [] has joined #mythtv
12:20<Chutt>nothing i know of logs this channel
12:21-!-cattelan [] has quit [Read error: 113 (No route to host)]
12:22<justinh>er.. I mean
12:22<mikegrb>can be changed to require a pass
12:23<janneg>I don't really care whether this channel is logged or not but it should be announced if we do
12:23<laga>wow. logs from 2002.
12:23<janneg>but no logs for 2006
12:24*mikegrb nods... got to fed up with lilo, wasn't on this network then
12:27-!-MGisbers [] has quit [Connection timed out]
12:27-!-gnome42 [] has joined #mythtv
12:29-!-JoeBorn [] has quit ["rebootus maximus"]
12:31<janneg>mikegrb: I think it would be good to make the logs private. we communicated for the last years that this channel isn't logged
12:31<MrGandalf>janneg: it's a race condition in the frontend. If I turn on ALL logging, all is well
12:32<gbee>if this channel were logged from tomorrow onwards I wouldn't mind, so long as I know it's happening.
12:32<gbee>I've said things in this channel before now which I would not have said knowing that public logs existed
12:34<janneg>gbee: new patch that might help the nova-t500
12:34<gbee>cool, thanks
12:35*gnome42 crosses fingers for gbee!
12:35<mikegrb>mythtv / my son's middle name in the bottom boxes to get #mythtv
12:35<mikegrb>(mythtv / isaac)
12:35<mikegrb>(yes my son was named after chutt... beat that :p)
12:37-!-Hoochster [] has quit [Read error: 104 (Connection reset by peer)]
12:37<gbee>janneg: I've not had any problems since I applied the last patch and firmware (and power cycled), but I'll look at any additional fixes
12:37-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
12:38<gnome42>janneg: I was snooping around that deleteLater business. Came up with this for SIScan
12:38<gnome42>only compile tested
12:39<gbee>actually, that patch is interesting, since it claims to solve tuning issues
12:39<gnome42>gbee: Oh, your recording problems are gone?
12:40-!-xris [] has joined #mythtv
12:41<MrGandalf>janneg: seems to be tied with the guide. It also happens on my other frontend which doesn't have any of my patches applied. If you enter the channel number in directly, it works fine.
12:42<janneg>gbee: those tuning problems look like your failing recordings
12:43<janneg>MrGandalf: I was browsing
12:43<MrGandalf>try from the guide
12:44-!-cattelan_ [] has quit [Read error: 110 (Connection timed out)]
12:48<janneg>MrGandalf: seems to work fine too
12:48<MrGandalf>janneg: perfect :) Well, a good case could be made that if you could easily reproduce it the bug would likely have been fixed by now anyway
12:49-!-Hoochster [] has joined #mythtv
12:50-!-JoeBorn [] has joined #mythtv
13:03<janneg>gnome42: the dtor should be remain useable. I've changed the patch and will test it
13:04<gnome42>janneg: ok, I was sure about that.
13:06<MrGandalf>I put an extra VERBOSE in doEditSchedule before ChangeChannel() so spit out the size of changeChannel return by GuideGrid::Run
13:07<MrGandalf>It returned 189
13:07<MrGandalf>i'm pretty sure that's a bit big
13:07-!-cattelan_ [] has joined #mythtv
13:08-!-cattelan_ [] has quit [Client Quit]
13:08-!-cattelan_ [] has joined #mythtv
13:11-!-cattelan_ [] has quit [Client Quit]
13:11-!-cattelan_ [] has joined #mythtv
13:18<johnp__>How do you output a line from the EIT, ( I could do with step by step instructions )
13:21<janneg>johnp__: just for debugging?
13:21<janneg>cerr << "bla..." << variable << endl;
13:23<johnp__>Could do with some independence from myth, like tzap and dvbsnoop ( I did know this but it's lost in the mists of time)
13:23<MrGandalf>something definately wrong with DBChanList GuideGrid::GetSelection()
13:25<gnome42>janneg: commit looks good. Thanks
13:26-!-harminoff [] has quit [Remote closed the connection]
13:26<MrGandalf>janneg: can you have a look at GuideGrid::GetSelection()? There looks to be some redundancy in there.
13:27-!-harminoff [] has joined #mythtv
13:29<gbee>johnp__: if you want to dump a single EIT table, then tune to a channel with mythtv (or tzap) and then dvbsnoop -nph -n 1 0x12
13:29<gbee>where "-n 1" is the number of events to dump
13:36<johnp__>gbee,janneg:Thanks people.
13:37<gbee>xris: there?
13:39<xris>here but busy. saw your comments from last night, no time to look
13:42-!-nemik_ [] has joined #mythtv
13:45<clever>janneg: id perfer VERBOSE() over cerr/cout/printf
13:46<clever>also 'stdout' appears to be a socket
13:46<clever>to mysql
13:47<clever>by closing fd 0 you might corupt the mysql session by mistake if you use printf or cout
13:49<kormoc>stdout can't be a socket to mysql
13:49<clever>mythbacke 5728 mythtv 0u IPv4 15802 TCP theP4:34878->media:mysql (ESTABLISHED)
13:49<clever>acording to lsof file device 0 is mysql
13:50<clever>if you close(0); then the socket() that mysql uses in the lib's will probly wind up returning 0
13:50<clever>on my frontend stdout is null
13:51<kormoc>stdout/stderr/stdin are special and wouldn't be listed in lsof
13:51<clever>lrwx------ 1 mythtv mythtv 64 Jan 21 14:51 /proc/5728/fd/0 -> socket:[15802]
13:51<kormoc>they won't be listed anywhere, they're just 'magically' there
13:51<clever> sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
13:51<clever> 117: 3C01A8C0:883E 6701A8C0:0CEA 01 00000000:00000000 02:0006BA1D 00000000 119 0 15802 2 c67d8c00 55 10 0 2 100
13:52<clever>kormoc: when i look at /proc/PID/fd/ on normal programs i can see /dev/pts/x open as fd 0-2
13:52<clever>when i look at mythbackend i can see 0 is a tcp socket
13:52<clever>stdout is just fd 0 under linux
13:53<kormoc>typically, but not always
13:53<kormoc>if you close it and re-open it, it can change numbers, as it's just a standard stream
13:54<clever>but printf and cout i beleive will go to stream 0
13:54<clever>cerr will go to 1
13:54<clever>cin will use 2
13:54<kormoc>they are actually smart enough to know to use the correct fd
13:54<janneg>gbee: the earlier patch won't affect the nova-t 500 try this one instead
13:54<kormoc>so if stdout is 221, cout will use 221
13:54<clever>kormoc: how is that info saved across a execve then?
13:55<clever>ive used pipe to make a pair of connected fd's
13:55<janneg>clever: please guess that VERBOSE is using
13:55<clever>and dup2 to rename them into 0,1,2
13:55<kormoc>the pipe breaks it into the different namespace
13:55<gbee>janneg: thanks
13:55<clever>then closed everything else and execve'ed
13:55<clever>ive been able to duplicate the code irssi uses for /exec in one of my own programs and it work right
13:56<clever>without doing anything special to mark fd 0 as stdout
13:56<kormoc>the fd number doesn't mean anything from one program to the next
13:56-!-nemik [] has quit [No route to host]
13:56<kormoc>that's because the shell is actually doing the work to keep them working correctly
13:56<clever>from what i know 0 appears to be stdout when a program starts up
13:56<kormoc>typically is
13:56<clever>ive ran programs without a shell before
13:57<kormoc>with pipes?
13:57-!-stuarta [n=stuarta@unaffiliated/stuarta] has joined #mythtv
13:57<clever>but it would probly work exactly the same way with tcp sockets or pty's
13:57<kormoc>Well, given without a shell, you can't pipe...
13:58<clever>the pipe syscall is given an array of 2 int's
13:58<clever>and it puts in there the fd of both ends of a pipe
13:58<kormoc>and in what context did you run this program?
13:58<clever>c++ program i made
13:58<kormoc>but you didn't run it via a shell, so it replaced init? or was it it's own shell?
13:59<clever>the c++ prog ran from a shell in its own pid
13:59<clever>thats a small chunk of it
13:59<kormoc>then it ran via a shell and the shell handled the magic
13:59-!-okolsi [n=mythtv@] has quit ["ircII EPIC4-2.2 -- Are we there yet?"]
13:59<kormoc>there's a difference between ./app 1 | app 2 and using syscall pipes
13:59<clever>look at line 33
13:59<clever>i didnt use |
14:00<clever>i used a ! cmd on irc:P
14:00<clever>which triggered the function in the pastebin
14:00<kormoc>this is entirely useless
14:00<clever>that function made 2 sets of pipe's for stdin/err and stdout
14:00<clever>then used dup2 to copy those to the right fd's
14:00<clever>a for loop to close every fd over 2
14:01<clever>and then execve'd "/bin/bash" "-c" "stringfromelsewhere" NULL
14:02<clever>i did the 'magic' myself when starting the shell which then does the word spliting of the args to start the cmd i wanted
14:03<clever>when you './app 1|app 2' the shell just uses pipe syscalls internaly to do the same thing basicaly
14:08<janneg>clever: VERBOSE is just a macro around cout
14:08<clever>ive read the VERBOSE code
14:08<clever>and use it does use cout :S
14:08<clever>now im confused:P
14:13<clever>on line 779 of programs/mythbackend/main.cpp fd0 is closed with a plain syscall(bypassing the lib's)
14:14<clever>and nothing appears to update cout/printf on where to go now
14:15<clever>seems odd for it to just do that in the middle of the code like that
14:16-!-bendailey [] has joined #mythtv
14:17<gbee>kormoc: just noticed mythweb uses a javascript packing script which is now being flagged (intentionally) by a couple of antivirus outfits because it's being used by a large in a number of javascript exploits to 'hide' from AV software, the prevailing advice is to forget JS packing because the benefits aren't worth it anyway unless the code is bloated to start with
14:17<gbee>just thought I'd throw that out there, if you've not heard it already
14:18*laga is also seeing some interesting javascript errors on a rather old mythweb checkout
14:18<xris>laga: time to update, then. :)
14:18<laga>eg i can't delete any recordings in the main recordings page
14:18<clever>my mythweb has been dead for awhile
14:18<clever>the system hosting it went tits up on the hdd
14:19<laga>works fine if i go the subpage of the individual recording
14:19<laga>xris: i'll update soon and let you know :)
14:20-!-superm1 [n=superm1@ubuntu/member/superm1] has quit [Remote closed the connection]
14:21<kormoc>gbee, it drops download size by 50% or so, can speak up loading on slow connections
14:21-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
14:22<gbee>kormoc: the argument, as I recall, is that with some browsers unpacking actually adds more to the execution time than is saved in download time
14:22<gbee>but I can't find the article now
14:23<kormoc>gbee, when I profiled it with firebug, it didn't add time spent unpacking it, so it was a net gain, but a small one
14:23<gbee>combined with security companies who are now blocking packed scripts and/or sites that use them, the summary seemed to be that packing was a bad idea
14:23<kormoc>and granted, that doesn't take into account IE or safari
14:24<gbee>but I'm not suggesting it's removed from mythweb, just conveying what I'd read
14:25<gbee>I think I remember it saying that IE7 was especially bad, unpacking there added several seconds (for whatever reason, not sure I understood why at the time)
14:26<kormoc>Well, that would be a very good reason to revert the change
14:26<kormoc>I'll have to speed test it
14:29<xris>weird... packing like that is usually supposed to speed things up
14:29-!-bendailey [] has left #mythtv []
14:30<gbee>I'd be interested to hear the results if you do kormoc, I couldn't really believe it when I read the figures for IE7 but I didn't have any reason to doubt the claims either
14:31<MrGandalf>janneg, gbee: GuideGrid::fillChannelInfos() in the "hande duplicates" loop
14:32<gbee>can't see where we are going wrong with mythweb previews, the times received by the backend are an hour off (for some recordings, mainly last summer) but the times displayed in mythweb are correct
14:32-!-beavis [] has joined #mythtv
14:33<clever>making the preview images kills my master backend:S
14:33<gbee>clever: yeah, that's what I was looking at when I spotted this other bug
14:33-!-Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
14:33<janneg>clever: closing stdin in the backend should do any harm
14:34-!-Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
14:34<clever>is stdin 0 or 2?
14:34<janneg>stdin used to be fd 0
14:34<clever>thats where half my confusion is from
14:34<clever>yeah closing stdin wont harm cout/printf
14:36<janneg>kormoc: given that konquerer is much faster in rendering mythweb pages it shouldn't affect safari users
14:36<clever>i rarely use konq
14:36<clever>its on a KVM with winblows so i only use it when firefox on winblows is misbehaving
14:36<xris>gbee: different preview issue, or is that still the 100% cpu usage one?
14:36<clever>and even then theres a tvout right next to the whole thing with mtyh
14:37<clever>100% system usage error durring preview generation, has hit me
14:37<janneg>xris: it might cause the 100% system usage
14:38<xris>the bad date?
14:38<gbee>xris: different, for some reason mythweb is requesting preview images using GetPreviewImage where the starttime is an hour off e.g. 11:58:00 instead of 12:58:00
14:38<xris>none of my recordings are that old, though.
14:38<gbee>I spotted that problem when debugging the 100% cpu usage bug
14:38<xris>sounds like a daylight savings time issue. Go ahead and create a ticket for me on that one.
14:39<janneg>MrGandalf: I fail to see the bug
14:39<MrGandalf>janneg: callsign matching
14:39<MrGandalf>all my radio stations have the same callsign
14:39<MrGandalf>tracking down the commit now..
14:39<stuarta>that's a bit odd
14:40<xris>gbee: no idea how to get around that one, though... mythweb is probably correctly asking for the times in standard time, but the backend recognizes the db field as daylight time, and neither is doing the DT to ST conversion, so things don't match up.
14:41<janneg>MrGandalf: I still fail to see the bug except using channum and callsign for tuning instead of chanid
14:42<janneg>that's just the multirec merge
14:42-!-tulbreak [] has joined #mythtv
14:42<janneg>xris: mythweb shouldn't do any time conversions on starttimes
14:42<MrGandalf>janneg: well, if I comment out the callsign matching, all is well for me
14:43<gbee>xris: I can't see where it's going wrong, but it might be in the value sent from the backend in the first place
14:43<xris>actually, now that you mention it, the recorded show data might actually come straight from the backend and not the db.
14:43<gbee>I realised just now that I was wrong, all the times displayed in mythweb are wrong
14:44<gbee>for the affected recordings
14:44<xris>janneg: it's not converting things... but mysql might do it automatically because the timezone identifier changes between DT and ST.
14:44<MrGandalf>janneg: I'm not saying that portion has bugs, but for some reason the tuning isn't handling it well
14:45<gbee>the example I used earlier was a film version of Hamlet, recorded on 19th May 2007 at 12:58 (according to the database) but mythweb thinks it was 12:00 (11:58 actual start)
14:45<xris>gbee: you don't have daylight time, do you?
14:45<MrGandalf>janneg: I understand the concept behind it, but I'm not sure I agree with matching callsigns (but that's beside the point)
14:45<stuarta>xris: not at the moment
14:45<stuarta>but we do over summer
14:45<gbee>xris: we do, British Summer Time BST, versus GMT
14:45-!-Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
14:45<xris>really? wow, I thought the US was the only country to do stupid stuff like that.
14:45<stuarta>nope, most countries do
14:46<laga>almost everyone does it
14:46<stuarta>australia is the best :) 3 timezones in winter, 5 in summer
14:46<xris>no.. US has cities/counties that don't observe DST when the surrounding areas do
14:47*stuarta files that under the oddness of the US
14:47<MrGandalf>janneg: as I understand it, if a tuner is in use, this allows us to tune a channel on a different source with a matching channum or callsign
14:47<MrGandalf>or rather a different chanid
14:48<MrGandalf>the tuning seems to be tuning every channel in that matching list, however, and not just tuning the first which passes IsTunable()
14:49<GreyFoxx>So,just what sort of info is needed if we want to start a QAM/ATSC tuning database ?
14:49<GreyFoxx>It sucks rescanning and updating xmltvid's and such after you spend timing figuring out which channels are which :)
14:49<xris>gbee: pretty sure that the recordings page displays the info straight from the backend... so either mythweb's time display function is doing the conversion to/from daylight time (because when you display a DST time in standard time, it *would* be an hour earlier), or the backend is providing incorrect info.
14:50<xris>10 AM DT *is* 11 AM ST
14:51<gbee>I'll look programinfo::toString()
14:51<xris>any way to make the upnp stuff accept unix timestamps instead of date strings?
14:51<gbee>I think that it might be intentional though
14:51<GreyFoxx>xris: What calls specifically ?
14:52<xris>the problem with the YYYY-MM-DDTHH:MM:SS format is that it doesn't allow for timezone differences.
14:52<gbee>xris: that would be pretty simple for the xml stuff
14:53<xris>either that or we force code in some place to treat all dates as UTC, or something like that.
14:58-!-davilla [n=davilla@] has joined #mythtv
15:03<MrGandalf>janneg: ticket updated with the fix
15:03<MrGandalf>missed a break in TV::ChangeChannels()
15:12<GreyFoxx>xris: TMS has data for translating zipcodes/postalcodes to the cablecos in your area right ?
15:12<GreyFoxx>I assume they must since they do it now
15:17-!-kormoc_ [n=kormoc@unaffiliated/kormoc] has joined #mythtv
15:17-!-ahbritto [] has joined #mythtv
15:18-!-ahbritto [] has quit [Remote closed the connection]
15:18-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit [Read error: 113 (No route to host)]
15:18-!-ahbritto [] has joined #mythtv
15:19-!-BleedAway [] has joined #mythtv
15:20<gbee>xris: I think changing date() to gmdate() in unix2mythtime() should fix it?
15:21<gbee>the backend is sending the time in GMT, but php's date() function assumes the time it is given in the current timezone
15:22<gbee>testing it now
15:23<gbee>maybe not
15:26<janneg>MrGandalf: committed
15:26<MrGandalf>janneg: thanks
15:27<MrGandalf>has anyone noticed greedydeint doesn't look as good in trunk?
15:29<janneg>GreyFoxx: the info from dtv_multiplex, serviceid, atsc_minor_chan and tsc_major_chan from channel
15:34<GreyFoxx>ok, just looking at the icon stuff xris wrote and it looks like we submit most of that now when people download their icons and submit the changes back
15:34-!-harminoff [] has quit [Remote closed the connection]
15:34-!-harminoff [] has joined #mythtv
15:40*stuarta wonders how to fix the OSX build problem
15:41<gbee>don't think my brain is firing on all cylinders today, I can't get my head around this timezone problem
15:42<stuarta>with timezones, i've always been a fan of 1. store it/use it internally in GMT *always*
15:42<stuarta>2. convert to localtime for user interaction
15:42<gbee>mysql doesn't store timezone information so I'm not sure how 12:58 in the database becomes 11:58 in mythweb
15:43<stuarta>locale info?
15:44<stuarta>heh. did a "low quality" transcode. went from 1.2gb to 1.5gb
15:44<stuarta>oh well
15:45*stuarta wanders off for a bit
15:48<janneg>stuarta: I've valgrinded the backend a little bit and fixed two minor leaks (maybe 100k a day)
15:48<gbee>both database and backend share the same timezone at the moment (GMT)
15:48<janneg>didn't included recordings though
15:55-!-harminoff [] has quit [Remote closed the connection]
15:55-!-harminoff [] has joined #mythtv
15:57<kormoc_>gbee, where are you seeing this?
15:58<justinh>does look ok to folks here for changes to keys.txt for multirec?
15:59<gbee>recordings page, causes problems when we request information on a recording from the backend (program details page and preview images)
15:59<gbee>only affects a dozen or so recordings
15:59<gnome42>justinh: checking ....
16:00<gnome42>justinh: may not be quite right, give me a minute.
16:01<gbee>recordings between Apr 23 and Oct 26 2007 (guessing that probably matches up with the start/end of BST, but I can't remember the dates exactly)
16:03<gnome42>justinh: I was wrong it is correct. Maybe we should mention NEXTCARD which was bound to Y is now unbound? (and can be rebound if desired)
16:03<gbee>March 25th - October 28th, so yes
16:04-!-kormoc_ is now known as kormoc
16:04<gbee>UK timezone, equivalent to DST
16:04<janneg>british summer time
16:07<justinh>gnome42: Y isn't bound to anything now at all? I thought it'd just changed
16:08<justinh>I'd try it out myself but lacking a dvb tuner in my dev box at the moment. still shopping
16:08-!-mattwire [] has joined #mythtv
16:08<justinh>going to wiki up multirec when I have first hand experience of it if nobody else beats me to it too
16:09<gnome42>you are correct. I meant that NEXTCARD is now unbound so if user's want that back they need to change it themselves.
16:09<justinh>ahh you mean add a note that the binding used to be NEXTCARD. feeling a bit slow tonight
16:10<gnome42>yep! no, worries :)
16:11<justinh>now says if that's ok I'll commit it
16:11<gnome42>sure, looks fine
16:12<sphery>stuarta: Probably the transcoding-to-NUV-uses-twice-the-bitrate-specified bug (MPEG-4 only, perhaps?)
16:18-!-cattelan_ is now known as cattelan__away
16:18<GreyFoxx>hmmm I'm suprised more people havenm't complained about those 2 mysql5 specific lines :)
16:18-!-cattelan [] has joined #mythtv
16:18<GreyFoxx>though honestly I didn't intend them to be mysql5 specific :)
16:18<sphery>They were warned...
16:18<GreyFoxx>if they are all that we have that would force a user to upgrade I can certainly look at changing them
16:19<GreyFoxx>yeah which is why I haven't reverted them :)
16:20-!-MaverickTech [n=Maverick@] has quit [Read error: 110 (Connection timed out)]
16:20<sphery>Don't know that's all of it--just the one most people are likely to see (as it's part of the upgrade). IMHO, having it fail during upgrade (and, therefore, alert the user), is a /great/ idea.
16:21<sphery>Helps for the "didn't RTFM crowd." Otherwise, they may complete the upgrade and think they're good until they get strange behavior/crashes/...
16:21<laga>can't you put in a version check?
16:22<sphery>Might be a nice addition to the update that fails to provide a "need to upgrade your DB"-specific message
16:22<GreyFoxx>laga: yeah, but part of the reason we decided to go mysql5 only was for more complex SQL usage. So while my column types can easily change to accomodate older stuff the bigger reason for the change can't
16:22<GreyFoxx>but if 0.21 time comes along and those two lines are the only reason for a user to upgrade to 5 I'll look at making them 3/4 friendly
16:23<sphery>Hmmm. Thought he was suggesting a better error message.
16:23<GreyFoxx>ahh those are generic
16:23<GreyFoxx>we spit out exactly what mysql tells us
16:23<GreyFoxx>don't actually look at the error message
16:24<sphery>Yeah, but if we checked the DB version and spit out an error saying to upgrade the DB if it's < 5.0 or did the update if it's 5.0+...
16:24<GreyFoxx>That's certainly doable
16:25<GreyFoxx>right at the start of DBCheck
16:25<GreyFoxx>good idea
16:25<sphery>I don't know how to check the MySQL version using SQL or I'd show you. :)
16:25<GreyFoxx>select VERSION();
16:25<sphery>Could even be during the update that breaks it, but before the update would allow users to downgrade if they choose.
16:26<GreyFoxx>It's a globally available value
16:26*sphery is embarrassed
16:26<GreyFoxx>hehe I only know cause I had to do it not that long ago :)
16:26<justinh>status; works too
16:27<GreyFoxx>yay, time to go pick up my kid
16:27<GreyFoxx>later :)
16:27<justinh>GreyFoxx: maybe nobody has complained because mysql5 is so ubuquitous now :)
16:27<justinh>ubiquitous, even
16:28<Daviey>Sun :(
16:34<stuarta>janneg: my backend mem consumption is pretty flat now, except for when it makes recordings. then it takes a jump
16:35<stuarta>it's much better since the multirec merge
16:35-!-nemik_ is now known as nemik
16:36<justinh>Daviey: who's running mythbackends on Solaris?
16:37<justinh>oh wait, they do linux now too don't they
16:37<Daviey>justinh: Sun is buying mysql
16:38<justinh>I used to work for Sun. one of the best jobs I ever had. loads of great jollies all over the place
16:40<Daviey>couldn't have been a bad job!
16:40<Daviey>But eventually you got bored of making the tea/coffee? :)
16:41<gbee>justinh: mind if I convert mythappearance to mythui? It's the perfect place to start since it's small and only uses two widget types (image/text)
16:41<justinh>not many jobs send you to Florida, SF, Nice (7 weeks there in GP & cannes festival season), germany... all just to attend meetings & make notes
16:42<gbee>it's either that, or mythweather
16:42<justinh>gbee: don't mind at all. great thing to use an example for me too :)
16:43-!-czth [n=dbrobins@nat/microsoft/x-1789683b53134084] has joined #mythtv
16:47*stuarta wonders if justinh has a sun microsystems tea cup?
16:47<Chutt>i thought we were rejecting plugins that didn't use mythui
16:47<stuarta>i do, buggered if i know where it is tho
16:47<Daviey>stuarta: groan' for putting his java cofee in.. :(
16:47<stuarta>nah, this was from when they just did servers
16:50*stuarta runs off again
16:52<janneg>stuarta: good to hear
16:55<gbee>Chutt: MythAppearance got in there because I agreed with Justin that we'd convert it to mythui before 0.21, since it's such a simple plugin I should have it converted tonight
16:58<gbee>the current lack of a context concept in mythui might make it a little messier for now, I can go back and fix that in retrospect though
16:59-!-grokky [n=grokky@] has joined #mythtv
17:04-!-tulbreak [] has quit []
17:05-!-jgarvey [] has quit ["Leaving"]
17:05-!-MaverickTech [] has joined #mythtv
17:06<gbee>might actually move both mythcontrols and mythappearance into the frontend before 0.21, they don't really count as proper plugins
17:08<stuarta>nn all
17:08-!-stuarta [n=stuarta@unaffiliated/stuarta] has quit ["zzzzz"]
17:14<gbee>of course, little details like the mythui headers not being installed to /usr/local/include/mythtv/ weren't part of the plan
17:16<gbee>ahh, because they are in include/mythtv/libmythui/ :)
17:20-!-otwin [n=otwin@] has left #mythtv ["Konversation terminated!"]
17:21-!-clever_ [] has joined #mythtv
17:21<janneg>oh, what happened to the plan to integrate mythdvd into the frontend?
17:22<sphery>I thought that was on Anduin's post-0.21 list
17:24<janneg>I can't remember seeing any followup to the discussion we had after the mythvideo mythdvd merge
17:26-!-clever [] has quit [Connection timed out]
17:29-!-mzb_d800 [] has quit [Read error: 113 (No route to host)]
17:29-!-mzb [] has quit [Read error: 104 (Connection reset by peer)]
17:29-!-mzb [] has joined #mythtv
17:30<gbee>justinh: small problem in mythappearance, it's using the 'game' context for keypress translation, that should probably be 'global'
17:35<justinh>gContext->GetMainWindow()->TranslateKeyPress("Game", e, actions); - guilty as charged
17:36<justinh>I remember thinking I might need to change that. derrr
17:40-!-johnp__ [] has left #mythtv []
17:41-!-moodboom [] has quit [Client Quit]
17:45-!-xris [] has quit []
17:47-!-mzb_d800 [] has joined #mythtv
17:47<justinh>bah fine time for my dev box to break
17:53<gbee>justinh: don't worry, fixed it as part of the mythui changes
17:53<gbee>better than it's not fixed in trunk just yet or it will probably conflict
17:58<justinh>I think I've missed something all the time I was talking about one day looking at the qt popup menus & stuff. if they get done in mythui they could be made completely themable that way or am I barking up the wrong tree?
18:06<gbee>shit, got a real fright just now - restarted my frontend and it was as though my database had gone, thought I'd lost 2-3 years of data
18:06<gbee>maybe now would be a good time to start backing up
18:06-!-beavis [] has quit ["Verlassend"]
18:07<justinh>I'm guilty of making nightly backups but hardly ever checking them. probably just as bad
18:08<gbee>setting up a backup cron job has been on my todo list for a very long time, but I keep putting it off
18:08<justinh>eep. just checked cos i couldn't remember where I was putting them. the dir name has changed. doh!
18:09<gbee>one of the reasons I really liked sphery's proposal for backups to be created by the housekeeper was because it saved me the 5 minute job of scripting it
18:10<justinh>automysqlbackup is what I'm using here. quite nifty AFAICT
18:11<hads>/usr/bin/mysqldump -u mythtv -pmythtv mythconverg -c > /mnt/share/backup/mythtv/db_$(date +%a).sql
18:13<gbee>yeah, I've actually got a nice, simple little script that I run on my webservers which posts off a gzipped database dump to a remote machine (rsync) four times a day
18:15<gbee>not sure the remote machine part is required in this case, I'll probably just connect a USB drive and send a copy there
18:17-!-xris [] has joined #mythtv
18:23<sphery>gbee: The reason I haven't finished the auto DB backup/maintenance patch is because I'm waiting for you to waste 5 mins on the backup cron job. :)
18:23<gbee>sphery: :p
18:23<sphery>Actually, I'm working on the patch and hope to have it complete and well tested within the next 3 weeks.
18:24<gbee>wasn't hinting btw, just that I'm really looking forward to it :)
18:24<sphery>Whether that leaves Captain_Murdoch (assuming, due to housekeeper changes) enough time to review it in time to leave enough time for general testing before 0.21 is a whole other question, though...
18:29-!-harminoff [] has quit [Remote closed the connection]
18:29-!-harminoff [] has joined #mythtv
18:43<gbee>Chutt: been meaning to ask what the idea behind the "lang" attribute in MythUIText was? Translation for third party theme strings?
18:44<Chutt>you can just put them there instead of in the .h file generated by the themestring tool
18:44<Chutt>not as good for translators, obviuosly
18:44<Chutt>err, obviously, too
18:46-!-mattwire [] has quit [Read error: 113 (No route to host)]
18:47-!-mattwire [] has joined #mythtv
18:47<gbee>ok, just wondered if you were intending to replace the themestring tool, so you've answered my question :)
18:50<Chutt>unless you can think of a better way to handle strings in the xml files
18:51<Chutt>(themestring is still prefered)
18:52-!-mattwire [] has quit [Remote closed the connection]
18:57<gbee>nah, I thought themestring worked well enough, better than having translations in the theme itself IMHO
18:58<gbee>I'm trying to work out why <value> is getting ignored, text placed there isn't displayed
18:59<gbee>I noticed it a couple of weeks ago but it wasn't a problem at the time, just checking now to see if it's due to way we require the lang attribute
19:00<gbee>to answer my own question, yes it is
19:02<sphery>gbee: Is this because of the ones you found?
19:03<gbee>sphery: nope, didn't tell Bruce or anyone outside of this channel about that problem
19:03<gbee>of course this channel is logged as I've now discovered ;) but it's probably just coincidence
19:21-!-Talim_1979 [] has joined #mythtv
19:21-!-Talim_1979 [] has left #mythtv ["Leaving"]
19:23<gbee>if ((m_Message.isNull() || m_Message.isEmpty()) -- was failing because m_Message is initialised to " "
19:23<gbee>" " would count as empty to me, but apparently not to Trolltech ;)
19:25<gbee>that can actually be simplified because isEmpty returns true on null strings as well
19:25<kormoc>no trim function?
19:25<gbee>kormoc: no need for it in this case, just changed the initial value of m_Message to "" instead, no harm done
19:25<kormoc>fair 'nuff
19:25<gbee>at least I don't think so, we'll soon find out
19:29-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
19:30-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
19:31<jarle>just had mythfrontend segfault trying to playback a HD stream ( I case anybody has got any input on how to debug this...
19:35<gbee>anybody care to suggest a fix for the compat header in mythpainter.h? When building against mythpainter.h in it's installed location the header path is incorrect (it's one directory lower because of where the libmythui libraries are installed)
19:35<gbee>maybe it can be moved out of the header entirely and into the cpp, I don't know why it was added in the first place
19:38-!-moodboom [] has joined #mythtv
19:39<gbee>justinh: mythappearance is now mostly converted, got a little held up on a mythui bug so I'll finish in the morning
19:40<gbee>only thing left to do is the menu, going to give MythDialogBox a try there, never used it before so I'm not ever sure if it's complete
19:41<sphery>gbee: BTW, did you ever find something for the MythWeb/UPnP preview DST thing?
19:41<sphery>I've seen things like the following to always give standard time, though I don't know if the 1-hour DST offset assumption is valid: date("m/d/y g:i", (date("I", $timestamp) ? $timestamp - 3600 : $timestamp))
19:43<sphery>(direction might not be right, though--may need the ternary args reversed)
19:43<justinh>gbee: that's cool. looking forward to cutting my teeth helping with the port if I'm up to it. also looking fwd to having fun with ui bling. interesting to find out how much playing with things will slow real work down ;)
19:44<gbee>sphery: no gave up on it for now, I wasn't sure where it was going wrong so I wanted to stick some cerr stuff in to dump the value at different points
19:45<gbee>sphery: curious as to how that might work? wasn't aware that unix timestamps included dst information?
19:45<gbee>I thought by definition they were GMT (or UTC if you really must)
19:47<gbee>ahh, hmm I see what date is doing there, it's literally checking to see if the time given falls into the normal DST period
19:47<xris>which should work
19:47<gbee>problem there is that the period varies by country, so it's not going to be 100% accurate
19:47<xris>but like I said, I still get the cpu usage problem with recent recordings..
19:47<gbee>unless php knows your locale
19:48<gbee>xris: yeah, problem with the http server somewhere, will fix that once I've fixed the DST bug
19:48<sphery>the date("I", $timestamp) checks whether that timestamp is within the period of DST for the locale
19:48<xris>gbee: gtcha
19:48<xris>sphery: that's what I assumed it did
19:48<gbee>sphery: should work then :)
19:48-!-davilla [n=davilla@] has quit ["Leaving"]
19:49<xris>sphery: but I think you're right in that things are backwards
19:49*sphery can't do DST math
19:49<xris>DST is "forward"
19:49<gbee>sphery: neither can I
19:49<gbee>never can remember whether the clocks go back/forwards
19:49<xris>"spring forward, fall back".. and DST is in the summer.
19:50<justinh>gbee: - 14 day EPG over the air!
19:50<gbee>xris: want to commit that fix then? Or should I give it a go here first?
19:50<sphery>hmmm. wouldn't we then need to remove the DST spring forward to get back to standard?
19:51<sphery>Do we even know that a 1-hour offset is universal, too?
19:51<xris>gbee: no time today.. I'm still on the clock, and have to go out to dinner soon.
19:51<gbee>xris: ok, well I should have time to test the fix first then
19:53<gbee>justinh: cool, wonder what format they are broadcasting that data in, obviously MHEG wrapped
19:54<gbee>interesting that they say it replaces all embedded STB guide software - must have twisted a few arms to make that happen and I'm not sure everyone will like that
19:54<justinh>won't work on just any ole DVB STB apparently. must be using some hitherto unimplimented features
19:55<xris>sphery: offset sort of depends on where the timestamp comes from, I guess.. you're right, though, the code is probably fine.. question is, is there an equivalent check to *undo* that time when the upnp stuff looks up the recording?
19:55<sphery>Yeah. Your seconds-since-the-epoch approach sounded far better
19:55-!-Dillweed [] has joined #mythtv
19:56<gbee>xris: no, but that's the point - the time we get now from mythweb is wrong, this will fix it
19:56-!-Dillweed [] has left #mythtv []
19:57-!-leprechau [] has quit [Remote closed the connection]
19:58<gbee>I suppose that QDateTime is behaving in a similar way to PHPs Date(), when it originally converts the time from the database to a unix epoch form it's doing a DST conversion
19:58<sphery>And, I wonder what will happen when it does switch to DST (i.e. will it then not need the "fix")?
19:58<gbee>when that time is converted back by mythweb, it doesn't do that conversion and so we end up with a time which is one hour out
19:59<gbee>sphery: no, that's what the date("I", $timestamp) bit checks
19:59<justinh>gbee: so much for 14 days' worth of data, only updated every night. no use really. bless em. teletext ltd had to do something to prevent lost revenue when analogue goes byebyes
19:59<gbee>I'm pretty sure that fix will work correctly
20:02<xris>gbee: could be... it'd be easy enough to drop a check into modules/tv/includes/recordings.php
20:03-!-mzb [] has quit [Read error: 113 (No route to host)]
20:03-!-mzb_d800 [] has quit [Read error: 104 (Connection reset by peer)]
20:04-!-mzb [] has joined #mythtv
20:04-!-mzb_d800 [] has joined #mythtv
20:04<gbee>yeah, I'll test it in the morning, I had trouble getting my head around it earlier but it's now 1am and I've got no hope ;)
20:06-!-mzb [] has quit [No route to host]
20:07-!-mzb [] has joined #mythtv
20:07-!-mzb [] has quit [Read error: 113 (No route to host)]
20:08-!-mzb [] has joined #mythtv
20:08-!-mzb_d800 [] has quit [Read error: 113 (No route to host)]
20:08-!-mzb [] has quit [Read error: 104 (Connection reset by peer)]
20:09-!-mzb_d800 [] has joined #mythtv
20:09-!-mzb [] has joined #mythtv
20:15-!-Pumpernick [] has quit [Read error: 104 (Connection reset by peer)]
20:33-!-clever_ is now known as clever
20:40-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
20:55-!-JoeBorn [] has joined #mythtv
21:00-!-BleedAway [] has quit [Read error: 104 (Connection reset by peer)]
21:01-!-BleedAway [] has joined #mythtv
21:13-!-mzb_d800 [] has quit [Read error: 104 (Connection reset by peer)]
21:13-!-mzb [] has quit [Read error: 104 (Connection reset by peer)]
21:14-!-mzb [] has joined #mythtv
21:14-!-mzb_d800 [] has joined #mythtv
21:23<rooaus>sphery: RE earlier question about DST offset, South Australia has 30min offset, so 1 hour is not universal.
21:24-!-mzb_d800 [] has quit [Read error: 113 (No route to host)]
21:24-!-mzb [] has quit [Read error: 104 (Connection reset by peer)]
21:25-!-mzb [] has joined #mythtv
21:25-!-mzb_d800 [] has joined #mythtv
21:33<sphery>rooaus: d'oh. Guess it's possible to guess dates in and out of DST and get the difference between the offset for each (using date("Z")), but that makes an ugly hack even more hackish... :)
21:34<sphery>gbee: ^^^ and rooaus's comment
21:37-!-harminoff [] has quit [Remote closed the connection]
21:38<rooaus>sphery: The reason is that SA is a half hour ahead of Victoria in winter and during DST, Vic is +60min and SA +30min. Meaning Vic and SA are in the same DST timezone.
21:38-!-harminoff [] has joined #mythtv
21:39-!-mzb [] has quit [Read error: 104 (Connection reset by peer)]
21:40-!-mzb [] has joined #mythtv
21:41-!-mzb_d800 [] has quit [Read error: 104 (Connection reset by peer)]
21:41-!-mzb_d800 [] has joined #mythtv
21:46-!-mzb_d800 [] has quit [Read error: 104 (Connection reset by peer)]
21:46-!-mzb [] has quit [Read error: 113 (No route to host)]
21:47-!-mzb_d800 [] has joined #mythtv
21:48-!-harminoff [] has quit [Remote closed the connection]
21:48-!-harminoff [] has joined #mythtv
21:52-!-ahbritto [] has quit [Client Quit]
21:57-!-iamlindoro_ [] has left #mythtv []
21:58-!-harminoff [] has quit [Remote closed the connection]
21:59-!-harminoff [] has joined #mythtv
22:04-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
22:05-!-mzb [] has joined #mythtv
22:09-!-knowledgejunkie_ [n=knowledg@unaffiliated/knowledgejunkie] has joined #mythtv
22:14-!-knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has quit [Read error: 110 (Connection timed out)]
22:16-!-PointyPumper [] has joined #mythtv
22:38-!-harminoff [] has quit [Remote closed the connection]
22:38-!-harminoff [] has joined #mythtv
23:39-!-mzb [] has quit ["Time to quit"]
23:39-!-mzb [] has joined #mythtv
---Logclosed Tue Jan 22 00:00:35 2008