MythTV upgrade from 0.23 to 0.24 voes

[Jaglover]

It worked fine with 0.23, after upgrading to 0.24 everything works but live TV. Is there something about kernel configuration that needs to be changed/patched?

[PraetorZero]

Did you make the jump to a 2.6.38 kernel and headers? Using an MPEG encoder (PVR-x50)?

Take a look here in the mailing list. If you're using upstream's overlay, this appears to have been fixed. Sync and rebuild.
_________________
What's the worst that can happen?

[Jaglover]

No, not really. I had 38-r1, 38 headers and mythtv-0.23, it worked fine. And I'm using pcHDTV HD-5500. Nevertheless, thanks for the tip.

What is the best place for MythTV support? it seems they do not have forums?
_________________
Please learn how to denote units correctly!

[PraetorZero]

That would be their mailing list.

Archive is here

Sign up here
_________________
What's the worst that can happen?

[Jaglover]

Thank you. I'm using https://github.com/MythTV/packaging/tree/master/Gentoo
What overlay you are talking about?
_________________
Please learn how to denote units correctly!

[PraetorZero]

[depontius]

[Jaglover]

Finally decided to dig into it, after rebuilding mythtv-0.24 against 2.6.36 headers it started working. There seems to be an issue with V4L1 support (which was removed in 2.6.38) on certain cards.
_________________
Please learn how to denote units correctly!

[Punchcutter]

[depontius]

[Randy Andy]

Hi Folks.

I have a question to you MythTV experienced users, cause i'm only experienced in install and usage of VDR.

Some time ago i installed MythTV-022 or one of the first 23 releases, when it came to the tree, afaik.
Although it looks nicer and seems to be more prepared for lots of different multimedia content, it had one big disadvantage which was the main reason to discard it.

It was the W.A.F. (the woman acceptance factor).
Its cause my woman is the zapper queen, and with MythTV it takes much longer to give back tv-picture and sound, after changing the channels,
than with vdr.
So this was the knock out criterion here. We're using satellite TV. Frontend and backend was in one PC, not via network.

I didn't stopped the time, so i can't name it here, but it was obviously. Two up to three times longer than with vdr, equipped with a full feature card,connected directly to the TV, and and three budget cards.
Can't say how much more it needs, if it is connected via graphic card via hdmi connector to the tv, which is also possible for vdr, but i didn't configured it in this way until now, although it would have a higher resolution and a better picture.
To be fair, i must say that MythTV used the graphics card routing, when i tried it. I don't know if it could used the direct FF card routing instead.

My VDR switches as fast as a standard satellite receiver. You know, every DVBT receiver needs much longer for zapping, compared to it. And MythTV needs a little longer than that.

So my main question is: Is this typical for MythTV cause its server/client concept, or was it related to the version i used when i tried it.
How is your experience regarding the switching time, if you could compare it.

Thanks for sharing your experience,

Andy.
_________________
If you want to see a Distro done right, compile it yourself!

[depontius]

I'm still running 0.23.1 out of mainline portage. Channel switching time is so bad that I never use it.

As for W.A.F., probably the big issue is the poor reliability. I have a dedicated mythfrontend machine in the TV cabinet. To make it more appliance-like, it's set to suspend rather than power off. (An "off" PC still chews power, unless you disconnect the AC, and a suspended PC doesn't take much more than an "off" one.)
1 - I found that mythfronend doesn't like very much to be suspended and wakened, so I kill it at suspend and restart at wake.
2 - For some reason, mythfrontend sometimes doesn't even like to start upon wake - sometimes. I have an lirc button to "killall -u mythtv_ that generally fixes it.
3 - Playing DVDs is a bit hit-or-miss. There are also DVDs that sometimes Myth won't play, and xine will.

Still, my wife tends to like it. As a "VCR" it's pretty good.
_________________
.sigs waste space and bandwidth

[Randy Andy]

depontius,

thanks for your perception.

Reasons enough for me to stay with my VDR system, and to improve it a little to a HTC system, by setting on top Freevo or somthing similar.
Cause my focus is watching and recording TV.

NVRAM wakeup works fine here since years although completely shutting down the VDR every day.
Boot time smaller than a minute is good enough for me.

But playing DVDs, Pictures, Music, and other stuff, is not as comfortable as my wishes.
_________________
If you want to see a Distro done right, compile it yourself!

[depontius]

Fun little tidbit from this past weekend... I normally service the computers at home on Saturday mornings, before the rest of the family is up and around - or at least start the servicing, because compiling on the slower systems may take a while.

