Slashdot Mirror
MythTV 0.19 Released
slummy writes "After much anticipation, MythTV 0.19 has been released. The release notes outline the new features and bug fixes, and the official announcement for this release is available on the MythTV site." From the release notes: "The major changes in this release [include]: LiveTV rewritten to support saving buffered content while watching. Signal Monitoring for DVB and pcHDTV recorders. Ending times may be changed while recordings are in progress. Playgroups allow for default playback options on recordings. Channel changes can be made across tuners without changing tuners manually first. New popup keyboard simplifies setup using remote. Preview schedule changes when making adjustments to recording schedules. Added ability to control MythFrontend through a telnet socket."
Ubuntu Breezy packages for MythTV can be found at http://deb.thehunter.ws/. Huge thanks to those Drunken Caffeinated Monkeys.
Right and wrong. The capture card does not contribute significantly to the delay (there IS a delay though, but its on the order of ms, not seconds). The biggest delay is the recording spooling, which allows you to pause and rewind live TV. The encoder runs a few seconds ahead of the decoder/display to prevent any glitches. You'll see this in any PVR device. This is pretty much unuseable for games of course.
No, actually he's not. I see the same behavior on my v18.1 system with a PVR-250 and PVR-350. The delay exists because the "live TV" signal that's displayed on the screen is actually played from the buffered data, and it takes a short period of time for the system to buffer enough data before it displays it. The same delay is seen during channel changes. In my particular case, it's about two seconds.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
Actually, I found that MythTV itself was rather easy to configure. What was hard was all of the subsystems required by MythTV.
For example, on a fresh Gentoo install, I have to get audio working (ALSA or OSS), and then video (Xorg, nvidia drivers, tv-out, etc.) and then get the capture/tuner card working (bttv, ivtv, etc.). And get them all working nicely together...
Once I had all that done, MythTV was a snap to configure and have up and running.
From experience I've found that when building a new MythTV, it's best to test/debug each subsystem as you go along.... most times the problem you are having has nothing to do with "MythTV" per se.
-- null
Capture cards with onboard MPEG encoders (the kinds you *want* to be using with MythTV) have a 1-2 second delay inherent in their operation. They are completely unsuitable for most games out there, except for possibly puzzle games where reaction times mean nothing.
Yes, "dumb" capture cards are fine for games and I use an old BT848-based card with my Xbox, but such capture cards are not a wise choice for anyone serious about reliable TV recording, since they require large amounts of CPU on the encoder box.
retrorocket.o not found, launch anyway?
You really should consider reading the setup guide. If you were running incompatable hardware then I could see how it would be difficult but otherwise it's really pretty easy. In short, if it's taking you weeks with supported hardware then you really need to stop thinking you already know it all and try just following the instructions.
Define "full rate ADSL"
Most likely your upstream rate is still not nearly high enough to stream video at a decent quality reliably.
MPEG-2 from a hardware encoder card at good quality will be 5-8 Mbits/sec. Transcoding to MPEG4 at good quality will take it down to around 1 Mbit/sec, which is still faster than 90% of the DSL upstream connections I've seen. Even with 1.5 mbit DSL, overhead means you're going to be pushing the limits of your connection.
For streaming internally within a LAN, Myth does EXTREMELY well. I routinely stream MPEG2 recordings over an 802.11g connection. (11b will not work for MPEG2 stuff, it will work for transcoded MPEG4.)
retrorocket.o not found, launch anyway?
I have MythTV running in the background of my primary system. Using the hardware accelerated encode/decode/tvout of the Hauppauge WinTV-PVR 350 I can watch, pause, ff, and rw live and recorded television with little impact upon my system (doesn't even register in system monitor or top). I use a separate instance of the Xserver only displays on of the tvout of the 350 and only receives input from the remote of 350.
Before I took the plunge and set up MythTV the process confused me. There is so much talk of a MythTV frontend system and a backend system, that I was unsure if it was possible to run both parts of MythTV on the same system. I found that with a hardware accelerated card, both the frontend and the backend can be run in the background with little impact upon anything else. I do wish it didn't require MySql to save on ram usage.
Now I do write, email, program, and browse on my system on the primary head, while my wife skips commercials on the television using the remote! Don't be afraid to try it, my system isn't a speed daemon and isn't even in the same room as my television. I just connect the system and television with some long high quality coax.
Thank you MythTV developers!
I've been running MythTV for about two months, and have previously posted on my experience. I've been 100% Unix at home for ten years last month and my MythTV box is one of three Linux boxes plus one OS X box at home.
."
My experience with MythTV is can be summed up in the statement "It's great, but . .
Great:
* Support for recording and playing back HDTV broadcast feeds from FireWire (cable box) and MPEG-2 capture card (over-the-air) sources.
But . . .
* FireWire input is generally reliable, but nodes sometimes mysteriously and unpredictably move around based on when and how the cable box, mythbackend daemon, and the MythTV box get started and restarted. (I don't think this is a MythTV problem, but more to do with the current state of the Linux FireWire libraries plus some unreliability on the part of the very common Motorola DCT-6200.)
* MythTV's current state of over-the-air channel detection and setup is so, so horribly bad as to be nearly unusable. It's still not completely clear to me how the combination of Zap2It's program data and mythtv-setup's transport scanning are to work together. Anyone setting up over-the-air reception is going to run into the utterly baffling "missing PIDs" issue. Despite this I previously had, after enormous amounts of grief and multiple tries, three over-the-air HDTV channels working and working well; then all of a sudden one stopped working despite signal locks and an unchanged antenna orientation. Right now, with a rebuilt box, I only have one channel working right.
Great:
* Very, very nice user interface (I really like the Retro theme and Isthmus OSD) with tons of great features.
But . . .
* Holes in the most obvious places. For example, I have two HDTV cable boxes and the aforementioned over-the-air capture card. Let's say cable box #1 can't be used at the moment because fo the aforementioned wandering-node issue or because the preset channel is not broadcasting due to an outage. There's no way to, in Live TV mode, skip that tuner and go on to the others; instead, mythfrontend bounces me right back to the menu (if it doesn't crash completely). If the over-the-air card can't lock into the channel it's preset to, mythfrontend again bounces me right back to the menu or crashes instead of letting me instead try a channel that is working.
So on and so forth. (By the way, I really dislike the way its fans tend to push KnoppMyth as some kind of all-in-one, turnkey MythTV box-on-a-CD for dummies. It's not, unless you want to call lack of support for SATA drives in the install script and USB keyboards and mice a "feature" (unless things have improved since 5A26), and portraying it this way simply hurts the MythTV cause.)
Don't get me wrong; I still *really* like MythTV, am very happy with what I can do with it and how I've set up my little quasi-home theater setup, and it's quite possible 0.19 has taken care of some of the more glaring issues. But it's labeled 0.19 *for a reason*. Everything I wrote in my previous posting still holds, for better or for worse.
You are correct. ETSI document EN 300 743 describes the subtitle stream specification, which includes both RLE subtitle image data, and actual character codes.
3 00743v010201o.pdf
The specification can be found here: http://webapp.etsi.org/action%5COP/OP20021004/en_