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

---Logopened Thu Jul 17 00:00:46 2008
00:12-!-jhulst_ [n=jhulst@unaffiliated/jhulst] has quit [Remote closed the connection]
00:12-!-jhulst__ [] has joined #mythtv
00:56<jpabq>gbee, did you increase the font size for "will be recorded" on purpose? I upgraded to svn r17834 tonight, and that font size is now too big.
00:58<gbee>haven't deliberately changed any font sizes
00:59-!-jhulst__ [] has quit [Read error: 113 (No route to host)]
01:00<gbee>I'm not sure which bit you are talking about either
01:11-!-cattelan_ [] has joined #mythtv
01:22-!-cattelan [] has quit [Read error: 110 (Connection timed out)]
01:27-!-gnome42 [] has quit [Remote closed the connection]
01:31<jpabq>gbee, I am surprised you are awake.
01:32<jpabq>In the "To do" (Upcoming recordings), the shows which will record (as apposed to currently recording, or not recording) are now showing with a bigger font on my system.
01:34<jpabq>It used to be that the only difference between the "currently recording" and the "will record" on that list, was a slight brightness difference between the two levels of green.
01:44-!-cattelan_ [] has quit ["This computer has gone to sleep"]
01:45<jpabq>I was previously using r17774. I will see if I can figure out when it changed for me. But not tonight.
02:47-!-mace [n=mace@debian/developer/mace] has quit [Read error: 110 (Connection timed out)]
03:04-!-bio___ [] has quit [Remote closed the connection]
03:04-!-bio___ [] has joined #mythtv
03:05-!-edannenbe [] has joined #mythtv
03:35-!-joobie [] has quit [Read error: 60 (Operation timed out)]
03:47-!-Dibblah [] has joined #mythtv
04:58-!-edannenbe [] has quit [Remote closed the connection]
05:09<gbee>jpabq: for some reason it didn't affect me, but should fix it
05:14-!-edannenbe [] has joined #mythtv
05:56<gbee>hmm, my problem last night wasn't what we thought, although it wouldn't have helped either - there is some bug in the reference counting of QString and because QDeepCopy doesn't exist I not sure how to work around it yet
05:58-!-dagar [] has quit [Connection timed out]
05:59-!-dagar [] has joined #mythtv
06:33-!-edannenbe [] has quit [Remote closed the connection]
06:34-!-edannenbe [] has joined #mythtv
06:46-!-PointyPumper [n=pintlezz@] has quit [Connection reset by peer]
06:47-!-PointyPumper [n=pintlezz@] has joined #mythtv
06:55-!-tomimo_ [] has quit ["Gotta get going ..."]
06:55-!-mikecharest [i=1880ae56@gateway/web/ajax/] has joined #mythtv
06:59-!-ivor [n=ivor@kde/developer/ivor] has quit ["leaving"]
07:00-!-mikecharest [i=1880ae56@gateway/web/ajax/] has quit [Client Quit]
07:15-!-tomimo [] has joined #mythtv
07:34-!-Ben43 [] has joined #mythtv
07:36<danielk22>gbee: you can use ascii() to create a deep copy of a QString in Qt4 -- but only with ASCII strings.
07:37<danielk22>QString new_str(old_str.ascii());
07:38<Chutt>ascii() is not safe
07:38<danielk22>of course ascii() is not reentrant so you should make sure that you lock the string before copying it.
07:38<Chutt>QString newStr(str.toAscii())
07:38<Chutt>will do the right thing
07:39<Chutt>err, leave off the toAscii()
07:39<danielk22>so detach() is the new deep copy then?
07:39<Chutt>looks like it
07:39<Chutt>Q3DeepCopy calls detach
07:40<Chutt>it's not documented as such, though
07:40<danielk22>I wonder if str.detach(); fopen(str.toAscii()); is thread safe?
07:40<gbee>I've re-arranged things a little so that it no longer appears to trigger that segfault but I'll keep detach in mind for the future
07:41<Chutt>danielk22, detach() does a realloc() on the data, so it should be
07:43<Chutt>danielk22, ascii() should be replaced by toAscii() everywhere, though, i think
07:44<Chutt>ascii/latin1/utf8 are so not-reentrant they use a global buffer for their conversion
07:44<danielk22>I wonder why they didn't just replace ascii() with toAscii() then?
07:44<Chutt>toAscii returns a QByteArray
07:45<Chutt>not a char*
07:45<danielk22>ah, ic
07:45<Chutt>so you need to do toAscii().constData()
07:45<Chutt>that's why it's safe, looks like
07:48-!-noisymime [] has quit [Read error: 110 (Connection timed out)]
07:48<danielk22>Yeah, looks much safer both functions are reentrant so long as the underlying data structure isn't changed while you call them.
07:48<Chutt>since the refcounting is atomic now, though, it _should_ be better too
07:52<danielk22>Yeah, it sounds like if we get rid of the non-re-entrant functions, our only concern will be the classes that actually interact with multiple threads. Not all the classes that interact with them in individually single threaded assemblies. That should also make finding QString that need locking a lot easier.
07:53<Chutt>i did go through this a bit when i did libmythdb/libmythui to qt4
07:53<Chutt>since non-reentrant stuff like ascii() is only in qt3support
07:54<Chutt>gbee, that's rather odd
07:54<gbee>that dynamic_cast should fail and return a null pointer, since it's casting to MythUIType and in this case the parent is MythScreenStack, but why the segfault?
07:55<gbee>Chutt: indeed
08:21-!-Ben43 [] has quit ["L8rs"]
08:29-!-anny__ [n=chatzill@] has joined #mythtv
08:29<anny__>hello all, is this the right place to ask for compilation problems
08:32<stuarta>no, please see the topic
08:34<anny__>ah sorry
08:47-!-chainsawf [] has joined #mythtv
08:48-!-Ben43 [] has joined #mythtv
08:58-!-cattelan [] has joined #mythtv
09:00-!-chainsawbike [] has quit [Connection refused]
09:10-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:36-!-mace_ [] has joined #mythtv
09:48-!-anny__ [n=chatzill@] has quit ["ChatZilla 0.9.83 [Firefox 3.0/2008052906]"]
10:06<gbee>Chutt: I can reproduce that dynamic_cast segfault, it happens whenever a new screen is added to the stack after the SearchResultsDialog one has been popped off
10:06<gbee>I've no found out why yet
10:09-!-jgarvey [] has joined #mythtv
10:09-!-gustave_ [] has joined #mythtv
10:13-!-foxbuntu [] has quit ["Leaving"]
10:14-!-mace_ is now known as mace
10:53-!-Kieran491 [] has joined #mythtv
10:55<Kieran491>I am not sure if this is a development question or not... But what are the methods of running MythTV in a minimal eviroment IE geting rid of "Desktop Enviroments" is it possible to run MythTV with out the Desktop eviroment is it possible with X or dose it have to be done with out X?
10:55<laga>try #mythtv-users :)
10:55<laga>and the wiki, probably
10:56<Kieran491>Ahh k
10:57<Kieran491>Wheres the Wiki Located?
10:57<laga> i believe
10:57<Kieran491>Thanks :)
11:08<jpabq>gbee, 17838 did fix the font size problem. Thanks.
11:15-!-iamlindoro_ [n=iamlindo@] has joined #mythtv
11:46-!-gnome42 [] has joined #mythtv
11:53-!-xris [] has quit []
11:58-!-skamithi [] has joined #mythtv
12:02-!-ivor_ [] has joined #mythtv
12:02-!-ivor_ is now known as ivor
12:25-!-cattelan_ [] has joined #mythtv
12:27-!-skamithi [] has quit ["WeeChat 0.2.6"]
12:30<mikegrb>sudo aptitude update
12:40-!-cattelan [] has quit [Read error: 110 (Connection timed out)]
12:42<janneg>gbee: mythlistbutton.cpp:1313: error: no 'QString MythListButtonItem::setStringData(const QString&)' member function declared in class 'MythListButtonItem'
12:42<janneg>mythlistbutton.cpp:1318: error: no 'QString MythListButtonItem::getStringData()' member function declared in class 'MythListButtonItem'
12:43<janneg>but I don't see why
12:43-!-xris [n=xris@] has joined #mythtv
12:45<janneg>ah, it's the case
12:46<janneg>I'll commit the fix after my compile finishes
12:48-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
12:49<gbee>damn, wonder how that happened because I was using that patch
13:03-!-javatexan [] has joined #mythtv
13:05<danielk22>janne: is there a command line tool to issue DiSEqC commands?
13:08-!-skamithi [] has joined #mythtv
13:10<janneg>danielk22: I don't know
13:13<janneg>gnutv and szap won't do it, dvbtune might
13:14<janneg>hmm, I'm wondering if szap might support DiSEqC commands from the channels.conf
13:15<danielk22>i can't seem to tune or even rotate my dish, but i'm not sure if it's a mythtv problem, a hardware problem or a driver problem.
13:22-!-dageorge [] has quit [Read error: 110 (Connection timed out)]
13:22-!-dageorge [] has joined #mythtv
13:34-!-javatexan [] has quit [Read error: 104 (Connection reset by peer)]
13:36-!-cattelan_ is now known as cattelan
13:38-!-cattelan [] has quit ["Leaving"]
13:38-!-cattelan [] has joined #mythtv
13:39-!-cattelan [] has quit [Client Quit]
13:45-!-pdlnhrd [] has joined #mythtv
13:45-!-pdlnhrd [] has left #mythtv []
13:46<laga>hum. it looks like there is no easy way to find out on which box a mythvideo file resides
13:46-!-iamlindoro_ [n=iamlindo@] has quit [Read error: 104 (Connection reset by peer)]
13:47-!-iamlindoro_ [n=iamlindo@] has joined #mythtv
13:47<laga>i wonder if it would make sense to let the frontend act as a server for mythvideo files
13:47<laga>and mythmusic, too
13:49<gbee>I'd just move all the files to the backend, or a network mounted storage group accessible by the backend, treat them like recordings
13:50<gbee>locally accessible files, say on a cd/flash drive connected to a frontend don't have to be accessible to all frontends, but then again that functionality wouldn't be hard to add at some point
13:52<laga>gbee: yeah, that means you'd have to run a backend on your frontend box to share its files.. of course, NFS would be possible, but that's something people need to set up
13:53-!-slim_ [n=slim1@] has joined #mythtv
13:53-!-slim_ [n=slim1@] has left #mythtv ["Ex-Chat"]
13:53<gbee>laga: yeah, but how many people actually use mythvideo or mythmusic that way? with files on the frontend instead of a backend/NAS?
13:54<gbee>if they do set it up like that then they already have to setup NFS so nothing changes
13:55<gbee>if they just want access to files locally, say when their iPod is connected to the frontend then they don't need the backend - the frontend can access them directly
13:55<gbee>they just won't be shared, which is no different to how it works now
13:56<gbee>maybe others have a different idea, but I think the concept of having all media on a single machine then just letting the frontends stream makes most sense
13:57<laga>gbee: my backend only does recording, all music is on my frontend (which is also my desktop). but of course, that's probably not a typical setup.
13:58<gbee>laga: I'm sure some people with single frontend setups run it like that, but I guess the question is what would prevent you moving the music to the backend?
13:58<laga>gbee: well. but that's not how recordings are handled. recordings can live on other backends. so if people want to share their music on a frontend, they could fire up mythbackend i suppose.
13:58<laga>gbee: my backend isn't running all the time. i use mythshutdown and /proc/acpi/alarm :)
14:00<laga>(with the point being that i use amarok to listen to music usually. of course, if i use mythmusic then the backend is also running)
14:04<gbee>as I say, the idea I'm proposing doesn't prevent you having your music on the frontend, it just wouldn't be available to other frontends unless you share it via NFS, but for users who want all their media stored on a backend or two then the music is available to _any_ frontend that appears on the network without configuration, scanning or need for NFS mounts
14:05-!-edannenbe [] has quit [Remote closed the connection]
14:05-!-_gunni_ [] has joined #mythtv
14:05<gbee>I guess so long as that configuration is supported I don't really mind what additional stuff it does, if that means putting a upnp server in the frontend, well I don't think it's a great idea but go for it
14:05-!-mikecharest [i=8cf2fa0a@gateway/web/ajax/] has joined #mythtv
14:05<laga>gbee: yeah, if i want to share my music then i could just start mythbackend on my frontend box. just treat the mp3s like recordings and give them an URL ;)
14:18-!-_gunni_ [] has quit ["KVIrc 3.4.0 Virgo"]
14:20-!-_gunni_ [] has joined #mythtv
14:29-!-Kieran491 [] has left #mythtv []
14:33-!-jarle [] has quit [Remote closed the connection]
14:34-!-jarle [] has joined #mythtv
14:35-!-PointyPumper [n=pintlezz@] has quit [Connection timed out]
14:36-!-mindphlux [] has joined #mythtv
14:36-!-mindphlux [] has left #mythtv []
14:37-!-jarle [] has quit [Remote closed the connection]
14:37-!-jarle [] has joined #mythtv
14:38-!-thedarkone [] has joined #mythtv
14:51<gbee>what do people think to amending the coding standards a little, making the suggestion to use m_ a little stronger? It improves readability a great deal in my experience
14:53<gbee>member variables are prefixed with m_ to distinguish them from variables local to the function
14:54<gbee>so m_someVariable belongs to the class, but someVariable is limited in scope to the method/function in which it is used
14:57<janneg>ok, it improves readability in unfamiliar code. I usually fail to remember that when I'm writing code and I didn't know it was in our coding standards
15:00<kormoc>I was thinking m_ meant method, which made very little sense to me
15:03-!-huhlig [] has joined #mythtv
15:18<gbee>on the subject of coding standards, I'm following a convention with mythui that I'd like to suggest goes in - pointers to widgets are given a suffix to denote what uitype they are - e.g. titleText, videoList, okButton, filterCheck and so on
15:32-!-cattelan [n=cattelan@] has joined #mythtv
15:33-!-robthebob [] has joined #mythtv
15:38<gbee>now we need int storage in MythListButtonItem, I think that int/string/void* should be enough for all scenarios, but does anyone have a better idea?
15:38-!-mikecharest [i=8cf2fa0a@gateway/web/ajax/] has quit [" ajax IRC Client"]
15:44<janneg>union or void* and type information
15:44<janneg>the union won't help
15:46-!-skamithi [] has quit ["WeeChat 0.2.6"]
15:51<gbee>void* probably covers it all just fine, the reasoning for adding strings was kinda spurious and resulted from working when I should have been in bed
15:58<Chutt>gbee, doesn't qobject have this?
15:58<Chutt>(and thus, all the MythUI objects)
16:01<gbee>looks interesting, MythListButtonItem isn't a MythUIType object, but it could subclass QObject
16:01<Chutt>or just use QVariant instead of lesser types
16:01<gbee>plus it allows for multiple bits of data to be assigned to a button, which could be useful under some circumstances
16:02<gbee>ok, thanks I'll look into that
16:06<gbee>think the latter idea, just using QVariant would be enough
16:06-!-gustave_ [] has quit ["ChatZilla 0.9.83 [Firefox 3.0.1/2008070206]"]
16:08<gbee>I can't think of a situation were you'd want to assign lots of information to a button that wouldn't be better off using an object instead
16:12-!-robthebob [] has quit [Read error: 104 (Connection reset by peer)]
16:13-!-Winkie [] has quit [Read error: 60 (Operation timed out)]
16:18-!-PointyPumper [n=pintlezz@] has joined #mythtv
16:23<Anduin>gbee: dynamic_cast crashing is often the result of a bad pointer being passed in, I don't want to make assumptions about where you keep your heap but that seems likely
16:24-!-Winkie [] has joined #mythtv
16:25<gbee>heh, well I suspect that is the case, but I can't pin it down at the moment
16:25-!-packetscan [] has joined #mythtv
16:26-!-cattelan [n=cattelan@] has quit ["This computer has gone to sleep"]
16:27<gbee>I'd welcome a second pair of eyes, the code in question is in the branch
16:28<gbee>the pointer in question comes from the stack list, it's persistant for the entire duration of the frontend - created at startup and not deleted until we exit
16:32<leprechau>kernel update...brb....
16:32-!-leprechau [] has quit [Remote closed the connection]
16:36-!-leprechau [] has joined #mythtv
16:39-!-cattelan [] has joined #mythtv
16:54-!-javatexan [] has joined #mythtv
16:55-!-javatexan [] has left #mythtv []
17:01<Anduin>gbee: I don't see it just looking at the code, I'll run it later and see what I can find.
17:02<gbee>Anduin: thanks, really appreciate it
17:04<gbee>course of events goes like this - run a search on a title with multiple results, after the popup with the list of results pops up it's not necessary to continue you can press escape, after this point any screen added to the popup stack will trigger the segfault, last night it was the busy dialogs which appear during the UID search but I've disabled those for now, instead calling up the menu again does the same
17:06<gbee>only occurs after the results list has been up, so something either in the creation of SearchResultsDialog or the title search is causing it
17:07<Anduin>Yeah, my initial guess was that it was popping one too many, I didn't see where it could do that though
17:07<Chutt>is the popup stack getting deleted?
17:07<Chutt>the screenstack itself
17:08<gbee>obviously not intentionally at any point
17:08<Chutt>well, yes =)
17:08<Anduin>That would make sense, I just don't see where it would happen
17:08<Chutt>but, that'd cause this
17:08<Chutt>reference to it left around
17:10<Chutt>anything call PopScreenStack?
17:10<Anduin>Yeah, VideoDialog::SwitchLayout()
17:11-!-jgarvey [] has quit ["Leaving"]
17:11<gbee>it does? ermm
17:12<gbee>it calls PopScreen, not ScreenStack
17:12<Anduin>ah, yeah
17:13<gbee>that just deletes the screen off the stack and adds the new one created using the different layout - much faster btw that the old jumppoint view switching, which is nice
17:13<Chutt>does it fade? =)
17:13-!-huhlig [] has quit [Read error: 110 (Connection timed out)]
17:13<Anduin>not currently (passes false)
17:13<Anduin>(having never run it)
17:13<gbee>no, only because you'd see the menu if it did
17:14<gbee>can't currently add a bew screen underneath the top one
17:16<Chutt>on top
17:16<Chutt>and delete/remove the old (under) one when it goes away
17:17<gbee>either way means a small change to mythscreenstack, I'll do it when I've converted over the remaining mythvideo screens
17:18-!-jmblack [n=jmblack2@] has joined #mythtv
17:19<gbee>it currently shares an instance of the video tree so it doesn't have to re-load the data on a view switch, plan to add position states so that the same video and branch in the tree is selected after the switch
17:22-!-dekarl [] has joined #mythtv
17:38-!-dekarl1 [] has quit [Read error: 110 (Connection timed out)]
17:41-!-jwhite [] has quit ["Leaving"]
17:43-!-jwhite [] has joined #mythtv
17:55-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:01-!-noisymime [] has joined #mythtv
18:07-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
18:07-!-jwhite [] has quit [Read error: 104 (Connection reset by peer)]
18:09-!-jwhite [] has joined #mythtv
18:12-!-joobie [] has joined #mythtv
18:15<gbee>guess I need to source 4.4 packages
18:22-!-iamlindoro_ [n=iamlindo@] has quit [Read error: 110 (Connection timed out)]
18:23-!-kormoc_ [n=kormoc@unaffiliated/kormoc] has joined #mythtv
18:28-!-jwhite [] has quit ["Leaving"]
18:32-!-joobie [] has quit [Read error: 110 (Connection timed out)]
18:34-!-jwhite [] has joined #mythtv
18:38-!-jhulst_ [n=jhulst@unaffiliated/jhulst] has joined #mythtv
18:38-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Read error: 110 (Connection timed out)]
18:39-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit [Read error: 110 (Connection timed out)]
18:47-!-jhulst__ [] has joined #mythtv
18:54-!-purserj [] has quit [Read error: 54 (Connection reset by peer)]
18:54-!-purserj [] has joined #mythtv
18:55-!-czth [n=dbrobins@nat/microsoft/x-1d99efa5dbb3ef6d] has joined #mythtv
19:00-!-jhulst_ [n=jhulst@unaffiliated/jhulst] has quit [Read error: 113 (No route to host)]
19:10-!-mattwire [] has joined #mythtv
19:10-!-mattwire [] has quit [Client Quit]
19:11-!-ivor [n=ivor@kde/developer/ivor] has quit ["leaving"]
19:49-!-Dibblah [] has quit [Read error: 113 (No route to host)]
19:54-!-mikecharest [i=1880ae56@gateway/web/ajax/] has joined #mythtv
19:54-!-komroc__ [] has joined #mythtv
19:56-!-kormoc_ [n=kormoc@unaffiliated/kormoc] has quit [Success]
19:58-!-komroc__ is now known as kormoc
20:02-!-iamlindoro [] has quit [Read error: 104 (Connection reset by peer)]
20:03-!-iamlindoro [] has joined #mythtv
20:15<Chutt>anyone disagree with qt4.4 (with a stub for qt4.3)?
20:18-!-Dave123 [] has joined #mythtv
20:26<gbee>anyone else unable to upgrade from 1221 to 1222?
20:32<Captain_Murdoch>as long as 4.4 is optional and core MythTV works with 4.3 I think most would be happy.
20:33<kormoc>I'm a gentoo user, let's go to qt cvs/svn! :P
20:33<Chutt>gbee, that's similar to the bug Anduin/nigel are talking about, no?
20:33<gbee>I'd have rather let the 4.4 packages mature a little before upgrading, but I've bitten the bullet know and installed them so I've no objections
20:34<Chutt>i'm running it on my production box
20:34<Chutt>it's in ubuntu, so..
20:34<gbee>Chutt: didn't read that thread, so let me go take a look
20:37<gbee>there might be some squealing from those who wanted us to chose 4.2 instead of 4.3 because they are using Redhat EL or something equally slow
20:37<Captain_Murdoch>switching to a 4.4 requirement may inhibit a lot of testers if they're running systems that don't have 4.4 rpms available. with the UI changes and 4.x port I think we need as many testers as possible. I have 2 more systems I need to upgrade before I can start running trunk on my production systems, but I'm getting there.
20:37<gbee>but then their objections were no more valid then than they would be now
20:37-!-xris [n=xris@] has quit []
20:38-!-|gunni| [] has joined #mythtv
20:38-!-_gunni_ [] has quit [Read error: 110 (Connection timed out)]
20:39<Captain_Murdoch>for kicks, /me goes searching for 4.4 rpms for the three different systems he has running at home.
20:40<gbee>Chutt: looks similar, I might just have to do the 1222 update manually then :(
20:42<gbee>letting the backend do the upgrade works, so that's not so bad
20:43<Captain_Murdoch>Axel has qt 4.3.4 src rpms for the 3-5 ELs
20:43<Captain_Murdoch>gbee: might be related to the "SaveSettingOnHost('Language') - No database yet" I noticed that the other day when I ran mythtv-setup instead of mythbackend to upgrade my dev box.
20:44<Captain_Murdoch>by that time, we've already opened 3 connections, but some part of code thinks we don't have a DB connection.
20:51<gbee>well I'd love to figure it out, but I need to start getting to bed at a reasonable time ;) I'm absolutely shattered
21:09<Anduin>There are two threads (thread 1 and 2), both in UpdateDBVersionNumber() and both with, apparently the same MSqlQuery instance. It looks strange to me, MDBManager::popConnection() does lock while removing/newing.
21:16<Anduin>Ok, so just a copy/paste error it seems :(
21:16-!-xris [] has joined #mythtv
21:27<CDev>Chutt: I noticed you weren't on IRC the other day when I asked a question about our db connection pooling... Have a quick minute?
21:28<CDev>I was actually reading the QT4 manual for once and noticed this: "A connection can only be used from within the thread that created it. Moving connections between threads or creating queries from a different thread is not supported."
21:28<CDev>Isn't our connection pool shared across threads?
21:28<Chutt>doesn't seem to be hurting anything, though...
21:29<CDev>True. As far as we know... I've just noticed more strange behavor reported by others and was curious if it may be related.
21:30<Chutt>could probably just get rid of the pool
21:30<Chutt>or it wouldn't be _that_ bad to make it thread specific
21:30<CDev>either that or use QThreadStorage to have a pool per thread.
21:31<CDev>I wonder if the comments are still true, about having problems if we disconnect from mysql and try to re-connect.
21:32<CDev>Figured I bring it to the attention of a few developers, in case it turns out to be a bigger issue. Thanks for the time.
21:34<Chutt>i'll try to check the source out to see what they're reasoning is
21:34<CDev>np. It could be that just specific drivers have an issue, so they made a blanket statement.
22:05<Chutt>danielk22, you don't need to do the QByteArray stuff
22:13<Captain_Murdoch>I can reproduce that issue that gbee posted. issue is related to that "SaveSettingOnHost('Language') - No database yet" message. MSqlDatabase::OpenDatabase() isn't opening that 4th connection because isOpen() returns true if m_db.hostName().length() == 0.
22:14-!-foxbuntu [] has joined #mythtv
22:23-!-samubuntu [] has joined #mythtv
22:27<danielk22>chutt: are you sure?
22:29<danielk22>in any case I think it makes the process more apparent.
22:35-!-Ben43_ [] has joined #mythtv
22:44-!-samubuntu [] has quit [Remote closed the connection]
22:44-!-famicom [] has quit ["Leaving"]
22:45-!-compbrain [i=wan@pdpc/supporter/student/CompBrain] has joined #mythtv
22:54-!-Ben43 [] has quit [Remote closed the connection]
22:54-!-Ben43_ [] has quit ["L8rs"]
22:55-!-Tanthrix [] has quit [Read error: 104 (Connection reset by peer)]
23:03-!-cecil is now known as cesman
23:15-!-foxbuntu [] has quit [Remote closed the connection]
23:26-!-kormoc [n=kormoc@unaffiliated/kormoc] has left #mythtv []
---Logclosed Fri Jul 18 00:00:33 2008