Saturday I found that the MythTV 0.24.1 ebuilds from the MythTV github had "gone stable." The only reason my systems didn't auto-upgrade is because I also had mythtv-themes-0.23 installed, and that blocked the upgrade. Sunday afternoon my son was at work and my wife and daughter were at a wedding shower. So I verified that I wasn't actually using any themes from mythtv-themes, uninstalled it, and allowed the upgrade to go on.

Relatively painless - one system ran out of space, and I had to clean up and restart. Everything came back looking just the way it had before, which is really important for the Wife Acceptance Factor. I haven't really bugged it all out yet, but so far haven't found any hitches.
_________________
.sigs waste space and bandwidth

[gcasillo]

So, are we going to see mythtv-0.24 in portage any time soon? I have had terrible playback issues on two computers running MythTV, an ion 330 frontend only and a quad core Q6600 that doubles as backend and frontend. Like the framerates are off. I've tried different playback profiles, deinterlacers, and whatever else is possible. I suspect it's an issue in the latest nvidia-drivers, but none of my logs show anything of note. It's bad enough to be noticeable in both SD and HD recordings but not quite bad enough that I want to go off the reservation and run an overlay.

I've been willing to wait it out for a fix, but newer versions of KDE-4.7 and xorg-server-1.10 and nvidia-drivers-whatever have changed nothing. Sadly, we're stuck at mythtv-0.23 while fixes for 0.24 are already being pushed out in 0.25-to-be releases.

Am I SOL with MythTV on Gentoo now, or can I expect some movement in the coming weeks. I've already endured a low WAF, and now MAF (my acceptance factor) is hitting the floor.

[Jaglover]

[depontius]

Actually, 0.24.1 and MythTV in general are having some serious WAF problems around here. I see 3 main areas - first, the DVD player just isn't that reliable; second, remote control operation isn't that reliable; and third, startup isn't that reliable. A bit more detail...

1 - The DVD player has a fair amount of trouble playing DVDs - commercial DVDs, home-burned DVDs, etc. When you push the "Play DVD" button the system just sits there for a while, and you don't know if this was a remote control problem, (see #2) if it's about to start playing, or if it's not going to play at all. An hourglass or some such would be appreciated here. I'm about ready to work up an LIRC file for xine and use it to play DVDs. I'm not sure if want to do that from within Myth as an external player, or build my own wrapper around both and kill Myth, then start xine, and vice versa.

2 - Sometimes it takes several presses of the remote button before Myth does anything. This is particularly troublesome when trying to fast-forward, especially when trying to go back to play. To be fair, I recognize that there are really two pieces of code in play here, LIRC and MythTV. I have no feel for which is to blame - if LIRC is failing to see the button presses or if Myth is failing to see the "keys" that LIRC is feeding it. Back to #1 for a moment, presuming I get LIRC also configured for xine and swap between the two, the LIRC->xine path will give me another data point on remote control reliability.

3 - This is an appliance-ized dedicated mythfrontend machine. In order to get faster startup, I suspend and wake based on the remote control power button. But mythfrontend didn't like being suspended and wakened, so now I just kill and restart it. But sometimes, for some reason, it doesn't even like that. So I have an extra button sequence that will "killall -u mythtv", forcing yet another restart. That button sequence has to be used entirely too often.

There was recently a thread on the mythtv mailing list about WAF, and I reported #1 there. But in general I feel that when I've posted to that list with complaints, the answer is that I'm mentally deficient and should adjust my thinking and ways of doing things.
_________________
.sigs waste space and bandwidth

[gcasillo]

Yes, I've read several threads with respect to 0.24 issues. I've accepted that from time to time, my MythTV back and frontends go off the rails of usability. The usual solution for this is to revert back to a known combo of versions. Recent changes in LIRC were a pain in the rear, and I had to keep my frontend at 2.6.35 and lirc-0.8.7 for a long time. I finally licked that issue with the new kernel driver for my MCE remote. Now, I'm plagued by low framerate playback.

So, from now on, anything running MythTV, particularly frontends, gets put in the penalty box, and I don't update unless I am 100% certain I can do so without incident. And even then, I'll be sure to allow myself to revert back if I run into problems.

And I respectfully disagree that I have no right to complain over FOSS. I have the right to complain until I'm blue in the face. Constructive criticism is important. However, I have no right to expect timely improvements and fixes to FOSS made by others on their own time. Important distinction to make.

FWIW, I am of the opinion that when fixes that address fundamental usability take several months (or longer) to appear, the advantages of FOSS are marginalized. I understand that I am dependent on the volunteerism of others, and when I submit bug reports, I try to do so with some decorum and outward appreciation of their efforts.

But when fixes aren't forthcoming, we are not as apt to update as frequently, and if we aren't updating, testing, reporting, and interacting (users and devs), then FOSS diminishes.