I notice once you update to 0.22 with this procedure that you can no longer access the LinHES configuration menu due to the following entry in mythfrontend.log:

I assume this is because it relies on mythvantage which I know is not up to date yet.

Also the Apple trailer script is missing: from the first line of "is.xml".

Correct. Any upgrade to 0.22 right now will result in a LinHES Configuration menu that does not function properly if at all. This will change once R6.02 is released. The last I heard R6.02 will come with mythtv-0.22 standard and I presume a fully functional service menu.

_________________
Mike
My Hardware Profile

Did you resolve this? Running into same

Try this at your own risk... untested!

_________________
Mike
My Hardware Profile

After running the above...

OK, I did the below:


and was then able to do the
cleanly. However still no FE. Wants to run, but hangs and dumps to Tux.

I did some digging around and found that http://home.kabelfoon.nl/~moongies/streamtuned.html has a newish mythstream for QT4. The one in the repository was for 0.18 and caused some frontend crashes.

I just got it to compile (had to install fftw). Now to try it out later tonight...

Must be it! THX

Did a pacman -R mythstream and I'm up and running.

I've been having some backend issues so I decided to check if there is an update so perhaps my problems will go away. I noticed for my machine an update would:


But looking in my mythbackend log I see:


Has the repository gone "backwards"? I mean is the SVN number to be installed 22002 while what I have currently is 22957? I'm wondering because perhaps it was rolled back because of some regression and I'm seeing it with my backend lockups.

Anyone heard of recent backend lockup problems? It's kind of driving me crazy

22002 is just the LinHES package numbering. 22 = mythtv version 0.22-fixes | 002 = second release of the package. I agree it is a bit confusing as I queried the devs on this when mythtv-0.22 was first packaged for LinHES.

_________________
Mike
My Hardware Profile

Hi,

Don't confuse the package version "22002" with the Mythtv source revision which will be "23190" or something like that.

You can check you current package version using;



BigB.

Thanks guys. I'll update and hopefully things get better.

Just wanted to say that I updated my machines and report some preliminary results.

1) I had to "force" the update on my diskless clients because the media_dirs package install fails. Which makes sense as it makes a bunch of directories in /myth and it looks like the clients do not have permission to do that over NFS. But it's fine since they were created when I first updated the backend.

2) The mythbuntu theme appears to have been taken out. No biggie but thought I would mention it incase someone is thinking of updating. I went back to "blue abstract" from here:

http://www.mythtv.com/wiki/Blue_Abstract_Theme

The author has been tweaking it and added support for fan art in Watch Recordings since the last time I used it.

3) The LinHES menus now appear to work in 0.22. Which means the mythvantage port to 0.22 must be done. I didn't actually try to change any configuration with them since my machines are all setup now. It's actually the first time I've seen them because when I installed R6 I went directly to the 0.22 builds.

My "problem" is I have mythbackend "lockups" from time to time. I haven't been able to reproduce them on my own either before this update nor after (so far). So I will just have to wait until it happens again. I have only found one issue that might be the culprit - people are having dead "mythbackend --generate-preview" instances making the backend unresponsive. I'm not sure if this is my problem, I need for it to lockup again to verify.

Did you see anything in the mythbackend or mythfrontend logs?

I had lock ups which I nailed down to mythtranscode of certain sources. I turned off mythtranscode for now. I also occasionally get mythcommflag running away writing to logs on certain sources (usually 480i encoded in H.264).

I did see some H.264 errors but other than that nothing that looked "bad". While testing I turned on "all" debug which really made the backend slow down - to the point of watching video on a front end is severely compromised.

I don't do transcoding so thats not it. I'm leaning toward more something like the mythcommflag or generating the preview images.

It usually happens during the week at 8 or 9PM when 3 or 4 recordings start at the same time. In testing I've scheduled all 6 tuners at once and I can't get it to break. I'll just have to keep an eye on it this week and try to catch these times when it has happened in the past, and then check what is going on. Up until now I've just stopped the backend and restarted. I think by doing that I most likely stopped any mythcommflags or generate-preview processes, thats why a simple restart "fixed" things.