As others have pointed out, the bitching was entirely about ATI's appallingly awful Linux drivers. They are exceptionally picky about what they will run on; nVidia's just seem to need MTRR in the kernel to work.
For me at least, installing and upgrading my gentoo systems' nVidia drivers is quick and painless, and in fact much easier than windows (unless you use the WHQL drivers from windows update).
Granted, nVidia have snafu'd up a coupla times in the past when they couldn't keep up with kernel development (slowness WRT 2.6 and 4/8k stacks for example), but it's always been remedied fairly speedily. Contrast to ATI, who don't even support x86-64 yet, which nVidia have supported since before the chips came out.
Back to your point, we'd *all* love to see nVidia and ATI GPL their drivers and bung 'em in the kernel, but since they both want to keep alot of secrets from the other and they don't actually have rights to alot of the code, their hands are tied.
I do however share your optimistic belief that the code will become progressively more open in the future; the high end GFX workstation will hopefully prove instrumental in this respect.
I've never liked onboard much, so have never used it. Some people have problems with the nForce built-in both under Windows and Linux; there's also a fair few people happily using them for MythTV. YMMV, I guess!
"They were very slow to support 2.6"
Sorta true, but 'slow' isn't an objective measurement; I believe they were faster than everyone else (not that I paid much attention to it at the time - I didn't try 2.6 until 2.6.5). As an aside, they supported x86-64 before the chips were even available, something ATI *still* hasn't done a year on - so if you want an accelerated ATI card on an AMD64 mobo, you have to stick with 32bit Linux. Yuk.
"And as a gentoo user, I hated the binary installation program."
As the AC pointed out, gentoo has had ebuilds of this since forever (also heavily mentioned in the installation howto), since nVidia doesn't mind other distros supplying the drivers (read their license), and packages for the drivers are available in both gentoo and debian (the only two distros I commonly use). Yes, those packages do contain binary modules, but both nVidia's and ATI's hands are tied in this respect - there is no way they can open source their drivers.
"This was a great article, however, because it shows just how much chance and luck there is in getting these drivers to work"
Heh, this is obviously gonna be one of those "YMMV" cases;) Installation for me has always been a snap (easier and quicker than in windows at any rate), and I have personally never had the nVidia driver obviously b0rk on me (except on a dodgy gigabyte mobo with a dicky AGP slot), and their ease of installation, performance and stability has done nothng but increase with each successive upgrade.
"And then there is the very real fear of whether it will work after you upgrade your kernel"
This has pretty much been eradicated, at least with nVidia, since the module uses GPL'd glue code to bond to your new kernel. It's only if you [en|dis]able some new function that nVidia haven't caught up with yet (such as the infamous 4/8k stacks issue) that you may run into problems.
I use nVidia cards in the three systems I have that need acceleration; namely my desktop and two MythTV boxes. XvMC and OpenGL are used heavily on both, and I have more problems with other things crapping out (like ivtv and mythbackend, grr!) than I do my nVidia cards.
Personally, I've had more problems with my motherboard (AMD64 with 64bit gentoo) than I have with my GFX card, and I go through about a kernel a week. After the initial installation, upgrades have been totally seamless (there's even several scripts around that will check your kernel-dependent external drivers - nvidia, ivtv, lirc, etc - against your running kernel, and recompile and restart services as neccesary, which makes upgrades seamless *and* pretty much transparent) and the driver has been rock solid (within reason) - for a binary driver without the kernel devs sanction (albeit using GPL glue code), I find this impressive.
"Sad to see that Nvidia is the most Linux friendly vendor?"
Try an ATI card next time then;)
Some might call me an nVidia fanboy, some might call me lucky, but in my experience nVidia's efforts under Linux are to be applauded. They're supporting a very niche OS, and (in my experience at least) are doing a very good job of it. Their drivers are worlds apart compared to those crummy closed drivers that require a specific kernel version on a specific distro, and then require a specific ambient temperature, moon phase alignment and virgin sacrifices to work (yes, I once tried to get a Promise RAID card working in Linux too).
In an industry dominated by secrecy, competition and closed sources, nVidia are considerably further along in penetrating and supporting the Linux market than anyone else I've had the misfortune to deal with.
Disclaimer: I don't work in any way for nVidia, and I am not trying to discredit the parent, just pointing out my side of the coin
Arguments about "XXXX should GPL their drivers!" aside...
I may be wrong, but I was under the impression that the "core" of the nVidia driver is essentially very similar under both Windows and Linux, hence why producing Linux drivers in tandem with their Windows one should be relatively easy, since there's only one codebase. Again I may be wrong, but I believe this is not the case for ATI.
nVidia got around the rapidly changing kernel interface by GPLing some "glue" code that bound the kernel to the binary module. Hence it's trivially easy for the kernel devs to keep the nVidia module(s) compatible with the kernel by way of altering the glue, and hence why the nVidia module works with pretty much every kernel on pretty much every x86 distro I've seen.
OTOH, getting the ATI's to work has been a complete PITA, and frequently I give up. They too have (recently) gone down the "glue" code route, but their driver is still *very* picky as per your configuration. For nVidia all I have to do is make sure that MTRR is enabled in the kernel.
I've been using bleep since the launch, and it's grown to encompass most of the UK's premier indie labels, including Warp and Ninja Tunes. I've downloaded about a gig and a half from their site, some of which was legitamising the stuff I downloaded offof P2P when I was a student, and then filling my capacity for Aphex Twin, Red Snapper and Funki Porcini:)
They've had a pretty stellar track record in my book (always up - may be something to do with it running BSD;) always maxes out my download bandwidth, no-nonsense policies), and my only gripes with it are:
The site doesn't work properly in Opera (unsure if this is a bleep thing or an opera thing) They don't provide vorbis or FLAC, but they say they are considering it - email them with your support for superior file formats! Although the MP3's they do flog are of very good quality (some even made by the artists themselves if you believe the blurb) The unzipped filenames are less than helpful, and I need to run them though EasyTag before they're usable - thankfully the tags are very well done and consistent throughout The previews need to be longer, as most electronica tracks don't vary much over 30s. A "random song radio" would be ncie for impulse buys as well:)
TBH, the only fundamentally wrong thing with Bleep is that none of the major labels will ever come onboard, which will be a loss for a lot of you. Thankfully, not for me, as I switched to indie labels-only several years ago, and have never looked back. If you're at all into electronica or hip hop, give Bleep a whirl, if only to listen to a few previews - you won't be disappointed!
Disclaimer: I do not work for Warp Records and am in no way affiliated with the bleep.com (although I wish I was, damnit! Time to roll out that CV...)
Maybe this was intended as a joke, but I'm of the opinion that the "adult" industry has done more for the widespread adoption of the internet and online distribution in general than any other competing industry. Mod parent up!
...the same kinda thing done with an Opteron or an FX-53.
Although they got the system to boot at 6GHz, it was only stable enough to bench at 5.6GHz. Given that the default clock was 3.6GHz, that's a 155% overclock. To do the same to an Opteron x50/FX-53 (2.4GHz) would mean you'd need to clock it to 3.75GHz - does anyone know if this is possible with lN2?
For one thing, the AMD64's don't run as hot as the Prescott's, and their architecture is much friendlier to insane clock speeds (i.e. much shorter pipeline, embedded memory controller directly proprtional to clock speed, MUCH larger L1 cache so there's less stalls waiting for access to memory) in the overclocking parlance... does anyone ever try overclcoking for performance, rather than pure GHz?
Personally I'd love to see a 5.6GHz P4 go up against a 3.8GHz AMD64 (maybe with some o' those gentoo bootstrap "benches")... it'd be a true geekfest:)
...just roll your own MP3/vorbis/FLAC/speex version by recording the output from your FM/DAB radio via line in. Yes, it's an analogue hole, but you get *much* better quality than from a RealMedia source.
If you live in the UK, you can hook your line-in up to your FM/DAB tuner, and make yourself cron jobs to record the input to WAV, then transcode into vorbis or flac... gives much higher quality than -dumpstream from a RealMedia stream.
Works well for me:) All I need now is a way of getting the computer to change the frequency, although I rarely record more than one thing a week, so I just set the tuner manually.
Pretty much any hardware firm with an interest in servers will have contributed to Linux in some form or other. They know that if someone is considering Linux and one company has demonstrated that they "support" Linux and have actually contributed to it, it will make thier hardware peform better than the competitors.
Even companies like Tyan (server motherboards) have produced a range of kernel patches you can download from their site, as well as their system monitoring utils and information on lm_sensors, that sort of thing. By open-sourcing their drivers, 3ware/AMCC have practically cornered the market in hardware IDE RAID cards for Linux.
F-Secure make a rather splendid AV to combat this exact problem. All the samba servers we deploy to companies run F-Secure to scan incoming mail, the samba shares, and the management agent to distribute patches to the windows clients. It's a very good package.
Sigh. I didn't want ads in my browser (not that they're very noticeable anyway), so I bought it. I find Opera faster and *much* easier to use and customise than the Mozilla family. My company uses Opera exclusively (some of them paid for, the rest ad-supported) because using FireFox with windwos romaning profiles still has issues (as does OpenOffice, grr), as does upgrading.
I'm not saying that the Moz family isn't a great software suite, but until it can equal the user friendliness of Opera for me, it won't be my primary browser.
Depending on the application, anything from nothing to alot;)
Unlike the EMT64 Intel x86-64 processors, the AMD64's actually contain extra registers which only work on 64bit code, so be running 64bit code you get extra registers.
This really makes a difference with some CPU-heavy apps; a couple of examples that spring to mind are LAME and MySQL, which show performacne increases of ~30-50% vs. 32bit code on the same hardware. Not bad for a "free" upgrade:)
The key difference between patents on a mechanical process like the steam engine and an informational process like software is that 15 years of stagnation in steam engines is a small blip in the roadmap. The basic process of steam engines hasn't changed much in the past 200 years, it has just gradually evolved.
Information however is pretty much instantly outdated. How much code are Linus and MS using that's 15 years old? Very little, I'd wager.
The point it that 15 years of information patent essentially makes that information useless to everyone but the applicant. After those 15 years are up, the information will be so outdated as to render it useless.
Your problem would be fitting both a TV card and a DXR3 into a VIA C3 box...;)
Theoretically, if should be more than possible, although I know nothing about getting DXR3's up and running under Linux (before my time really).
Although I will say that the Hauppauge PVR-350 (pretty much fully supported under Linux thanks to ivtv) is kinda the combination of the two - hardware encoding and decoding integrated into one PCI card, although they're a bit rubbish for displaying anything other than TV on (although the quality of the TV-Out is unsurpassed).
Another popular option is one of the dirt cheap nVidia GF4 MX's or similar, which will assist the CPU in all video decoding thanks to XvMC extensions (if you use the closed nVidia drivers). If you can shoehorn an AGP card into your system, you'll see almost no load on the CPU with MPEG2 playback, and maybe a little load on the CPU with MPEG4.
You might also want to experiment with the various drivers available for the onboard GFX on those VIA boards (CLE266) which support accelerated MPEG2 playback.
Although to be frank, those VIA CPU's are a tad underpowered to run as a backend if you want to take advantage of all of Myth's features - transcoding, commercial flagging and MythMusic visualisations are all quite CPU intensive. They do make good "dumb" frontends though.
Agreed. Half of what the reviewer said about MythTV ignored its primary strength: flexibility. Sure, MCE is a highly capable product, but it doesn't anywhere near the scalability of a MythTV setup.
You want to set your recordings from work? Easy. Want to rip a DVD? Easy. Want to create a fully integrated MythTV network with a TV in every single room of your mansion and allowing you to watch 20 channels simultaneously? Easy.
The trickiest thing about MythTV is really nothing to do with MythTV at all; if you follow the instructions and use a fairly modern distro, you're fine - pretty much the only thing I had to do was throw in the mysql table and then run the setup utility. The main problem with getting Myth working is getting driver support for the TV cards working (wrt to the popular Hauppauge PVR-2/350 and other cards supported by ivtv), and even then these have come on in leaps and bounds since I started using them (no more manual editing of/etc/modules.conf, it's all automatic), so it's only a matter of time before they hit the mainline kernels, making Myth installation even easier.
Dedicated distros like KnoppMyth make getting your first Myth box up and running a much less painful task, and it's generally all downhill from there. There is also a huge amount of user-driven documentation on the project, and a very active mailing list.
XMLTV is still supported by TiVO, just not in America - there are MythTV users outside of the US you know;)
XMLTV is a combination of site scrapers and XML downloaders that myth can use to insert records into the database, and is available for lots of common regions. However, as the parents says, this was often quite ugly. We're beginning to see a shift to commercial services offerring flat XML files for download via Myth, usually for a price (be it marketing info, money, whatever).
I believe the newer versions of Myth have an internal player as well that supports playback of DVD's, although I'm not sure if it supports encrypted ones. I've not checked it out, since I also use Xine, since it supports DVD menus and mPlayer doesn't.
If you can get output from your cable/sat device into your Mythbox capture card, then yes it's compatible.
There are instructions on how to get your Mythbox to change channels on your cable/sat box in numerous tutorials all over the web.
KnoppMyth is a good way of getting Myth up and running quickly, although most seasoned Myth users seem to prefer to use a full fledge distro in order to give easier configuration of all those peripheral devices. Gentoo, Debian unstable and FC1/2 are very popular choices.
There's a fair amount of documentation over at mythtv.org, and even more extensive hardware specs (alot of which was written by your truly - please edit it if you disagree!) over at the Myth wiki hardware section http://mythtv.info/moin.cgi/HardWare.
I'm based in the UK so don't know much about HDTV, but IIRC the only HDTV card that'll work under Linux (and Linux only) is available from PCHDTV http://pchdtv.com/
Firstly, they try and compare software encoding offof any old bttv card to hardware encoding on a card like the PVR-250 (which Myth is more than capable of handling adequately). Apples and oranges.
They make almost no mention of the many plugins Myth has available, such as the web browser, RSS syndication, weather, music, every kind of video ever (through mPlayer and/or Xine)...
Almost complete non-mention of the way MythWeb (web-based MythTV control and viewing system) seamlessly integrates with the system, and allows you to do funky things with your Mythbox from work
And they also ignore MythTV's *real* strength in that you can cluster as many computers and TV cards as you want into a single cohesive entertainment system spanning your entire house, thanks to it's funky client/server architecture.
Very little objective/subjective comment on the relative merits of the interfaces
Frankly, I find it rather difficult that they could put an entire Myth system together in little under 4 hours, especially since they seem to know little about Linux (for instance, it is practically impossible to compile MythTV in 20 minutes - it takes aaaaaggggggeeeeessss. Methinks they meant download and install rather than compile).
Most of the review (and screenshots) seems to be spent on drooling over MCE's blue buttons. In short, not a very worthwhile or in-depth comparison IMHO.
Slashdot Mirror
As others have pointed out, the bitching was entirely about ATI's appallingly awful Linux drivers. They are exceptionally picky about what they will run on; nVidia's just seem to need MTRR in the kernel to work.
For me at least, installing and upgrading my gentoo systems' nVidia drivers is quick and painless, and in fact much easier than windows (unless you use the WHQL drivers from windows update).
Granted, nVidia have snafu'd up a coupla times in the past when they couldn't keep up with kernel development (slowness WRT 2.6 and 4/8k stacks for example), but it's always been remedied fairly speedily. Contrast to ATI, who don't even support x86-64 yet, which nVidia have supported since before the chips came out.
Back to your point, we'd *all* love to see nVidia and ATI GPL their drivers and bung 'em in the kernel, but since they both want to keep alot of secrets from the other and they don't actually have rights to alot of the code, their hands are tied.
I do however share your optimistic belief that the code will become progressively more open in the future; the high end GFX workstation will hopefully prove instrumental in this respect.
"I have an Nforce2 based MB with built-in video"
;) Installation for me has always been a snap (easier and quicker than in windows at any rate), and I have personally never had the nVidia driver obviously b0rk on me (except on a dodgy gigabyte mobo with a dicky AGP slot), and their ease of installation, performance and stability has done nothng but increase with each successive upgrade.
;)
I've never liked onboard much, so have never used it. Some people have problems with the nForce built-in both under Windows and Linux; there's also a fair few people happily using them for MythTV. YMMV, I guess!
"They were very slow to support 2.6"
Sorta true, but 'slow' isn't an objective measurement; I believe they were faster than everyone else (not that I paid much attention to it at the time - I didn't try 2.6 until 2.6.5). As an aside, they supported x86-64 before the chips were even available, something ATI *still* hasn't done a year on - so if you want an accelerated ATI card on an AMD64 mobo, you have to stick with 32bit Linux. Yuk.
"And as a gentoo user, I hated the binary installation program."
As the AC pointed out, gentoo has had ebuilds of this since forever (also heavily mentioned in the installation howto), since nVidia doesn't mind other distros supplying the drivers (read their license), and packages for the drivers are available in both gentoo and debian (the only two distros I commonly use). Yes, those packages do contain binary modules, but both nVidia's and ATI's hands are tied in this respect - there is no way they can open source their drivers.
"This was a great article, however, because it shows just how much chance and luck there is in getting these drivers to work"
Heh, this is obviously gonna be one of those "YMMV" cases
"And then there is the very real fear of whether it will work after you upgrade your kernel"
This has pretty much been eradicated, at least with nVidia, since the module uses GPL'd glue code to bond to your new kernel. It's only if you [en|dis]able some new function that nVidia haven't caught up with yet (such as the infamous 4/8k stacks issue) that you may run into problems.
I use nVidia cards in the three systems I have that need acceleration; namely my desktop and two MythTV boxes. XvMC and OpenGL are used heavily on both, and I have more problems with other things crapping out (like ivtv and mythbackend, grr!) than I do my nVidia cards.
Personally, I've had more problems with my motherboard (AMD64 with 64bit gentoo) than I have with my GFX card, and I go through about a kernel a week. After the initial installation, upgrades have been totally seamless (there's even several scripts around that will check your kernel-dependent external drivers - nvidia, ivtv, lirc, etc - against your running kernel, and recompile and restart services as neccesary, which makes upgrades seamless *and* pretty much transparent) and the driver has been rock solid (within reason) - for a binary driver without the kernel devs sanction (albeit using GPL glue code), I find this impressive.
"Sad to see that Nvidia is the most Linux friendly vendor?"
Try an ATI card next time then
Some might call me an nVidia fanboy, some might call me lucky, but in my experience nVidia's efforts under Linux are to be applauded. They're supporting a very niche OS, and (in my experience at least) are doing a very good job of it. Their drivers are worlds apart compared to those crummy closed drivers that require a specific kernel version on a specific distro, and then require a specific ambient temperature, moon phase alignment and virgin sacrifices to work (yes, I once tried to get a Promise RAID card working in Linux too).
In an industry dominated by secrecy, competition and closed sources, nVidia are considerably further along in penetrating and supporting the Linux market than anyone else I've had the misfortune to deal with.
Disclaimer: I don't work in any way for nVidia, and I am not trying to discredit the parent, just pointing out my side of the coin
Arguments about "XXXX should GPL their drivers!" aside...
I may be wrong, but I was under the impression that the "core" of the nVidia driver is essentially very similar under both Windows and Linux, hence why producing Linux drivers in tandem with their Windows one should be relatively easy, since there's only one codebase. Again I may be wrong, but I believe this is not the case for ATI.
nVidia got around the rapidly changing kernel interface by GPLing some "glue" code that bound the kernel to the binary module. Hence it's trivially easy for the kernel devs to keep the nVidia module(s) compatible with the kernel by way of altering the glue, and hence why the nVidia module works with pretty much every kernel on pretty much every x86 distro I've seen.
OTOH, getting the ATI's to work has been a complete PITA, and frequently I give up. They too have (recently) gone down the "glue" code route, but their driver is still *very* picky as per your configuration. For nVidia all I have to do is make sure that MTRR is enabled in the kernel.
Oh dear, a "me too!" post...!
:)
;) always maxes out my download bandwidth, no-nonsense policies), and my only gripes with it are:
:)
I've been using bleep since the launch, and it's grown to encompass most of the UK's premier indie labels, including Warp and Ninja Tunes. I've downloaded about a gig and a half from their site, some of which was legitamising the stuff I downloaded offof P2P when I was a student, and then filling my capacity for Aphex Twin, Red Snapper and Funki Porcini
They've had a pretty stellar track record in my book (always up - may be something to do with it running BSD
The site doesn't work properly in Opera (unsure if this is a bleep thing or an opera thing)
They don't provide vorbis or FLAC, but they say they are considering it - email them with your support for superior file formats! Although the MP3's they do flog are of very good quality (some even made by the artists themselves if you believe the blurb)
The unzipped filenames are less than helpful, and I need to run them though EasyTag before they're usable - thankfully the tags are very well done and consistent throughout
The previews need to be longer, as most electronica tracks don't vary much over 30s. A "random song radio" would be ncie for impulse buys as well
TBH, the only fundamentally wrong thing with Bleep is that none of the major labels will ever come onboard, which will be a loss for a lot of you. Thankfully, not for me, as I switched to indie labels-only several years ago, and have never looked back. If you're at all into electronica or hip hop, give Bleep a whirl, if only to listen to a few previews - you won't be disappointed!
Disclaimer: I do not work for Warp Records and am in no way affiliated with the bleep.com (although I wish I was, damnit! Time to roll out that CV...)
Maybe this was intended as a joke, but I'm of the opinion that the "adult" industry has done more for the widespread adoption of the internet and online distribution in general than any other competing industry. Mod parent up!
...the same kinda thing done with an Opteron or an FX-53.
:)
Although they got the system to boot at 6GHz, it was only stable enough to bench at 5.6GHz. Given that the default clock was 3.6GHz, that's a 155% overclock. To do the same to an Opteron x50/FX-53 (2.4GHz) would mean you'd need to clock it to 3.75GHz - does anyone know if this is possible with lN2?
For one thing, the AMD64's don't run as hot as the Prescott's, and their architecture is much friendlier to insane clock speeds (i.e. much shorter pipeline, embedded memory controller directly proprtional to clock speed, MUCH larger L1 cache so there's less stalls waiting for access to memory) in the overclocking parlance... does anyone ever try overclcoking for performance, rather than pure GHz?
Personally I'd love to see a 5.6GHz P4 go up against a 3.8GHz AMD64 (maybe with some o' those gentoo bootstrap "benches")... it'd be a true geekfest
Raw clock doesn't count, only the percentile increase. I don't see why an Opteron/AMD64 couldn't be clocked to 180% with lN2.
...just roll your own MP3/vorbis/FLAC/speex version by recording the output from your FM/DAB radio via line in. Yes, it's an analogue hole, but you get *much* better quality than from a RealMedia source.
If you live in the UK, you can hook your line-in up to your FM/DAB tuner, and make yourself cron jobs to record the input to WAV, then transcode into vorbis or flac... gives much higher quality than -dumpstream from a RealMedia stream.
:) All I need now is a way of getting the computer to change the frequency, although I rarely record more than one thing a week, so I just set the tuner manually.
Works well for me
Pretty much any hardware firm with an interest in servers will have contributed to Linux in some form or other. They know that if someone is considering Linux and one company has demonstrated that they "support" Linux and have actually contributed to it, it will make thier hardware peform better than the competitors.
Even companies like Tyan (server motherboards) have produced a range of kernel patches you can download from their site, as well as their system monitoring utils and information on lm_sensors, that sort of thing. By open-sourcing their drivers, 3ware/AMCC have practically cornered the market in hardware IDE RAID cards for Linux.
F-Secure make a rather splendid AV to combat this exact problem. All the samba servers we deploy to companies run F-Secure to scan incoming mail, the samba shares, and the management agent to distribute patches to the windows clients. It's a very good package.
Sigh. I didn't want ads in my browser (not that they're very noticeable anyway), so I bought it. I find Opera faster and *much* easier to use and customise than the Mozilla family. My company uses Opera exclusively (some of them paid for, the rest ad-supported) because using FireFox with windwos romaning profiles still has issues (as does OpenOffice, grr), as does upgrading.
I'm not saying that the Moz family isn't a great software suite, but until it can equal the user friendliness of Opera for me, it won't be my primary browser.
Depending on the application, anything from nothing to alot ;)
:)
Unlike the EMT64 Intel x86-64 processors, the AMD64's actually contain extra registers which only work on 64bit code, so be running 64bit code you get extra registers.
This really makes a difference with some CPU-heavy apps; a couple of examples that spring to mind are LAME and MySQL, which show performacne increases of ~30-50% vs. 32bit code on the same hardware. Not bad for a "free" upgrade
The key difference between patents on a mechanical process like the steam engine and an informational process like software is that 15 years of stagnation in steam engines is a small blip in the roadmap. The basic process of steam engines hasn't changed much in the past 200 years, it has just gradually evolved.
Information however is pretty much instantly outdated. How much code are Linus and MS using that's 15 years old? Very little, I'd wager.
The point it that 15 years of information patent essentially makes that information useless to everyone but the applicant. After those 15 years are up, the information will be so outdated as to render it useless.
Your problem would be fitting both a TV card and a DXR3 into a VIA C3 box... ;)
Theoretically, if should be more than possible, although I know nothing about getting DXR3's up and running under Linux (before my time really).
Although I will say that the Hauppauge PVR-350 (pretty much fully supported under Linux thanks to ivtv) is kinda the combination of the two - hardware encoding and decoding integrated into one PCI card, although they're a bit rubbish for displaying anything other than TV on (although the quality of the TV-Out is unsurpassed).
Another popular option is one of the dirt cheap nVidia GF4 MX's or similar, which will assist the CPU in all video decoding thanks to XvMC extensions (if you use the closed nVidia drivers). If you can shoehorn an AGP card into your system, you'll see almost no load on the CPU with MPEG2 playback, and maybe a little load on the CPU with MPEG4.
You might also want to experiment with the various drivers available for the onboard GFX on those VIA boards (CLE266) which support accelerated MPEG2 playback.
Although to be frank, those VIA CPU's are a tad underpowered to run as a backend if you want to take advantage of all of Myth's features - transcoding, commercial flagging and MythMusic visualisations are all quite CPU intensive. They do make good "dumb" frontends though.
Just to show that silly omissions come in twos, I said it was still supported by TiVO, rather than by MythTV as I *should* have said...
D'oh!
Agreed. Half of what the reviewer said about MythTV ignored its primary strength: flexibility. Sure, MCE is a highly capable product, but it doesn't anywhere near the scalability of a MythTV setup.
/etc/modules.conf, it's all automatic), so it's only a matter of time before they hit the mainline kernels, making Myth installation even easier.
You want to set your recordings from work? Easy.
Want to rip a DVD? Easy.
Want to create a fully integrated MythTV network with a TV in every single room of your mansion and allowing you to watch 20 channels simultaneously? Easy.
The trickiest thing about MythTV is really nothing to do with MythTV at all; if you follow the instructions and use a fairly modern distro, you're fine - pretty much the only thing I had to do was throw in the mysql table and then run the setup utility. The main problem with getting Myth working is getting driver support for the TV cards working (wrt to the popular Hauppauge PVR-2/350 and other cards supported by ivtv), and even then these have come on in leaps and bounds since I started using them (no more manual editing of
Dedicated distros like KnoppMyth make getting your first Myth box up and running a much less painful task, and it's generally all downhill from there. There is also a huge amount of user-driven documentation on the project, and a very active mailing list.
Try out MythTV... the geek in you commands it!
XMLTV is still supported by TiVO, just not in America - there are MythTV users outside of the US you know ;)
XMLTV is a combination of site scrapers and XML downloaders that myth can use to insert records into the database, and is available for lots of common regions. However, as the parents says, this was often quite ugly. We're beginning to see a shift to commercial services offerring flat XML files for download via Myth, usually for a price (be it marketing info, money, whatever).
I believe the newer versions of Myth have an internal player as well that supports playback of DVD's, although I'm not sure if it supports encrypted ones. I've not checked it out, since I also use Xine, since it supports DVD menus and mPlayer doesn't.
emerge -f mythtv && time emerge mythtv definitely takes a about 20 minutes on my athlon 2400, plus distcc array.
The plugins are also C++, which are also rather time consuming.
Don't forget Wap Records!
http://www.bleep.com/
Lots on content from the UK's premier indie labels, plus all of Bjorks back catalogue, all available in unencumbered high quality LAME MP3's
If you can get output from your cable/sat device into your Mythbox capture card, then yes it's compatible.
There are instructions on how to get your Mythbox to change channels on your cable/sat box in numerous tutorials all over the web.
KnoppMyth is a good way of getting Myth up and running quickly, although most seasoned Myth users seem to prefer to use a full fledge distro in order to give easier configuration of all those peripheral devices. Gentoo, Debian unstable and FC1/2 are very popular choices.
There's a fair amount of documentation over at mythtv.org, and even more extensive hardware specs (alot of which was written by your truly - please edit it if you disagree!) over at the Myth wiki hardware section http://mythtv.info/moin.cgi/HardWare.
I'm based in the UK so don't know much about HDTV, but IIRC the only HDTV card that'll work under Linux (and Linux only) is available from PCHDTV http://pchdtv.com/
...there are alot of problems with this review.
Firstly, they try and compare software encoding offof any old bttv card to hardware encoding on a card like the PVR-250 (which Myth is more than capable of handling adequately). Apples and oranges.
They make almost no mention of the many plugins Myth has available, such as the web browser, RSS syndication, weather, music, every kind of video ever (through mPlayer and/or Xine)...
Almost complete non-mention of the way MythWeb (web-based MythTV control and viewing system) seamlessly integrates with the system, and allows you to do funky things with your Mythbox from work
And they also ignore MythTV's *real* strength in that you can cluster as many computers and TV cards as you want into a single cohesive entertainment system spanning your entire house, thanks to it's funky client/server architecture.
Very little objective/subjective comment on the relative merits of the interfaces
Frankly, I find it rather difficult that they could put an entire Myth system together in little under 4 hours, especially since they seem to know little about Linux (for instance, it is practically impossible to compile MythTV in 20 minutes - it takes aaaaaggggggeeeeessss. Methinks they meant download and install rather than compile).
Most of the review (and screenshots) seems to be spent on drooling over MCE's blue buttons. In short, not a very worthwhile or in-depth comparison IMHO.
Coming soon from Apple.... the iPopEye...