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

---Logopened Sun Mar 09 00:00:05 2008
---Daychanged Sun Mar 09 2008
00:00<kormoc>GreyFoxx, ooh, I've wanted to ask you a question about dvd playback. My box's playback is weird, jumpy video and audio. Have any suggestions on debug channels to use to figure out why?
00:03<GreyFoxx>I find -v playback to be most useful
00:03-!-purserj [] has quit [Read error: 110 (Connection timed out)]
00:04<kormoc>kk, I'm assuming it's related to being a sata dvd player, but yeah, it'd be nice to know
00:06-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
00:06<GreyFoxx>don't think I've even seen a sata dvd drive yet :)
00:07<kormoc>Heh, I ordered the wrong one accidentally so I'm sorta stuck with it.
00:10*GreyFoxx downgrades all frontends to 16431
00:13<clever>ticket #4896 opened
00:14<clever>looks like a real simple fix and solve the problem i had
00:14<Anduin>They are nice when you only have one PATA header, I haven't seen any sata related problems with mine.
00:18<Anduin>Why is extracting out the channel changers a good idea? I know I read something in the scrollback.
00:20<kormoc>Anduin, less binary blobs for svn to deal with
00:20<kormoc>Anduin, also real diffs on updates and the like
00:21<kormoc>Anduin, was there any specific reason not to?
00:21<Anduin>It breaks my rpm build... so no :)
00:21<kormoc>Heh, sorry
00:22-!-purserj [] has joined #mythtv
00:52-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
01:04-!-knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has quit ["Leaving..."]
01:16-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
01:30-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit ["Konversation terminated!"]
01:31-!-gnome42 [] has quit [Remote closed the connection]
01:32<hads>kormoc: That does seem like an odd commit message.
01:32<kormoc>Which one?
01:33<hads>Sorry, relating to that post on -dev list about r16471
01:34<kormoc>It's true, isn't it?
01:34<kormoc>Oh, whoops, I'll add them back in then
01:34<Chutt>i mean, the backend _should_ run it
01:34<Chutt>but there's no reason it has to
01:35<hads>Obviously people can run from if they want to, just sounded odd.
01:35<hads>Loads of people here still use the --file option from cron I believe.
01:35<kormoc>Ahh, I thought there was some technical reason we wanted the backend to do so, my mistake
01:35<Chutt>the only real thing is the scheduling, but that's not strictly necessary
01:41<hads>The --capabilites stuff allows us to let the backend to do it now normally though which is great.
01:52-!-ahbritto [] has quit [Client Quit]
01:59-!-Netsplit <-> quits: briand, feiner_, iamlindoro, sn9, purserj, ead, clever, nasa, mkasson__, danielk22
03:02-!-Netsplit over, joins: purserj, nasa, clever, iamlindoro, briand, sn9, feiner_, danielk22, mkasson__, ead
04:28-!-beavis [] has joined #mythtv
04:29-!-ahbritto [] has joined #mythtv
04:41-!-agatka [] has joined #mythtv
04:46-!-agatka [] has quit [Remote closed the connection]
05:19<clever>xris: you about?
05:20<cesman>is there a reason MythWeather uses innodb instead of myisam?
05:20<clever>something about something keys
05:26<kormoc>Aye, it uses constraints to handle the deletion and the like
05:30<cesman>kormoc: is that an answer to my question?
05:31<hads>Foreign key constraints and other good stuff are only supported in the InnoDB engine in Mysql.
05:35-!-ahbritto [] has quit [Client Quit]
05:41-!-ahbritto [] has joined #mythtv
05:42-!-purserj [] has quit [Nick collision from services.]
05:49-!-johnp__ [] has joined #mythtv
06:24-!-xris [] has quit []
07:13-!-phatmonke [n=ben@] has joined #mythtv
07:22<gbee>I don't think 16471 is a bad idea, plenty of users still think mythfilldatabase has to be run via cron script or with custom args but that's not the case
07:26<rooaus>gbee: Wasn't part of mythfilldatabse moved into the housekeeper thread so it doesn't need to be run when using EIT only etc? I thought that was why those scripts existed?
07:27<gbee>the cleanup of the program table was moved to the housekeeper, yes
07:28-!-phatmonke [n=ben@] has quit []
07:28<gbee>I'm not sure why those scripts exist, I think you've mentioned the only good reason and that no longer applies
07:29<gbee>the scripts and custom args field in mythtv-setup are more likely to do harm than good, xmltv now picks the best options for that grabber automatically, user supplied args are probably inefficient or incorrect
07:49-!-nomats [] has joined #mythtv
08:12-!-_gunni_ [] has joined #mythtv
08:16-!-beavis_ [] has joined #mythtv
08:16-!-beavis_ [] has quit [Client Quit]
08:21<sphery>gbee: Yeah, but now we have scripts like contrib/smartfill (moved to contrib/mythfilldatabase/smartfill ), which--by its name alone--tells users it's better than what's in Myth. And it's "better" because it always downloads +7, this next Sat and Sunday, and today as well as +1 and +13... So, rather than the bandwidth/resource friendly SchedulesDirect usage of +1 and +13, it downloads 6 days of data every day...
08:21<sphery>Give users a flexible tool and they'll figure out how to abuse it.
08:22*sphery would like to see smartfill get removed, too
08:22<laga>gbee: i use --update. although i should configure my grabber correctly :)
08:29<akv>ain't it a problem that backend and frontend has to be exactly same versions? Of cause it works fine with one box running both backend and frontend...but several boxes with frontend, some on laptops that are running different distros... ?
08:31<laga>build it yourself?
08:31<akv>laga: gonna be a pain to maintain...
08:32<laga>well, running different distros sounds like a pain to maintain, too :)
08:32<laga>i'd expect that most big distros will have builds of 0.21 available soon
08:32<akv>laga: well...i'd like to run something stable on my server but testing on my laotop
08:32<laga>and different revisions from the fixes branch tend to be compatible
08:33<laga>akv: so you want to run trunk on your laptop and 0.21/0.20 on your server?
08:33<akv>something like that
08:34<akv>at the's not a problem cause i'm running ubuntu hardy on the server
08:34<akv>but when it goes stable, i'm not going to upgrade the server
08:35<laga>akv: that's not possible. development tends to break things, including backwards compatibility.
08:35<laga>akv: mythbuntu usually has trunk builds
08:36<akv>ain't it possible to allow the newer backend to negotiate with the backend of which functions are available somehow to have full backwards compatibility?
08:37<laga>probably, if you submit a patch ;)
08:37<akv>auch! ;)
08:37*akv felt a slap there ;)
08:37<laga>heh :)
09:16-!-johnp__ [] has quit [Read error: 110 (Connection timed out)]
09:33-!-Deek [] has quit [Remote closed the connection]
09:56-!-Vaelys [n=Ziphy@] has quit [Remote closed the connection]
09:58-!-rn114__ [] has joined #mythtv
10:01-!-Vaelys [i=awong@slammer.cs.Dal.Ca] has joined #mythtv
10:03-!-nasa [] has quit ["Leaving"]
10:05-!-_gunni_ [] has quit [Read error: 104 (Connection reset by peer)]
10:06-!-rn114 [] has joined #mythtv
10:06-!-_gunni_ [] has joined #mythtv
10:06-!-rn114__ [] has quit [Read error: 113 (No route to host)]
10:16<laga>Anduin: hum, it seems that -M doesn't always find something.. even when the website turns a hit
10:16-!-TelnetManta [] has quit [Connection timed out]
11:11-!-TelnetManta [] has joined #mythtv
11:21-!-HReadren [] has joined #mythtv
11:21-!-HRearden__ [] has joined #mythtv
11:25-!-[Soul] [] has joined #mythtv
11:30-!-dekar1 is now known as dekarl
11:38-!-cattelan_ [] has quit [Remote closed the connection]
11:52<gbee>GreyFoxx: can you delete and
12:07-!-HReadren [] has quit [Read error: 110 (Connection timed out)]
12:07-!-HRearden__ [] has quit [Read error: 110 (Connection timed out)]
12:08-!-[Soul] [] has quit []
12:19-!-cattelan [] has joined #mythtv
12:23-!-cattelan [] has quit [Client Quit]
12:23-!-cattelan [] has joined #mythtv
12:27<CDev>GreyFoxx: I was just reading the mythtv-users history and it gave me an idea for the xbox 360.
12:29<CDev>you could easily add recordings by having your media scanner code copy compatible entrys from the Recorded table into the upnpmedia table.
12:29<laga>Anduin: ok, i fixed i'll make a ticket later as soon as i get some sanity in this mix between tabs and spaces..
12:29<CDev>entries even.
12:32-!-cattelan [] has quit ["Terminated with extreme prejudice - dircproxy 1.2.0"]
12:32-!-robthebob [] has joined #mythtv
12:33-!-cattelan [] has joined #mythtv
12:33-!-rn114 [] has quit [Read error: 113 (No route to host)]
12:46-!-gnome42 [] has joined #mythtv
13:02-!-aevil [] has joined #mythtv
13:08-!-PointyPumper [i=Pintlezz@] has quit [Read error: 110 (Connection timed out)]
13:10-!-dekar1 [] has joined #mythtv
13:15-!-dekarl [] has quit [Read error: 60 (Operation timed out)]
13:32-!-rn114 [] has joined #mythtv
13:32-!-robthebob [] has quit [Read error: 113 (No route to host)]
13:32<gbee>ok, that's freaky
13:34-!-Netsplit <-> quits: Honk, otwin, _gunni_, whodat, teprrr, ToadP, tomimo, hads, jeffc91, kvandivo, (+2 more, use /NETSPLIT to show all of them)
13:34<gbee> is trying to set a cookie when I visit the admin area, thought all the icons came from lyngsat so I've no idea where pbs comes into it
13:34-!-Netsplit over, joins: _gunni_, ToadP, teprrr, otwin, stuarta, whodat, tris, kvandivo, Honk, hads (+2 more)
13:40-!-Deek [] has joined #mythtv
13:45-!-johnp__ [] has joined #mythtv
13:46-!-superm1 [n=superm1@ubuntu/member/superm1] has quit ["Leaving"]
13:52<gbee>Chutt: think there are some changes which have yet to be merged back from -fixes to trunk
13:52-!-phatmonke [n=ben@] has joined #mythtv
13:53-!-onixian [n=xian@] has joined #mythtv
13:55<Chutt>i didn't get the last couple
13:59<Anduin>laga: Thanks
14:01<laga>Anduin: there are some annoying charset issue and i'm not sure if i can fix them. i'll just make a separate ticket for them if you don't mind
14:03<Anduin>laga: I don't, thought I had fixed them all though, oh well.
14:04<laga>Anduin: they're with the script itself. eg the website expects iso8859 and we send utf-8 (depending on the environment)
14:04-!-onixian [n=xian@] has quit ["This computer has gone to sleep"]
14:06-!-loops [] has quit ["Leaving"]
14:06<Anduin>laga: Ah, my simple test case rears its ugly head
14:10-!-dekar1 is now known as dekarl
14:15-!-aevil [] has quit ["Ex-Chat"]
14:19-!-Netsplit <-> quits: Honk, otwin, whodat, _gunni_, teprrr, tomimo, ToadP, jeffc91, hads, kvandivo, (+2 more, use /NETSPLIT to show all of them)
14:20-!-Netsplit over, joins: _gunni_, ToadP, teprrr, otwin, stuarta, whodat, tris, kvandivo, Honk, hads (+2 more)
14:23-!-Netsplit <-> quits: Honk, otwin, whodat, _gunni_, teprrr, tomimo, ToadP, jeffc91, hads, kvandivo, (+2 more, use /NETSPLIT to show all of them)
14:23-!-Netsplit over, joins: _gunni_, ToadP, teprrr, otwin, stuarta, whodat, tris, kvandivo, Honk, hads (+2 more)
14:27-!-Netsplit <-> quits: Honk, otwin, whodat, _gunni_, teprrr, tomimo, ToadP, jeffc91, hads, kvandivo, (+2 more, use /NETSPLIT to show all of them)
14:28-!-Netsplit over, joins: _gunni_, ToadP, teprrr, otwin, stuarta, whodat, tris, kvandivo, Honk, hads (+2 more)
14:37-!-superm1 [n=superm1@ubuntu/member/superm1] has joined #mythtv
14:39-!-rn114 [] has quit [Read error: 113 (No route to host)]
14:39-!-rn114 [] has joined #mythtv
14:40<sphery> /sb c
14:41<kormoc>Woah, snazzy patch by bjm
14:41<sphery>Yeah. Too bad I tend to keep all my favorite shows to watch in a marathon...
14:43<kormoc>I still need to play with the auto-zoom patches, as I think they'll help my shows alot
14:46-!-loops [] has joined #mythtv
14:48<sphery>kormoc: And here I though MrGandalf's patch on #4599 was a good one to replace /and/ (allowing us to delete 2 from the repo) because Mark's at least uses the Perl bindings somewhat (for Storage Groups, at least). I guess, though, it could probably get all the DB connection info from the bindings, too.
14:50<sphery>OK, now that I look at it, it seems to get the recordings list and the DB connection using the bindings...
14:54<kormoc>I might just be blind, perl isn't my best language
14:55<sphery>I did just write some scripts using the perl bindings, so I had a head start... :)
14:56<sphery>the "use MythTV;" and the "my $MYTH" stuff...
14:56<kormoc>Well, I thought there was methods to do what sub getRecordings is doing
14:56<kormoc>same with getStorageGroups
14:56*kormoc pokes at the perl bindings
15:00-!-dekarl [] has quit [Read error: 104 (Connection reset by peer)]
15:00<kormoc>Yeah, get_recording_dirs should replace getStorageGroups, tho, it should likely be updated to the style he uses (get the name as well as the dir)
15:03<kormoc>and shouldn't getRecordings use the recordings object/class rather then using the array, no?
15:03<sphery>Agreed on both points.
15:04-!-Dibblah [] has quit [Read error: 104 (Connection reset by peer)]
15:04<kormoc>kk, so I wasn't too far off, I'll comment a bit more detailed as to what I mean
15:05<sphery>Though, get_recording_dirs (in the bindings) needs updated to use the new StorageGroup::getRecordingsGroups() (meaning a change to the protocol to expose that info)
15:05<sphery>I'll put that one on my TODO list...
15:05<sphery>That allows us to differentiate between, i.e. DB Backups or Thumbnails storage groups or those that will be used with plugins, such as MythVideo.
15:07<sphery>kormoc: What do you think of the idea of removing and
15:07<sphery>(once that one is committed)
15:07<kormoc>I'm quite in favor of it
15:07<sphery>Cool. I really want to clean up some of the old legacy scripts from contrib (so was glad to see your reorganizing it).
15:08<sphery>If we do it soon after 0.21 is released, anyone who feels the new script is missing functionality provided by the just-replaced scripts has plenty of time to fix it, too.
15:09*kormoc nods
15:09<kormoc>I just wonder where in the tree to put it... :P
15:11<kormoc>I'm also going to try to find some documentation of the stuff that's in contrib right now and try to get a little bit of a readme for everything, as right now it's a bit confusing what does what
15:14-!-dekarl [] has joined #mythtv
15:22-!-mattwire [] has joined #mythtv
15:25<sphery>kormoc: At least my addition to contrib (the misc_status_info stuff) has a README.
15:26<kormoc>Heh, yeah, there's a lot of good ones in there, but there's a few things that are entirely missing
15:26<kormoc>The one script I deleted was for mythexplore, talk about old and never used :P
15:29<sphery>yeah, I didn't know that history of MythVideo...
15:29<kormoc>I didn't until I researched it
15:33-!-rn114 [] has quit [Read error: 104 (Connection reset by peer)]
15:33<sphery>I'm wondering whether a user "call-to-arms" would be a good way to get the start of some README's. Those that don't get README's get removed... :)
15:34-!-mattwire [] has quit [Remote closed the connection]
15:34-!-rn114 [] has joined #mythtv
15:37-!-mattwire [] has joined #mythtv
15:40-!-rn114 [] has quit [Read error: 104 (Connection reset by peer)]
15:41-!-rn114__ [] has joined #mythtv
15:41-!-foxhunt [] has joined #mythtv
15:41-!-mattwire [] has quit [Client Quit]
15:42-!-mattwire [] has joined #mythtv
15:43<kormoc>Hrm, I wonder if I want to try to tackle volume normalization next or not... It'd be a fun thing to attempt
15:43-!-PointyPumper [n=pintlezz@] has joined #mythtv
15:44<sphery>Did you read all the posts related to Mark's ALSA patches? :)
15:46<kormoc>No I haven't, but I shall dig them up now :P
15:47<sphery>Just meant that he's probably not having fun with all the complaints/issues that have surfaced. No need to dig them up.
15:47<kormoc>Ahh, heh
15:47<kormoc>That's sorta the nature of development I fear
15:47<sphery>I do remember someone posting a ticket that had the "initial groundwork" for a volume normalization or something...
15:48<kormoc>Hrm, I'll take a gander at it
15:48<kormoc>I think I understand how to do it properly with pcm style outputs, not sure how all the multi-channel stuff works
15:49<kormoc>nifty, I'll poke at that a bit
15:49<sphery>have fun
15:51<kormoc>Ooh, I'm sure I'll have wonderful epic failures :)
15:51-!-mattwire [] has quit [Remote closed the connection]
15:53-!-SS3 [] has joined #mythtv
15:59-!-degreseven [] has joined #mythtv
16:07-!-SS3 [] has quit ["leaving"]
16:15-!-foxhunt [] has quit [Remote closed the connection]
16:16<kormoc>Oh damn, the auto-zoom stuff is snazzy
16:17<GreyFoxx>I(s that the auto 4:3 detection stuff ?
16:18<GreyFoxx>I'll have to check that outi
16:18-!-rn114 [] has joined #mythtv
16:18-!-rn114__ [] has quit [Read error: 104 (Connection reset by peer)]
16:18<gbee>not tried the latest patch, earlier versions used the Full zoom on content that was better Half zoomed, but I think he sorted that
16:19<gbee>GreyFoxx: so DVD playback is broken in 0.21? :(
16:20<GreyFoxx>gbee: Yeah so far all DVD's Ive tried in multiple frontends under multiple resolutions crash the FE
16:20<GreyFoxx>16434 the video alignment change seems to be the culprit
16:20<gbee>think that would probably deserve a 0.21a release once fixed
16:20<GreyFoxx>I think so
16:20<gbee>danielk22: you aware of this?
16:21<kormoc>would it be broken in trunk as well?
16:21<GreyFoxx>Not sure about trunk, I haven't switched back to it yet
16:21<laga>GreyFoxx: i don't even get video playback when i try to play a dvd iso. audio works, though
16:21<gbee>kormoc: if the change was merge from fixes
16:21<GreyFoxx>laga: I think the DVD iso is the same issue
16:21<GreyFoxx>try reverting to 16433 and see if it plays
16:22<laga>GreyFoxx: i'll try later, i'm struggling with python at the moment
16:22<gbee>DVD playback has been very reliable in trunk, so any issues are probably related and recent
16:22<laga>ah, there's a ticket already for dvd iso..
16:22<kormoc>Cause I'm having an issue with it crashing on chapter changes, but it starts playing fine
16:23<GreyFoxx>I had to resort to mplayer last night to watch a dvd
16:23<kormoc>my dvd stuff always seems to be weird
16:23<GreyFoxx>hehe I wouldnt have minded if I wasn't showing off the stuff to a friend who had come over :)
16:23<GreyFoxx>after he left I went digging to find out where it broke heh
16:23<kormoc>That's how it always works :P
16:23<GreyFoxx>yeah :)
16:23<laga>the internal player for dvds has never worked well for me :/
16:23<stuarta>evening all
16:23<GreyFoxx>this is the first dvd playback I've had in a long while
16:23<gbee>hmm, actually I've just tried, and a second DVD crashed on an assert in vm.c - that's never happend before
16:24<GreyFoxx>16434 buffer size/alignment change is leading ffmpeg to write data outside of our allocated buffer I believe
16:24<gbee>I wrote off the first assert crash as being specific to the DVD, but two in a row?
16:25<gbee>right, a known working DVD refuses to play ...
16:25<gbee>starting to suspect one of the changes made by Erik's patches to libdvdnav
16:26<GreyFoxx>We should define a set of
16:26<gbee>either that, or my drive has gone on the fritz
16:26<GreyFoxx>oops wrong channel :)
16:27<gbee>err PEBCAK
16:28<gbee>forgot that I formatted and reinstalled late last week, so I no longer have decss installed ...
16:30<stuarta>doh indeed
16:30*stuarta notices we've done a release <- been away for the weekend
16:31<danielk22>gbee, maybe this is a good opportunity to fix some segfaults when decss isn't installed..
16:32<gbee>danielk22: yeah
16:34<gbee>not a high priority issue though, the regression in DVD playback caused by 16434 is more important right now
16:35<gbee>wish I could help with that :/
16:35<danielk22>gbee: What is the regression? Is there a ticket?
16:36<GreyFoxx>dvd playback crashes for me on all frontends, multiple disk, multiple resolutions
16:36<GreyFoxx>I put a backtrace on a ticket
16:36<GreyFoxx>looking for the number now
16:36<gbee>several reports, at least one on the -user list
16:36<danielk22>any usable backtraces?
16:36<GreyFoxx>I put a bt on there, but I can certainly make another
16:37<GreyFoxx>reverting to anything before 16434 plays fine
16:39<danielk22>hmm, looks like one is with the intel drivers the other with via.. I'm guessing both have a XVideo layout unlike the nvidia..
16:40<GreyFoxx>the two FE's I've had crashing are Nvidia
16:41-!-rn114 [] has quit [Read error: 104 (Connection reset by peer)]
16:41-!-rn114__ [] has joined #mythtv
16:41<danielk22>gf: prolly good because I have some hope of reproducing this then..
16:41<GreyFoxx>I can generate a new bt if you want
16:42<danielk22>nah, it doesn't look like a bt will be terribly useful in this case. It's probably a buffer allocation that's wrong somewhere.
16:43-!-xris [] has joined #mythtv
16:44<gbee>just installing a post 13464 version of trunk to see if I can reproduce
16:46<gbee>ok, I can
16:47<danielk22>heh, I need to recompile. I forgot I had ./configure'd without X support (using DirectFB) to some compile options before the release target was cut.
16:49<gbee>backtrace, don't know how it compares to GreyFoxx's one -
16:49<gbee>0x00002b34d90642b0 in put_pixels16_mmx (block=0x27dbee0 "\020\020\020\020\020\020\020\020\r\020\023\024\024\024\024\024", pixels=0x2aaab22ec010 <Address 0x2aaab22ec010 out of bounds>, line_size=720, h=16)
16:49<danielk22>yeah, it's the same. ffmpeg is writing outside the bounds of the allocated frame it seems. Actually the -v playback log might be more useful than the backtraces..
16:50-!-mattwire [] has joined #mythtv
16:50<GreyFoxx>same in mine
16:51<gbee>0x00002b34d84033b9 in MHIContext::StartMHEGEngine (param=0x3db2d80) at mhi.cpp:171 << Ok, probably not harmful but a waste of time starting the MHEG engine on DVDs, I'll fix that at some point
17:01<gbee>playback log -
17:10<danielk22>k, I haven't been able to reproduce the crash, but have reproduced still frame wackiness.. I'm now getting -v playback logs with and without 16434 to compare..
17:18-!-gerhard [] has joined #mythtv
17:24-!-Dibblah [] has joined #mythtv
17:36<danielk22>2008-03-09 17:14:21.376 VDP: LoadBestPreferences(0x0, 29.97) --- might be a problem...
17:36-!-\S2 [] has joined #mythtv
17:36-!-\S2 is now known as S2
17:40-!-purserj [] has joined #mythtv
17:44-!-dagar [] has quit ["Leaving"]
17:44-!-johnp__ [] has quit [Read error: 110 (Connection timed out)]
17:45-!-dagar [] has joined #mythtv
17:50<danielk22>gbee, greyfoxx: I just attached a patch to #4897, it's probably not the final patch.. but if you can let me know if it helps.. that would be valuable info...
17:52-!-mattwire [] has quit [Remote closed the connection]
17:55-!-sn9 [] has left #mythtv ["This is a /part message."]
17:55-!-mattwire [] has joined #mythtv
17:58<gbee>danielk22: seems to have worked, DVD is at least playing which it didn't before
18:00<gbee>second DVD also plays fine
18:01<jams>oh a patch for dvd
18:01<jams>let me try that
18:02<gbee>ok, tried four and all worked as expected (not sure I needed to test that many, but better to be sure)
18:02-!-richards [] has quit ["ChatZilla 0.9.81 [Firefox]"]
18:06<jams>danielk22- seems to have helped here.
18:10-!-mattwire [] has quit ["Leaving"]
18:11<rooaus>Found this...
18:12<danielk22>So he's working at JPL..
18:15<kormoc>Is that the guy who's been flooding tickets?
18:15-!-S2 [] has quit [Remote closed the connection]
18:16<danielk22>yep, lots of little bug fixes
18:18<danielk22>gbee: ok, I'm actually making the official patch to the NVP instead of the videooutbase.. That appears to be where I broke things.
18:19-!-degreseve1 [] has joined #mythtv
18:19-!-mattwire [] has joined #mythtv
18:20<gbee>I was suggesting earlier that we push out a 0.21a release, but that depends on Chutt having the time/motivation
18:20<Chutt>naw, not for just dvd
18:20<Chutt>two weeks, then i'll consider a point release
18:21<gbee>how serious it is all depends how many DVDs you watch I guess ;)
18:21<danielk22>gbee, chutt: I've attached a better fix to #4897. Testing with a few DVD's now..
18:22<Chutt>i don't consider it a huge problem :p
18:23<gbee>superm1: this a patch you can apply to the packages going through for Hardy?
18:23<danielk22>chutt: This bug might also break playback in Australia, where aspect only stream changes can happen. I don't know it will for a fact though. Still we might want to wait a little while to see if any other problems turn up..
18:23<Chutt>no point putting something out now, and then again a few days later
18:23<Chutt>fixes branch is good enough, most packagers pull from that anyway
18:24<danielk22>chutt: is trunk fully synced from fixes now?
18:25<Chutt>i may be a tad behind
18:25<Chutt>i last synced it friday night
18:25<janneg>danielk22: aspect only stream changes are also common in europe. I haven't noticed any problems though
18:25<gbee>danielk22: no, I know there is at least one of mine which hasn't yet been synced, it's a minor plugin patch though
18:25<Chutt>danielk22, aspect only changes should still send the same w/h, though
18:25<Chutt>so it should be fine
18:25<danielk22>janne, ok.. i wasn't sure if it would be a problem depends on whether w&h are sent..
18:26-!-BigJ [] has joined #mythtv
18:32-!-gerhard [] has quit ["ChatZilla 0.9.81 [Firefox]"]
18:35<danielk22>ok, ?I
18:35<danielk22>i've committed the fix.. worked on my batch of test dvd's ...
18:36*GreyFoxx svn ups
18:36-!-degreseven [] has quit [Read error: 110 (Connection timed out)]
18:38<danielk22>does anyone know who wrote the DVD Menu stuff in MythTV? I'd like to get the buttons working properly with overscan, zoom, & the OpenGL and chromekey renderers.. was it Stanley? Someone else?
18:38-!-phatmonke [n=ben@] has quit []
18:40<gbee>Menu stuff was Stanley, JSD did the original DVD playback but it didn't include menus
18:40<gbee>Stanley is in here a couple of times a week (skamithi), not tonight though
18:45<danielk22>k, thx
18:45<Chutt>buttons won't work on chromakey, i don't think
18:45<rooaus>kormoc: Updated #3664, wasn't able to test as I don't have the problem file any more. What do you think fixed it?
18:45<Chutt>ie, dvd buttons/overlays/etc are the reason there's the ai44 subpicture support in xvmc
18:46<kormoc>rooaus, it uses the perl bindings and they should handle the failures gracefully now I believe
18:47<kormoc>And if not, it should be fixed in the bindings to do so
18:50<rooaus>kormoc: OK, I think the prob may still exist but the patch was the only perl I have ever written. Will consider the binding fix if I can reproduce it.
18:51<kormoc>Sounds good, could always ping xris too if it's a complicated chunk of code
18:51<gbee>hmm, X is currently using 33% memory on a 2Gb system during playback of a DVD
18:51<danielk22>chutt: the dvd menu stuff is done in the NVP, and without enough info on the size of the OSD surface.. so if there is any zooming, or you use a renderer that renders the OSD at a different resolution, like PVR-350, XvMC-OpenGL, OpenGL, chromakey, etc the highlights are in the wrong place...
18:58-!-beavis [] has quit ["Verlassend"]
19:00-!-cva [] has joined #mythtv
19:01-!-cva [] has left #mythtv ["leave"]
19:02<GreyFoxx>yay, dvds play again
19:02<GreyFoxx>thx daniel
19:03<danielk22>heh, to paraphrase Colin Powell, "You break it, you fix it"
19:05<kormoc>danielk22, gonna merge that to -trunk?
19:06-!-myth-newb [] has joined #mythtv
19:06-!-myth-newb [] has left #mythtv []
19:07<gbee>might be a good opportunity to merge all the changes
19:23-!-ahbritto_ [] has joined #mythtv
19:25<rooaus>gbee: What do you think about adding storage group support to mythmusic?
19:26<gbee>rooaus: like the idea, is it an offer, or a suggestion? :D
19:26<gbee>wouldn't be hard to implement
19:27<rooaus>gbee: Offer (if I can), you had mentioned upnp but storage groups would work better for offline storage (ipods, usb etc)
19:28<gbee>rooaus: I was considering re-using upnp with music stored on the backend and shared between frontends, but only because upnp is available and perfect for the job
19:31<rooaus>gbee: Fair enough. The more I look at storage groups the more I like them, does seem to be a rather nifty concept and works well in a myth context.
19:31<gbee>I don't think it prevents us from using storage groups, i.e. your main collection is stored on the backend under a backend storage group but the frontend can still work from local (portable) storage devices connected directly
19:34<gbee>If I ever do get around to moving stored media to the backend, music and video, then it won't be before 0.23, mythui and other things will probably keep me busy for 0.22
19:35<gbee>by that time someone else will probably have supplied a patch, that usually happens with all my best ideas, someone else implements them before I have a chance ;)
19:38<rooaus>Yeah, I know you had plans for mythmusic, I just wanted to confirm that this fitted in with them. There is already some work being done on moving the video stuff to storage groups, not sure where that is at though.
19:41<gbee>I've drifted away from mythmusic because many of the changes I wanted to make will be easier and better under mythui, so I'll be working on that first
19:42<gbee>then the metadata restructuring (because I've started it, so I might as well finish)
19:42<gbee>and after that I'll probably re-write my playlist editor patch for mythui
19:43-!-_gunni_ [] has quit ["KVIrc 3.2.4 Anomalies"]
19:43<laga>maybe eskil's shoutcast patch can get some love, too :)
19:43<gbee>somewhere in the middle of those changes I'll find something else to work on and I might just finish it all before I die of old age
19:44<rooaus>gbee: lol
19:45-!-rn114__ [] has quit [Read error: 113 (No route to host)]
19:46<rooaus>laga: +1, I promised Eskil I would do what I could to help with that... not sure how much help I will be though ;)
19:47-!-siXy2 [i=siXy@] has joined #mythtv
19:49<gbee>eskil's shoutcast patch frightens me, it's not that I don't like the idea but merging it means touching the music tree and I really don't like that, it gives me headaches :)
19:50-!-ahbritto [] has quit [Client Quit]
19:51<gbee>I think Paul has a better grasp of the playlist/music tree code and I respect him for that, he's probably in a better position to review and commit the patch than I am
19:52<sphery>rooaus / kormoc : responded with some more background on #3664 on the -dev list . It should be fixed but for a very different reason... ;)
19:52-!-siXy2 [i=siXy@] has quit [Client Quit]
19:52<rooaus>gbee: Yeah the music tree stuff is fun ;)
19:52<kormoc>Kk, I'll take a gander
19:54<sphery>gbee: I love the idea of backend storage/UPnP delivery of Music (and Videos). I hope someone writes a patch and steals credit for your idea. (And, even in that approach it should be using a "special" storage group--see StorageGroup::kSpecialGroups).
19:54<kormoc>I really want videos streaming from the backend so we can use the flash video player to play them too :)
19:55<gbee>hey, I don't mind them taking credit, I just look forward to writing the code and I'm disappointed when I don't get the chance
19:56<sphery>my backends can't even play my recordings in real time, let alone transcode them... :(
19:58<rooaus>sphery: Agree about the special group, that was the plan... and maybe one for ripping as well (which is implicitly part of playback group).
19:58<sphery>rooaus: sounds good.
19:58<gbee>then there are the purely selfish times when the changes others propose go in different direction from what I personally wanted to do, hard to argue that someone else contribution shouldn't be include merely because it's not what I had in mind or because I don't really want to maintain it
20:01<rooaus>gbee: That is understandable, people can submit patches then disappear to never maintain/help with code once in svn.
20:01<sphery>I'll be putting support in the protocol for getting access to StorageGroup::getRecordingsGroups(), so we can leave those special groups out of, i.e. MythWeb's create-a-new-recording-rule page. I'll also be modifying the backend status page so they're shown in separate Disk Usage sections, but I'm waiting on gnassus's MythVideo storage groups changes (which should add some sort of storage group type).
20:02*xris still wants a "get listings" query...
20:02<xris>I think cdev put one into the xml queries, though. I just need to use it.
20:03<sphery>That sounds like a good approach--use the protocol for those things the frontends need, but use UPnP for "extra" info...
20:03<rooaus>sphery: Thanks for the detail on #3664, clears that up.
20:05<sphery>I happened to remember that changeset quite well, as I had been applying a hack patch for a couple of years to disable the load_file_info because it killed my backends (doing 5 "views" of links for 400+ recordings every 30 minutes--it couldn't complete one view in the 30 minutes... :)
20:06<sphery>When I mentioned it to xris, he said something to the effect of, "Oh, we're still doing that? It's been long enough we should be able to trust file extensions," and committed a change soon after.
20:08<xris>sphery: personally I think that the API should have both mythproto and xml versions of everything. there should be a mythapi object that has proto and xml input/output methods
20:09<sphery>Well, that clears up my question... Was just considering whether it made more sense to expose StorageGroup::getRecordingsGroups() info via XML or myth proto.
20:09<xris>my main interest is to get as much stuff as possible away from raw db queries. There's no reason that mythweb/perl needs to talk to the db -- it would be far more efficient for the backend to maintain the info in RAM and just pass it back upon request. No need to join tables, etc, etc.
20:10<xris>but I don't have much control over the c++ code (esp. because I, well, can't do c++)... so all I can do in that venue is recommend that it's a good architectural idea.
20:10<sphery>We really don't have a listings equivalent of ProgramInfo, do we?
20:12<sphery>If we did, I'd definitely volunteer to add it to the proto for you. Since we don't, I'll say that if you can get me a good idea of what info/format you want, I can put it on my list...
20:13<sphery>I'm thinking, though, that sending a long list of ProgramInfo::ToStringList() might be a bit heavy...
20:13<sphery>especially on some of these boxes with hundreds or thousands of channels...
20:14<xris>yeah, that was my concern.
20:14<xris>I think a request by channel and start/end time range would be usable.
20:14<sphery>Still just dumping a bunch of ProgramInfo's?
20:14<xris>could make it start/end and list of chanids
20:15<gbee>ProgramInfo::ToStringList() is probably overkill for listings data, but maybe we should start by listing what data we'd expect
20:15<xris>same format that the upcoming/recorded program queries work now
20:15<sphery>that's ProgramInfo::ToStringList()
20:15<gbee>right, that's pginfo tostringlist
20:16<gbee>I'm thinking that for listings you just need, title, subtitle, genre and time
20:16<sphery>(my copy/paste was faster :) I'll see about coding it up and let you play with the patch... If usable, I can submit it for review.
20:17<gbee>the rest can be grabbed as requested, one at a time from the backend
20:17<sphery>Maybe a ProgramInfo::ToStringListLite() ;)
20:18-!-duerF [] has joined #mythtv
20:18<rooaus>^^^ Now with 50% less text
20:18<gbee>sphery: I'm only guessing that it would be faster and lighten the load on the server, I'd be interested to see the actual benchmarks of a Lite() version
20:19<sphery>xris: If I can clear a few other things off my list, I'm hoping to work on the recordedfile info, too (though perhaps with heavier data stored or potentially stored in the DB, too)
20:19<gbee>the bulk of a ToStringList is the text and that would be included in any Lite() version anyway
20:19<sphery>gbee: d'oh... benchmarks = do both approaches and profile = do twice the work plus a profile :)
20:20-!-TelnetManta [] has quit [Connection reset by peer]
20:20<xris>I need to find some time to do more work on mythweb stuff, but I'm hoping that by the time I do, SD will be ready to start our self-hosting project, which will then eat up all of my free time again.
20:21<sphery>xris: That's OK. kormoc has been a good xris double. (But we have missed you :)
20:21<gbee>sphery: I'd just benchmark against what we've got now :) But yes, it would be more work and that's why I was careful not to say you should actually do it
20:22<xris>sphery: yeah. that's why I hired him. :)
20:22<sphery>Actually, an interesting programming task is always worthwhile, even if you throw the code away. I enjoyed hacking a shell-based backup script, which I'm now planning to throw away and use a Perl-based one I wrote.
20:22<xris>both in real life, and for mythweb. :)
20:22<kormoc>amazingly enough, I really need to do a bit of low level php profiling with how we deal with protodata, it can take upwards of 80% of my execution time for certain strings to get worked out
20:22<rooaus>xris: An autoexpire manager/listing would be real cool in mythweb, seems a good interface for reviewing large lists of data. But sadly, my dog ate my patch :D
20:22*kormoc laughs
20:22<kormoc>I keep meaning to do that one of these days (tm)(r)
20:23<xris>kormoc: yeah. we could *definitely* improve the performance of mythproto by treating the strings as files and doing some binary-file read/write techniques rather than just using split() on the strings.
20:23<kormoc>Xris has been bugging me for about three and a half years to redo the video interface, and that's sorta mostly done
20:24<gbee>on a related matter, it's been a while since anyone did some profiling/benchmarks of the queries we are using
20:24<sphery>kormoc: would you consider a patch to MythWeb that defered loading of the recording details in the listings page until the mouse hovers over a link for a bit (0.25 seconds or so?) I feel guilty moving my mouse cursor off the listings window because of how many links I cross...
20:25<sphery>gbee: and now they can be profiled against MySQL 5 versions of the queries... :)
20:25<kormoc>sphery, Sure, I actually don't quite like the instant hit as well, but I didn't want to be the only one who felt that way :)
20:25<kormoc>sub-queries rock!
20:25<gbee>sphery: trust you to see where I was going with that ;)
20:26<sphery>kormoc: If I can figure it out enough, I'll try to code one up. That way, you'll have my name on the ticket/patch to defer blame...
20:26<gbee>here I go again, proposing more work even before I've finished the last lot ;)
20:27<sphery>we're afraid to let you run out of work as you might find other (non-Myth) things to do and we don't want to lose you.
20:28<gbee>sphery: you've given me a great idea, from now on I'll submit all my work as patches under a pseudonym - "It wasn't me guv, 'onest. It was Bob666!"
20:29<sphery>Hmmm. Have you noticed that all gbee does anymore is review patches from Bob666?
20:31<gbee>could develop into a split personality where I start rejecting my own patches because they aren't good enough ....
20:32<gbee>I don't have time to seek professional mental help, so I think I'll stick to the way things are now ;)
20:32<sphery>The Dark Half
20:33-!-mattwire [] has quit ["Leaving"]
20:58-!-Snow-Man [] has quit ["leaving"]
21:09-!-TelnetManta [] has joined #mythtv
21:27-!-mzb [] has quit ["Time to quit"]
21:31-!-MaverickTech [] has joined #mythtv
21:39-!-[Soul] [] has joined #mythtv
21:39-!-[Soul] [] has left #mythtv []
21:46-!-Snow-Man [] has joined #mythtv
21:51-!-Ozymandias2 [] has joined #mythtv
22:21-!-duerF [] has quit ["Ex-Chat"]
22:30-!-feiner_ [] has quit [Remote closed the connection]
22:32-!-feiner [] has joined #mythtv
22:59-!-fatejudger [] has joined #mythtv
23:00-!-fatejudger [] has left #mythtv []
23:00-!-sc00p [] has quit ["Leaving"]
23:33-!-sentinel [] has joined #mythtv
23:39-!-sigger__ [] has joined #mythtv
23:41-!-mkasson__ [] has quit [Read error: 110 (Connection timed out)]
23:44-!-sentinel is now known as sentinel23
23:58-!-degreseve1 [] has left #mythtv []
---Logclosed Mon Mar 10 00:00:16 2008