Arch Linux

I for one don't use the AUR and would like at least the mythtv 0.19 to remain in extra. You're always welcome to add a mythtv-devel package or so for use in the AUR which contains the latest fixes.

I agree that I have not had as much time as I would have liked to keep up with Myth as you, and I'd like to work toward your maintenance of the package. I expect you will also have more time than I to maintain ivtv, and it might be best to give that up to you, too, if you want.

The question would be how to go about doing this. It seems to me that the following would be logical:

1) I'll let you maintain the PKGBUILD materials, I'd just build them and rubber stamp them -- and we would list you as maintainer in the PKGBUILD. There could still be delay inherent here; sometimes I get swamped and have less than enough time to get to things. So I move that we get out of this state sooner rather than later.

2) I'll sponsor you for becoming TU. You could maintain the myth packages, then, in [community]. We could move mythtv and ivtv into [community]. Since Myth is plenty of work on its own, I don't think anyone would complain about you only maintaining those packages, even if it's below any package number minimum, to maintain TU status.

Then perhaps one day, based on what Judd and the others think about your work in the AUR, perhaps you end up made Developer and can put the whole lot of Myth packages into [extra].

Dale, are you content as long as you don't have to build the packages yourself? Or do you disprefer having to go to [community] at all? Sasha has demonstrated time and again that he's more knowledgeable than I about Myth, and I'd welcome having his energy put to good use.

Other thoughts?

I'm still weary of using binary packages from [community] at all. I know I'm probably over reacting, but better safe than sorry (at least for me). If you still want to move it out, I'll just build it from source, it's not a big deal.

Ideally your point #1 works best for me (even if I have to help out when you're overloaded to build/stamp the packages).

I don't know if I'm ready to be a TU. Option #1 looks good to me for now.

I'll keep a watch on making sure mythtv operates as well as possible on Arch and just post to bugs when something comes up. :)

A few things.

1) The mythdbconn.cpp in the p7zip didn't match the md5sum in the PKGBUILD. I determined that this was because it was using CRLF (DOS-style) endlines instead of UNIX ones. After I converted those, it matched the ms5sum. How would this have happened?

2) The mythdbconn.cpp in the myth 0.19 tarball seems to be exactly the same as the one you've provided. Is this left over from before the change was integrated into the main branch? I've removed this from the build since it has no effect.

3) It would be hugely helpful if you could send me future changes in the form of a patch file to the existing package; it will take less time for me to figure out what's going on and get the changes integrated.

4) I don't believe we need to require 'x-server'. One might want to run the backend on an x-less box, and it seems silly to require X for that unless it breaks something. In any case, there certainly should be some compile-time dependencies for X, which I need to re-do anyhow for the new xorg. I'll do that as soon as we get this thing working again.

5) I notice you required ffmpeg. That's probably fine, even though it might sometimes be overkill, it's relatively small for someone already installing myth.

The new build will be up in testing shortly. Let me know what you think!

Ah, I didn't notice it got integrated into the main branch. Sorry about that. As for the line encoding, that's probably because I packaged it on a windows box after getting everything via scp from my linux box.

X-server is required for both the backend and the frontend. The backend requires it to run a configuration GUI (mythtv-setup, there's been some talk of making a CLI version). FFmpeg is required for various encoding, transcoding, decoding operations. There's no way of getting around that one.

Further testing of .19 tells me that mythtv still isn't getting along with the most recent builds of mysql. I honestly don't know what to do about it, since I don't know enough cpp to delve into the code and find out what's dying, and the devs don't acknowledge that the problem exists anymore (It's been fixed in .19!). The rate of failure is down significantly, but it's still unacceptably high. I personally recompiled everything with mysql4 and it's been rock solid, but there's some talk that mysql < 5.0.15 may be OK too.

I just reopened the following bug at Myth and poked ijr a little for silly behavior:

http://svn.mythtv.org/trac/ticket/946

Let's see what happens. I may go digging in the code myself one of these days, but it would be much easier to hear from people who know more first.

is this fixed in 0.19 ?

So the answer to this is that the myth guys deny this is a bug, claiming instead that you need to configure mysql properly. I think I come down somewhere in the middle, and would like to see them put a little effort into making things work easily for their users.

Can anyone confirm or deny that they've tried to "configure" around this problem in their mysql configuration files and either succeeded or failed?

Personally, I haven't noticed the problem, but I haven't had time to use Myth much lately.

The problem has been fixed in current SVN. I've been test running myth for a week now with current mysql and things have been pretty solid.

It may be good to make a myth-0.19.01-1 using the 0.19-fixes SVN branch. That branch will probably solidify into a real 0.19.1 in a few weeks.

Actually, I've been planning to switch back onto the fixes branch in general -- seems like there's rarely a downside to doing so, and we get the fixes much faster that way. I'll do that.

Just as an update -- having a hard time compiling the newest svn fixes branch against the new kernel headers. Stay tuned as I/they work through this.

Try disabling joystick support.

The joystick support was it, and so it's disabled until I can determine they've fixed it.

Does this fix all our timeout problems?