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

---Logopened Mon Mar 03 00:00:26 2008
00:11-!-samhain` [] has joined #mythtv
00:11<samhain`>is there a way to turn off live tv record....disable rewind, ff,etc.
00:36<dekar1>samhain, what would that be good for? And see topic
00:36-!-foo8ar_ [] has quit []
00:36-!-dekar1 is now known as dekarl
00:39-!-samhain` [] has left #mythtv []
01:01-!-feiner_ [] has joined #mythtv
01:02-!-feiner [] has quit [Read error: 104 (Connection reset by peer)]
01:03-!-gnome42 [] has quit [Remote closed the connection]
01:09-!-t0ny-p40 [n=t0ny-p40@] has left #mythtv ["Leaving"]
01:13-!-JoeXBorn is now known as JoeBorn
01:33-!-loops [] has quit [Remote closed the connection]
01:38-!-superm1 [n=superm1@ubuntu/member/superm1] has quit ["Leaving"]
01:56-!-clever[rev] [] has quit [Read error: 110 (Connection timed out)]
02:01-!-clever[rev] [] has joined #mythtv
02:01-!-grokky_ [] has quit [Read error: 110 (Connection timed out)]
02:02-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
02:04-!-onixian [n=xian@] has joined #mythtv
02:07-!-xris [] has quit []
02:23-!-xris [] has joined #mythtv
02:34-!-loops [] has joined #mythtv
02:44-!-onixian [n=xian@] has quit [Read error: 110 (Connection timed out)]
02:52-!-clever[rev]_ [] has joined #mythtv
02:53<clever[rev]_>thanks for the spam, spam bot!
03:04-!-clever[rev] [] has quit [Read error: 110 (Connection timed out)]
03:23-!-fstxx [] has quit [Read error: 110 (Connection timed out)]
03:46-!-mykeul [n=mykeul@] has joined #mythtv
03:58<Deek>new vendor ID for DCT-6200: 195e
04:02-!-Dibblah [] has joined #mythtv
05:14<gbee>Deek: open a ticket, easy to overlook the info here
05:27<eharris_>Captain_Murdoch: great. Hadn't found those yet. I will definitely look at it.
05:31<anykey_>anyone seen rev 16312 backend crashes when surfing channels? I've got three backends here, one crashes immediately when going into LiveTV, the other two after zapping through about 3 channels.
05:36-!-onixian [] has joined #mythtv
05:39<gbee>anykey_: seems to work just fine here
05:40<anykey_>gbee: seems to be something with encrypted channels
05:40<anykey_>gbee: With a CI/CAM of course
05:49<anykey_>gbee: I'm going to get a backtrace
06:29-!-jarle [] has quit [Read error: 110 (Connection timed out)]
06:29-!-Dibblah [] has quit [Read error: 104 (Connection reset by peer)]
06:32-!-Dibblah [] has joined #mythtv
06:33-!-jarle [] has joined #mythtv
06:50-!-MrGandalf [] has quit ["work"]
06:59-!-onixian [] has quit [Read error: 113 (No route to host)]
07:08-!-onixian [] has joined #mythtv
07:09-!-adante [] has joined #mythtv
07:14-!-loops [] has quit [Remote closed the connection]
07:15-!-clever[rev]_ is now known as clever[rev]
07:17-!-TelnetManta [] has quit ["Ex-Chat"]
07:24-!-loops [] has joined #mythtv
07:39-!-renatofilho^ [n=renato@] has joined #mythtv
07:43-!-aeha [] has left #mythtv []
07:46-!-lsobral [n=sobral@] has joined #mythtv
07:47-!-mzb [] has quit [Read error: 113 (No route to host)]
08:02-!-xian__ [] has joined #mythtv
08:10-!-onixian [] has quit [Read error: 113 (No route to host)]
08:25-!-aeha [] has joined #mythtv
08:37-!-TelnetManta [n=benwilli@] has joined #mythtv
08:38-!-coolmcgrrr [] has joined #mythtv
08:39-!-coolmcgrrr [] has left #mythtv ["Konversation terminated!"]
09:03-!-Viiru [] has quit [Remote closed the connection]
09:05-!-Viiru [] has joined #mythtv
09:11-!-padrino_ [] has quit [Read error: 113 (No route to host)]
09:29-!-janneg [] has quit [Remote closed the connection]
09:37-!-moodboom [] has joined #mythtv
09:39-!-janneg [] has joined #mythtv
09:39-!-janneg [] has quit [Client Quit]
09:39-!-janneg [] has joined #mythtv
09:45-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:46<Cardoe>well I took the plunge last night and upgraded my 0.20.x to 0.21
09:46<Cardoe>everything went smooth
09:46<Cardoe>font size changed to something smaller
09:47<Cardoe>and the sound is out but I'm thinking something got muted (I was trying to test it while the fiancee is telling me it's time for bed)
10:00<janneg>Cardoe: I've fixed -mtune vs -mcpu in trunk, I'll merge it to 0-21-fixes tomorrow
10:02<sphery>Cardoe: Font size changed because Myth now normalizes font sizes appropriately and no longer depends on a 100x100DPI X setup. Before, your X wasn't at 100x100DPI.
10:14-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
10:18-!-gnome42 [] has joined #mythtv
10:22<superm1>sphery, interesting. so maybe the workaround in our gdm-cdd.conf can be ditched then
10:31<Cardoe>superm1: you guys use gdm to login?
10:32<superm1>because then existing ubuntu setups can easily switch
10:32<superm1>and because it works well and is themeable
10:32<superm1>has a failsafe mode if people need it
10:32<laga>because it's so sweet when people complain that "gdm is not needed on a appliance"
10:32<Cardoe>gtk+ and such is a pretty heavy depend
10:33<superm1>well our control centre is already gtk+
10:33<superm1>and so is xfce
10:33<laga>Cardoe: mythbuntu uses xfce4 etc, which also uses gtk
10:33<superm1>so it's not like most of it won't already come from that
10:34-!-leprechau [] has quit ["Leaving"]
10:35<sphery>superm1: Should be possible to get rid of it. The only requirement is that the aspect ratio must be properly specified (but the DPI can be anything, so long as it's proportional to the "real" value). This also means that Myth 0.21 should work better for users with 16:10 displays or for users without square pixels.
10:35<Cardoe>sphery: Any fix for the issue that the config windows span off the edge of the screen?
10:35<superm1>sphery, i'll do some experimentation on my tv and see how other applications that normally run look too then
10:36<Cardoe>but playback and media library etc are fine
10:36<Cardoe>just the setup windows
10:36<sphery>Cardoe: That one requires modification of the setup stuff. Should get fixed when setup moves to mythui (post 0.21 ;).
10:37<Cardoe>I've heard that before.
10:37<Cardoe>Since like 0.16 ;)
10:37<sphery>IIRC, there are some issues with 800x600 or smaller displays. I plan to look into that this week and post some patches if required (I think those are only in the frontend settings). The mythtv-setup stuff is just trying to cram too much on one page, so with overscan, etc., it doesn't always fit.
10:38<Cardoe>this is a 720p widescreen LCD TV
10:38<sphery>Are you underscanning the signal to compensate for the TV's overscan?
10:39<sphery>Otherwise, it's probably just drawing, i.e. Back/Next/Finish buttons outside the visible area.
10:39<Cardoe>if it is, it's something myth did on it's own
10:39<Cardoe>the back/next/finish are mostly visible
10:39<sphery>We didn't build in a safe-action area or anything in mythtv-setup.
10:39<Cardoe>the issue are the checkboxes on the left hand side
10:39<Cardoe>they're way off the edge
10:39<Cardoe>so no idea if something is checked or no
10:39<superm1>i've seen that happen too in VM installs
10:40*laga too on his 720x576 TV
10:40-!-xian__ [] has quit ["This computer has gone to sleep"]
10:40<sphery>I'll watch for it when looking over the settings/mythtv-seutp stuff. Wild guess... Could it be something to do with the QT theme? Did you try changing QT themes (in Myth's settings).
10:41-!-onixian [] has joined #mythtv
10:42<Cardoe>i.e. Desktop, Windows, etc?
10:44<Cardoe>because that entry field has been blank for as long as I can remember
10:44<sphery>Sounds right. It's the setting called "Qt Style". I'm using platinum (seems most visible).
10:44<Cardoe>don't think I have a platinum choice but I'll double check during lunch (about 2 hrs from now)
10:46<sphery>Hmmm. Noticed on my backend (never configured as a frontend), it defaults to blank. Looking at the code to see what that does.
10:47-!-jamesd [] has quit [Remote closed the connection]
10:47-!-leprechau [] has joined #mythtv
10:49-!-onixian [] has quit ["This computer has gone to sleep"]
10:51<sphery>Cardoe: Seems that blank causes Myth to use whatever QT's default style (on the system) is. I forgot the name of the program you use to set the style for QT, but you could use that to set a system-wide default.
10:52-!-JoeBorn [] has joined #mythtv
11:02<sphery>Cardoe: It's the aptly-named qtconfig. (Unless kcontrol is more appropriate--though that may only affect QT4 on modern systems.)
11:05-!-prg3 [] has joined #mythtv
11:10-!-beavis_ [] has joined #mythtv
11:17-!-leprechau [] has quit [Remote closed the connection]
11:19-!-foo8ar [] has joined #mythtv
11:26-!-PointyPumper [n=pintlezz@] has joined #mythtv
11:26-!-rinaldi_ [] has joined #mythtv
11:33-!-JoeBorn [] has quit [Read error: 110 (Connection timed out)]
11:36-!-xris [] has quit []
11:42-!-grub [] has joined #mythtv
11:47-!-rinaldi_ [] has left #mythtv []
11:51-!-foo8ar [] has quit [Read error: 110 (Connection timed out)]
11:52<Cardoe>sphery: you realize I remember when 0.17 was suppose to be a release where the only changes were to mythui
11:53<briand>i just woke up from a coma -- is 0.21 out now?
11:54<GreyFoxx>within the next few days/week
11:54<Cardoe>sphery: but I've also been saying since like 0.12 that I really need to find some more time to dedicate to MythTV stuffs
11:55<briand>tnx, GreyFoxx ...
11:55<briand>I've been consumed playing with my new internet tablet (n800).
11:56<briand>and, despite all my b*tch*ng about uPnP in the past, I was quite amazed to see my mythtv box show up under the "Shared Media" folder in the file manager.. and let me stream video or audio to the n800.
11:56<beavis_>Active tickets:
11:56<beavis_> 71
12:01<GreyFoxx>briand: heh
12:02<GreyFoxx>Assuming noone complains I'm gonna commit a change to allow seeking in mkv/mov/mp4 files which shouldn't affect playback of anything else
12:03<GreyFoxx>The "hack" as I prefer to call it rather than fix only comes into play in situations where we had seeking failues before anyway
12:03<GreyFoxx> for anyone who wants to try it on recent svn
12:06<gbee>Cardoe: of course nothing is guarenteed when it comes to MythTV, with few devs and even little time it's suprising the work which does get done, but I've set my heart on eliminating as much old ui code as I can for 0.22
12:08<Deek>gbee: OK, ticket 4833 made
12:08-!-dekar1 [] has joined #mythtv
12:08<gbee>I think we'd all like to aim for a quicker release cycle too, though the bigger MythTV gets the harder that becomes
12:09<gbee>tempted to close #4828 simply because the code isn't going to exist in 0.22 (hopefully)
12:13<Deek>looking fwd to 0.21, just ran into the "mythtranscode dies on discontinuity" bug
12:23-!-onixian [] has joined #mythtv
12:24-!-dekarl [] has quit [Read error: 113 (No route to host)]
12:35-!-onixian [] has quit ["This computer has gone to sleep"]
12:38-!-feiner_ [] has quit [Read error: 104 (Connection reset by peer)]
12:48-!-MrGandalf [] has joined #mythtv
12:50-!-Netsplit <-> quits: prg3, mace, kurre2, purserj, meshugga, Vaelys, Snow-Man
12:51-!-Netsplit over, joins: prg3, purserj, kurre2, meshugga, Vaelys, Snow-Man, mace
12:52-!-feiner_ [] has joined #mythtv
12:58-!-xris [] has joined #mythtv
12:58<MrGandalf>So, who is Erik Hovland?
12:59-!-grub [] has quit [Remote closed the connection]
13:02<Deek>hmm, would it theoretically be possible for a myth .nuv to contain an a52 (or some other 6+-channel) stream?
13:05<Deek>Don't really care if it can be done now, it's enough to know I wouldn't be wasting my time looking into it. :)
13:09-!-mykeul [n=mykeul@] has left #mythtv []
13:10<gbee>Deek: for what purpose?
13:12<Deek>6-channel HDTV recordings lose 4 of them on transcode to .nuv
13:15<gbee>just to be clear, why are you transcoding them? To remove commercials or to reduce their size?
13:16-!-robthebob [] has joined #mythtv
13:17<Deek>To just get rid of commercials, I could do an autodetect xcode -- but I'd also like to convert 1080-30i to 720p-24
13:18<gbee>yeah, which is what I was wondering really - ok :)
13:18<gbee>fwiw I don't really know anything of the NUV container but in theory I don't see why it should have a problem
13:18<Deek>(while keeping it as a recording instead of a video)
13:19<gbee>although maybe at some point we might switch containers to something that is more universally recognised (not my department since I don't use NUV at all)
13:22-!-aevil [] has joined #mythtv
13:23<sphery>Deek: I think Captain_Murdoch has started working on the idea of allowing the transcoder to transcode to any ffmpeg-supported format (for CODEC's, at least, but I know he's planning to allow some other container formats, too).
13:39<sphery>Looks like #4787 is invalid. We have code (since r12151--initial SG commit) that checks if a storage group directory is writable (at libs/libmyth/storagegroup.cpp +277 ) and it still works (shows an error upon exiting mythtv-setup and asks if the user wants to fix it). Sent an e-mail to the -dev list (BCC'ed reported)--I think he ran mythtv-setup and mythbackend as different users.
13:40-!-jgarvey [] has joined #mythtv
14:13<akv>superm1: you there?
14:14-!-robthebob [] has quit [Read error: 104 (Connection reset by peer)]
14:14-!-rn114 [] has joined #mythtv
14:16<gbee>anyone know if we keep track of the display aspect as determined from displaysize in a global method or as a setting?
14:20<gbee>Chutt: are we sticking to MyISAM or is there a chance that we could migrate to another more capable engine, such as InnoDB? or even a mix of types?
14:21*MrGandalf votes for a mix
14:22<sphery>I know a lot of users have converted their systems to use InnoDB (and possibly others).
14:23<MrGandalf>You're talking about in the CREATE, not converting existing I hope
14:25<sphery>If we put it in the CREATE, we'll probably have problems from users whose MySQL is compiled without InnoDB support (as in the ticket gbee must be looking at) unless we say that MySQL 5.x with InnoDB storage is a requirement for Myth.
14:25<MrGandalf>And why the push for InnoDB?
14:26<gbee>MrGandalf: if we are to use things like foreign keys then we'd had to convert tables to innodb
14:26<MrGandalf>I see
14:26<MrGandalf>just easier to manage MyISAM (from a single table restoration perspective)
14:26<gbee>and it's not that I'm especially pushing for it, even though I like the idea, I'm really just trying to decide whether it's a good use of my time to convert mythweather to use MyISAM instead
14:27<stuarta>however InnoDB should give us protection from things like the corruption of the seektable
14:27<MrGandalf>the seektable gets corrupt? I wasn't aware of that
14:27<gbee>yeah, InnoDB has a lot going in it's favour
14:27<MrGandalf>could explain some things
14:27<sphery>And row-level locking...
14:28<stuarta>MrGandalf: normally pops up in -users as "I can't seek"
14:28<stuarta>generally cause they've crashed their database sometime
14:28<MrGandalf>stuarta: get the same issues at times.. tend to ignore them though or rebuild
14:28<Deek>or in logs as "error deleting seektable"
14:29<sphery>Though MyISAM is supposed to be faster (barring locking issues due to table-level locks), so for those whose systems are already on the verge of MySQL collapse...
14:29<stuarta>hey i've got a few recordings atm that give me grief since i crashed my db
14:29<stuarta>commflag --rebuild doesn't work for them, tho transcode --buildindex seems to
14:30<gbee>for me, the main reason for switching to InnoDB would be foreign key contraints - which might not be entirely necessary for MythTV since orphaned records aren't a huge problem but it's still useful enough that it's worth consideration
14:31<gbee>sphery: that's why I'd use a mix - MyISAM for those tables where fast queries are a must-have and InnoDB where data integrity is more important
14:32<sphery>I'm happy either way. I don't have any of the DB performance issues that people on -users list seem to (even with MySQL defaults). :)
14:32-!-gezb [] has joined #mythtv
14:32<gbee>but I think we'd get more mileage from a review of queries and optimisations than keeping MyISAM over InnoDB
14:33<gbee>MyISAM _is_ faster, but not in a way which would have a major impact on performance of a MythTV system IMHO
14:33<sphery>Yeah. And modifying those queries to take advantage of MySQL 5 features (and possibly even storage-engine features), would probably help a lot, too.
14:34<MrGandalf>anything to speed up EIT I'm in favor of..
14:34<gbee>there was a ticket just today pointing out an indexing fault which caused slowdowns (not confirmed it yet)
14:34<sphery>Though going to the embedded DB makes it a lot easier to dictate configuration... :)
14:35<gbee>sphery: aye, just more work overall even if it's the preferred long term goal
14:37<gbee>right now I'm having to be realistic about what I'm able to do in the next few weeks/months, so I'm ditching tickets so that I can concentrate on the tasks I'm most interested in seeing completed for 0.22
14:37<MrGandalf>gbee: you have a ticket number?
14:38<MrGandalf>#4820 looks very interesting
14:39<gbee>MrGandalf: sorry, wasn't a ticket after all but a post to the -dev list "Index on programrating table on system column - why?"
14:40<gbee>#4820, at least the last post to that ticket looks related to the changes that danielk22 decided to revert
14:42<sphery>gbee: Right. I also saw a conversation in -users that's almost definitely related.
14:42<sphery>I'm starting to think danielk22 may be planning to modify the code rather than a revert (since it hasn't been reverted, yet).
14:43<gbee>dunno, think it should be reverted until a better fix is ready since so many people are starting to use trunk in the run up to 0.21
14:44<sphery>I considered reverting it in my personal tree, but haven't (and haven't had issues, yet).
14:45<gbee>neither have I, but I might revert it just to be safe
14:47<gbee>wouldn't mind if "record in this timeslot" was more flexible and recorded any showing that was within an hour or two
14:56<sphery>Interesting... In mythtv-setup, when loading the video source configuration info (takes a while to find SD lineups), the main menu screen is partially visible. The first time, only the clock part of it is, then after, all of it except the part covered by a little dialog ("Fetching lineups from Schedules Direct...").
14:56<sphery>Probably not worth "fixing."
15:03<Cardoe>so is MythAppearance gone for 0.21?
15:03<Cardoe>that's in trunk for 0.22?
15:03<GreyFoxx>Merged into the main app, so yeah
15:03<Cardoe>so it's not a plugin at all then
15:03<GreyFoxx>not anymore
15:04<sphery>It's under "Screen Setup Wizards" in Utilities/Settings|Setup
15:07<sphery>Nice. I don't see any locations in mythtv-setup or mythfrontend settings where the screen doesn't fit in 800x600. Guess someone fixed the broken areas in the last couple of months.
15:08<sphery>Though, Cardoe, we still draw the Cancel/Back/Next buttons and some of the text (mainly headings) right up to the edge of the window (which might be overscanned offscreen).
15:09<Cardoe>sphery: my issue are the checkboxes
15:10<sphery>Did you get to try a different QT theme/style?
15:15-!-rn114 [] has quit [Read error: 113 (No route to host)]
15:15-!-rn114__ [] has joined #mythtv
15:17-!-jamesd [] has joined #mythtv
15:24<MrGandalf>Um, DummyVideo aspect ratio, it defaults to 1.3333 (4/3). Shouldn't that instead use whatever XineramaMonitorAspectRatio is set to?
15:24-!-_gunni_ [] has joined #mythtv
15:24<Cardoe>sphery: I switched it but the frontend kept locking up with no icons or anything on it.. just the background..
15:25<MrGandalf>er, DummyDecoder rather
15:25<Cardoe>sphery: so I'll have to tinker more when I get home. I set it to Platinum
15:25<Cardoe>so mythweb's new default background is black huh
15:28<hads>It's more of a dark grey/green.
15:28<sphery>Did you try clearing your cache/forced refresh? Sounds like your CSS needs reloaded. (Mine's still dark blueish)
15:29<sphery>The grey might be a better name for it (with a dark-bluish tint, perhaps).
15:31-!-gezb [] has quit []
15:38-!-|gunni| [] has joined #mythtv
15:49-!-mattwire [] has joined #mythtv
15:52<Cardoe>is the flash player not part of the default mythweb?
15:53<laga>Cardoe: you have to enable it somewhere IIRC
15:54-!-_gunni_ [] has quit [Read error: 110 (Connection timed out)]
15:55<sphery>Cardoe: It's not supported since it's a proof of concept and will only work in certain cases, so xris disabled it for the release. So, basically, it shouldn't be listed in the 0.21 What's New... :)
15:56<stuarta>unless filed under "Alpha Features"
15:58<gbee>is there any benefit to getting the display aspect once on startup (MythXGetPixelAspectRatio etc) then storing it in the database/settings cache?
15:59<stuarta>is it not kept in the gContext?
15:59<Cardoe>sphery: is there any documentation on the streaming?
15:59<gbee>nope, not as far as I can tell
15:59<Cardoe>i.e. can I pass parameter X to change the transcode on the fly parameters?
15:59<xris>Cardoe: you can enable it in the settings, but it's off by default
16:00<sphery>Cardoe: README talks a bit about streaming (but not the Flash stuff). And, README is now available through the web server. :)
16:03<Cardoe>sphery: mentions nothing about tweaking the resulting stream
16:03<Cardoe>sphery: looked at it already
16:07<Cardoe>sphery: basically can I pass command line options to ffmpeg is what I'm curious about
16:07<MrGandalf>gbee: haven't seem MythXGetPixelAspectRatio in my db.. on that topic, which aspect ratio setting is the preferred in Myth? There seem to be several.
16:08<sphery>Cardoe: Don't think so (unless kormoc recently added something for that). I think you have to edit the ffmpeg command line in the PHP source directly.
16:08<gbee>MrGandalf: no idea which is the 'correct' or preferred one
16:09<gbee>looks like we indirectly do store the physical display dimensions in mythcontextprivate, but I'm still looking into that
16:10<gbee>the XineramaDisplayAspect stuff is only used if we are using Xinerama because it's apparently not possible to query the physical display dimensions directly from X in that scenerio
16:11<MrGandalf>I just notice that was the only one set in my db.
16:12<MrGandalf>maybe AspectOverride
16:12<MrGandalf>I need to play around a bit.. hard to do that from work.
16:17<gbee>DisplayRes provides a method to get the display aspect, but that code path doesn't account for Xinerama setups, videout_xv calls on the methods in util_xv directly
16:17<gbee>so I'm not quite sure which is the 'correct' method I should use if I implement a GetDisplayAspect method in mythcontext
16:17<Cardoe>sphery: Gentoo doesn't install the README file into the web root by default.
16:17<gbee>danielk22: any thoughts?
16:18<Cardoe>sphery: Its a bit of a security issue since the current mythweb setup only allows for protecting the mythweb files and not the README
16:19-!-mattwire [] has quit [Remote closed the connection]
16:19<gbee>I'd probably move the xinerama logic from videooutput_xv into DisplayResXV and provide a method in mythcontext to get the display aspect which can then be used whereever it is required
16:19<Cardoe>xris: the auth is inside a <Files> section
16:19<xris>what does it matter if the README is exposed, though?
16:19<MrGandalf>gbee: good idea
16:20<Cardoe>xris: if a directory is suppose to be protected, nothing inside of it should return a 200
16:20<Cardoe>especially not a file that says "this is what I'm running and the exact version that I'm running!"
16:20<gbee>MrGandalf: only coincidental that I'm thinking about this, but I need something similar to create a proper fix for #4704
16:21<xris>Cardoe: or you could just tweak the defaults (which you're doing already if you're turning auth on) to cover the whole directory.
16:21<xris>mythweb specifically allows certain stuff without auth so that streaming video is more likely to work
16:22<eharris_>Captain_Murdoch: Hmm, unfortunately, your additions for
16:22<Cardoe>xris: not by default
16:22<xris>Cardoe: mythweb doesn't have *any* auth by default
16:24<eharris_>Captain_Murdoch: unfortunately, your additions for QUERY_RECORDING only appear to be in .21 and later, but not in .20-fixes.
16:25<MrGandalf>gbee: I see
16:25<MrGandalf>Who is Erik Hovland?
16:26<sphery>eharris_: Perl bindings (at least in a useful form) are only available post 0.20-fixes...
16:26-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
16:26<MrGandalf>that guy seems pretty busy..
16:26<gbee>no idea, but I wish he'd stop pushing up the ticket count for 0.21
16:26<sphery>eharris_: But no work is being done on 0.20-fixes and 0.21 will be released "soon."
16:26<stuarta>would have been nice of him to submit them *much* earlier
16:27<gbee>stuarta: aye
16:27<MrGandalf>gbee: you don't think he's doing good work?
16:27<Chutt>MrGandalf, quite a few of his tickets are bogus
16:27<Chutt>like 4841, for instance.
16:27<gbee>MrGandalf: no it's good work, if not always correct, but just causing us problems this close to a release
16:27<Chutt>or he'll fix one instance of something in a file
16:28<Chutt>and ignore another dozen of the same type of thing
16:28-!-TelnetManta [n=benwilli@] has quit ["Ex-Chat"]
16:28*MrGandalf shrugs..
16:29<MrGandalf>anyway.. that time of day..
16:29-!-MrGandalf [] has quit ["home"]
16:29<gbee>and he keeps assigning a 0.21 milestone to his tickets - we're upto 80 now which is where we were a month ago
16:31-!-val-at-ofc [i=scott@pdpc/supporter/monthlygold/vallor] has joined #mythtv
16:31<Dibblah>I'm wondering if this is a harvest of some sort of automated toolset on Myth...
16:31-!-val-at-ofc [i=scott@pdpc/supporter/monthlygold/vallor] has left #mythtv ["Leaving"]
16:31<gbee>is no-one maintaining libdvdnav anymore? half of his tickets have been addressing problems in that library which really should have gone upstream
16:32<eharris_>sphery: since .21 isn't released yet, most people aren't running it. And since .21 doesn't seem to have backwards compatible protocol, means I'll probably have to hack around it manually.
16:32<Cardoe>gbee: wasn't there a fork?
16:32<Chutt>Anduin, #4361?
16:32<gbee>Dibblah: I strongly suspect that
16:32<sphery>eharris_: Or wait a short bit...
16:32<Cardoe>eharris_: which distro are you on?
16:32<eharris_>Cardoe: I've been on knoppmyth for a long time.
16:32<gbee>Cardoe: dunno, which is why I asked - our version of dvdnav is modified but not massively
16:32<Cardoe>eharris_: grab one of their betas
16:33<Anduin>Chutt: Yeah, still needs one more checkin
16:33<Chutt>Anduin, ok
16:33<Chutt>just going through..
16:33<janneg>mplayer forked libdvdnav, original upstream is dead
16:33<Anduin>Chutt: Should be closed today
16:34<sphery>I think that the "Qt Style" StyleSetting's use of "" as the default style ( programs/mythfrontend/globalsettings.cpp +2846 , label="Desktop Style" and value="") is broken.
16:34<eharris_>Cardoe: I'd be happy to upgrade my frontends to a beta, but I don't trust a beta for the backends. At least not yet.
16:34<sphery>It results in writing the translated label to the DB since ComboBoxSetting::addSelection() (via SelectSetting::addSelection()) copies label to value if value.isEmpty(), rather than using a check for QString::null, as in SelectManagedListItem::addSelection(), for example.
16:34<eharris_>and since the stuff I need to do is on backend, I'm stuck.
16:34<sphery>eharris_: all or nothing, anyway (can't do only frontends)
16:35<eharris_>sphery: yeah. Too bad.
16:35<stuarta>it's better than 0.20 was
16:35<Cardoe>I'm going to agree with sphery here about the broken-ness
16:35<eharris_>be really nice if more attention was paid to backwards compatibility.
16:35<Cardoe>sphery: like I said, I'll confirm it tonight
16:36<gbee>eharris_: if we had a team of 100 ...
16:36<Cardoe>sphery: using qtconfig.. I don't see "Desktop Style" as a valid choice.
16:36<eharris_>gbee: Oh, I'm not complaining, just wishing.
16:36<gbee>eharris_: I've been running trunk for two years on a production machine, except for one little blip in current trunk caused by a hurried fix it's been more stable than any other version
16:37<sphery>So, if I write a patch to fix the StyleSetting default (i.e. to something like "UseSystemDefaultDesktopStyle" for the value), is it OK to ignore cleaning up the DB (i.e. trying to replace the translated string in the DB)?
16:37<sphery>Just let users change it through the Appearance settings...
16:38<eharris_>gbee: well, maybe I'll grab another disk and attempt an upgrade some night this week. Has the protocol been locked yet for the upcoming .21 release?
16:39<Cardoe>sphery: ~/.qt/qtrc is where style= resides
16:39<gbee>eharris_: yes, unless a fix demands a protocol bump
16:39<Cardoe>sphery: leaving it blank does weird things
16:40<Cardoe>sphery: "Desktop Style" does the same weird things
16:40<Cardoe>CDE, Motif, MotifPlus, Platinum, SGI, Windows are valid
16:40<Cardoe>and it appears if you have kdebase installed, Plastik is valid too
16:41<Cardoe>gbee: didn't xine fork libdvdnav?
16:42<Cardoe>gbee: and mplayer as well.. I think they have their own forks..
16:43<eharris_>Cardoe: I'm having trouble locating a source for a knoppmyth beta. Do you happen to know where that is?
16:43<janneg>Cardoe: and so did we
16:44<Cardoe>janneg: right but gbee was saying the tickets should be submitted upstream but I'm saying upstream is dead.. it depends who's fork you want to follow..
16:44<sphery>We have code that checks for "" and does not call qApp->setStyle(style) to allow the user to use the system-defined default (i.e. from ~/.qt/qtrc or wherever), but style will /only/ be "" if there is no value "Style" in the DB--which won't happen with the way we currently set default values for missing "important" stuff and with the broken StyleSetting.
16:46<gbee>Cardoe: I said they should be submitted upstream if it was still maintained, which apparently it isn't
16:46-!-|gunni| [] has quit ["KVIrc 3.2.4 Anomalies"]
16:46<Chutt>gbee, there, 58.
16:46<sphery>(actually, won't happen in mythfrontend, might happen in mythtv-setup, but only until mythfrontend is run)
16:48<Cardoe>sphery: well then that sounds like the bug I've tripped over.
16:48-!-mattwire [] has joined #mythtv
16:48<sphery>Yeah. You're the reason I found it. :) Thanks, BTW.
16:49<gbee>Chutt: heh
16:50<Chutt>more of the other bugs could be moved as well
16:50<xris>Chutt: so has there been any serious thought about summer of code?
16:50<Chutt>i'm not wasting time on it
16:52<xris>on SoC, or was that for the other conversation?
16:52<Chutt>on soc =)
16:52<Chutt>gbee, someone needs to email him and say 'don't touch the milestone'
16:52<xris>wondering I could submit mythweb as its own project. heh
16:52<Chutt>i doubt it's big enough
16:53<xris>heh. might be enough to pull a single project.
16:53<xris>I have at least 2 things that could benefit from it. the more interesting one I think would be a complete rewrite of the music portions.
16:54<xris>the other one I've been thinking about would be a from-scratch rewrite of the video player... add some more tools, etc.
16:54<Chutt>gbee, #4350? (backend @100% cpu bug)
16:54<xris>Chutt: it's fixed
16:54<Chutt>bug's still open
16:54<xris>we don't know how/why, though
16:56-!-mattwire [] has quit ["Leaving"]
16:56<sphery>#4787 is invalid (see ). Almost 100% sure it was user error.
16:56<sphery>It definitely worksforme
16:57-!-beavis_ [] has quit ["Verlassend"]
16:59-!-JoeBorn [] has joined #mythtv
16:59<Chutt>most of these tickets are fairly innocuous
16:59<Chutt>i'll do a larger scrub this evening
16:59<janneg>xris: even after deleting all previews and mythweb's cache? if someone can confirm please close the bug
16:59<gbee>Chutt: I've been told by three/four different people that 4350 is fixed but I'm not sure I believe it, I'm not aware of any changes which could explain why it's no longer reproducable
17:00<gbee>I've been meaning to test it myself and maybe I'll get around to that tomorrow
17:00<Chutt>i'd like to release friday night.
17:01<gbee>works for me, I've a light workload at the moment and will give over a couple of afternoons this week to closing my remaining 0.21 tickets
17:02<sphery>I was affected by the 100% CPU thing. I have 3 hours 'til my next recording, so I'll test it out.
17:02<gbee>I'll take a look to see what else I might help with
17:03<sphery>Definitely no problems if you have existing previews (the locale fix fixed that)
17:03<Cardoe>what version of mjpegtools do you guys use with mytharchive?
17:03-!-splat1 is now known as splAt1
17:04<Cardoe>superm1: ping
17:04<gbee>the patch attached to #4350 fixes the 100% CPU but may break other things - the fix is CDev's and his comments in the code explain the reservations with the approach
17:07-!-jgarvey [] has quit [Read error: 110 (Connection timed out)]
17:07-!-jgarvey [] has joined #mythtv
17:13-!-aevil [] has quit [Read error: 110 (Connection timed out)]
17:16-!-grokky [] has joined #mythtv
17:22<Cardoe>sphery: so it appears it hangs if the frontend encounters a backend with a different protocol..
17:23<Cardoe>maybe a popup could show on the frontend saying that?
17:23-!-splAt1 is now known as splat1
17:23<sphery>It should exit the frontend
17:23<sphery>(should means how it was designed to work)
17:24<Cardoe>which isn't too terribly informative...
17:24<sphery>It logs a message, which may not be visible to the user, so a dialog would probably be good, but it shouldn't hang (just looking for verification).
17:24<Cardoe>it appears it did exit
17:25<Cardoe>it just hung for a bit with just a background
17:25<Cardoe>before it did finally exit
17:25<sphery>I'll look into doing a patch that shows a dialog.
17:26<sphery>We actually have dialogs with the backend and mythtv-setup (because of the UPnP autodetection stuff), but since the frontend is not allowed to upgrade the DB, anymore, we just exited there.
17:29<sphery>gbee: Well, it took forever, but my 2 backends were able to completely regenerate the previews for my 436 shows after an rm /path/to/recordings*/*.png and CPU's are back to 99.9% setiathome.
17:31<sphery>Yeah. Probably is one of those hidden issues CDev was talking about, but it's no longer triggered for some reason.
17:32-!-MrGandalf [] has joined #mythtv
17:32<Chutt>sphery, it _was_ happening before to you?
17:32<gbee>I hate closing issues when I cannot explain why they are fixed, but I'm not going to complain too much, one less headache
17:32<Chutt>i'd like to get all the major+ issues closed out
17:33<sphery>Chutt: Yeah. I locked up my system several times, so I had been commenting out the part of MythWeb that gets the thumbnails. I don't need to now.
17:33<gbee>there were some upnp related changesets which I didn't pay much attention too, possible that one of those touched the right area
17:34<gbee>sphery: can you try just deleting the mythweb cache but not the originals?
17:34<xris>I'm fine considering that one fixed, though like gbee, I'm curious to know *why* it's fixed, so we can prevent it from happening again
17:34<xris>gbee: I tried both ways
17:35<xris>wiped cache, regenerated fine.. wiped cache AND server thumbs, and regenerated fine
17:35<sphery>BTW, I never noticed mythbackend hitting 100% while generating the previews (even though my backends are Athlon XP 2000+ class) and all my recordings are HDTV).
17:35<Chutt>i'm getting lots of 'a script has konqueror to freeze' messages when using mythweb
17:35-!-jgarvey [] has quit ["Leaving"]
17:36<gbee>sphery: yeah, wasn't the actual generation causing the problem, it had something to do with the http server
17:36<xris>Chutt: fully up to date?
17:36<Chutt>and i still can't load /tv/ due to that json error =(
17:36<Chutt>xris, a day or so old
17:36<xris>I thought kormoc fixed those for you
17:37<MrGandalf>damn, db update 1210 is a killer
17:38<Chutt>yay, the recorded programs screen _does_ work.
17:39<sphery>Whew. Glad it worked for you since you moved up the schedule for your testing after my test results. :)
17:39<Chutt>it's still generating
17:40<xris>Chutt: generating with every page load?
17:40-!-foo8ar [] has joined #mythtv
17:40<janneg>MrGandalf: you could just truncate your program table, it wasn't so bad with my 80000 entries though
17:40<Chutt>still has the bug where if you move the mouse while clicking on autoexpire, you lose control of the mouse cursor, though
17:41<Chutt>xris, that's fixed as well
17:41<MrGandalf>janneg: I thought of that.. trouble it, it takes like 24 hours or more to fill it again
17:41<MrGandalf>ah well, got nothing better to do anyway
17:41<xris>mouse cursor?
17:42<Chutt>xris, it becomes unclickable on other things
17:42<sphery>xris: It doesn't regenerate ever time on my system, either (used to, though).
17:42<Chutt>busy cursor sticks around, doesn't go away unless i alt-f4 the window
17:42<Chutt>we had this discussion a few months back :p
17:43*hads remembers
17:43<hads>Happens here too
17:43<gbee>which update was 1210 then?
17:44<MrGandalf>alter program tables for audioprop, videoprop, subtitletypes sets...
17:44<janneg>gbee: adding properties to program and recordedprogram
17:46<gbee>ok thanks, I knew it was the one Janne made, I just couldn't remember the details
17:47<kormoc>xris, I can't reproduce on my home install anymore, not sure what causes it
17:47*xris heads home (well, to drop coworker off at airport)
17:47-!-xris [] has quit []
17:49-!-foxhunt [] has joined #mythtv
17:51<MrGandalf>oops, the alters are 1211.. my bad
17:56<janneg>MrGandalf: iirc db update 1211 was cheap compared to 1210
17:57<MrGandalf>maybe, but it still takes a bit :) still on the first alter of 1211 6 minutes in
18:00<Cardoe>MrGandalf: so is the upgrade failing from 0.20.x to 0.21?
18:00<janneg>wtf? is your program table fragmented. I remember correctly if I say your program table has one million entries?
18:01<Cardoe>erm.. never mind.. sounds like a weird issue
18:01<Cardoe>sphery: I'm heading home. will test some more.
18:01-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:01<MrGandalf>cardoe: my, I run trunk.
18:01<MrGandalf>janneg: yeah, near 1,000,000.. ~7.5 per alter for 1211.
18:02<MrGandalf>I really need to start filtering some stuff..
18:02-!-Deek [] has quit [Read error: 113 (No route to host)]
18:03-!-BigJ [] has quit [Client Quit]
18:04<janneg>MrGandalf: so my 80,000 is 1/12. the whole 1211 update took less than 10 seconds. I was quite surprised since 1210 took much longer
18:06<MrGandalf>janneg: given the size of your program table, you may have had a good portion in cache after 1210.
18:07<janneg>MrGandalf: since I wrote both updates there was at least a day between the updates
18:07<MrGandalf>janneg: I see.
18:13-!-BigJ [] has joined #mythtv
18:20-!-rn114__ [] has quit [Read error: 104 (Connection reset by peer)]
18:20-!-xris [] has joined #mythtv
18:27-!-foxhunt [] has quit [Remote closed the connection]
18:30<gbee>any thoughts/comments on this patch?
18:35<sphery>gbee: Regarding your preview pixmap scaling code ( programs/mythbackend/mythxml.cpp +795). When you save it, you're using the default filesystem permissions (as defined by the user's umask). We used to do that with the preview generator, but some users couldn't be bothered to set their environment appropriately when running NFS with different uid's on different hosts or with different users running mythbackend/mythfrontend, so ...
18:35<sphery>... danielk22 added a chmod(filename.ascii(), 0666). Think that's a good idea for scaled previews, too?
18:36<gbee>sure, sounds reasonable
18:36<sphery>OK. Thanks.
18:36-!-joobie [] has joined #mythtv
18:38<gbee>they should only be accessed by the backend though, so I don't see it being a problem if we don't set global read perms?
18:39<gbee>I was thinking that we might move that scaling logic in the preview generator at some po
18:43<gbee>that might sacrifice the speed gain we get from just scaling on the spot because you've got the overhead of loading up the preview gen
18:44<sphery>Though do we always verify that only the backend that recorded the show makes/scales the preview? I was thinking in some configurations a different backend may touch it. If so, then if uid's don't match, the user may have issues (i.e. especially with restrictive umasks, like 0066).
18:44<sphery>Regardless, having all previews with the same filesystem permissions "looks" right. :)
19:05-!-dhr [] has quit [Read error: 104 (Connection reset by peer)]
19:17<gnome42>Chutt wins handily by a length!! In the: "I can file those tickets faster than you can submit'em race" :))
19:17<MrGandalf>a few days back someone said that if yadif or greedyhdeint was used, deinterlacing was always turned since those two can distinguish between the two on it's own.
19:19<danielk22>sphery: the chmod is only needed because ppl don't set up their permissions correctly.. it's really "not right" but it prevents a lot of complaints about the preview generator not working..
19:20<danielk22>sphery: "don't set up their permissions correctly" ".. or set their group id's or user id's to a consistent state across machines sharing an NFS file system.."
19:22<gbee>I take it there are no problems with the implementation of the patch? I'm not too sure whether GetDisplayAspect returns anything useful for OSX but I guess Nigel will supply a fix if it doesn't
19:22<sphery>danielk22: Right. But, we have a workaround for them on previews created by the preview generator, I thought we should have the same for (XML-requested) previews created by scaling the preview-generator-created previews.
19:23<danielk22>sphere: yeah we should.. but maybe this should be abstracted into a util file "make_file_readable" that can at some point not open this security hole on systems that are configured correctly :)
19:23<MrGandalf>but I'm not seeing that
19:24<danielk22>gbee: I think the call actually works on OSX, but we don't use it for scaling the video..
19:25<sphery>I should stop recommending symmetry fixes that duplicate problems in existing code as it always ends up creating a lot more work than the one-liner patches I envision. :)
19:25<sphery>Any ideas on how to determine if the system is configured correctly?
19:25<gbee>danielk22: ok, that's fine then - I was thinking that the method I'm added could be reused in videooutput_xv but I'm adding it mainly so that preview images are scaled correctly for non-square pixel displays
19:27<MrGandalf>sphery: sorta like the QDeepCopy thing in mythevent? :) I had no idea that one would be so... challenging.
19:27<sphery>MrGandalf: Yeah. And that one has caught the attention of several unsuspecting users...
19:28<gbee>never given much thought to the process, but how are slave recordings handled anyway? Does the frontend connect directly to the backend that made the recording or does everything flow through the master backend? Or do recordings have to be in a common shared directory?
19:28<MrGandalf>it's a simple fix though. As Daniel said, add a usleep() ;)
19:28<danielk22>gbee: have you looked at MythGetPixelAspectRatio() in util.h ?
19:28<kormoc>gbee, I think the FE connects directly to the slave BE
19:29<gbee>danielk22: yeah, that's where I started - it was a toss up between using that directly and re-using the instance of DisplayRes which we already created in MythContext
19:30<sphery>gbee: MasterBackendOverride allows the master to stream and delete files if available "locally" even if created by other backends.
19:30<gbee>DisplayRes indirectly gets the aspect ratio from a call MythGetDisplayDimensions()
19:30<MrGandalf>but only for recordings, not LiveTV
19:31<sphery>I have separate storage on my 2 systems with no shares, so in that case each file is always handled by the backend that recorded the show.
19:31<danielk22>gbee: DisplayRes is probably more accurate though, if Xinerama is enabled, it's still aware of the Aspect Ratio right?
19:32<danielk22>hmm, maybe not.. I don't think it's Xinerama aware..
19:33<gbee>I would guess that DisplayRes returns the 'wrong' aspect ratio in cases where Xinerama is enabled, it's not special cased for xinerama (yet), which is why the patch checks if xinerama is enabled and looks at XineramaDisplayAspect
19:33<gbee>the xinerama check might be better placed in DisplayResX
19:33<gbee>I'll move it
19:33<danielk22>Hmm, it also looks like DisplayRes::Initialize() is only called when Video Mode switching is enabled.. so it's prolly not safe to use otherwise..
19:36<gbee>danielk22: I moved Initialize out of there -
19:37<gbee>hmm, should have looked at Initialize() I guess ...
19:41<gbee>yeah, not too sure if it is going to be safe if those resolution settings don't exist
19:43<gbee>maybe I'll just keep it simple and use MythGetPixelAspectRatio() for now, fixes the bug for X users at least and is unlikely to cause new issues in 0.21
19:44<danielk22>yeah, I think that is the only fix which is 0.21 safe..
19:44<Chutt>danielk22, those mythevent changes going to be backed out?
19:45<danielk22>they didn't fix the problem and cause additional stability problems for others..
19:45<Chutt>i want to release on friday, i think
19:45<danielk22>k, i should have some time this week...
19:45<Chutt>so some moron's asking permission to put the mythtv logo on a remote control
19:46<Chutt>calling it the 'mythMOTE'
19:46<Chutt>with a logo that's lifted directly from mythtv
19:46<Chutt>I've told them no, twice, now.
19:50-!-prg3 [] has quit [Remote closed the connection]
19:54-!-prg3 [] has joined #mythtv
20:04<xris>grumble. anyone know what aspect ration british TV is shown in?
20:05<Chutt>whatever aspect they want
20:05<gbee>4:3 and 16:9
20:05<Chutt>4:3, 16:9, 14:9
20:05<gbee>or anything in between
20:05<xris>trying to nuvexport some top gear episodes and drop off the top/bottom bars. 4:3 and 16:9 are definitely wrong
20:05<gbee>actual pixel aspect is 5:4
20:05<xris>I wonder if ffmpeg will even accept 5:4 or something like that
20:06<xris>gbee: my source is 528x480 in 4:3
20:06<xris>I then have to crop 9% or so from top/bottom to get rid of black
20:06<xris>I should just give up on mp4 files and use avi with its nice square pixels
20:07<xris>you tell mp4 to use 1:1 aspect and it gives you a square recording. heh
20:07<gbee>yeah, will have been changed for NTSC (fewer lines)
20:08<gbee>originals are broadcast in 16:9 here, most modern material is fully widescreen
20:09<xris>yeah. bbc america just annoying, then
20:10<xris>dunno why they don't just give it the full 16:9 stretch, then.
20:10<gbee>am I right in believing that widescreen over there means HD?
20:10<xris>oh well. I'll try 14:9 and see if that works.
20:10<xris>in the US? doesn't mean HD, but a lot of people think it does.
20:10<xris>and for TV, most stuff *actually* broadcast in widescreen is HD.
20:11<xris>most dvds are widescreen, and not hd
20:11<gbee>ok, clears that one up then :)
20:14<gbee>we've been receiving widescreen broadcasts via analogue for years and now SD digital too, analogue widescreen TVs are pretty much the norm, at least for main room sets
20:16<gbee>little confusing that people were saying that widescreen over there only appeared with HD because the US tends to be ahead of everyone else in the west when it comes to the introduction of new tech
20:17<gbee>plus I would have sworn I'd seen widescreen TVs in films ;)
20:20<Chutt>gbee, we don't have the equivalent of the 'widescreen' flag you guys have for SD
20:20<Chutt>so everything that's broadcast as widescreen is letterboxed
20:30-!-TelnetManta [] has joined #mythtv
20:31-!-CTho [] has joined #mythtv
20:32-!-mzb_d800 [] has quit [Read error: 113 (No route to host)]
20:37-!-m00db00m [] has joined #mythtv
20:39-!-mzb_d800 [] has joined #mythtv
20:39<Chutt>trying to fix #4567
20:39<Chutt>problem's simple - the aligned height != stream height
20:40<Chutt>videoout classes are too complicated these days :p
20:49<Chutt>gbee, #4756 - the code looks iffy
20:57-!-CTho [] has quit ["if you have any goats, please sacrifice one to nvidia and one to ati for me ;)"]
21:07-!-mzb [] has joined #mythtv
21:27<GreyFoxx>Chutt: see anyreason I shouldnt commit :
21:27<GreyFoxx>basically a work around for no DTS info coming back from libav allowing us to seek around in mkv/mov/mp4 files
21:28<Chutt>naw, go for it
21:28<GreyFoxx>a few of us have used it heavily for several days with no problems
21:51<Chutt>though i still have to merge those all to fixes
21:51<Chutt>since i'm bein lazy
21:51-!-JoeBorn [] has quit ["I'll be back soon, I have more to say!"]
21:55-!-Deek [] has joined #mythtv
21:55-!-Deek [] has quit [Remote closed the connection]
21:56-!-Deek [] has joined #mythtv
21:58<CDev>Beat me to it... I was just about to test #4648
21:59<Chutt>oh, sorry
21:59<Chutt>i was looking through patches
21:59<CDev>np. Less work for me.
22:00<Chutt>i didn't test extensively, though
22:00<Chutt>just tried to play a file over the ps3
22:01<CDev>I never had the problem listed, so that was going to be the extent of my testing as well. (I may have tried my dsm-520).
22:30-!-jd86 [n=jdio@pdpc/supporter/student/jd86] has quit ["Leaving"]
22:50-!-userlame [n=userlame@] has joined #mythtv
22:51-!-ahbritto [] has joined #mythtv
22:51<userlame>hi, i've had a mythtv install for about a week now and i'm running into a problem; my schedule shows up two channels was fine at first, and after a couple mythfilldatabases earlier it went back to normal for a day or so
22:51<userlame>any ideas?
22:56<hads>userlame: Check the topic.
22:58<userlame>ah my bad, thx
22:58-!-userlame [n=userlame@] has left #mythtv []
22:59-!-ahbritto [] has quit [Client Quit]
23:02-!-davilla [] has joined #mythtv
23:39-!-Timple [] has joined #mythtv
---Logclosed Tue Mar 04 00:00:09 2008