[mythtv-users] Fedora-based diskless frontends -- anybody have one working?
I'm wondering if anybody's successfully set up a Fedora-based diskless frontend booting over the network. I'm trying to get an ATRPMS-based (pretty much Jarod's-guide-style) FC4 machine booting up over the net and mounting the root read/write over NFS -- not because I don't have a spare drive, but because it's in an environment which has already killed one drive because of heat issues. I've gotten it booting over PXE, retrieving the kernel (via DHCP, TFTP, and PXELinux), and booting *that* -- actually, that part was surprisingly easy -- but I can't get it to the point of NFS-mounting the root drive. I've tried playing with DHCP and pxelinux.cfg parameters, and even inserted nfs.ko (and its dependencies, sunrpc.ko and lockd.ko) and forcedeth.ko (my network driver) in the initrd, and played around with the "init" script in the initrd every which way from Tuesday, but can't seem to get a configuration that doesn't result in a kernel panic when it can't find its root (the latest is that it's reporting an RPC 101 error -- though I have to insert sleeps in the init script just so I can have time to read the error messages on the TV, which is annoying). I've been over the archives and the rest of the 'net trying to get this to work. There seem to be 1000 different things that 1000 different people recommend, every one is different, and most are rather outdated -- and none match a modern FC4 system, or gloss over the details, or at least don't work for me, or are intended for a different purpose. I can't get system-config-netboot (1.0.34) to work on my system, and I haven't heard any success stories with that anyhow. I'll recompile the kernel if necessary, though I'd love to avoid that just to make maintenance easier in the future (since it's already a headache to maintain the house's systems, and ideally I'd like to have all 3 primary frontends running diskless); for that matter, it'd be wonderful to avoid manually modifying initrd every time I upgrade kernels, though that's probably a lost cause. So -- any diskless Fedora success stories? If so, could you describe what's in your pxelinux.cfg, dhcpd.conf, and initrd -- or what else you did to get it working? -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] HD Frontend hardware: cases for enclosed spaces
Mark Kundinger wrote: Well, the one thing that might be a sticker is how intensively you plan on using it as a DVD player. If you use that a lot, then I'd recommend putting the Mythbox in the exposed location, for easy access. Good point, but I don't really mind opening the doors to get at the DVD player -- heck, that's where my old DVD player was before it gave up the ghost. So should I take it that nobody's tried to use a frontend in an enclosed space like these before, or that people have tried and simply had no airflow problems either way? -spc -- /- Sean Cier <[EMAIL PROTECTED]>-\ (Dreams of falling, dreams of flying; ) ( a man who never dreams goes slowly mad) \-http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] HD Frontend hardware: cases for enclosed spaces
I'm finally chucking the wretched XBox that has served as my living room frontend for far too long, and building a proper machine. I want HDTV support (only have an SDTV there at the moment, and no HD sources, but the latter will hopefully change before long, and the former will undoubtedly be replaced some day). That means a hefty processor; I'm planning on going Athlon 64. I'll have a hard drive just to avoid the headaches of remote boot, but it'll spin down and presumably not be a factor heat-wise. The catch is, I want to put this in my armoire-style TV cabinet. That means either: -- in a shelf under/over the TV (~5" high X 27" wide x 20" deep, but a case must be no more than 4.2" high to actually be able to get it in there), which is open on the front but enclosed on the sides/rear/top/bottom, or -- in the cabinet area, in which case it'd have a whole half of the cabinet to itself (17"w x 19"h x 21" deep), but apart from a 1" vertical wire-access slit in the rear, the doors will be closed and it'll be completely enclosed effectively 24/7. So, I see three options. I'd love advice, feedback, anecdotes, what-have-you about which will most likely work without fear of overheating, and give me the least grief from a stability, functionality, future lifetime (e.g. replacable parts), and compatibility/standard-hardware standpoint (I want to be able to use modules from ATRPMS as much as possible, like my other boxes, not spend hours patching it every way from Tuesday just to get something to maybe run briefly on Thursday mornings when Saturn is ascendant). -- Slim desktop-style case, ala Minuet or Pundit-R (these *can* work horizontally, right?). Seems like if the vents are in the right places and the case has pretty good -- Cube-style SFF case in the cabinet, ala Antec Aria (I've been happy with Antec cases in the past) or Shuttle. Seems like the small case, with clearance on the sides *and* top, would give a shot at better airflow. -- ATX-sized desktop case in the cabinet, ala Cooler Master 620 (which I'm using happily for another frontend), Ahanix D.Vine, Silverstone, NMediaPC, etc. If the lack of edge clearance (the cabinet is only 17" wide) isn't an issue from an airflow standpoint, this would be a lot easier to deal with than a shuttle-style SFF case. -- Say screw it and put a run-of-the-mill mini-tower in the cabinet. Wouldn't look as sexy as the other solutions, but definitely the easiest, and *probably* would have the best airflow overall; and hey, it'd be behind doors usually. With no tuners and such, the hardware demands are relatively light and I never anticipate them growing too far (though perhaps evolving with new video cards, new processors, etc someday) -- but I want something solid that isn't going to give me grief, and something that'll last a while without going completely obsolete. And, I want *full* Myth PVR/music/DVD/video functionality -- no embedded hardware that'll only do half of what my other frontends will. I'm not too concerned with absolute silence in this location, though I of course don't want an absolute jet engine either. I'm only concerned with appearance if I use one of the shelves rather than the cabinet, though I'll go for a decent HTPC-style appearance either way rather than a drab 1990 beige. -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] PVR-150/500 and bttv?
Duncan Brown wrote: Try using the basic tveeprom module direct from the kernel instead of the one provided by ivtv: (tveeprom-ivtv, you'll also need to remove the alias in modprobe) That seems to have fixed it beautifully -- thanks, Duncan! Out of curiosity, what does the tveeprom module *do*, anyhow? -spc -- /- Sean Cier <[EMAIL PROTECTED]>-\ ( Death to Vermin! ) \-http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] PVR-150/500 and bttv?
Apologies for the semi-OT post, but I'm wondering if anybody else here is successfully running a PVR-150 (or 500) and a bttv-based card in the same system -- preferably using ATrpms -- and if so, whether you could post your modprobe.conf. For background, I'm running FC4, and my new PVR-500 works beautifully, as does the old bttv card when ivtv isn't present. When trying to use both, though (yes, I *need* 3 analog tuners! 2 aren't enough! Especially when my Air2PC doesn't seem to like Northern VA Comcast's QAM... grumble grumble), I'm getting the following dmesg errors when I try to use both with my latest modprobe.conf: Sep 10 09:11:00 deepthought kernel: bttv: disagrees about version of symbol tveeprom_hauppauge_analog Sep 10 09:11:00 deepthought kernel: bttv: Unknown symbol tveeprom_hauppauge_analog Sep 10 09:11:00 deepthought kernel: bt878: Unknown symbol bttv_read_gpio Sep 10 09:11:00 deepthought kernel: bt878: Unknown symbol bttv_write_gpio Sep 10 09:11:00 deepthought kernel: bt878: Unknown symbol bttv_gpio_enable Sep 10 09:11:00 deepthought kernel: bttv: disagrees about version of symbol tveeprom_hauppauge_analog Sep 10 09:11:00 deepthought kernel: bttv: Unknown symbol tveeprom_hauppauge_analog The relevant portions of my modprobe.conf: alias char-major-81 ivtv alias char-major-81-0 ivtv alias char-major-81-1 ivtv alias char-major-81-2 bttv alias tveeprom tveeprom-ivtv alias tuner tuner-ivtv alias msp3400 msp3400-ivtv options bttv chroma_agc=1 pll=1 radio=0 card=34 tuner=2 Relevant RPMS (almost everything on this system is pure ATrpms-based): kernel-2.6.12-1.1398_FC4 ivtv-kmdl-2.6.12-1.1398_FC4-0.3.7k-96.rhfc4.at ivtv-0.3.7k-96.rhfc4.at ivtv-firmware-dec-2.02.023-4.at ivtv-firmware-enc-2.04.024-4.at ivtv-firmware-audio-0.0.1-1.at bttv-kmdl-2.6.12-1.1398_FC4-0.9.15_20050708_202133-58.rhfc4.at bttv-0.9.15_20050708_202133-58.rhfc4.at I imagine one or more of the the alias tveeprom/tuner/msp3400 lines are to blame, but before getting too deep into a workaround, I was wondering if it's trivial or not worth fixing. -spc -- /-Sean Cier <[EMAIL PROTECTED]>-\ (Yield, he told the silver triangle. Cough up arcane secret. ) \-http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] Is it legal to archive and collect episodes?
Brad Templeton wrote: If the flag is set, you have protected content. A tuner is forbidden from handing protected content in digital form to a device that is not "trusted" to further honor the protection. Some things you can do: [...] e) Put out digital audio, but at no better than CD quality Please say this isn't true. Is this seriously part of the FCC mandate? Are they seriously going to obselete nearly every receiver out there with DD/AC-3 and DTS support? This has got to be an installed base comparable to -- maybe great than -- even the current sum total of HDTV owners! -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] DVI to HDMI
Brad Templeton wrote: Well, here's an odd failure story. I picked up a cable -- perhaps it was too cheap, but the sense I get with HDMI and cheap cables is that as a digital standard it either works or it doesn't. Which is a common myth or misunderstanding. Each bit being either 0 or 1 doesn't mean that a billion bits either get there or don't -- and moreover, it doesn't mean the cabling is not a factor. It's still an analog signal carrying those digital bits, a signal which is subject to attenuation, noise, etc. And even beyond that, the cable itself can cause problems; for instance, coaxial (RCA-style) digital audio interconnects can carry noise such as a 60Hz hum along with the actual signal, resulting in audible artifacts even over a 'digital' cable -- which is why some prefer an optical cable to electrically isolate components (I myself am not nearly that much of a perfectionist, but it's a good example of 'digital cable' != 'perfect reproduction'). And the image sucked! It wasn't as overscanned, which is nice, but it was noticeably worse in computer display mode (which shows resolution the best). What sucked about it -- sparklies (often green), horizontal lines (i.e. a ground loop), colour, fuzziness, or something else? Colour is a common difference; it usually just means things have to be calibrated differently, and the digital version is generally more reliable and accurate even if it doesn't 'look right' at first. Sparklies (or just lack of signal) are the only common artifact I know of that might actually be due to the cable itself; otherwise it's probably either a setting somewhere (i.e. not actually using the same resolution contrary to appearances; or a display setting -- e.g., my projector has a whole set of settings that are independent based on input) or possibly the display itself actually has inferior electronics along the 'digital input' path. -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] FYI: 6600GT mythcommflag stats
Blair Preston wrote: Not sure what y'all want to see, I a 6 week old myth user. What I want to see is video of how you even work the remote. My 7-month old daughter *loves* to play with them, but she has yet to actually navigate the menus successfully, much less run benchmarks. If this isn't proof that Myth is easy to use, I don't know what is. -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] v.17 success stories?
[EMAIL PROTECTED] wrote: Those that are having troubles are usually more vocal, but I would like to hear from folks who are having success with v.17. I am interested in upgrading my v.16 systems, but they are working so well it makes me nervous. Just upgraded a backend (FC2) and three frontends (FC1, Xebian, and FC3), and all is working beautifully (well, except for the missing modules on the XBox). For the FC1 box I needed to grab the FC2 redhat-artwork rpm then pull qt 3.3 from Axel's bleeding repo, but otherwise it was pretty much a one-line upgrade on each box, had it done in an hour last night while splitting my time between that, washing dishes and ripping CDs. And I didn't even accidentally wash any CDs or rip any dishes, even when watching Aqua Teen Hunger Force at 1.5x speed (which will seriously mess with your head). -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] Xbox Xebian 1.1.1 and Mythtv 0.17? Anyone got it working yet?
Matthew Daubenspeck wrote: It looks like Dennis's installer doesn't work with 1.1.1. I tried that today, and it didn't work. As another data point: I use 1.1.0 with Dennis's 0.4.5-beta, which installed fine. I just upgraded to 0.17, and -- apart from all the missing 0.17 modules in Matt Zimmerman's repository (no mythvideo, mythdvd, mythmusic, etc) -- it works beautifully. -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] DVD rip idea
Michael J. Emswiler wrote: If anyone knows of a quick and easy way to get at the disc title in an easy manner, I'm all ears :-) DVDNAME=`isoinfo -d -i $DEVICE | grep "Volume id" | cut -b12-` -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: [mythtv-users] HD input in the future (DVI and HDMI)
Alex wrote: > Brad Templeton wrote: >> Sean Cier wrote: >>> protection: DVI+HDCP means DVI + copy protection, while HDMI basically >>> means DVI+HDCP+Audio+BidirectionalCommunications >> I had read a source that suggested you could not get a licence for the HDMI stuff if you didn't promise to do HDCP, but I haven't verified that. What would be the point of doing HDMI without HDCP? I hadn't meant to imply that HDMI without HDCP was even a possibility -- even if there's any chance it's technically or contractually possible, it's nowhere near likely to happen. HDMI is really geared towards the consumer electronics market. I have yet to see a DVI/HDMI source in this market which didn't support HDCP. All the current receivers support it too. Exactly. Just because the transmitter and receiver support HDCP, one does not have to use it unless the content provided requires that level of protection. Which we have to assume will be the case for all content one day, likely before long. Of course, that's not a guarantee -- look at the original red book spec and you'll see that even CDs have a 'copy protection flag' bit, which is universally ignored. But even given the chance market forces dictating that none of this copy protection (in particular the broadcast flag) is ever flipped on, we have to assume it will be. They have developed whole new rafts of key revocation tech that, in theory, let them revoke only the solo device that was compromised. Yep - that's one of the intents of HDCP. It is quite technically feasible as each device has a unique value. However as the previous mail alluded to, it may never be put into much practice. Discovery and management of a list of compromised key sets is not trivial. And even beyond the technical challanges are the economic issues. E.g. who's going to pay for updates to devices with revoked keys, or replacing those devices that aren't upgradable -- the studios who don't make the hardware or the hardware manufacturers who don't drive the revocation decision in the first place? And more significantly, what kind of consumer backlash are we going to see the first time several tens of thousands of consumers discover their TVs will suddenly no longer play the latest DVDs or TV? That's not just bad for the brand's reputation, it means money spent for customer support. And when it comes down to the bottom line rather than abstract theories and paranoid speculation, the affected companies will really have to take a good hard look at how much real money this technology is actually saving them. -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
[mythtv-users] HD input in the future (DVI and HDMI)
Brad Templeton wrote: Then the push will come from the studios to get rid of component video and DVI. (They are already fully underway with DVI, almost all new TV sets have HDMI instead, which is backwards compatible with DVI.) Uncertain how that battle will go. Just wanted to clarify here; I presume you were just simplifying for clarity's sake, but wanted to point out that HDMI does not mean DVI + copy protection: DVI+HDCP means DVI + copy protection, while HDMI basically means DVI+HDCP+Audio+BidirectionalCommunications (to negotiate formats, send IR signals, etc) with a new connector. So nothing about HDMI is really about copy protection -- it just happens that the version of DVI that HDMI is based on already included copy protection (HDCP) -- and AFAIK, nearly all currently-for-sale displays which have DVI input already have DVI+HDCP (as do many or possibly most video sources with DVI output, i.e. HD tuners and some DVD players). If anybody doubts this, a bit of searching reveals $30 dongles that take HDMI as input and send DVI output, simply by stripping out the 'unneccessary' bits of HDMI; no decryption involved, since the encrypted video stream is the same between the two. Also note that there's been a lot of suggestion that HDCP is quite readily crackable, quite possibly already effectively cracked; there's just not yet a good motivation to distribute the cracks ala libdvdcss, since nobody could yet do anything useful with the unencrypted DVI stream anyhow. It's a slightly fuzzy area since the industry(*) could fight back against *some* kinds of cracks by using key revocation -- but key revocation is an entirely untested technology, and is likely utterly, laughably impractical in the real world. (*)I'll leave determining *which* industry as an exercise to the reader. So even if full-resolution component video and 'vanilla' DVI become a thing of the past, using DVI+HDCP or HDMI -- currently the state-of-the-art connector, with no suggestions of anything higher-tech on the horizon -- and MPEG2 encoders which, as Brad suggested, Moore's law will inevitably bring us -- will mean that HD input to our Myth boxes will be a real possibility long-term, with likely the only 'hack' being obtaining a 'libhdcp' the same way you obtain 'libdvdcss' now (and, worst-case, the use of an external HD tuner box used the same way cable tuners are used by many now). Of course, it would be nice if even this turned out not to be necessary for our fair-use manipulation of the datastream, but if it does, it's not the end of the world. Of course, for OTA or unencrypted cable, using a GnuRadio card <http://comsec.com/wiki?UniversalSoftwareRadioPeripheral> and ATSC (or QAM) software codec could result in a more elegant solution even in a post-broadcast-flag era; but that doesn't necessarily work for encrypted cable signals, and its legal status for OTA remains to be determined (though it would have to be a pretty flaky legal decision to make that hardware illegal). Even better would be if the EFF and others succeeded in getting the ridiculous broadcast flag struck down in court (well, more specifically, the FCC's self-granted oversight over the entire data chain and hence the entire technology industry). And/or maybe a cable tuner PCI card that took a CableCard and delivered clear MPEG2 bitstreams or, hell, even uncompressed frames... hey, a guy can dream, can't he? -spc -- /- Sean Cier <[EMAIL PROTECTED]> -\ ( Everyone should believe in something; I believe I'll have another pint ) \- http://www.PostHorizon.com/scier -/ ___ mythtv-users mailing list mythtv-users@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
