Back to Home / #mythtv / 2008 / 03 / Prev Day | Next Day
#mythtv IRC Logs for 2008-03-07

---Logopened Fri Mar 07 00:00:14 2008
---Daychanged Fri Mar 07 2008
00:00<xris>I think a lot of students don't count it as a full time job.
00:00<xris>and take on other things at the same time.
00:00<dagar>I was thinking of trying it in place of a full time job
00:00<dagar>just barely enough money to justify not getting a job
00:01<dagar>besides, more money means more distractions for me
00:01<dagar>my myth boxes tend to multiply when I have cash...
00:03<xris>$4500 for two months not a full time job? that's right around $14/hour
00:03<dagar>I thought it was 3 or 4 months?
00:04<xris>I haven't checked the calendar for this year, but I think it was about 10 weeks in 2006 (which I guess puts it more near $12/hour)
00:04<dagar>not too shabby
00:11-!-ahbritto [] has quit [Client Quit]
00:11-!-reynaldo1 [] has quit ["Lost terminal"]
00:11-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
00:16-!-cattelan [] has quit ["This computer has gone to sleep"]
00:17<Chutt>xris, it's actually pretty low compared to real internships
00:18<xris>Chutt: depends on the industry, I guess.
00:18<Chutt>programming? =)
00:18<xris>I only paid my intern $12.50/hour
00:18<xris>and he was a college grad
00:19<xris>granted, I bumped him up to a decent salary after 3 months
00:19<xris>(although he's still not making as much as he's worth)
00:22<xris>I honestly don't know what pay ranges are valid. my wife has a degree from a pastry school and could only hope to *maybe* make $15/hour after working in the industry for a couple of years.
00:22<Chutt>MS pays a little of 60k/yr for interns (the equivalent, rather)
00:22<dagar>where do you live xris?
00:23<xris>Chutt: the general rule around here is that MS isn't "the industry".. smaller companies pay a lot less.
00:23<dagar>coop jobs at my university start around $15/hour
00:23<xris>heck, according to places like I'm bout $35k/year underpaid
00:24<xris>dagar: see, I don't know anything. I made like $7/hour in college (late 90s) working for the IT dept
00:24<dagar>is that based on other user input?
00:24<xris> supposedly is. I don't trust their numbers or their job descriptions, though.
00:24<xris>but have used them to get raises before
00:24<Chutt>xris, i've got no idea, either, just going by what my brother was paid as an intern
00:25<Chutt>the other places he was at weren't much less
00:26<xris>then google's stuff is low...
00:26<xris>I'm also going off of numbers from 2 years ago.
00:26<Chutt>well, for good stuff in the US
00:26<Chutt>it's lots o cash for international students
00:26<xris>inflation and cost of living in seattle alone is like 4.5%/year
00:26<xris>or rural US
00:28<xris>Chutt: there's also a lot to be said for working on something you enjoy, and getting good experience.
00:28<xris>but unfortunately, I don't think very many companies count FOSS work as good experience (it's sad)
00:29<Chutt>mine did
00:30<xris>I do when I hire
00:30<kdub> shows pretty much exactly what mine is
00:31<Chutt> says $0 for me
00:32<dagar>what did you enter?
00:32<xris>I never know what to put in for me.
00:32<Chutt>just software engineer 4
00:32<xris>sr web developer, or just programmer 3, 4, or 5.
00:33<Chutt>ah, works in firefox
00:37<Chutt>heh, yah, that's way off
00:37<xris>too high or too low?
00:38<xris>wow. mine's way higher than I make
00:38<Chutt>but then, it's probably because of the telecommuting
00:39<xris>back in a bit
00:39-!-xris [] has quit []
00:39<clever>2008-03-07 01:32:18.635 MSqlQuery: DELETE FROM settings WHERE value = 'MusicAutoShowPlayer' AND hostname = 'theP4' ;
00:39<clever>2008-03-07 01:32:18.637 MSqlQuery: INSERT INTO settings (value,data,hostname) VALUES ( 'MusicAutoShowPlayer', '1', 'theP4' );
00:39<clever>where in the code is that delete/insert pair generated?
00:41<clever>MythContext::SaveSettingOnHost it seems
00:46-!-xris [] has joined #mythtv
00:52-!-davilla [] has quit ["Leaving"]
00:55-!-MrGandalv [] has joined #mythtv
00:56-!-_packetscan [] has joined #mythtv
00:58-!-Netsplit <-> quits: sphing, kurre2__, loops, MrGandalf, sphery, packetscan, mzb_d800, dlblog
00:58-!-Netsplit over, joins: loops, sphery, sphing, dlblog, kurre2__, mzb_d800
00:59<clever>patch done, testing
00:59-!-cattelan [] has joined #mythtv
01:01-!-cattelan [] has quit [Client Quit]
01:07<clever>seems to work perfectly but half the if never ran
01:08-!-gnome42 [] has quit [Remote closed the connection]
01:09<clever>isnt detecting the failed updates...
01:10-!-Tanthrix [] has quit [Read error: 104 (Connection reset by peer)]
01:10-!-Tanthrix [] has joined #mythtv
01:11<clever>0 rows matched isnt an error
01:14-!-_packetscan is now known as packetscan
01:29<clever>if i do an update that matches 1 row and updates 0 what will QSqlQuery::numRowsAffected return?
01:29<clever>(row allready set to value im setting)
01:29<clever>Rows matched: 1 Changed: 0 Warnings: 0
01:29<clever>Rows matched: 0 Changed: 0 Warnings: 0
01:30<clever>i need to be able to tell the diff between those from qt based code
01:38<Deek>should be zero, because no rows were changed
01:51<clever>yeah and thats the problem
01:51<clever>the docs dont seem to show a function for rows matched
01:51<clever>so if i try to update a setting which doesnt exist nothing goes wrong
01:51<clever>and it doesnt get saved
01:52-!-Tanthrix [] has quit [Read error: 110 (Connection timed out)]
01:52<clever>im changing SaveSettingOnHost to update then insert if it needs to
01:53<clever>the delete,insert seems wrong and feels like the cause of some past bugs ive had
01:56<Deek>how about select then insert/update?
01:59<sphery>why would delete, insert cause bugs (and how is it that update or insert wouldn't)
02:00<Deek>clever: no version of mysql_num_rows() ?
02:00<clever>in qt it seems to be .size()
02:00<clever>and it only returns the size for a select type query
02:00<clever>updates will have a .size() of -1
02:01<clever>sphery: sometimes the fe/mysqld hang right between the delete and insert
02:01<clever>and i kill one of them
02:01<clever>then when it comes back up the setting is missing
02:01<clever>so far the only victim has been the language, causing the fe to ask on startup and give me a heartattack thinking everything is gone
02:03<clever>an update query would do atomicly within the server preventing that from happening
02:03<sphery>sounds like you need to run an to update indices, ...
02:03<clever>most often its when the db server runs out of space
02:03<clever>and i restart the fe before discovering that
02:04<Deek>yeah, I'd almost never do delete/insert in a sitch like that; I'd select/(update|insert)
02:04<clever>my patch is currently trying to fetch the setting to see if it even needs a change
02:04<clever>then trying to update and insert if the update fails
02:04<clever>but it cant detect the update matching 0 rows(because it doesnt exist to begin with)
02:05<clever>so if the setting isnt in mysql it never gets saved
02:06<clever>07 03:04:43 < tausq> clever: do you mean something like this?
02:06<clever>that query would fix my bug perfectly if there was a uniq key on value,hostname
02:07<Deek>so the Qt code is screwed (apparently written for mSQL)
02:08<clever>its just missing a function to access a mysql only feature
02:08<clever>and the qt guys gave a way to extract the original mysql object from the qt one and use real mysql lib api on it
02:08<clever>which would require including mysql headers
02:09<clever>which feels like more of a major change then my idea
02:11-!-mzuverink [n=mzuverin@unaffiliated/mzuverink] has quit ["Leaving"]
02:12<stuarta>gbee: i'd expect dvb-s initially
02:13<stuarta>(re: freesat)
02:14-!-PointyPumper [i=Pintlezz@] has quit [Read error: 104 (Connection reset by peer)]
02:17<clever>testing the new code...
02:22<stuarta>the mysql sql code was written to work with even mysql 3.3
02:23<clever>could wrap the whole thing in an if to use the old buggy method with that version
02:24<stuarta>there's a long term goal to move to embedded mysql which must be kept in mind
02:24<clever>the embeded mysql server probly wont be 3.3:P
02:25<clever>ive skimed over the mysql api before when using it in some of my c++ code
02:25<stuarta>no but embedded things generally aren't as featureful as the big brother
02:25<clever>other then the way you init&connect theres little change when you switch to an embeded i beleive
02:25<clever> ALTER TABLE `settings` DROP INDEX `value` ,
02:25<clever>ADD PRIMARY KEY ( `value` , `hostname` )
02:26<clever>now the fe wont even start!
02:27<hads>Isn't 5+ required now anyway?
02:27<xris>should be for .21, yes
02:27<clever>undoing hasnt fixed it...
02:27<clever>im making this change in trunk
02:28<clever>which will become .21 if im correct
02:28<hads>Well, 21-fixes will become .21 :)
02:28<stuarta>i knew we upped the requirement, but i couldn't remember the new version
02:28<clever>i need to track down how i killed the frontend now...
02:28<clever>2008-03-07 03:27:43.062 This version of MythTV requires an updated database schema. Please run mythtv-setup or mythbackend to update your database.
02:28<stuarta>but still develop against trunk, as we are in feature freeze.
02:29<sphery>gbee: The frontend was able to upgrade my schema without issue using command line: mythfrontend -O ThemePainter=qt -geometry 800x600 -u (SSH X redisplay). Even tested once with the backup failing and once with it succeeding. Both times, the upgrade happened without issue.
02:30<sphery>gbee: I even tried moving the -u around in the command line and couldn't get it to fail. Your 1213 upgrade was great because I could keep resetting DBSchemaVer to 1212 and the upgrade would be able to succeed without other changes. Therefore, if you could try it again and let me know what you find... Thanks.
02:31<clever>i see the problem
02:31<sphery>clever: Why all the concern over losing a single value when your MySQL server ran out space? That's a pretty critical error that--had it not occured when changing the setting--would have happened soon enough (and perhaps at a much more critical location).
02:32<clever>DBSchemaVer is owned by the '' hostname
02:32<sphery>MythTV cannot be expected to cope with a MySQL server that doesn't have space to write MythTV critical data.
02:32*stuarta goes to work
02:32<clever>sphery: it could also crash for other reasons right at that point
02:32<sphery>clever: That means it's a global setting, not a host-based setting.
02:32<clever>another thread may happen to segfault then
02:32<clever>yeah but its not under the NULL hostname
02:32<clever>thats the problem
02:32<clever>somehow it got moved to the '' hostname
02:33<clever>so now the frontend is failing to find DBSchemaVer
02:33<clever>and is refusing to start
02:34<clever>no settings are owned by NULL anymore
02:34<clever>i screwed something up:P
02:34<sphery>your re-indexing, probably
02:35<clever>mysql> update settings set hostname=NULL where hostname='';
02:35<hads>Or a stray UPDATE
02:35<clever>that didnt fix it
02:35<clever>theres values belonging to other hosts
02:35<clever>just none to NULL
02:36<clever>hostname cant be null
02:36<clever>when did that happen...
02:36<clever>Rows matched: 127 Changed: 127 Warnings: 0
02:36<Deek>Primary keys can't be null.
02:37<clever>that was my guess
02:37<clever>what about uniq's?
02:39-!-czth__ [n=dbrobins@nat/microsoft/x-8a414d7ecd6f446e] has joined #mythtv
02:41<clever> ALTER TABLE `settings` DROP INDEX `value` ,
02:41<clever>ADD UNIQUE `value` ( `value` , `hostname` )
02:41<clever>and hostname can still be null!
02:42<sphery>CDev: I updated to trunk r16421, and was unable to get the 100% CPU issue to resurface. Tried 1) deleting all png's in the recordings directory, 2) deleting all png's in the recordings directories and in the MythWeb cache, 3) deleting all png's in the MythWeb cache and never caused the backends to hit 100% (Athlon XP 2400+ and 2000+ doing previews for 442 HDTV shows). I'm pretty sure xris was using trunk, too, and he was only 27 ...
02:42<clever>seems to be working without any bugs now
02:43<sphery>... changesets behind me when he saw the issue resurface. Guess he'll have to help you track it down.
02:43<clever>sphery: i can reproduce that bug on my end
02:47<sphery>What bug? The 100% CPU thing?
02:47<sphery>trunk, right? what rev?
02:47<clever>MythTV Version : 16319M
02:47<clever>ive updated recently but ive mostly just been avoiding triggering it
02:47<clever>but i beleive its still there
02:48<sphery>I just updated from r16316, where I couldn't reproduce the issue. I'm now on r16421, and I still can't reproduce it.
02:48-!-_splat1 [n=splat1@] has joined #mythtv
02:49-!-splat1 [] has quit [Read error: 104 (Connection reset by peer)]
02:49<clever>ive got a healthy mix of framegrabber recordings, nuv's from transcode, and mpg's from a pvr150
02:49<clever>it could be a certain random header value in one of them causing it
02:49<clever>like the nuv files that segfault mythtranscode yet play just fine
02:49<sphery>Can you test with r16319? Try rm *.png in the recordings and MythWeb cache (mythweb/data/cache) directories, then use MythWeb to call the Recorded Programs page (when your backend is not scheduled to record for a while).
02:50<clever>allready in the process of testing it without the rm
02:50<clever>recording list is still loading
02:50<clever>db and mythweb server is 400mhz so its a bit slow
02:50<sphery>OK. If that doesn't do it, might need the rm to really strestt test it.
02:51<clever>the probly isnt exactly 100% while making the images
02:51<clever>but 100% that stays there long after it finishes
02:51<sphery>Yeah, it's the 100% after the fact that's the problem.
02:51-!-ahbritto [] has joined #mythtv
02:51<clever>same bug then:)
02:51<sphery>(Though mine never hits 100%--while making previews, or after--since the problem disappeared (unexpectedly).
02:51<clever>it also seems to be generating the preview images in a sync method(not async)
02:52<clever>add in the network delays between mythweb and the master and 300 recordings and it gets damn slow
02:52<clever>i also think theres something horidly wrong with my P4 box
02:52<sphery>Yeah, there's a new thread for each request, and the thread can't do anything else until it's got an image to return int he response...
02:53<clever>400mhz ubuntu 7.10 has a relatively fast phpmyadmin
02:53<clever>1.6ghz ubuntu 6.06 has a painfully slow phpmyadmin
02:53<sphery>BTW, thanks for testing. CDev couldn't reproduce it this afternoon, and I told him I'd try (since I was previously affected).
02:53<clever>and alot of other things are also oddly slow
02:53<clever>that just doesnt seem right
02:53<Chutt>sphery, it's still fixed here as well
02:53<sphery>Yeah. Strange
02:54<clever>it was even more strange before i put linux on it
02:54<clever>it was runing xp just fine
02:54<clever>i found a stick of ram that looked right
02:54<clever>shutdown and shoved it in
02:54<clever>bios yelled at me for bad ram and cpu freq settings
02:54<sphery>Wonder why xris is seeing it, again? If it's really there, it's a very timing-sensitive bug.
02:54<clever>(it can play some wav files thru the onboard sound card)
02:55<clever>i removed the ram and because the bios made me think of the cpu settings, overclocked it by maybe 5%
02:55<Chutt>it was happening before within the first couple previews created
02:55<Chutt>without fail
02:55<clever>booted xp back up
02:55<clever>it turned into a 5mhz box!
02:55<clever>horidly slow
02:55<clever>dads fix all answer of reboot went into play
02:56<clever>it locked up during shutdown and never booted that drive since
02:56<clever>and the drive was extremely hot
02:56<clever>somehow a stick of ram damaged the hdd
02:56-!-czth_ [n=dbrobins@nat/microsoft/x-ed76fd6821ebcf0a] has quit [Read error: 110 (Connection timed out)]
02:57<clever>and may also be to blame for why its so slow still
02:58<clever>if i do power the hdd up it gives off an odd sound and works fine for the first hour
02:58<clever>and once it heats back up it just stops functioning
02:58<clever>any1 got some dry ice so i can finaly backup the whole thing?:P
03:00<sphery>Anduin: Looks like paulh independently arrived at the same conclusion as you regarding the RefCounted.Release() causing #4816.
03:00<Chutt>it's a race to see who fixes it first
03:01<Chutt>winner gets, um
03:01<sphery>a commit message with their name on it?
03:01<clever>and this lirc bug is damn anoying in config pages
03:01<clever>when i 'press' a button it gets stuck pushed in 60% of the time
03:02<sphery>clever: I saw you mention a failed automatic DB backup the other day. Do you have any info on what caused it (i.e. logs or anything)?
03:02<clever>sphery: a change to the db schema i manualy did caused hostname to become 'not null' causing all global settings to get shoved over to the '' hostname
03:02<clever>o wait no that was something else
03:03<clever>not shure what caused the db backup to fail
03:03<sphery>yeah, this was from a couple of days ago.
03:03<Anduin>sphery: Yeah, I still have an occasional crash on exit I still need time to track down, I really should get better at updating tickets rather than assuming everyone who needs to know is on irc.
03:03<clever>i didnt look that closely
03:03<clever>it was from when i did the svn update
03:03<clever>most i can do is update to a new db schema and see if it fails again
03:03<Anduin>(crash on exist is in roughly the same area)
03:03<sphery>OK. Just wondered. If you see it again, please let me know (and I'd appreciate your keeping a copy of logs for me). THanks.
03:03<clever>the log is long gone
03:04<clever>screen is keeping the last few 1000 lines in scrollback
03:04<clever>i just hit the 100% bug
03:04<clever>50% system cpu usage
03:04<clever>and the recording list isnt even done yet
03:05<Dibblah>clever: Current SVN?
03:05<sphery>clever: If you update to head, you'll get 1213, which can be re-run over and over (great for testing) by just changing the value of DBSchemaVer.
03:05<clever>MythTV Version : 16319M
03:05<clever>16319 still has the 100% cpu bug
03:06<sphery>Dibblah: it cleared up for me by the time I upgraded to trunk r16316, and I'm not seeing it now at r16421, so he's in between those two...
03:06<clever>its one of the recordings between dec 1st and today
03:07<clever>81% cpu to mythbackend and Cpu(s): 38.0% us, 57.7% sy, 1.6% ni, 0.0% id, 0.0% wa, 0.0% hi, 2.7% si
03:07<Dibblah>Could it be the seeking bug?
03:07<sphery>It shouldn't be the actual recording causing it (or the preview generation). All backtraces we had seemed to indicate it was the http server.
03:07<Dibblah>Meaning the seektable is offset, therefore the I-frame isn't aligned?
03:08<clever>i'll update all my systems to head and see if it happens again
03:08<sphery>Anduin: perhaps you could compare notes with paulh on the -dev list as he's still checking his "hypothesis"
03:08<clever>Updated to revision 16421.
03:09<sphery>let me know how your DB backup goes, please. :)
03:09<Chutt>i'm up to 30 bugs at work now
03:10<Chutt>i prefer to keep it around 10
03:11<clever>ive also tracked down a DST bug i had
03:12<clever>most of my frontends where unable to cancle recordings past the DST change
03:12<clever>the master is forced into TZ=AST4 without any dst rules
03:12<xris>Chutt: small dev team leads to lots of small ignored bugs
03:12<clever>all the slaves are properly set for the local zone(currently gmt-4) and will shift by an hour after the change
03:13<sphery>clever: using MythWeb or using mythfrontend to cancel?
03:13<clever>so my slaves are addjusting for dst and the master with its poor TZ isnt
03:13<Chutt>xris, my team is 3 people
03:13<clever>sphery: frontend to cancle
03:13<xris>Chutt: there are two of us working on an ERP for a $100M company
03:13<clever>after forcing the slave frontend into TZ=AST4 without any dst rules i 'fixed' it
03:13<xris>used to be just one.. I'll let you guess what state the code is in... and it's perl. :)
03:13<clever>which prooved that it was the improperly set tz
03:14<clever>i probly need something like TZ=America/Halifax
03:14<sphery>Oh. Well, TTBOMK, Myth requires all frontends/backends to be in the same time zone (with same DST settings). MythWeb still may have an issue with DST even if all have same TZ/DST.
03:14<clever>which will bring the dst rules into all myth systems
03:14<xris>the mythweb issue is with recordings made in/out of DST
03:14<clever>i was unable to set TZ in mythweb
03:15<xris>clever: it's in php.ini
03:15<clever>so i just gave up and moved it to a box with the proper /etc/logcheck/
03:15<clever>i mean /etc/localtime
03:15<clever>i was using set_env within the mythweb part of apache.conf
03:15<clever>and doing it in php.ini would break all my other php scripts which depend on the global tz being something else
03:16<clever>sticking it on a box with /etc/localtime set right fixed it and should also reduce the mythweb<->db delays(db is now local to mythweb)
03:19<clever>sphery: when i had done the TZ=AST4 change i didnt think about the dst rules it would cause to break, but it now seems simple to fix
03:21*clever uploads a ticket with the setting change
03:22<Chutt>could someone merge 16419 to the branch, please?
03:22<Chutt>i've gotta get some sleep, but want it in there for testing..
03:25<janneg>I'll do it
03:25-!-xris [] has quit []
03:26<clever>ive tested a few things with it on my end and it seems bug free
03:26-!-Tanthrix [] has joined #mythtv
03:31<clever>who wants to test out my patch?
04:00-!-rn114 [] has joined #mythtv
04:07-!-mykeul [n=mykeul@] has joined #mythtv
04:13<clever>sphery: nearly updated to head
04:14<clever>WARNING: MythTV was unable to backup your database.
04:18<sphery>clever: is mysqldump in the PATH of the user running mythbackend (or mythtv-setup or whatever you ran)?
04:18<clever>mythtv@theP4:~$ type mysqldump
04:18<clever>mysqldump is /usr/bin/mysqldump
04:18<clever>bash can find it:)
04:18-!-rn114 [] has quit [Read error: 113 (No route to host)]
04:18-!-PointyPumper [i=Pintlezz@] has joined #mythtv
04:19<sphery>was mythbackend/mythtv-setup started from the same environment (i.e. in the same shell that could find mysqldump)?
04:20<clever>i allways run mythbackend and friends from the shell
04:20<clever>on the master
04:20<clever>and some slaves
04:20<clever>and i ran the mythbackend in a shell WITHOUT the & this time
04:21<sphery>Hmmm. 512 looks like it should be a MySQL connection error. Do you have a password (that's not the password for user mythtv@ specified in a mysql options file (~/.my.cnf)?
04:21<clever>because it seems to detect the lack of stdin and not ask(causing it to use stupid defaults)
04:21<clever>ls: /home/mythtv/.my.cnf: No such file or directory
04:22<clever>removing the 2>/dev/null may help:P
04:22<sphery>what do you get when you run: mysqldump -p --host='' --user='mythtv' --add-drop-table --add-locks --allow-keywords --complete-insert --extended-insert --lock-tables --no-create-db --quick 'mythconverg' > '/media/mainlv/mythtv/mythconverg-1212-20080307051409.sql'
04:23<clever>mysqldump: Got error: 1146: Table 'mythconverg.weatherdatalayout' doesn't exist when using LOCK TABLES
04:23<clever>a similar problem was killing mythweb
04:23<clever>ive moved my mysql server between several hosts
04:23<clever>and the inodb files got left behind
04:24<sphery>you don't have InnoDB storage enabled, do you?
04:24<clever>so the inodb tables are screwed up
04:24<clever>root@media:/media/videos/media/mythconverg# rm weatherdatalayout.frm
04:25<clever>now the dump is doing something...
04:25<sphery>Hmmm. Don't think it's worth the code to detect that--would require passing a list of all the tables I want mysqldump to backup.
04:25<clever>| 87437 | mythtv | theP4:42103 | mythconverg | Query | 2 | Sending data | SELECT /*!40001 SQL_NO_CACHE */ * FROM `recordedseek` |
04:25<clever>a better way is to just check for the error ahead of time
04:25<clever>and maybe try and fix it
04:26<clever>but i havent found a way to fix it from mysql
04:26<clever>half the querys claim the table exists
04:26<clever>yet drop table and others claim it doesnt exist
04:26<clever>no way to 'fix' it from mysql querys
04:26<sphery>Yeah. The mythweather reliance on foreign keys (and, therefore, InnoDB storage) may catch quite a few people off guard.
04:27<clever>i couldnt even get it to work when i last tried
04:27<sphery>MySQL seems to do stupid things if the storage engine isn't supported (i.e. creates "ghost" tables).
04:27<clever>so i just rm'ed the .frm file
04:27<clever>but now that i think of it THIS may be exactly why mythweather didnt work!
04:27<clever>id add pages to the layout
04:27<clever>error: no pages in layout
04:28<clever>repeat 50 times
04:28<clever>arg! arg! arg!
04:28*clever turns green
04:28*clever hurls monitor thru wall
04:29<sphery>I have a patch that will move all the backup commands to a script to give the user much more control (and allow --debug output). Finishing up the final script (it's now a Perl rewrite of one that was originally a shell script).
04:29<sphery>Yeah. MythWeather 0.21/trunk requires InnoDB.
04:29<clever>and playing musical chairs with the datadir and 3 mysql servers may have screwed the tables up before i tried to actualy use it
04:30<clever>so that just leaves the 100% cpu bug and the lirc bug
04:30<clever>done upgrading to 16421
04:30<clever>Cpu(s): 62.1% us, 10.8% sy, 23.2% ni, 0.0% id, 0.0% wa, 0.5% hi, 3.4% si
04:31*clever pulls the trigger
04:32<clever>the recording list raced thru up to dec area
04:32<clever>that took 20mins to load last time
04:32<clever>some cache must finaly be doing its job:P
04:34<sphery>You may need to rm *.png in the recordings directories and in the mythweb/data/cache directory
04:34<sphery>(to test the 100% CPU issue)
04:34<clever>its only got ~ 40% of the images cached
04:34<clever>its still got several months to generate
04:35<clever>its down to oct now
04:35<clever>| 2007-05-19 20:00:00 |
04:35<clever>oldest recording
04:37<clever>still crunching on oct...
04:42<clever>finaly done loading the recording list
04:42<clever>no bug
04:42<clever>rm *.png away
04:43<clever>this is taking awhile to simply remove some png files...
04:47<clever>thats odd
04:47<clever>the --generate-preview has a nice value of 9
04:47<clever>that cant be helping performance:P
04:54<clever>nothing yet and ive reached feb
04:58-!-mzb_d800 [] has quit [Read error: 113 (No route to host)]
05:03<sphery>clever: cool. sounds good. Now we just have to figure out why xris is affected by the 100% CPU thing.
05:03<clever>still crunching feb
05:04<clever>and unaffected
05:04<clever>it hit me during dec last time
05:04<clever>604 recordings!
05:08<clever>boinc still has 26% of the cpu
05:08<clever>and it reniced itself to 19
05:27-!-camelreef [] has joined #mythtv
05:27<camelreef>good morning from Scotland
05:27<camelreef>oh, wrong channel, I'm a user
05:28-!-camelreef [] has left #mythtv [""oh god a "l33t3r" (c) 2007 leftovers"]
05:30<clever>oct and still no crash...
05:41<clever>done loading and no crash!
05:41<clever>the bug is either lucky or dead
05:42<clever>2008-03-07 06:41:44.774 Preview Error: Run() file not local: '/GetPlaybackURL/UNABLE/TO/FIND/LOCAL/FILE/ON/theP4/1045_20071205125900.nuv'
05:43<clever>what if i was to make such a file just to screw with mythtv:P
05:52<clever>sphery: a 2nd problem ive noticed
05:52<clever>i thought i commented out the line to generate preview images to work arround the 100% cpu bug
05:52<clever>yet somehow its come back on its own:S
05:53-!-mntmst [] has quit [Read error: 110 (Connection timed out)]
05:55<gbee>if someone supplies a patch to replace the reliance on foreign keys in mythweather then I'll include it for 0.21, but I don't have time to do all the work myself
06:06-!-mzb [] has quit [Read error: 113 (No route to host)]
06:22-!-clever_ [] has joined #mythtv
06:36-!-clever [] has quit [Read error: 110 (Connection timed out)]
06:44-!-mntmst [] has joined #mythtv
06:58-!-MrGandalv [] has quit ["work"]
07:30-!-GBee1 [] has joined #mythtv
07:40<teprrr>btw, is there no menu editor available?
07:40<teprrr>just wondering whether I should start creating one..
07:41-!-dagar [] has quit [Read error: 110 (Connection timed out)]
07:42-!-dagar [] has joined #mythtv
07:46-!-gbee [] has quit [Read error: 110 (Connection timed out)]
07:48-!-briand [] has quit [Read error: 110 (Connection timed out)]
08:01-!-GBee1 is now known as gbee
08:02<gbee>teprrr: just edit the xml, not sure it's really worthwhile working on an editor
08:03-!-clever_ is now known as clever
08:04-!-reynaldo [] has joined #mythtv
08:04<gbee>there are plenty of ways to help out MythTV (there are 300+ outstanding tickets) but if a menu editor is what you really want to work on, then don't let me stop you ;)
08:04<teprrr>gbee, imho it'd be cool if there was support for dynamic menus based on what some plugins provide+core functionality.. and which would be configurable easily :P
08:04<teprrr>yeah, sure, perhaps I'll take a look more soon
08:42-!-ToadP [] has quit [Remote closed the connection]
08:42-!-ToadP [] has joined #mythtv
09:01-!-briand [] has joined #mythtv
09:26-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:37<gbee>leave mythmusic out of the demo at linuxtag? :P
09:45<GreyFoxx>Hmmm looks like I had several recordings not end at the proper time this week
09:45<GreyFoxx>2 half hour shows, 1 recorded for 5.5 hours (12G file) and another recorded for 10hours (23G file)
09:46<GreyFoxx>both are on my master backend with pvr cards
09:46<danielk22>Wow! I was going to say check to see if ntpd is still working, but that usually accounts for at most a few minutes..
09:47<GreyFoxx>the 12G one was last night, and the 23G was Monday
09:47<GreyFoxx>in fact now that I think about it I had a firewire HDTV recording a couple days ago that was reporting 4 hours long even though the show was 1 hour. I didn't actually verify if it was longer than an hour
09:47<jamesd>sounds like bug, perhaps a conspiracy by the harddrive makers to sell 1TB drives to the myth community ;-)
09:53<GreyFoxx> Between 4:30am and 10am nothing was logged but regular upnp stuff
09:54<GreyFoxx>recording starts at 4:30am and then another starts at 10am on another tuner. At the same time as the new one starts the first one ends
09:57-!-packetscan [] has quit [Remote closed the connection]
09:58<gbee>GreyFoxx: similar problems with livetv got me thinking about adding checks and maximum recording size/length safeguards -
09:58-!-packetscan [] has joined #mythtv
09:59<GreyFoxx>hmmmm each of the two I still have on my system that did this, both recorded from the same tuner, on the same channel
10:00<GreyFoxx>and both ended within 1-2 minutes of a logged "Reschedule requested for id 0."
10:00<GreyFoxx>I'm sure it happened on afirewire recording as well, but I deleted that already
10:01<gbee>Chutt: this is the fix I'm thinking about for #4756 -
10:02<Chutt>does it actually work?
10:03<gbee>Chutt: not a clue, I can't reproduce the crash so I'm just guessing at the likely cause from the backtrace
10:04<Chutt>have you used both qt and ogl painters to repro?
10:04<gbee>calling popscreen directly is a little too dangerous as we potentially delete the wrong screen, at least if DeleteScreen is called it should only ever delete itself (well that's the theory)
10:05<gbee>Chutt: no, I should probably try QT as it bypasses the fade ...
10:05<Chutt>PopScreen should probably take the screen as parameter
10:06<Chutt>but still, i still don't see how that'd get called twice
10:06<gbee>yeah, that's the other patch I wrote, on balance I liked the first one as it was simpler and seemed less likely to trip up
10:06<Chutt>one sec
10:07<gbee>Chutt: QApplication::postEvent(mainwindow, new ExitToMainMenuEvent());
10:08<Chutt>postEvent's fine
10:09<gbee>heh, well I don't fully see how it's happening, but the jumpoint calls popscreen -> popscreen sends an Escape keypress -> Escape triggers a second popscreen in mythweather
10:10<gbee>by the time the second popscreen is handled top (mythweather screen) has been deleted and so it deletes the main menu instead
10:10<Chutt>where does the jumppoint call popscreen?
10:10<Chutt>(it shouldn't)
10:19<gbee>jumppoint exits to mainmenu first by sending the ExitToMainMenuEvent() event, which sends the Escape keypress, which triggers a call to popscreen
10:19<danielk22>ugh, popups in Qt.. that's why the channel scanner is so crash prone :(
10:19<gbee>sorry it took so long, kdevelop decided to crash while I was tracing it through
10:21<gbee>JumpTo -> Escape Keypress -> MythAppear calls popscreen -> Popscreen -> Escape Keypress (why?) -> Popscreen -> Segfault
10:22<Chutt>i still don't see how that'd happen
10:22<Chutt>JumpTo sends an event
10:22<Chutt>next Qt loop iteration, it processes event, calls ExitToMainMenu
10:22<Chutt>that checks the top screen, and it's not 'mainmenu', so it sends an escape to exit the top screen
10:23<Chutt>next qt loop iteration, mythappear process escape, calls popscreen
10:23<Chutt>popscreen deletes top screen (mainwindow->isexitingtomain is true), postevent's new exittomainmenu event
10:24<Chutt>next qt loop iteration, postEvent process
10:24<Chutt>calls ExitToMainMenu
10:24<Chutt>sees top screen is now 'mainmenu', stops
10:27<gbee>you're right, shouldn't happen as I've stated it - missed the "screen->name() != QString("mainmenu")" in ExitToMainMenu
10:28<gbee>ok, I'm stumped
10:30<gbee>can't reproduce it with the QT painter either
10:31-!-catinpan is now known as catinpan_away
10:31-!-catinpan_away is now known as catinpan
10:31-!-superm1 [n=superm1@ubuntu/member/superm1] has quit ["Leaving"]
10:33<gbee>I guess the Exit event in popscreen is to take us completely back to the main menu if we're more than one screen deep
10:34<Chutt>it's meant to go one more level up
10:34<Chutt>then the eventhandler sees we're at mainmenu, and stops the jumpping, and calls the jumppoint
10:38<gbee>ok, I give up
10:38-!-lcase [] has joined #mythtv
10:38<gbee>if I could reproduce it I'd stand a chance of seeing what is going wrong
10:39<gbee>don't think I can expect the user to step through it in gdb for me
10:41<Chutt>bump it to 22?
10:42-!-aevil [] has joined #mythtv
10:42<gbee>yeah, unless anyone else wants to have a go?
10:49<gbee>well I'm running out of reasons to avoid the mythweather job
11:17<GreyFoxx>What are the major bugs.blockers left ?
11:20-!-gnome42 [] has joined #mythtv
11:21<sphery>There's a report from xris of the 100% CPU on XML preview request thing returning, but I know of at least 4 people who were previously affected who can not reproduce with current head.
11:23<gbee>utf8 fixes for upnp, but I'm not sure I'd call it a blocker just something that shouldn't be too hard to fix
11:24<gbee>probably just needs local8bit conversions on the file and directory names read directly from the filesystem
11:24<gbee> < If anyone wants to help out
11:26<gbee>channel scanner segfaults, video profile naming, mythweb not handling recordings created during DST and the segfault in SSDP code are the main ones
11:27<sphery>Sounds like Anduin/paulh have a good start on the segfault in SSDP code.
11:27<danielk22>gbee: i'm about to look at video profiles
11:28<sphery>xris/kormoc don't even have a plan for fixing the MythWeb DST issue, right?
11:29<gbee>sphery: there was a plan, but it involved backend changes iirc
11:29<sphery>Oh, yeah. Change the programinfo to use unix timestamps, right?
11:29<sphery>sounds a bit dangerous for right before a release...
11:30<gbee>yeah, but it's a big enough bug that it might be better to fix it now
11:30<sphery>unless, perhaps, we have a new protocol command to specifically request a "special" stringlist (so the rest of the code using programinfo is unaffected), perhaps.
11:30<danielk22>yep.. I thought that change was already applied?
11:31<danielk22>the yep, was for 'sounds a bit dangerous'
11:34<gbee>I've already forgotten the important details of the bug
11:36<sphery>me too... What do you think of a new command QUERY_RECORDING*_UNIXDATE or something? Ugly for the long term, but might be an acceptable transitional approach to support MythWeb 0.21 (and allows testing changes to QUERY_RECORDING* in trunk before 0.22).
11:39-!-beavis [] has joined #mythtv
11:40<janneg>danielk22: you probabbly mix it up with the QUERY_PIXMAP_LASTMODIFIED change which was applied in
11:41-!-mykeul [n=mykeul@] has left #mythtv []
11:41<danielk22>janne: yep, your right
11:44-!-xris [] has joined #mythtv
11:45<sphery>There's the guy who knows what needs modified in the backend to fix MythWeb's DST issue... :)
11:45<gbee>sphery: there may be a purely mythweb/php fix, but as I can't remember exactly what was going wrong I'm not sure
11:46-!-_splat1 is now known as splAt1
11:46-!-splAt1 is now known as splat1
11:46<sphery>xris: Did you say you needed the QUERY_RECORDING* commands to send Unix dates to fix the DST thing?
11:48<xris>sphery: not sure how/if that would help.
11:49<gbee>one of PHPs date functions should know when a given time falls into a DST period in the current locale, so it may be enough to +1/-1 an hour to the the requested starttime
11:49<xris>I actually don't really know what the issue is with the DST thing.. whether mythweb's converting the date wrong, or what
11:49<xris>gbee: you'd think that. but I don't trust it. I do trust mysql, though
11:50<gbee>let me do some digging and add details to the ticket which I should have done in the first place
11:51<gbee>does no-one else have recordings made during a DST/BST period? I don't know if we've confirmed that this is a genuine bug and not some problem with my install
11:52-!-aevil [] has quit ["Ex-Chat"]
11:58<sphery>gbee: Do you remember where the issue presents itself? I have recordings from DST that show up fine in my Recorded Programs page (and I've recently regenerated the previews through MythWeb many times without issues).
11:58<gbee>it's the Record Programmes page of mythweb
11:59<gbee>hang on, I'm just posting an example to the ticket
12:00<sphery>cool (I guess previews would have been fixed with QUERY_PIXMAP_LASTMODIFIED, anyway)...
12:05<gbee>added an example of starttime/progstart pulled from the database for "Thirteen Days" and then a screenshot of the time as shown by mythweb
12:06<gbee>no preview image because it's requesting the wrong starttime
12:06<gbee>clicking on the recording gives the error "Unknown programme"
12:08<gbee>that applies to every recording on the backend created during BST (UK equivalent of DST)
12:08<gbee>oh and I've just managed to reproduce the 100%cpu bug :(
12:09<danielk22>gbee: is there a ticket for translation strings for playback profiles?
12:09-!-dekarl [] has joined #mythtv
12:10<gbee>danielk22: don't know of one
12:10<sphery>Hmmm. I'm not seeing that. I have recordings from before, during and after the DST change from last year, but they're all showing previews and I can click them to see program details. (BTW, DST starts here in 2 days, so I'm not in it now, but the shows recorded during last years' DST were.)
12:11<gbee>danielk22: the main ticket does mention translations -
12:11<sphery>gbee: Is your MythWeb on a different host from your backend? If so, do you have the same timezone specified in the php.ini as on the backend?
12:12<gbee>sphery: different host yeah, let me check php.ini (system is on same timezone though)
12:24<gbee>sphery: think you've hit the nail - there was no timezone given in php.ini, when I check phpinfo() it thought the timezone was UTC instead of GMT/BST (I blame the French)
12:25-!-MrGandalf [] has joined #mythtv
12:25<sphery>Actually, xris hit the nail on the head last night when talking to someone else with the same issue. :)
12:25-!-dekar1 [] has quit [Read error: 110 (Connection timed out)]
12:25<xris>yeah, he definitely has a weird setup... runs his server in UTC time
12:26<xris>but php is f'd up by not inheriting timezone info
12:27<gbee>running anything in UTC is f'd up as it's not a proper timezone :p
12:28<sphery>Was looking at the Errors/Exceptions part of but it seems like that wouldn't help us determine if we should warn the user, right?
12:28<gbee>no idea why php wasn't using the system timezone
12:28<sphery>Yeah. It sounds like PHP will warn you if it /is/ using the system timezone. ???
12:30<gbee>that's just a warning because in many cases your server may not be in the same timezone as your customers etc
12:31<gbee>so it can safely be ignored if that isn't the case
12:31<gbee>but it should be using the system time by default and I've no idea why my install isn't doing that
12:32<sphery>Wonder whether a new protocol command QUERY_TIMEZONE would be useful for detecting this issue...
12:33<gbee>I think we should probably include TZ info and then use date_timezone_set() to force php into using the same
12:35<sphery>include it where?
12:36<xris>gbee: that'd be a nice addition
12:37<gbee>sphery: as part of the time string sent by the backend maybe, or as a seperate protocol command as you've suggested
12:38<gbee>seperate command makes a little more sense, but only if we cache the result somehow
12:39<gbee>part of the session or something
12:39<sphery>Agreed. Might be difficult to match C/PHP TZ abbreviations up all the time...
12:44<sphery>How would the backend reliably determine the timezone it's using?
12:46<gbee>well there I think we have to assume that the system timezone is accurate
12:47<gbee>we can extend the same idea to frontends though, so the frontend doesn't have to be in the same timezone as the backend any more (not that it's a good idea to use a frontend over a remote connection)
12:48<sphery>Yeah. I was looking for more of an implementation... All POSIX stuff seems to say, "If TZ is absent from the environment, implementation-defined default timezone information shall be used"
12:51<gbee>we'll worry about that after 0.21? :)
12:51<sphery>Guess that works...
12:53-!-MrGandalf [] has quit ["home"]
12:53-!-kdub [n=kyle@] has quit [Nick collision from services.]
12:54-!-kdubya [n=kyle@] has joined #mythtv
12:58-!-lcase [] has quit []
13:02-!-rn114 [] has joined #mythtv
13:02-!-_gunni_ [] has joined #mythtv
13:03-!-Anduin [] has left #mythtv []
13:09-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
13:11-!-rn114__ [] has joined #mythtv
13:11-!-rn114 [] has quit [Read error: 104 (Connection reset by peer)]
13:17-!-eharris_ [] has joined #mythtv
13:21-!-erik__ [] has joined #mythtv
13:29-!-eharris [] has quit [Read error: 110 (Connection timed out)]
13:34-!-Anduin [] has joined #mythtv
13:40<danielk22>Hey does anyone want to give the new display profiles a try before I commit the change #4631 ?
13:41<danielk22>They all use ffmpeg software decoding, and should work decently on X11 & OSX out of the box. If someone has one of the old sample profiles as their default profile, this resets the default to the "Normal" profile.
13:42<danielk22>I would especially like to have an OSX user test these, since I don't have the setup to test this here..
13:43-!-jgarvey [] has joined #mythtv
13:43<xris>danielk22: would love to test, but I still get GL compile issues in OSX.
13:43<gbee>danielk22: I'll give them a try, don't have a mac here though
13:43<xris>it's trying to link against the wrong directory
13:45<danielk22>xris: ?? how long has this problem existed?
13:45<xris>couple of weeks, at least
13:45<xris>j-rod and I have been struggling with it. he's gotten further than I have
13:45<danielk22>has nigel looked at it?
13:45<xris>hang on, I'll recompile and give you info
13:45<xris>no clue
13:46<xris>not sure if it's a mythtv thing or a 10.5 thing
13:46<j-rod>I haven't seriously pursued it in a week or two
13:46<j-rod>built okay like 3 or 4 weeks ago, then failed the last time I tried, haven't got back to it yet
13:46<j-rod>to busy hammering on firewire
13:46<danielk22>osx firewire?
13:47<j-rod>awesome protocol, really, but damn, there are some SHITTY firmwares out there...
13:47<j-rod>nope, linux kernel firewire stack
13:47<j-rod>the new hotness juju/firewire stack vs. the old ieee1394 stack
13:48<danielk22>there were some fixes I wanted to make to the osx stack, like not linking to sample code.. but never got around to when i had a firewire stb.
13:48*xris hopes it'll work in f-9
13:48<j-rod>all kinds of precautions you have to take to deal with crap firmware
13:48<j-rod>haha, and it looks like apple screwed up their firewire target disk mode firmware on x86_64.
13:48<xris>need the f-9 beta to get released. I tried to install the alpha in vmware, but it broke vmware (forced a reboot)
13:48<j-rod>some of the config rom registers are returning what look like byte-swapped values.
13:50<j-rod>the installer is all kinds of broken right now. can't install most nightly trees lately unless you're really lucky
13:50<j-rod>not sure how our installer team fucks things up so egregiously during development, and yet still managed to pull something out of their ass at the last minute for release that actually works... :)
13:50<gbee>linear better than kernel?
13:51<j-rod>xris: I'll get back to video one of these days... after all the storage bugs are fixed! :)
13:51<xris>gbee: deint? I think linear looks better.
13:51<j-rod>gbee: ?
13:51<j-rod>oh, sorry
13:51<xris>would still like to see dscaler ported to linux/mythtv.
13:51<xris>gbee: kernel uses fewer resources.
13:52<gbee>xris: I only ask because the help text states that kernel uses linear
13:52<xris>ok, weird. then maybe I'm wrong. lol
13:52<laga>xris: yadif and greedhy look very good here
13:53<xris>laga: ?
13:53<gbee>from memory it says something like "Kernel deint compares fields and avoids deinterlacing if they are similar, otherwise it uses linear deint"
13:53<xris>maybe "linear" and "linear blend" are different? dunno
13:54<xris>mythtv already avoids deinterlace for progressive streams
13:54-!-erik__ [] has quit ["Lämnar"]
13:54<gbee>don't know anything about the merits of different deinterlacing methods
13:54<danielk22>kernel does this on a pixel by pixel basis..
13:55<danielk22>mythtv just looks at the flags the broadcaster sends
13:55<danielk22>which are sometimes wrong
13:56<danielk22>linear always does linear deinterlacing, even with progressive frames, which is why it gets blurry..
13:56<danielk22>progressive frames -> progressive frames marked as interlaced
13:58<xris>so kernel is better than linear?
13:59-!-rn114__ [] has quit [Read error: 113 (No route to host)]
13:59-!-rn114 [] has joined #mythtv
14:01<danielk22>well except it has some artifacts, I prefer linear for HD material
14:04<xris>danielk22 / j-rod: ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib
14:04<gbee>I don't really have an eye for this stuff, most of the time I couldn't tell if something is progressive or interlaced except when it's paused
14:05<xris>gbee: it really depends on the content. I can't tell on my machine at all because the nvidia driver does all of that for me.
14:05<gbee>I suppose everything broadcast here is interlaced
14:05<j-rod>xris: and that's after upgrading your X11 w/the Xquartz one?
14:05<xris>j-rod: yeah, did that long ago
14:05<j-rod>(thought that was one of the things that upgrade was supposed to fix, but yeah, thought you already upgraded. shit.)
14:05<gbee>xris: do it deinterlace video which goes to a monitor, or just stuff to tv-out?
14:06<xris>I've even added: extra-ldflags="-dylib_file /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib"
14:07<gbee>that could be why I can't tell, all my machines use nvidia cards, but I didn't realise the driver did any deinterlacing - suppose it makes no sense to deinterlace stuff for tvout
14:08<gbee>ignore me, I'll get back to tinkering with mythweather
14:08<xris>gbee: driver does if you tell it to.. that's the "anti-flicker" setting
14:09<xris>only works well if you turn OFF deint in mythtv, though
14:09<gbee>well yeah, that makes sense now :)
14:12<gbee>what's the last known working version of the nvidia drivers? I used 100.14.19 when re-installing but that's the one with the pink screen & kernel panic bug
14:13<sphery>gbee: Are you concerned enough about your mythfrontend -u failure to say it needs investigated before 0.21? I couldn't reproduce it last night (tried with a failed and a successful backup, tried with the -u in varying locations in the command line).
14:14<gbee>sphery: not really concerned, it's annoying but not serious
14:14<sphery>gbee: I'm using 1.0-9755 (not that I'd specifically recommend that one, but I hadn't found any problems with it and heard a lot of discussion of issues with 100.x and 169.x versions, so I just didn't upgrade).
14:14<gbee>I can look at it after 0.21
14:14<sphery>gbee: OK. I'm really going to need more information to reproduce it, and since you're so busy with MythWeather, I figured later would be better for you.
14:15<gbee>sphery: yeah, I was using that version for the same reasons before I upgraded, but I thought that at least one of the 100.x series was ok
14:15<gbee>maybe I'll just stick with 9xxx
14:16<sphery>The only thing I can imagine that could have caused the -u issue is if the actual DB upgrade failed, but--in theory--if running it with mythtv-setup worked, that shouldn't be the case.
14:18<j-rod>ah, nice. now why the eff didn't I hit this too?
14:19<danielk22>xris: do you remember which of the two loops in 3995-v1.patch was infinite?
14:19<xris>no clue. but like I showed above, I tried that with the --extra-ldflags option to ./configure and it didn't help
14:19<xris>danielk22: not a clue, sorry
14:21-!-mntmst [] has quit [Remote closed the connection]
14:23-!-nsaspook [] has joined #mythtv
14:25<danielk22>xris: I'm going to need a backtrace of the deadlock...
14:26<gbee>sphery: it's odd, but the update to 1214 just worked fine with -u
14:26<xris>which bug was this supposed to fix, again?
14:26<danielk22>crash when deleting in progress recordings
14:28-!-ahbritto [] has quit [Client Quit]
14:29<xris>can you link me the patch again?
14:29<xris>and tell me how to set up gdb.. :) I'm not that good with it.
14:31<sphery>gbee: I'm willing to chalk it up to a partially-updated install (old libs) that still had some bad code in dbcheck from the 1213 update but that got updated when you did the partial install of mythtv-setup, if you are. :)
14:31<janneg>can someone confirm audio stutter after switching virtual desktops with kwin
14:33<gbee>danielk22: somethings not right with those new profiles, I updated, deleted the old profiles and I'm now using 'normal' - video is screwed up, all wrong colours, blocky etc
14:33<gbee>but I can't see anything different from the profile I've used in the past
14:38-!-moemoe [] has joined #mythtv
14:38-!-moemoe [] has left #mythtv ["wrong chan ;)"]
14:39<danielk22>greedyhdoubleprocessdeint perhaps? try switching to lineardeint
14:40<gbee>no difference
14:47<danielk22>it might be [16424] not the videoprofiles patch causing the problem, investigating...
14:48<gbee>turned off all deint, standard decoder, xv-blit - all known to work before
14:49<gbee>let me try a reboot though, as I said earlier I'm using a known back driver revision
14:49<gbee>playback worked fine earlier today, but this looks driver related IMHO
14:51<gbee>I'll get a sample to you if it doesn't work, I need to eat my dinner before it's cold so it will be about 40 mins
15:13<GreyFoxx>danielk22: That patch for #4567 doesn't fix the issue for me using his test.avi
15:17<GreyFoxx>Actually, it fixes it for the XV renderer
15:17<GreyFoxx>but the OpenGL renderer still shows the same few lines at the bottom as before the patch
15:21-!-ahbritto [] has joined #mythtv
15:22<Chutt>opengl renderer is not supported in 0.21 =)
15:22<Chutt>stock answer
15:26<sphery>danielk22: I agree. #4748 really doesn't need to be in 0.21. Since the auto backup will likely run a grand total of 1 time for 0.21 users, and since most users use the default MySQL port and those users who don't probably specify the port in a ~/.my.cnf (which would allow the auto backup to succeed), it's not worth the time at this point.
15:27<danielk22>in order to make it a safer fix, video_dim is left unchanged so each renderer needs to be changed to use the visible dimensions instead of the buffer dimensions.. but I've actually temporarily reverted the patch. The NVP needs the unchanged video_dim too...
15:27<Chutt>i'd still like to release tonight
15:27<sphery>danielk22: Besides, I've almost got #4760 ready to go (and it will obsolete #4748). Just need to finish the backup rotation and then do a restore script.
15:27<Chutt>but. realistically, expect the weekend
15:28<danielk22>i'm working on it right now.. the problem is that the NVP has GetARGBFrame which directly accesses VideoOutputNull..
15:32*GreyFoxx wonders over the to wiki's wishlist and release notes to see how far off they are
15:38<gbee>release notes are about ~2000 revisions off
15:39-!-gbee [] has quit ["Gone"]
15:40-!-Deek [] has quit [Remote closed the connection]
15:46-!-rn114__ [] has joined #mythtv
15:46-!-rn114 [] has quit [Read error: 113 (No route to host)]
15:46-!-Deek [] has joined #mythtv
15:49-!-splat1 is now known as splAt1
15:55<xris>GreyFoxx: was that backtrace from the mp4 playback able to show you anything?
15:55<xris>I'm wondering if it's a bug in my qt packages or something.
16:03<GreyFoxx>That second paste showing calling "mythtv" directly failed because you accidentally used -c instead of -v
16:03<Anduin>xris: At least one of them just pointed to heap corruption
16:04<GreyFoxx>the first did look like a QT problem parsing the OSD xml files or something since all of the DOM related stuff going on
16:06<GreyFoxx>anyone notice that now you get "2008-03-02 16:29:13.180 FilterManager: failed to load filter 'none', no such filter exists
16:06<GreyFoxx> if you don't have a deinterlacer set ? :)
16:06-!-mattwire [] has joined #mythtv
16:06<GreyFoxx>I would have thought it wouldn't even try if it was set to none :)
16:10-!-foxhunt [] has joined #mythtv
16:11-!-erik__ [] has joined #mythtv
16:15<Chutt>dvb people: #4796?
16:15<Chutt>seems a simple fix?
16:16<janneg>I wanted to look at it, thanks for reminding
16:18<danielk22>Looks correct just looking at the code. But I would want it tested for side effects before committing.
16:20<xris>GreyFoxx: I'll retry stuff when I get home
16:22-!-gbee [] has joined #mythtv
16:32<gbee>danielk22: sorry for confusion, playback problems were driver related
16:33<danielk22>I guess the big remaining question is how well do these profiles work on OSX?
16:34<janneg>danielk22: what's the preferred solution for a single program not needing a encoding fixup while all others program on the same network need it
16:34<janneg>I don't want to split it into transports and channel
16:35<danielk22>janne: I don't think we've handled that case before. If this is a Q for 0.21, I say just do the EIT fixup anyway.
16:36<janneg>no, nothing for 0.21
16:37<janneg>I see no side effects with the _pids_audio.clear()
16:37<danielk22>then we should come up with some elegant way to handle this.. you want to look at it?
16:37<danielk22>janne, go ahead and commit it then. It looks safe to me.
16:37-!-moodboom [] has quit [Client Quit]
16:40-!-emacsen [n=serge@pdpc/supporter/sustaining/emacsen] has joined #mythtv
16:40-!-purserj [] has joined #mythtv
16:40<emacsen>Is the HelloMyth still the best example of a mythtv plugin to start iwth?
16:41<gbee>probably not, uses libmyth instead of libmythui
16:42<emacsen>okay. can you point me to another one? :)
16:42<emacsen>or a guide?
16:42<emacsen>something simple
16:42<gbee>hmm, maybe it doesn't - not sure it uses any UI stuff now that I think about it
16:43<emacsen>I'm kinda surprised that there aren't myth bindings to other languges
16:43<gbee>it's a good guide to the basic structure of a plugin - so I'd stick with it for now and then look at mythcontrols in 0.21 for the UI stuff
16:44<gbee>hmm, yeah it uses myththemeddialog which is deprecated
16:45<emacsen>Mainly I want two things
16:46<emacsen>1) A command line program to tell the video manager to update it's database
16:46<sphery>emacsen: See (whole thread), and feel free to help with the 0.21 transition of the MythHello and mythtutorial2 plugin examples...
16:46<janneg>danielk22: we are unfortunately using the additive character of the fixup flags, otherwise we could just use the most specific fixup
16:46<emacsen>2) A nicer interface to my video podcasts, let me treat them more like other recordings (delete them, etc.)
16:47<gbee>emacsen: it's up to you, but I'd write patches for mythvideo instead of writing a new plugin
16:47<sphery>emacsen: Also, ask on mythtv-users mailing list (or, better, spend some time searching first) as I'm sure some have come up with approaches for handling those types of things.
16:47<janneg>creating another defixup table would be ugly
16:47<gbee>danielk22: I went ahead and uploaded that sample anyway, should you want to add it to your collection:
16:48<emacsen>shphery- yeah that's a good point. I won't spam up this channel for it though. thanks for the pointer
16:48<sphery>gbee: Hope it wasn't my driver version suggestion that caused you issues.
16:48<gbee>that goes for any dev wanting a sample of UK DVB-T (BBC One in this case)
16:48-!-emacsen [n=serge@pdpc/supporter/sustaining/emacsen] has quit ["ircII EPIC4-2.6 -- Are we there yet?"]
16:48<gbee>sphery: no, I hadn't made the switch yet, I was still running 100.14.19
16:50<janneg>the simplest solution is probably don't apply the encoding fixup if the text has an encoding
16:50<Chutt>mark's latest email on the -dev list would indicate he fixed 4817?
16:50<sphery>Silly Mark Spieth. He wants the ALSA drivers to abstract out differences between the hardware. ;)
16:51*gbee mutters rude words about ALSA
16:52-!-rn114 [] has joined #mythtv
16:52-!-rn114__ [] has quit [Read error: 104 (Connection reset by peer)]
16:53-!-MrGandalf [] has joined #mythtv
17:03-!-foxhunt [] has quit [Remote closed the connection]
17:06-!-clever [] has quit [Read error: 104 (Connection reset by peer)]
17:07<janneg>Chutt: it is fixed here, but I can't test passthrough
17:16-!-clever[rev] [] has joined #mythtv
17:16-!-clever[rev] is now known as clever
17:20<janneg>huh, trac reopens tickets on reverting the fixing commit?
17:22<danielk22>No, I referenced the wrong ticket when I did the actual commit, then when I noticed I copied the trac message to the right ticket and also reopened it..
17:32-!-mattwire [] has quit [Read error: 104 (Connection reset by peer)]
17:32-!-mattwire [] has joined #mythtv
17:33-!-renatofilho^ [n=renato@] has quit [Read error: 113 (No route to host)]
17:33-!-lsobral [n=sobral@] has quit [Read error: 113 (No route to host)]
17:34-!-renatofilho^ [n=renato@] has joined #mythtv
17:34-!-lsobral [n=sobral@] has joined #mythtv
17:38-!-MrGandalv [] has joined #mythtv
17:39-!-mattwire [] has quit ["Leaving"]
17:46-!-jgarvey [] has quit ["Leaving"]
17:49-!-aeha [] has joined #mythtv
17:51-!-xris [] has quit []
17:54-!-xris [] has joined #mythtv
17:56-!-MrGandalf [] has quit [Read error: 110 (Connection timed out)]
18:00<Dibblah>Heh. Erik's at it again :)
18:02-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:03<Chutt>at least they're not against 21
18:03<kormoc>When's the tarballs rolling?
18:04<Chutt>maybe tonight
18:04<Chutt>more likely tomorrow
18:04<Chutt>i'm going to be snowed in, so..
18:05<kormoc>Kk, I need to move that position fix from trunk to stable. Most of the people who reported it failed to get back to me if it fixed it or not, so I'm gonna assume it's fixes for all those wacky browsers
18:05<Chutt>everyone: merge any pending stuff to fixes :p
18:06<kormoc>Ahh, and #4881 is valid, I'll have to smash that one tonight as well...
18:08-!-lsobral [n=sobral@] has quit ["leaving"]
18:08-!-jmk_ [n=jmk@] has quit ["Leaving"]
18:08<Chutt>there's a couple other mythweb issues - any chance any of them are easy?
18:09<kormoc>Without looking, I can't say, but I'll smash as many out tonight as I can
18:09<xris>Chutt: won't know until I can lok tonight
18:09<Chutt>there's only 4 of em
18:09<xris>and kormoc's just as busy as I am tonight
18:09<Chutt>(with a .21 milestone)
18:09<xris>(since we both have the same plans)
18:09<Chutt>that's fine =)
18:09<Chutt>no worries, like i said, i probably won't build it until tomorrow
18:10<Chutt>i'm going to be testing tonight fairly
18:10<Chutt>err, fairly extensively
18:10<xris>I still want to know why I can't get this compiled in osx
18:11-!-reynaldo [] has quit [Read error: 113 (No route to host)]
18:11<Chutt>Library 1,146 books
18:11<Chutt>heh, yay for librarything
18:11<xris>I have too many to catalog without some sort of barcode scanner
18:12<xris>and the cuecat I got from kormoc wasn't hackable
18:12<Chutt>i used a cuecat initially
18:12<Chutt>i was always tempted to write a little webcam app to scan barcodes
18:12<xris>I wonder if there's a macbook-webcam barcode reader
18:12<Chutt>but that'd involve buying a webcam
18:12<xris>you want one? I'm sure I have a spare somewhere.
18:13<Chutt>xris, delicious library ($$ catalog app for the mac) has a webcam scanner built in
18:13<xris>should see if my wife would be interested in that.
18:15<clever>theres a defect in mythwelcome
18:15<clever>the next recording starts at 8pm and finishes at 21:00
18:15<clever>its mixing the 12h and 24h clocks!
18:15<laga>oh noes.
18:16<danielk22>xris: did you look at #3995?
18:16<Chutt>xris, librarything's cooler
18:16<xris>not during work :)
18:17<Chutt>ah well
18:17<xris>Chutt: I like shelfari, too... but can't do much without a scanner
18:17<gbee>heh, mythweb is worse, there are a dozen different time strings and the 12h clock puts a zero before times making them look 24h e.g. 08:00 is actually 8pm
18:17<danielk22>shoot, i forget the time difference sometimes :)
18:17<Chutt>shelfari's evil spammer people
18:17<xris>oh? I turned off notifications and they haven't bugged me since.
18:18<Chutt>they had a thing where they'd invite everyone from your address book (gmail, etc)
18:18-!-michthom [] has joined #mythtv
18:18<clever>laga: it seems like a simple fix
18:18<clever>at one point it uses a timeFormat variable
18:18<clever>then it uses hh:mm
18:18<clever>now it says 8pm and 9pm!
18:19<clever>now to fix up the other 2 times for the current recording
18:20<gbee>clever: all times in mythfrontend should use the settings DateFormat, ShortDateFormat and TimeFormat
18:20<kormoc>gbee, I will be unifying them someday :P
18:20<clever>but ive found "hh:mm" in 3 places in mythwelcome
18:20<clever>and m_timeFormat in 1
18:21<clever>duplicating so all 4 are m_timeFormat should fix it
18:21<xris>gbee: what kormoc said.. :)
18:21<gbee>clever: if m_timeFormat = GetSetting("TimeFormat");
18:21<clever>something is allready seting m_timeFormat
18:21<clever>but 75% of the code isnt even using it
18:21<clever>until now!
18:22<xris>danielk22: so the dylib error in MacOS compiling doesn't seem to work because ./configure --extra-ldflags seems to generate errors
18:22<clever>- " " + tr("to") + " " + tuner->endTime.toString("hh:mm");
18:22<clever>+ " " + tr("to") + " " + tuner->endTime.toString(m_timeFormat);
18:22<clever>such a simple patch:)
18:22<clever> has the finished patch and my tweaks to the fontsize so the time doesnt get cut off
18:23<laga>clever: open a ticket?
18:23<clever>programs/mythwelcome/ was the cwd
18:23<clever>its such a simple thing it seems easyer for one of you to just patch&commit
18:24<clever>and the ticket i worked on hours ago (4884) is untouched!
18:24-!-beavis_ [] has joined #mythtv
18:24<clever>seems tickets i open just get ignored...
18:25<laga>clever: you opened 4884 fifteen hours ago.
18:25<clever>and was talking in here about how to finish it before i posted it
18:27-!-unclemike [] has joined #mythtv
18:28-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
18:28-!-michthom [] has left #mythtv []
18:29-!-erik__ [] has quit ["Lämnar"]
18:32<clever>i'll post a ticket tomorow if i dont see it comited:)
18:32-!-rn114__ [] has joined #mythtv
18:32-!-rn114 [] has quit [Read error: 104 (Connection reset by peer)]
18:33<danielk22>xris: I'm of limited utility for OSX, I've done very little programming on the platform, and don't have OSX system to test on at the moment.
18:34<xris>you had asked earlier, so I had some hope. :) I think the issue might be that the extra-libdir stuff isn't getting set properly
18:34<xris>but I don't really know how to check
18:36<danielk22>It's probably related to the dependency cleanup Nigel and the MingW guy were doing, but I really don't know much about it.
18:36<danielk22>Andrei is his name?
18:39-!-beavis_ [] has quit ["Verlassend"]
18:40-!-beavis [] has quit [Read error: 113 (No route to host)]
18:40-!-grokky [] has joined #mythtv
18:41<kormoc>clever, first, it's 'already' not 'allready', SQL commands should be in all caps 'on duplicate key update' vs 'ON DUPLICATE KEY UPDATE'
18:41<clever>i'll remember that for my next patch
18:42<kormoc>Third, why not let the database handle if the setting didn't change? mysql is smart, and no need to log it imho
18:42<clever>the loging was more of a debug thing to make shure it worked right
18:43<clever>forgot to remove it
18:43<kormoc>comments like 'the new code' don't really age well, given in a year, it's no longer the new code
18:43<clever>didnt think of that
18:43<clever>also the compare to see if it even needs to update could use the settings cache, and return faster then mysql
18:44<kormoc>And you really should give the file a real name and extension, Setting_on_duplicate_key.diff rather then contextdiff
18:44<clever>might not be noticable for 1 query but could make a 300 setting page in mythtv-setup faster
18:44<clever>i didnt remember that the trac site would use that exact name i threw it into localy
18:44<clever>was just using that as a temp file on the way to the site
18:45<kormoc>personally, I think it's a mote point, as you could use INSERT DELAYED rather then INSERT if it's an actual speed improvement
18:45<kormoc>INSERT DELAYED will pend up the insert to run when the db is free and returns right away
18:46<kormoc>but I think the DB should be hit every time, as that's where the real data is. if the settings cache gets corrupted, your settings might just not stick, and that's sorta crappy
18:46<clever>also that part was to work arround a lack of rows_match() in the qt/sql api which i no longer need to work arround
18:47<clever>i'll try and remember all this for my next ticket:)
18:48<gbee>IMHO patches with the ticket number at the start of the filename are the most useful e.g. 4334_mythmusic_sorting_fix.diff
18:48<clever>then you can tell which ticket the patch is from:)
18:49<gbee>I've hundreds of patches that I've downloaded from tickets but forgotten to delete after committing :)
18:49<clever>yeah that can become a mess
18:49<clever>2 big problems still that happen often still
18:49<clever>lirc reception seems poor when under high cpu load
18:50<clever>which doesnt make much sense because its a pvr150 builtin receiver(shouldnt need the cpu to poll often)
18:51<gbee>oh ffs, why is forcing every user to select a vbi device node better than inserting that data into the stream and having it work automatically? What are these driver authors smoking?
18:52<Chutt>already closed it
18:52<clever>once i did do that on my framegrabber the backend semi randomly spit out vbi errors
18:52<clever>i suspect the cable co was cuting the vbi sentences off mid way when splicing comercials in
18:53<xris>danielk22: the dylib thing is actually new in osx 10.5... requires some sort of changes to the configure stuff. but it's over my head. I'll check with nigel, though.
18:54<danielk22>dylib is just their name for an shared object file. (so==dll==dylib)
18:54<xris>yeah, but it's the pathname that's the problem
18:55<danielk22>ic, we need to look in a new location..
18:55-!-Dibblah [] has quit [Read error: 113 (No route to host)]
18:55<Chutt>is that mythweb issue with loading /tv/ fixed yet?
18:56<kormoc>It's weird, I can't reproduce it on my home box...
18:57<kormoc>which likely means it's a session problem
18:59<gbee>#4880 -- Want to bet that they didn't even check to see if their checkout was correct?
19:00<kormoc>AH HA!
19:00<gbee>any better naming ideas for "Inactive Screens" in mythweather screen setup? I don't think it accurately reflects what that list contains
19:00<kormoc>Chutt, it'll be fixed in a minute
19:03-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
19:03-!-purserj [] has joined #mythtv
19:04<laga>hum, the gray-osd theme gives me squishy fonts :/
19:06<kormoc>Chutt, it's fixed for ya
19:07<janneg>Chutt: #4764 isn't solved. I'm seeing now bursts of buffer underuns and overflows alternating
19:10<Chutt>kormoc, thanks
19:11<Chutt>janneg, doh
19:11<kormoc>No problems :)
19:12<sphery>kormoc: re #4880, doesn't MythWeb now require PHP 5? He's using PHP 4.4.
19:13-!-asdffdsa [n=kyle@] has joined #mythtv
19:14<kormoc>sphery, Aye, that's correct
19:14<kormoc>xris, did you do the announcement about that?
19:14<sphery>easy to close, then... :)
19:14<xris>sphery: trunk requires php5
19:14<xris>kormoc: did you update the "requres php xxx" message?
19:14-!-TelnetManta [] has joined #mythtv
19:15<xris>there's a check for php_version() that sends a specific error about that.
19:15<kormoc>xris, you know, I didn't
19:15<kormoc>I forgot that existed
19:15<kormoc>let me do that real quick
19:15<kormoc>Ahh, whoops
19:15<kormoc>I thought that was all compat stuff and deleted it
19:17-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
19:18-!-purserj [] has joined #mythtv
19:24<gbee>shouldn't #4764 have a 0.21 milestone?
19:28-!-schula [] has joined #mythtv
19:28-!-schula [] has left #mythtv [" none :)"]
19:28-!-unclemike [] has quit ["Leaving"]
19:30-!-asdffdsa [n=kyle@] has quit [Read error: 110 (Connection timed out)]
19:31-!-kdubya [n=kyle@] has quit [Read error: 110 (Connection timed out)]
19:35-!-knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has joined #mythtv
19:36-!-kdubya [n=kyle@] has joined #mythtv
19:43<knowledgejunkie>Any chance my trivial mythnews URL patch (#4789) can be committed before release?
19:46-!-|gunni| [] has joined #mythtv
19:51-!-xris [] has quit []
19:51<MrGandalv>danielk22: re 4761, I've not seen that at all except for the first rotor tune but that's to be expected.
19:51-!-MrGandalv is now known as MrGandalf
19:55-!-kdubya [n=kyle@] has quit ["Leaving"]
19:55<danielk22>thx MrGandalf, I just asked for some more info. If the reporter doesn't reply I won't bother trying to reproduce this.
19:56<MrGandalf>sounds like a broken configuration to me
19:57<danielk22>unfortunately there is not much information in the ticket to confirm/deny that ...
20:01-!-_gunni_ [] has quit [Read error: 110 (Connection timed out)]
20:09<gbee>Chutt: release definately being pushed back to tomorrow?
20:09<Chutt>unless the alsa thing gets fixed
20:09<Chutt>i might just test tonight
20:09<Chutt>and build the release tomorrow
20:11<knowledgejunkie>gbee: if the release is 'real soon now' any chance you could put #4789 through ASAP so the Fedora News URL is not broken in the new release?
20:11<gbee>I'm about to check in some more mythweather bits, but there is still plenty I'd like to fix if I get the chance tomorrow
20:11<Chutt>gbee, .us tomorrow or .uk tomorrow?
20:12<gbee>uk tomorrow, I'll probably commit them before 9am US
20:12<Chutt>that's fine
20:13<gbee>it's 01:12 here now, so I'm off to bed in a few minutes
20:14<Chutt>i'd like to get anduin/paul's fix in as well?
20:16<Anduin>Chutt: I'll start tracking down the crash on close part of it in an hour
20:16<gbee>btw, Imperial units are still the norm over there for weather? Farenheit etc?
20:16<Chutt>gbee, yes
20:16<gbee>ok, I'll leave that as the default then :)
20:17<Chutt>Anduin, cool =)
20:17<MrGandalf>gbee: unfortunately
20:18<Anduin>The channel scanner stuff is bad as well though it sounds like danielk22 may have it tracked down.
20:19<gbee>MrGandalf: it's still a mix over here, I'd say it really started to change with my generation, I grew up with Imperial units at home and Metric at home
20:20<gbee>as a kid you bought fruit/veg/meat by the pound, but the law now requires it's sold in kilogrammes
20:20<MrGandalf>gbee: sometimes I get the feeling we're falling behind the rest of the world.
20:20<Anduin>gbee: We only reliably measure our bulk soda with metric
20:21<gbee>still using miles instead of kilometres though, at least for road signs
20:21<MrGandalf>gbee: what country?
20:21<MrGandalf>really.. I would have thought kilometres.
20:22<gbee>s/metric at home/metric at school/
20:23-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
20:23<gbee>nope, kilometres/kph on the continent but miles/mph in the UK
20:24<MrGandalf>that could get confusing I suppose
20:25<gbee>it's only really used on the road network, UK mapping is done on a KM grid and products are sold with their dimensions given in centimetres/metres etc
20:26<MrGandalf>I see
20:26<gbee>think it has two reasons, a) Drivers are used to miles, km on road and speed signs would cause problems b) The cost of replacing every sign in the country
20:26*MrGandalf really needs to see more of the world
20:27<MrGandalf>true, bound to happen at some point though and probably long before the US does.
20:27-!-xris [] has joined #mythtv
20:31-!-purserj [] has quit [Read error: 113 (No route to host)]
20:33-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
20:34<xris>pretty hdhomerun... now if only it was MINE so I could do more than stare at it in its box....
20:36-!-rn114__ [] has quit [Read error: 113 (No route to host)]
20:37-!-purserj [] has joined #mythtv
20:39<xris>was hoping it would come without shrinkwrap so I could play with it for a few days...
20:39<xris>then I'd know if it'd be worth the $200 to get one of my own.
20:48-!-Tanthrix [] has quit [Read error: 110 (Connection timed out)]
20:49<danielk22>xris: it came in shrink wrap? they must be moving some volume now then.. mine came in cardboard box...
20:50<xris>shrink wrapped box
20:50<xris>not bubble pack
20:50<xris>or whatever those plastic pack things are called
20:51<xris>I could probably open it with the end recipient being none the wiser, but I figure I probably shouldn't...
20:51-!-iamlindoro_ [] has joined #mythtv
20:51<danielk22>the ones that require tin snips to open?
20:51<danielk22>or the ones scissors can open?
20:52<xris>this is just like saran wrap
20:53<danielk22>ah, ok -- not what I was thinking of then.. this is just packing material in case it's raining when delivered..
20:53<xris>it's to prevent theft when sitting on retail shelves.
20:54<xris>well, deter... can't just open the box and grab the thing out of it... have to leave an obviously-tampered-with box.
20:54<knowledgejunkie>gbee: thanks for #4789
20:55<xris>knowledgejunkie: I was playing with the channel icon stuff yesterday.. should be EASY for me to add UK icon info to the database, but was hoping we could do something more than a plain csv file
20:55<GreyFoxx>xris: Weird. I see it says it's falling back to X11 output, but otherwise my main thought ius to try updating svn to get avoid doing the DoFastForward I had added to seek the the start of the video
20:55<knowledgejunkie>xris: how'd you like it?
20:55<GreyFoxx>apparently a couple people were having problems from it
20:56<GreyFoxx>but the changes made last night have taken care of the problem so it's not needed anymore
20:56<xris>knowledgejunkie: for the sweden icons, I just grab directly from the website their xmltv guys use as a master.. but I suspect that isn't good enough.
20:56<xris>er, wouldn't work for you
20:56<xris>is it in the xmltv source anywhere?
20:56<xris>ok, I'll re-compile
20:57<xris>was trying to see if maybe I was missing a qt package, but it looks like I have everything I can think of that would matter. and version 3.3.8b
20:57<gbee>info is on, no?
20:57<knowledgejunkie>the icons are in the channel_ids file distributed with the source (get out of date), but also available online at which is updated whenever I put changes through
20:58<knowledgejunkie>that way you could key against XMLTV ID
20:59<xris>I'll see what I can do to update the scanner script.
20:59<knowledgejunkie>should keep things bang up to date
21:00<gbee>is anyone going to diff trunk/fixes to get for anything that was missed?
21:01<gbee>xris: can probably use and
21:01<xris>gbee: cool
21:01<gbee>format varies unfortunately, but easily parseable with
21:02<gbee>a script + cron job
21:03<xris>yeah, I think I already have portions grabbing stuff like that from the xmltv source
21:03<xris>but that source isn't on the mythtv server
21:04<xris>sound familiar?
21:05<xris>dir == 'au','be','it','de_tvtoday','ch'
21:05-!-purserj [] has quit [Read error: 110 (Connection timed out)]
21:06<gbee>in future most/all of that stuff should end up here:
21:06<gbee>where it will be updated more frequently than the distributed source
21:07<gbee>though it's the same as what appears in SVN, those files are pulled from SVN nightly
21:07<gbee>tvtoday is dead iirc
21:10<xris>easier for me to grab from a web page than pull source to the mythtv webserver, too
21:11<gbee>shame there isn't a more consistent format to channel_id files and that not all grabbers include icon information
21:11<gbee>I'm off to bed
21:13<xris>looks like lots of those don't have icon URLs
21:14<knowledgejunkie>xris: au is also broken
21:14<xris>oh, looks like my initial xmltv scanner only grabs the xmltvids, not the icons.
21:14<xris>I'll update accordingly
21:16<knowledgejunkie>you can also close off #4435 against the update
21:18<Chutt>note: when making hot cocoa mix, and following the good eats recipe, go easy on the cayenne
21:19<knowledgejunkie>xris: with the uk_rt scanner, you can avoid adding entries where the channel name includes "Do Not Use" - I've flagged these manually as bad and they won't get presented at XMLTV config time either
21:19<xris>cayenne + grapefruit is tasty, too
21:19<Chutt>xris, this is a _bit_ much
21:19<sphing>xris: you said you're in Seattle with HD over Firewire?
21:19<Chutt>i put in slightly more than the called for pinch, though
21:19<xris>knowledgejunkie: so it's: xmltvid | what? | station name | icon ?
21:19<xris>sphing: yes
21:20<sphing>xris, which provider? do you get NBC 5c'ed?
21:20<xris>just about everything is 5c'd.. but clear over firewire.
21:21<xris>I don't know which station is nbc, though...
21:21<knowledgejunkie>xris: xmltvid | Radio Times internal ID | station name | icon |timeshift offset | broadcast hours
21:21<sphing>hmm, NBC locks up the backend for me
21:21<sphing>I'm also in seattle
21:21<xris>knowledgejunkie: thanks
21:21<xris>you think that's standard for the other icon grabbers, too? probably not...
21:21<knowledgejunkie>xris: i guess you only need worry about fields #1 and #4?
21:21<sphing>err: locks up in that it doesnt record and needs manual invention to fix, not that it crashes
21:22<knowledgejunkie>xris: it's not a standard - per-grabber configs I think
21:22<xris>sphing: dunno. I get all KINDS of trouble with firewire.. fedora bug.
21:22-!-Tanthrix [] has joined #mythtv
21:22-!-purserj [] has joined #mythtv
21:22<sphing>to be honest, its REALLY stable for me, when I don't go to a 5c'ed channel
21:23<knowledgejunkie>xris: going back to the 'bad channels' - I prepended "blank." to the beginning of the bad channels' XMLTV IDs, so you could just avoid those and not worry about checking the channel names
21:25<xris>sphing: I think I've had issues with 105 in the past, but I don't actually watch that much HD (no hdtv)... hd theatre, foodtv, scifi hd all seem to work, so that's what I care about. heh
21:25<knowledgejunkie>should help to keep the DB clean
21:26<sphing>hmm, food,sci, or theater dont work for me
21:26<sphing>basically only the QAM channels work for me :(
21:28<xris>using firewire?
21:30<sphing>are you broadstripe?
21:34<sphing>cable provider?
21:37<xris>no, comcast
21:40-!-|gunni| [] has quit ["KVIrc 3.2.4 Anomalies"]
21:40-!-purserj [] has quit [Nick collision from services.]
21:42-!-purserj [] has joined #mythtv
21:48<xris>knowledgejunkie: you don't happen to know the line format for the FR/BE ones, do you?
21:49<knowledgejunkie>xris: can find out for you - back in a few minutes
21:51-!-iamlindoro [] has joined #mythtv
21:52<xris>looks like xmltvid:callsign:channame:icon
21:55<knowledgejunkie>xris: for channel_ids_fr (colon delimited) fields are -> XMLTV ID : Internal ID : channel name : icon URL (without http://) : additional text
21:57<knowledgejunkie>xris: the previous channel_ids_fr entry is for tv_grab_be. the grabber's other file (channel_ids_nl) has the exact same format as channel_ids_fr
21:57<xris>except that there are no names
21:57<xris>but I don't use that field, anyway
21:59<rooaus>Any chance of #4074 being included before 0.21 is cut? It is a trivial patch to remove the permanently disabled (not implemented) "Create Audio CD" button in a mythmusic popup.
22:00<knowledgejunkie>xris: looking at the file on, the only files containing icon URLS are tv_grab_be, tv_grab_uk_bleb (non Lyngsat icons) and tv_grab_uk_rt
22:02-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
22:02-!-purserj [] has quit [Nick collision from services.]
22:04-!-purserj [] has joined #mythtv
22:06-!-mzb [] has joined #mythtv
22:20<Deek>heh, reading scrollback reminded me of a traffic sign
22:28-!-m00db00m [] has quit [Remote closed the connection]
22:39-!-JoeBorn [] has joined #mythtv
22:49-!-cattelan [] has joined #mythtv
23:15-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
23:19-!-flynch [] has joined #mythtv
23:25<flynch>appologies in advance for a stupid question, but I beleive that mythmusic in svn integrates with a music streaming solution like jinsora, can anyone tell me what it is.. I'm drawing a blank right now
23:26<Anduin>#4687 seems to be extradata related, I thought that stuff was being bumped as the first fix attempt made things worse
23:43<Chutt>Anduin, close it as a dupe, then?
23:44-!-flynch [] has left #mythtv []
23:44<Anduin>I would, maybe gbee or danielk22 think it should stay open though.
23:53<Chutt>i don't think it's been looked at
23:55-!-JoeBorn [] has joined #mythtv
---Logclosed Sat Mar 08 00:00:40 2008