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

---Logopened Mon May 12 00:00:54 2008
00:17-!-foxbuntu [] has quit [Remote closed the connection]
00:21-!-foxbuntu [] has joined #mythtv
00:37-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit [Read error: 110 (Connection timed out)]
01:06-!-foxbuntu [] has quit ["Leaving"]
01:06-!-gnome42 [] has quit [Remote closed the connection]
01:25-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
01:27-!-xris [] has joined #mythtv
01:35-!-|gunni| [] has joined #mythtv
01:35-!-joobie_ [n=joobie@] has joined #mythtv
01:35-!-joobie [n=joobie@] has quit [Read error: 104 (Connection reset by peer)]
01:39<pkendall>I have been working on syncing ffmpeg to the latest revision and have this all done.
01:39<pkendall>Who do I send the massive patch to for this?
01:40<pkendall>Is it better to send a patch to a specific revision of ffmpeg which the directories are then copied to myth?
01:40<pkendall>Thats how I keep it up to date on my system.
01:45<Anduin>pkendall: janneg does that, he is working on it, so a lot of duplicated effort
01:46<pkendall>I've already completed it!
01:46<pkendall>I wanted to do it for NZ DVB-T testing.
01:47<kormoc>pkendall, janneg does weekly/monthly merges and keeps our custom patches in sync, are you keeping the custom patches in your tree?
01:48<Anduin>Yeah, just letting you know that it is done by someone (and the last one to complete it resulted in nothing)
01:51-!-_gunni_ [] has quit [Read error: 110 (Connection timed out)]
01:54<hads>pkendall: Isn't your patch against 0.21-fixes?
01:56-!-CrazyFoam [i=gturner@gateway/tor/x-8c392a40364b46c2] has joined #mythtv
01:58-!-xris [] has quit []
02:04<pkendall>Yes, mine is against 0.21
02:05<pkendall>I basically keep an ffmpeg svn copy with the patches for mythtv in it. Then I do svn up and manage
02:05<pkendall>the conflicts manually.
02:05<pkendall>Normally it jst works.
02:05<pkendall>Yes I keep the custom patches in my tree.
02:08<pkendall>From looking at subversion, the ffmpeg files are all from revision 10931 (i.e. over 2000 revisions old!)
02:11-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
02:12<hads>pkendall: Patches for myth are generally only accepted against trunk. Regardless, if you wait for janneg to be around he'll let you know the status, I believe he usually has fairly up to date syncs.
02:13<pkendall>Sure, I'll hang out.
02:13<pkendall>I needed to get ffmpeg up to date so I could get LATM for the AAC audio too.
02:14<pkendall>So I have a patche for that too.
02:14<pkendall>since the faad2 latm stuff is really broken.
02:17-!-purserj [] has joined #mythtv
02:22-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Read error: 113 (No route to host)]
02:34-!-xris [] has joined #mythtv
02:42-!-xris [] has quit []
02:52-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
03:06-!-dekar1 [] has quit [Read error: 104 (Connection reset by peer)]
03:06-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
03:07-!-dekarl [] has joined #mythtv
03:07-!-kormoc [n=kormoc@unaffiliated/kormoc] has left #mythtv []
04:13-!-joobie_ [n=joobie@] has quit [Read error: 110 (Connection timed out)]
04:16-!-phunguy [] has quit ["changing servers"]
04:21-!-phunguy [] has joined #mythtv
04:31-!-phunguy [] has quit ["changing servers"]
04:39-!-rm_you [n=rm_you@] has joined #mythtv
04:39<rm_you>anyone know if the PCHDTV 5500 does normal TV channels as well as HD? If I bought that could I get rid of my old WinTV PVR150?
04:40*stuarta points to the topic
04:40-!-phunguy [] has joined #mythtv
04:40<rm_you>thank you :)
04:46-!-phunguy [] has quit ["changing servers"]
04:46-!-phunguy [] has joined #mythtv
04:53-!-rm_you [n=rm_you@] has left #mythtv ["Leaving"]
05:26-!-phunguy [] has quit ["changing servers"]
05:27-!-phunguy [] has joined #mythtv
05:33-!-phunguy [] has quit ["changing servers"]
05:33-!-phunguy [] has joined #mythtv
05:54-!-stuarta [n=stuarta@unaffiliated/stuarta] has quit ["server rebootski"]
05:57-!-stuarta [n=stuarta@unaffiliated/stuarta] has joined #mythtv
06:34-!-grokky [] has joined #mythtv
06:49-!-Cougar [] has joined #mythtv
06:50-!-phunguy [] has quit ["changing servers"]
06:50-!-phunguy [] has joined #mythtv
06:56-!-phunguy [] has quit ["changing servers"]
06:59-!-phunguy [] has joined #mythtv
06:59<gbee>hmm, /proc/cpuinfo doesn't list sse3 for my cpu, but it's included on the instruction set list for this cpu on several sites
07:00<laga>maybe it's got a different name?
07:00<laga>no, i've got sse3 here, too.
07:03<MrGandalf>probably kernel version.. I don't see it either
07:04-!-MrGandalf [] has quit ["I hate mondays"]
07:04<laga>i'm running 2.6.24 from ubuntu
07:07<gbee>it's an x2 3600+ (Windsor, not Brisbane)
07:08<gbee>running 2.6.24
07:08<gbee>wanted to try compiling with -tune=k8-sse3 but it refuses
07:12<janneg>iirc sse3 is called pni, prescott's new instructions
07:13<laga>argh. yeah, i was looking at "ssse3"
07:13<gbee>are we using -O2 or -O3 for release builds?
07:13<gbee>janneg: ahh, well it's there then
07:13<janneg>the flag was added to linux before intel's marketing department decided to call them sse3
07:13<gbee>wonder why it still won't build with k8-sse3 then
07:14<janneg>we're using -O3
07:15<gbee>I could have just looked at the build args I guess :)
07:20-!-TelnetManta [] has quit ["Ex-Chat"]
07:30<gbee>doh, I assumed this machine had gcc 4.3 installed, the same as all my others - but it's using 4.2.3 which explains why k8-sse3 was failing
07:38-!-phunguy [] has quit ["changing servers"]
07:50<gbee>-Wdisabled-optimization ??
07:51-!-grokky [] has quit []
07:51<gbee>sorry, ignore me, just remembered what that flag does
07:59-!-brunes [n=jasonk@] has joined #mythtv
07:59<brunes>If I want to contribute a patch to mythweb; how do I go about it? Just write it and submit it to TRAC? or.. ?
08:00<brunes>I have a few improvements in mind
08:03<brunes>I am going to add 1) Paging to the guide page and search results page, and 2) a live TV viewer
08:03<stuarta>write the patch again svn head and submit it to trac
08:03<stuarta>that would be 2 patches btw
08:04<brunes>Paging is amust for me; I have a very large guide (from DVB), and it can't even all load in one page when I change PHP to use 256 MB of memory
08:04<brunes>I had to up it to 512 MB
08:04<brunes>even then it takes forever and a day
08:05<brunes>Also i think live TV would be very cool - in my head it seems farilt easy to implement assuming the mythfrontend telnet interface is enabled by the user
08:06<stuarta>there is design work in progress for the backend to transcode on the fly
08:06<brunes>Question - I don't run HEAD for mythtv (not ready to jump from my stable install), does the HEAD mythweb work with 0.21 mythtv ? unless the data schema has changed significantly it should be OK right?
08:06<brunes>stuarta: Well... the transcode in mythweb using ffmpeg right now seems to work fine
08:06<stuarta>your patches will be rejected if you code against 0.21
08:06<gbee>not sure the second patch would be accepted because the flash streaming is proof of concept and will change a fair bit
08:07<brunes>stuarta: No I mean can I use HEAD mythweb with 0.21 backend?
08:07<brunes>So I can code against HEAD
08:07-!-TelnetManta [n=benwilli@] has joined #mythtv
08:07<brunes>gbee: Well if it is rejected I will just use it myself :)
08:07<gbee>I think there may have been a protocol change since 0.21, so probably not - but try it and see
08:08<stuarta>you may have to continually hack the protocol version number
08:08<brunes>OK sounds good
08:08<stuarta>generally mythweb works across protocol changes
08:08<brunes>I could always install HEAD to a different dir
08:08<brunes>if I must
08:08<stuarta>that's what i have on this box
08:08<gbee>I made a recent-ish protocol change, but I can't remember if it was before or after 0.21
08:08<gbee>I can't even remember what the change was
08:09<stuarta>but wouldn't recommend it if you use packages
08:11<janneg>using mythweb HEAD with mythtv-0.21 will bork your non-ascii chars
08:11<brunes>Would you guys reccomend doing the livetv using the mythfrontend protocol or the native protocol? I was thinking the frontend protocol would be better since due to the non-synchronous nature of web pages I can't say, 'own' a tuner while my process is running (since each page is a process) so it would be better to let the frontend own the tuner and use the frontend remote control protocol, and just transcode it's video as it records it
08:12-!-phunguy [] has joined #mythtv
08:13<janneg>the alternative would be develop the patches against 0.21 and use a test system to test them against haed. I don't think mythweb had mayor changes since 0.21
08:13<stuarta>no i don't think so either
08:14-!-gardz [] has joined #mythtv
08:16<brunes>OK then - if I do the patch against 0.21 then I can just do a diff between 0.21-release and between HEAD, if they are identical, odds are the patch would be the same, then its just a quick test
08:18<brunes>I am surprised my problem hasn't been enoucntered before.... most people must have fairly small guides? I only have 865 chans.
08:18<janneg>they won't be identical but it's unlikely that your patch will be affected from the differences
08:20<janneg>thats three times more than I have and I could easily delete over hundred without missing something
08:20<brunes>Yeah alot of it is garbage... I have like 200 hidden
08:20<brunes>I have another question as well that I am thinking of writing some code for in the mythfrontend guide... has a request ever been made to have an option to not display the preview video in the guide?
08:20<GreyFoxx>brunes: I don't see how the frontend protocol would make a goog choice for LiveTV. You are best just using the mythproto for which there is code in mythweb to use already for the flash streaming of recordings
08:20<stuarta>i have 79 chans
08:21<brunes>I find it eats a lot of my CPU and I really have no use for it... I am thinkign an option could be there to continue playing the audio but just not show the overlay. Would save lots of CPU and also allow more guide rows if you turned it on
08:21<GreyFoxx>the frontend telnet controls are for controlling the frontend, and it's display/playback. Not for stream the data to another machine
08:21<brunes>GreyFoxx: Mythweb runs on the backend box not another machine
08:21<GreyFoxx>brunes: I believe that is configurable already
08:22<brunes>GreyFoxx: Really?? Where I searched for some time could not find it
08:22<GreyFoxx>brunes: I'm 99% sure It's in the frontend setup
08:22<brunes>holy crow, if it is you made my day
08:22<brunes>but I honestly did look for a long time and could not find it
08:22<GreyFoxx>worst casebut then, I also don't use livetv so I haven't seen that preview window in the guide in years :)
08:24<brunes>GreyFoxx: I really can not find this option :)
08:24<brunes>unless it is in some un-obvious place
08:27<GreyFoxx>I think it's TV Settings -> Playback, first screen.. option "Continue Playback when Embedded"
08:28<GreyFoxx>Might even be able to just turn it off in the theme, but I'd try that setting first
08:29<brunes>Continue Playback When Embedded says it is when you are browsing previous recordings
08:30<brunes>it affects the livetv guide as well?
08:30<GreyFoxx>It's would take you seconds to find out :)
08:30<GreyFoxx>Li9ke I said, I haven't actually used livetv in years :)
08:30<brunes>Hrm doesn't seem to.. :/
08:30<GreyFoxx>other than simple "does the tuner still work" tests
08:35-!-gbee2 [] has joined #mythtv
08:35-!-gbee [] has quit [Nick collision from services.]
08:35-!-gbee2 is now known as gbee
08:37-!-phunguy [] has quit ["changing servers"]
08:42<brunes>Hrm.... so, it seems to me like this toggle is part of the themeing even though there is no manual way to disable it
08:42<brunes>if (m_player && m_player->IsRunning() && allowsecondaryepg)
08:42<brunes> theme->LoadTheme(xmldata, "programguide-video");
08:42<brunes> else
08:42<brunes> theme->LoadTheme(xmldata, "programguide");
08:43<brunes>so maybe to do what I want I can just edit the base theme XML
08:43-!-famicom [] has joined #mythtv
08:46-!-lsobral [n=sobral@] has joined #mythtv
08:48<gbee>brunes: that code will disappear hopefully before 0.22 is released
08:50<brunes>blah :(
08:51<brunes>gbee: You should add this option too while you're deleting that code :)
08:55-!-lsobral [n=sobral@] has quit [Read error: 104 (Connection reset by peer)]
08:56-!-lsobral [n=sobral@] has joined #mythtv
08:56-!-brunes [n=jasonk@] has quit [Remote closed the connection]
09:04-!-phunguy [] has joined #mythtv
09:11<gbee>cc1: warning: -funit-at-a-time is required for inlining of functions that are only called once
09:28-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:34<gbee>dbcheck.cpp takes forever to compile under gcc 4.3
09:36-!-siXy [] has joined #mythtv
09:42-!-bog1 [] has joined #mythtv
09:42-!-bog1 [] has left #mythtv []
09:48-!-foxbuntu [] has joined #mythtv
09:53-!-j-rod [n=jarod@nat/redhat-us/x-0cc474e8e2c0a3ee] has joined #mythtv
10:02-!-melunko_ [n=hmelo@] has joined #mythtv
10:05-!-danielk_Zzzzzz is now known as danielk22
10:10<gbee>really not kidding about it taking forever ... it's been over an hour
10:20-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
10:20<stuarta>that's ridiculous
10:22<gbee>I'm starting to wonder if it's still compiling or if gcc has hung :)
10:22<stuarta>strace it
10:23<danielk22>gbee: I bet it has hung..
10:24<danielk22>Any cpp with lots of strings in it takes a long time in newer gcc's, but not an hour.
10:24<stuarta>what have they done to gcc.
10:24<kormoc>It could be swapping, that increases the time a lot
10:24<stuarta>it used to be fast
10:26<janneg>gcc-2.95 was fast
10:26<gbee>hmm, looks like it's hanging - fun
10:27<janneg>try -O2 for C++
10:27<gbee>or not, strace is showing activity
10:32<gbee>killed off X and a few other processes to free up some memory and it seems to doing better now
10:33<gbee> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND20069 mythtv 20 0 1105m 769m 756 D 20 87.5 0:59.39 cc1plus
10:35-!-MrGandalf [] has joined #mythtv
10:36<MrGandalf>Can someone (briefly) explain to me how myth calculates the length of a recording?
10:41-!-phunguy [] has quit ["changing servers"]
10:41<kormoc>filesize? play length? recording length?
10:42<MrGandalf>regarding recordings showing double length.
10:42<MrGandalf>recordings, not livetv
10:43<MrGandalf>looking at the entry in recorded and the entries in recordedseek I don't see where it can get doubled.
10:46<janneg>it's calculated from recordedseek
10:46<MrGandalf>from the 'mark' column?
10:46<danielk22>last frame / (fps at beginning of recording)
10:48<MrGandalf>all of my h264 recordings are doubled and the frame rate is constant.. just trying to figure out why or at least script a quick fix for the db.
10:49<GreyFoxx>Mrg: I'd have 2 recordings in the last week that were definately 1 hour show as 1hr 59mins xx secs
10:49<GreyFoxx>didn't look into it though
10:50<danielk22>mrg: when you skip 30 seconds ahead does it go 30 seconds or 60 seconds?
10:50<danielk22>(skipping back may work correctly).
10:51<GreyFoxx>I'll dump out the recordedseek on the next one
10:52-!-rwalker [n=chatzill@] has joined #mythtv
10:53<MrGandalf>danielk22: skipping (both directions) is half what it should be. In other words, skip 30 == 15 seconds.
10:54-!-gnome42 [] has joined #mythtv
10:55<danielk22>Then either the fps is off or it is not detecting frames correctly in dtvrecorder.
10:56<MrGandalf>thanks, I'll look at that
11:02<MrGandalf>So it keeps key frames in the position map then
11:03-!-stoth [] has joined #mythtv
11:05<MrGandalf>and increments frames written for all non-keyframes so I'm assuming it's getting fps from that then.
11:07<danielk22>mrg: not sure, it might be getting it from ffmpeg based on some stream descriptor.
11:08<danielk22>It is often inaccurate for DTV recordings, so I'm pretty sure it's based on some descriptor sampled once during the recording.
11:10<MrGandalf>danielk22: this is an h264 recording, so I'm pretty sure it's not ffmpeg (please correct me if I'm wrong)
11:11<MrGandalf>I'm guessing DTVRecorder::FindH264Keyframes()
11:12<danielk22>look for SetFrameRate() .. in the recorders
11:12<danielk22>or anything else setting video_frame_rate
11:15-!-bendailey [] has joined #mythtv
11:17<danielk22>mrg: it looks like the video frame rate is actually set by calling SetVideoParams in avformatdecoder, so it does look like we just get it from ffmpeg's header parsing.
11:17<MrGandalf>in FindH264KeyFrames(), _frames_written_count is incrementing at a rate of 60 frames/second and the video is only 30fps
11:18<MrGandalf>that sucks then
11:18<danielk22>MrG: So it is not the fps that is the problem, it is FindH264KeyFrames().
11:19<danielk22>(In your case, people have different problems that have the same, or similar, symptoms.)
11:20<MrGandalf>I'm pretty ignorant here.. if a frame is not a keyframe, and not an audio/video frame, what could it be? Or could the audio and video frames be seperate?
11:21<danielk22>Not audio, it should only be looking at the video pid. But we don't demux the stream so our frame counting is only approximate.
11:22<janneg>the frame counting could also be off. we could be counting fields instead of frames
11:23<MrGandalf>janneg: very good point
11:23<MrGandalf>considering it's interlaced.
11:29<MrGandalf>hmm, fixing such a beast is probably beyond me then
11:30<MrGandalf>well, maybe..
11:30<MrGandalf>bbl, lunch..
11:31-!-phunguy [] has joined #mythtv
11:36-!-siXy [] has quit ["bye!"]
11:47<gbee>anyone else using gcc 4.3?
11:48<stuarta>that reminds me, i was going to install that :)
11:48-!-ille [] has quit [Remote closed the connection]
11:50-!-ille [n=christia@pdpc/supporter/student/ille] has joined #mythtv
11:55-!-jmk_ [n=jmk@] has joined #mythtv
12:00<gbee>really doesn't want to compile dbcheck :(
12:00<gbee>after a few minutes it just hangs
12:07<sphery>gbee: in theory people are--there have been several gcc 4.3 fixes checked in
12:09<gbee>at this rate I might try compiling dbcheck with 4.23 and seeing if mixing the two compilers on one build is a recipe for disaster :)
12:11<janneg>gbee: have you tried building it with different parameters
12:11<kormoc>gbee, I've frozen on 4.1.2 for awhile now
12:12<janneg>especially without -O3
12:12<gbee>janneg: yes, -O2 and a different -march, but so far it hasn't seemed to make much difference
12:12<janneg>try -O0
12:13<gbee>kormoc: I was after the SSE3 support in 4.3 to see if it made any difference to h.264 decoding performance
12:13<kormoc>ooh, I didn't know they finally added that, hrm...
12:13<gbee>it may not, but I wanted to experiment
12:18<gbee>waiting for it to fail with -march k8 but it hasn't yet, it's still very slow though
12:19-!-xris [n=xris@] has joined #mythtv
12:23<gbee>ok, works and is pretty fast with -O0
12:27<gbee>mpeg/tspacket.h:78: warning: array subscript is above array boundsmpeg/tspacket.h:145: warning: array subscript is above array bounds
12:32<Anduin>gbee: the version in trunk doesn't have that problem
12:33<gbee>Anduin: yeah, I was forgetting that this was a 0.21 build because I normally run production systems from trunk
12:38-!-mattwire [] has joined #mythtv
12:38<gbee>hasn't been fun being the clueless user this last week, between h.264 decoding issues, alsa bugs, fglrx refusing to build on 2.6.25 and the looming prospect of getting the DVB-S2 card working I'm starting to remember why people are often frustrated when setting up MythTV systems for the first time :)
12:39-!-phunguy [] has quit ["changing servers"]
12:40-!-phunguy [] has joined #mythtv
13:01<danielk22>gbee: that tspacket.h warning can safely be ignored.
13:02<gbee>danielk22: ok
13:03<stuarta>gbee: you got a dvb-s2 card?
13:07<gbee>stuarta: ordered it, should be here tomorrow or the day after
13:08<stuarta>ooo, i'm thinking about a dvb-s card, so if s2's aren't too bad it might be worth getting
13:08<gbee>right, well switching to gcc 4.3 and using k8-sse3 OR switching from a debug to a release build fixed the HD playback issues
13:08<stuarta>what's driver support like in theory?
13:08<gbee>stuarta: I flipped a coin between S and S2
13:08<gbee>with the latest v4l it should it theory work fine
13:09<stuarta>well let us know
13:09<stuarta>not sure if it's worth the extra 40-50quid tho
13:14<Dibblah>gbee: Have you looked at the fast cmov issue?
13:14<gbee>it was 2x the price of the equivalent DVb-S, but I figured that if freesat switch to S2 next year then I'll be paying for it anyway
13:14<gbee>Dibblah: no
13:14<Dibblah>(configure detects fast cmov incorrectly in most cases)
13:14<Dibblah>Which is not good for h.264)
13:14<Dibblah>There's a ticket, but the patch on it is demonstrably wrong.
13:14<gbee>Nova-HD-S2 cost £64, Nova-S is £30-something
13:14<gbee>Dibblah: detects slow cmov here
13:14<Dibblah>Which is wrong, unless you have netburst.
13:14<gbee>my decoding problem wasn't too serious, just a prebuffering pause every 6-10 seconds with a BBC HD sample (1080i)
13:14<Dibblah>Yes, I see that too. It's worse with cmov avoided (fast cmov: no)
13:15*Dibblah wonders what wonders the next ffmpeg sync will bring...
13:15<gbee>Dibblah: I hadn't thought about it before, I didn't really know which cpus were supposed to support it
13:16<Dibblah>CMOV is only slow on netburst CPUs, according to the ticket.
13:16<gbee>building with -march=k8-sse3 fixed it, at least with the sample
13:16<Dibblah>ISTR it's broken by the 'default / no' difference.
13:16<gbee>if the cmov issue also helps then it can't hurt
13:17*gbee goes to find the patch
13:17<Dibblah>Whups - Sorry - I'll find it.
13:17<Dibblah>Not meaning to tease :)
13:17<sphery>gbee: I would expect that switching from debug to release build would give you a pretty large (10+%--maybe even 20%) performance improvement in playback. It does on my systems.
13:18<Dibblah>Use profile, not debug.
13:18<gbee>Dibblah: don't even need debug on that machine, so release is fine
13:18<Dibblah>Which should theoretically be the same as release, just with symbols.
13:19<Dibblah>The patch is wrong, since the section of code at line 1852 doesn't get executed.
13:19<gbee>sphery: yeah, I figured that would be enough to fix it and I hadn't realised that it was a debug build when I was initially trying to solve the performance problem
13:19<sphery>yeah, debug explicitly disables some optimizations
13:19<Dibblah>($cmov is not default, it's yes by that point in the script)
13:20<gbee>by the time I actually looked at my configure args I'd already decided to try 4.3 + sse3 so I wasn't going to build twice - one of those, or both fixed it and I don't really care which
13:20<Dibblah>Due to line 1486
13:20<Dibblah>:) okay. Sorry for the noise.
13:21<gbee>Dibblah: nah, it all helps :)
13:22<gbee>I'll hack up a quick fix for cmov and see if that gives a further boost
13:25<gbee>Dibblah: have you let dagmar know that the patch is wrong?
13:27<Dibblah>Yes - Unfortunately, he doesn't want to look at it any more, since the rest of cpu autodetection is horribly broken and makes his head hurt, to paraphrase.
13:27-!-lsobral [n=sobral@] has quit [Read error: 104 (Connection reset by peer)]
13:30-!-lsobral [n=sobral@] has joined #mythtv
13:34<gbee>right, I was hoping to avoid fixing it myself for that reason :)
13:34*gbee sighs
13:45<mattwire>Ticket #5340 looks like the qt3 listbox scrolling bug
13:46<Dibblah>gbee: a quick fix is as above.
13:46<mattwire>I'm looking at #5339 because I think I have a neater way of fixing it
13:46<Dibblah>Change 1852 so it recognises 'yes' or 'default', as well as applying the patch as given. ISTR.
13:56-!-|gunni| [] has quit [Read error: 110 (Connection timed out)]
13:56-!-|gunni| [] has joined #mythtv
14:01-!-rwalker [n=chatzill@] has quit [Remote closed the connection]
14:03<gbee>Dibblah: I was thinking of a commitable fix, though even a quick fix is better that nothing
14:04-!-jgarvey [] has joined #mythtv
14:20-!-lsobral [n=sobral@] has quit ["Ex-Chat"]
14:22-!-j-rod_ [n=jarod@nat/redhat-us/x-f26cf5c690ce2dc0] has joined #mythtv
14:22<janneg>fast cmov autodetection is not worth the hassle, it should be fast with --cpu=k8
14:23<janneg>gbee: DVB-S2 won't work with latest v4l-dvb hg
14:26-!-j-rod [n=jarod@nat/redhat-us/x-0cc474e8e2c0a3ee] has quit [Nick collision from services.]
14:26-!-j-rod_ is now known as j-rod
14:26<MrGandalf>janneg: not even in the multiproto branch?
14:27<MrGandalf>you could always hack in support for the EXTENDED API which Myth supports.
14:27<janneg>I don't know but I don't expect it to get merged anytime soon
14:32<stuarta>doh that broke
14:34<stuarta>okay, why would XCloseDisplay cause the frontend to segfault
14:40<Dibblah>janneg: Well, currently, fast cmov is not detected correctly by configure, hence the ticket.
14:40-!-lsobral [n=sobral@] has joined #mythtv
14:41<gbee>janneg: err, won't work with any version, or it's just broken at the moment?
14:42<janneg>Dibblah: it should currently detected correctly with manual cpu selection with --cpu
14:43<gbee>janneg: we need to add k8-sse3 to the list
14:43<janneg>gbee: no repo on has support for dvb-s2
14:43<gbee>janneg: oh f**k
14:43<gbee>damn wiki implied it was supported ...
14:44*gbee has a sense of humour failure
14:44<Dibblah>janneg: ./configure --cpu=k8
14:44<MrGandalf>DVB-S2 works with a couple cards using the EXTENDED API (very old patch). I believe one S2 card is supported in the multiproto branch.
14:45<Dibblah>CMOV is fast no
14:46<Dibblah>It breaks because $cmov is explicitly set to yes for x86_64
14:46<gbee>janneg: as Dibblah says the existing configure doesn't set it correctly, fast_cmov is only set in the {test x"$cmov" = x"default"} block
14:46<Dibblah>... And the test for fast cmov is wrapped in if $cmov = "default"
14:47<gbee>and the arch == "x86_64" block sets cmov="yes" before that test
14:47*gbee leaves Dibblah to explain
14:47<Dibblah>Heh. You're doing fine.
14:49<janneg>ah, ok. I didn't read configure. it was working once
14:49<gbee>I suppose one fix would be to remove the cmov="yes" from the arch test
14:50<janneg>gbee: which wiki said it is supported?
14:51-!-Chutt [] has quit [Remote closed the connection]
14:51<gbee>says experimental support - which may mean there are patches, even if they aren't in the repo - but doesn't say where to find them
14:51<kormoc>gbee, mailing list has been the historic place with links
14:53<stuarta>the repository of on steven toth who works for hauppage iirc
14:54-!-melunko_ [n=hmelo@] has quit [Read error: 113 (No route to host)]
14:55<janneg>gbee: it's proabbaly supported in manu's multiproto repo
14:56<gbee>janneg: thanks, guess I'll need patches for mythtv support too?
14:56<MrGandalf>but that means a patch to support multiproto in Myth is in order.
14:57<stuarta>gbee: i suspect others may have already had a bash at the myth side
14:58*gbee decides to cancel his order as he doesn't have time to sort the mess of patches out, unfortunately
14:58<danielk22>mrg: i feel like i may have already committed such a patch a couple years ago...
14:58<danielk22>manu sent me some patches...
14:59<MrGandalf>danielk22: I think you committed the EXTENDED API stuff from Alan.
14:59<MrGandalf>which won't be supported going forward.
14:59<danielk22>could be, it was a long time ago.. i don't think either one looks like it will ever get into trunk.
14:59<janneg>I think MrGandalf is right
15:00<stuarta>ah feck, compiled without debug info for the production frontend on my dev box
15:00<MrGandalf>But please don't rip out the EXTENDED API until the Genpix is supported in multiproto :)
15:00*stuarta tries the dev versino
15:01<janneg>the extended API was abandoned when multiproto was started
15:01<danielk22>mrg: i'm not ripping anything out until some API makes it into the kernel...
15:02-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
15:03<danielk22>heh, or someone writes something better than that whole DVB driver tree.. one can always hope...
15:08<MrGandalf>So, would halving all my recordedseek.mark values fix my double length recording issue after the fact?
15:09<stuarta>try it and see
15:09-!-robthebob [] has joined #mythtv
15:11<gbee>janneg: thanks, but I've already emailed in the cancellation for the order
15:11<famicom>can someone please explain some more details on the mythtv sound system
15:11<janneg>yeah, right
15:11<gbee>I suspect that patch may not compile against 2.6.24 or any number of additional problems will arise, I'd rather go with something that isn't so much trouble
15:12-!-cattelan is now known as cattelan_away
15:12<gbee>just need to find a supported DVB-S card for under £40 now
15:12<famicom>gbee with or without CI module
15:12<famicom>so just plain free to air?
15:13<famicom>I can get you that
15:13*famicom buys his toys directly from the supplier
15:15<stuarta>ah bugger, it's not the EXA acceleration thats breaking it :(
15:15<famicom>DVB-S Sat Pro 450i or WinTV-NOVA-S-Plus
15:15-!-cattelan [] has joined #mythtv
15:15<laga>stuarta: breaking what?
15:16<stuarta>xorg 7.3 update came down into debian testing in the last few days
15:16<laga>nvm, just hoped it might be related to the segfault in we're seeing in ubuntu ;)
15:16<famicom>gbee, tell me which one you want and i'll hook you up
15:16<stuarta>now my frontends wont run
15:17<stuarta>which is better than x crashing which was the first problem
15:22<gbee>famicom: don't mind which model as long as it's supported by a recent kernel and doesn't cost too much, Dibblah has pointed out one which costs £40 (?50) including shipping, anything below that is fine
15:22<famicom>is this a personal or a business transaction
15:24<Dibblah>Effectively, these are nova S Plus's - But they're clones by Satelco.
15:25<famicom>could be
15:25<famicom>i just skimmed over my list of available stock
15:33<gbee>tired of getting this new machine sorted, I just want to get back to working on mythui
15:33<sphery>laga: Are all the problems on ATI-based systems? The one on the -dev list is (I was trying to help yesterday, saw the and had him load libc-dbg to get more details) and the two bugs you posted in reply are.
15:35<sphery>The segfault with the libc-dbg shows it occurring in, so danielk22 said it's unlikely to be a problem in Myth. Perhaps video drivers?
15:37<famicom>sphery yeah
15:37<famicom>same probleem here
15:38<danielk22>Technically I said it was unlikely to be a ld-linux problem in MythTV, but we may be triggering something in the driver due to a bug in MythTV. There is no way to know that with the information we have so far.
15:38<danielk22>Or, triggering something in X11 due to a bug in MythTV.
15:39-!-jarle [] has quit [Remote closed the connection]
15:41<sphery>danielk22: Thanks. I was trying to shorten the recap of the conversation a bit and knew you'd do it better.
15:43<danielk22>heh, I just don't want to be the guy who said it wasn't a mythtv bug when this is problem is eventually traced to some X11 call we made without the X11 lock in place, or something like that :)
15:43-!-bendailey [] has left #mythtv []
15:43<famicom>is this about X segfaulting during playback?
15:44<famicom>because if so, It's probably related due to the ati XV extension
15:44<sphery>famicom: Yeah. So far, reports on Ubuntu systems with ati driver.
15:44<famicom>sphery yup
15:44<famicom>Its funnyt that you guys mention it
15:44<famicom>because i was just working on it
15:44<sphery>fixing it?
15:45<famicom>figuring out what it was first
15:46<sphery>and you think you know what's causing it (something different about the ati implementation of the Xv extension or something?)
15:47<famicom>from what i know, it's caused by the fglrx XV extension
15:47<famicom>it affects xine as well
15:47<gbee>odd and this is with 0.21?
15:48<famicom>funnily enough, gstreamer seems unaffected
15:49<sphery>yeah, 0.21. I think most (all) of the reports are with the ati driver, not fglrx (see )
15:50-!-jarle [] has joined #mythtv
15:50<famicom>well, overall it seems to work like a breeze
15:50<famicom>except of certain HD streams
15:50<famicom>it renders a few frames, then chokes and dies
15:51-!-jarle [] has quit [Remote closed the connection]
15:52<gbee>this new machine is using fglrx with 0.21 built from source, I've had no crashes with it
15:52<famicom>try xine for a second
15:53<gbee>incidently HD works fine over HDMI out with fglrx, but that's a discussion for -users
15:54<famicom>fbee, what about sound>
15:54<gbee>famicom: I'd have to install xine first
15:54<gbee>famicom: no sound over HDMI -
15:54<gbee>known bug
15:55<famicom>actually, i got perfect working sound in gstreamer
15:56-!-jarle [] has joined #mythtv
16:00<mattwire>could someone do me a favour and run "mythtv-setup -v most" and run the channel icon downloader for a single channel
16:01<mattwire>I keep getting "Got 0 bytes from url: '" when I try and run it but it's fine when I do it in a web browser..
16:01<mattwire>just want to know if anyone else sees the same thing
16:03<gbee>I wasn't seeing it when I committed it
16:03<mattwire>no it was fine then
16:03<gbee>I had to fix a few things and I wasn't entirely happy with the state of it, but it was working
16:04<gbee>mattwire: oh ... wonder if xris changed something, or is this with trunk post QT4?
16:04<mattwire>that's what I'm wondering
16:04<mattwire>yes it's trunk post qt4
16:04<mattwire>hence I'm wondering if httpcomms might be broken
16:05<gbee>ok, it's almost certainly QT4 related, I'm pretty sure I've already seen another instance of httpcomms breakage
16:05<mattwire>yep, just need someone to verify :)
16:05-!-jpabq [] has joined #mythtv
16:06<gbee>ok, I'm checking
16:07<xris>gbee: I haven't touched that code in ages
16:07<gbee>xris: thanks, I think that confirms that it's a QT4 issue
16:07-!-richards [] has joined #mythtv
16:08<gbee>mattwire: I'm not seeing it
16:09<mattwire>so if you select a single channel it's giving you a list of possible icons fine?
16:11<gbee>no wait, I forgot to delete the existing icon
16:11<gbee>yeah Got 0 bytes from url: ''
16:11<mattwire>ah good...
16:12<mattwire>that means I'm not going crazy :)
16:12<mattwire>looks to me like httpcomms is not returning any data
16:12<gbee>a full scan fails too
16:12<mattwire>because the query runs fine from a web browser
16:13<mattwire>it will fail if httpcomms returns nothing
16:13<mattwire> QString str = HttpComms::postHttp(url,&header,&data);
16:13<gbee>mattwire: I can probably take a look at it later this week if you don't find the cause, but I suggest looking at differences between QHttp etc in QT3 and QT4
16:13<mattwire>will try and take a look
16:14<mattwire>may not get much time later in the week though :(
16:14<mattwire>do you think it's worth opening a ticket so it doesn't get lost?
16:15<gbee>if there isn't already a ticket open then yes, put QT4 somewhere in the subject
16:20-!-ille_ [n=ille@pdpc/supporter/student/ille] has joined #mythtv
16:23-!-TelnetManta [n=benwilli@] has quit ["Ex-Chat"]
16:25-!-MrGandalf [] has quit ["home"]
16:31<danielk22>FYI The UDP notifier code is also broken by Qt4 networking changes.
16:31<danielk22>I opened up a ticket for it at some point in the last 2 weeks.
16:32<gbee>if I get time I'll look at both
16:32<danielk22>My guess is the IPTV channel downloading code is broken too. But I haven't checked it.
16:34<gbee>danielk22: you were aware that someone was in here recently trying to use the flagger as a standalone app without the DB?
16:37<gbee>don't remember the guys name, just that he was very persistant
16:37<danielk22>If so yeah, I told him to post to mythtv-dev with the info.
16:38<danielk22>I'd like to make a few things not rely on the DB, not just the commercial flagger.
16:38*gbee puts 2 and 2 together
16:38<sphery>danielk22: and he offered money for the owrk (hope you took him up on the bounty)
16:38<gbee>yeah, I see now
16:38<danielk22>The new channel scanner for instance.
16:43<danielk22>I referred him to Chris Pinkham for the change, but Chris didn't respond so I'm going to look at tailoring the output to Cyrus' requirements for the bounty. I'm just did some groundwork this weekend which I'm committing in functional chunks right now.
16:53-!-pkendall [] has quit [Read error: 110 (Connection timed out)]
16:57-!-foxbuntu [] has quit [Remote closed the connection]
16:58-!-jmk_ [n=jmk@] has quit ["Leaving"]
17:15*stuarta disables opengl video sync and it works again
17:30<danielk22>stuarta: The opengl video sync uses the last of the X11 calls I know of in MythTV (outside of Qt) which doesn't employ the X11 lock.
17:30<danielk22>It's long been on my TODO list to fix.
17:31<gbee> speaking of which -
17:32<stuarta>would it cause it to crash at playback start?
17:32<danielk22>yeah, I'm not sure how to handle Qt's X11 calls.. (anything with glX is an X11 call.)
17:33<danielk22>(And the X11 libraries are not thread-safe.)
17:33<stuarta>here's me thinking it was just the xorg 7.3 upgrade
17:33<stuarta>which meant i've been in text mode for an hour or two
17:33<stuarta>while i completely reconfigured X
17:34<danielk22>xorg 7.3 may have made the problem worse, but there is any underlying problem in MythTV's X11 usage.
17:34<stuarta>cause my old xorg.conf caused a segfault in the x driver
17:34<stuarta>fair enuf
17:34<stuarta>the graphics side is a whole can o worms that i've left well closed
17:36<danielk22>Mark Kendall sent me a bunch of patches last week to cleanup video locking stuff that I haven't had a look at yet, but that wouldn't help with an QtGL problems.
17:37<stuarta>well i now have a way of testing it :)
17:37<stuarta>anyway bedtime
17:38<laga>sphery: re yes, seems to happen with the free ati driver.
17:46<gbee>danielk22: I'd like to synchronise the mythcommflag and mythtranscode arguments, no preference on the end result, merely that I'd like them to be the same
17:46-!-robthebob [] has quit [Read error: 104 (Connection reset by peer)]
17:47<laga>stuarta: opengl vsync doesn't work for me anymore in the latest radeon driver.
17:48<danielk22>gbee: k, did you notice the new MythCommandLineParser ? I'd like to use that to hold at least the common cmd line arguments.
17:49<danielk22>It's pretty bare at the moment, but it's written to be pretty general down the line.
17:49<gbee>danielk22: that's why I mentioned it
17:50<danielk22>yeah, it's silly to have multiple implementations for things line --chanid
17:50<gbee>atm you have a situation where mythtranscode uses "--infile or -i" while mythcommflag uses "--file, --video" etc
17:51<danielk22>file & video are not the same thing.. but yeah, that's a problem too.
17:51<gbee>danielk22: yeah, mythtranscode uses a --video flag, but the filename is still provided with --infile
17:52<danielk22>We should probably depreciate the old arguments for a while before removing them so as not to break external scripts.
17:52<gbee>which makes a certain amount of sense - but still I've no preference on which approach is used, as long as they are the same
17:52-!-czth__ [n=dbrobins@nat/microsoft/x-515fcba4722401d5] has joined #mythtv
17:53<danielk22>--infile --outfile make sense to me.
17:53<gbee>danielk22: that would be my intention, just remove them from --help and allow them to work, maybe even print a warning but without stopping execution
17:53<danielk22>yeah, print a warning so people will be reminded to fix the scripts..
17:53<laga>stuarta: correction: opengl vsync never worked for me with the radeon driver, but it's broken in the current driver. here's what it takes to get drm vsync to work for me:
17:53<danielk22>i'm all for it.
17:54<gbee>laga: OS driver?
17:55<gbee>nm, just looked at the bug
17:57-!-mattwire [] has quit [Remote closed the connection]
17:57-!-MrGandalf [] has joined #mythtv
17:58-!-richards [] has quit ["bye all"]
17:59-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:01<MrGandalf>hmm, halving recordedseek.mark values does indeed fix double length recordings.
18:02<danielk22>does skipping still work without spam in the frontend log?
18:03<MrGandalf>just a sec and I'll tell ya.. trying that trick on another recording..
18:04<MrGandalf>2008-05-12 18:03:50.863 AFD: DoFastForward(3023 (2155), do discard frames)
18:04<MrGandalf>2008-05-12 18:03:50.863 Dec: DoFastForward(3023 (2155), do discard frames)
18:04<MrGandalf>2008-05-12 18:03:50.864 AFD: SeekReset(3044, 0, do flush, do discard)
18:04<MrGandalf>2008-05-12 18:03:50.864 AFD: SeekReset() flushing
18:04<MrGandalf>Looks normal
18:05<MrGandalf>so it very likely then that it's counting fields and not frames
18:05<danielk22>I dunno, someone needs to look at a the spec to know for sure.
18:06<MrGandalf>I looked at the spec.. but then again, I don't really know what I'm looking at :)
18:07-!-jgarvey [] has quit ["Leaving"]
18:09-!-czth_ [n=dbrobins@nat/microsoft/x-63e8ecac8667263a] has quit [Read error: 110 (Connection timed out)]
18:12-!-Gokee2_ [] has joined #mythtv
18:13-!-Gokee2 [] has quit [Connection timed out]
18:22<janneg>or the file is reported as 30fps instead of the correct 60fps
18:24<danielk22>janne: I think he checked that already.
18:25<janneg>MrGandalf: the playback time is ok? i.e. is it after one minute real time playback at position 1:00?
18:25-!-danielk22 [] has left #mythtv []
18:25<janneg>it shouldn't if we're counting fields as frames
18:26<MrGandalf>janneg: I don't know about exact, but I do know that if I ffwd all the way to the end it is indeed at the end of the recording where it should be.
18:26<GreyFoxx>Janne: I've had a couple recordings recently, that showed double length and definately played at a normal speed and reported the proper location
18:26<GreyFoxx>next once I run into I wont delete
18:27<MrGandalf>My recordings, without modifying the seek table, show double and seek at half what they should.
18:27<janneg>MrGandalf: ffwd should be ok. playback could be broken
18:28<MrGandalf>if I half all the mark values, length is fine and seeking seems fine
18:28<janneg>and playback speed should be fine. but the reporting of playback time might be broken
18:28<janneg>MrGandalf: yes, that's expected
18:29<janneg>but is playback after 1 minute at the reported position 1 minute
18:30-!-danielk22 [] has joined #mythtv
18:30<MrGandalf>as I said, I don't know that it's exactly one minute into the recording but it seems to be and the position indicator shows one minute in.
18:31<MrGandalf>lemme look closer..
18:31<janneg>I suspect that it is. that would mean that the keyframe detection in dtvrecorder is counting fields as frames
18:31<janneg>MrGandalf: if it's broken it should be off by factor 2
18:31<MrGandalf>janneg: KeyframeSequencer::KeyframePredicate()
18:33<MrGandalf>Ok, I just wanted one minute of the recording, noted the position, went back to the beginning and ffwd to one minute in and it's in the same spot as it should be.
18:34<janneg>ok. so the error is definitively in the frame counting
18:34-!-Discordian [] has joined #mythtv
18:34-!-Discordian [] has left #mythtv ["Leaving"]
18:35<MrGandalf>the mpeg2 frame counting looks at the stream_id (if I remember correctly) in the PES header. There's no equivenlent in h264.
18:36<MrGandalf>stream_id for h264 seems always to be 0x00.
18:36<MrGandalf>no it looks for h264 NALs instead.
18:37<MrGandalf>And I'm guessing a SLICE NAL only contains a single field and not a whole frame.
18:59<janneg>I think the frame counting is completely broken for interlaced content. i.e. KeyframeSequencer::IsOnFrame() is broken
19:00<janneg>it's not the slice NAL, H.264 with multiple slices has correct lengths
19:04-!-joobie [n=joobie@] has joined #mythtv
19:04-!-lsobral [n=sobral@] has quit ["Ex-Chat"]
19:08<MrGandalf>IsOnFrame() only indicates that it found a SLICE.
19:08-!-CDev [] has quit [Read error: 104 (Connection reset by peer)]
19:12-!-beandog [n=steve@gentoo/developer/beandog] has joined #mythtv
19:13-!-_gunni_ [] has joined #mythtv
19:20-!-aneiane [] has joined #mythtv
19:21-!-CDev [] has joined #mythtv
19:24-!-stoth [] has quit [Remote closed the connection]
19:29-!-|gunni| [] has quit [Read error: 110 (Connection timed out)]
19:29-!-beandog [n=steve@gentoo/developer/beandog] has quit ["Leaving"]
19:29-!-brunes [] has joined #mythtv
19:30<brunes>question - is there a reason why there is a multi-column promary key for channum, sourceid, and visible in the channel table?
19:30<brunes>If I remove that primary key will things explode?
19:31<brunes>I want to be able to have multiple version os a channel in my guide with different channel numbers
19:34<MrGandalf>I created a patch once to support that
19:34<brunes>MrGandalf, So... just dropping this key and manually altering the table would not work?
19:34<MrGandalf>dunno.. sounds like a bad idea though
19:35<brunes>ill try it
19:35<clever>droping the primary key would also harm performance
19:35<clever>changing to a plain index would be better
19:35<brunes>it isnt the primary key
19:35<brunes>it is just an ancillary key
19:35<brunes>a constraint
19:35<clever>a unique key?
19:35<brunes>there is a constraint on those creating a key
19:36<MrGandalf>use the channel.chanmap to create your secondary channel mapping
19:37<brunes>ohhh nice
19:37<brunes>are these against HGEAD ?
19:37<MrGandalf>so that channel then gets duplicated in the guide with a slightly different color but the channel table doesn't have duplicate channels to support it.
19:37<MrGandalf>latest release.. might work in trunk
19:38<brunes>I am using release
19:38<brunes>so this should apply cean? nice
19:38<brunes>I'll try this tonight
19:38<brunes>My wife wants the chans to line up with our "old cable" :)
19:38<brunes>but I dont want to mess up the groupings
19:39<MrGandalf>that'll do it :)
19:40<brunes>So accroding to this patch I have to add a chanmap column as well correct?
19:40<brunes>to the channel table
19:40<MrGandalf>if you duplicate channels in the channel table, guide data won't get filled in
19:40<MrGandalf>yes, sec
19:40<MrGandalf>ALTER TABLE channel ADD COLUMN chanmap VARCHAR(10) NULL DEFAULT NULL AFTER channum;
19:41-!-Dibblah [] has left #mythtv ["Kopete 0.12.4 :"]
19:51-!-MaverickTech [] has joined #mythtv
19:51-!-MaverickTech [] has quit [Client Quit]
19:52-!-MaverickTech [] has joined #mythtv
19:53-!-skamithi [] has joined #mythtv
19:59-!-brad_mssw|mac [] has joined #mythtv
20:00-!-brad_mssw|mac is now known as brad_mssw
20:10-!-jpabq [] has quit ["Leaving"]
20:18-!-brad_mssw [] has quit []
20:27-!-AudioV [] has quit ["Ex-Chat"]
20:27-!-xris [n=xris@] has quit []
20:29-!-xris [n=xris@] has joined #mythtv
20:30-!-xris [n=xris@] has quit [Client Quit]
20:31-!-xris [n=xris@] has joined #mythtv
20:49-!-xris [n=xris@] has quit [Read error: 110 (Connection timed out)]
21:04-!-brunes [] has quit [Read error: 104 (Connection reset by peer)]
21:05<famicom>why is that hidden
21:12-!-xris [] has joined #mythtv
21:21-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
21:22-!-gbee [] has quit [Read error: 110 (Connection timed out)]
21:41-!-Tanthrix [] has quit [Read error: 104 (Connection reset by peer)]
21:51<famicom>i got the bug that crashes ati
21:59<famicom> echo " --enable-glx-procaddrarb use glXGetProcAddressARB() instead of glXGetProcAddress()"
21:59<famicom>thats the bugger
21:59<famicom>glXGetProcAddress fucks with the ati driver
22:09-!-cecil [n=cecil@] has joined #mythtv
22:29<danielk22>famicon: that option enables glXGetProcAddressARB, so that packagers can compile one binary that will work with multiple GLX implementations. It's up to the packagers to make sure it is safe to use before using it since it can't be fully checked at run-time.
22:31<danielk22>Which glXGetProcAddressXXX does work with the ATI drivers?
22:33<danielk22>Normally, when you run ./configure without using that hidden option, MythTV will use the appropriate GLX implementation based on your installed GLX headers.
22:43<kormoc>danielk22, the main issue is the ATI driver allows glXGetProcAddressARB to return 0, see
22:45<danielk22>glXGetProcAddressARB() is allowed to return NULL. That shouldn't cause any crashes in MythTV.
22:45<famicom>which is why stock ubuntu crashes, whereas a custome build works just fine
22:46<famicom>i dont know
22:46<famicom>its related to the proprietary drivers
22:46<famicom>who gives a fuck what it is allowed to do
22:46<kormoc>famicom, rambling doesn't help matters
22:46<famicom>since when do companies follow the specs
22:46<famicom>kormoc true
22:46<famicom>my bad
22:47<kormoc>danielk22, Fair 'nuff, I just know that a lot of projects seem to use the same workaround to fix sigfaults. Not sure if it's the same issue as been reported tho. I can confirm that Cedega also uses the same workaround code for the function.
22:48<famicom>actually it was a sigserv
22:48-!-xris [] has quit []
22:49<kormoc>I would venture to guess it's a different issue then
22:50<famicom>not sure, but it seems like it
22:52-!-xris [] has joined #mythtv
22:56<danielk22>kormoc: If someone wants to write our own implementation of glXGetProcAddress(), I'm fine with that. But we should always try the in-built one first, and we should never crash if glXGetProcAddress() returns NULL. glXGetProcAddress() is used to query extension function pointers, by definition extensions are optional and may even be present on only some OpenGL contexts within the same system.
22:58<kormoc>danielk22, certainly, I was just pointing out some prior stuff on ati and brokenness, I honestly don't really care, I'm not an ATI user :P
22:58<famicom>i personally dont encounter any issues myself
22:59<famicom>actually i just did
23:00<famicom>but i really dont see why we should go out and ignore reality over how things "should be done"
23:01<kormoc>Actually, I think that there are times we should just stick to the standards, and I'm not in a position to say if this is or isn't one of those times
23:02<danielk22>famicom what are you talking about? We added that ugly glXGetProcAddressARB() hack in recognition of the sad state of graphics drivers on Linux.
23:18<danielk22>We will do things more correctly for >10 y.o. implementations like the ATI drivers once we've refactored the OpenGL code down to one GLX context. The VIA drivers fail horribly when you try to query the glx version more than once, much less query the extension string. Preferably, I'd like VIA, ATI, and nVidia to work + any proper GLX 1.1+ implementations to work.
23:31<danielk22>GLX 1.2, which is what we currently target is over a decade old. And while I'm totally open to patches to allow the 16 y.o. GLX 1.1 to work, it is not a high priority for me personally. I don't think companies that are more than 10 years behind on their driver implementations will be relevant by the time I get around to adding support for them.
23:34<danielk22>Honestly, I'd much prefer if we could just target the 3 y.o. GLX 1.4 spec which allows multi-threading. ;)
23:36-!-danielk22 is now known as danielk_zzzzz
23:38-!-xris [] has quit []
23:41-!-skamithi [] has quit ["WeeChat 0.2.6"]
---Logclosed Tue May 13 00:00:54 2008