Took Amtrak to Columbia, SC from Miami (adding, "fun train trip" to "eclipse"). The train hit a guy on a bike & got delayed ~3.5 hours (tragic, but it meant we had a few more hours to sleep, and got to see SC in daylight instead of arriving at 4am). Got to the hotel at 9, had breakfast, then took a nap for another hour or so.
Spent Sunday at the SC State Museum (an impressive, top-notch museum, I might add), grabbed dinner, hit the observatory, then partied in downtown Columbia (not exactly South Beach, but fun nonetheless).
Monday, went back downtown to watch the eclipse. Enjoyed the "pre-clipse", started recording the crowd ~10 minutes before totality (exposure-locked, so it wouldn't keep increasing the exposure time as the sun dimmed). Was slightly disappointed by relative non-darkness... it was more like "twilight, right after the sun dips below the horizon (but without the red hue... kind of like an older dimmable LED)", and the corona was a lot more prominent than I thought it would be (frankly, I was expecting the sun to be more blocked... it actually looked more like a half-total, half-annular eclipse). Was initially worried about clouds, but the sky totally cleared up around 2:15 & stayed clear until well after totality ended (followed by a downpour about an hour later).
The trip home was uneventful & fun. The crowd at Columbia Station was probably the biggest in Amtrak history. All in all, a fun & worthwhile trip. Definitely planning to go see the next eclipse in 2024.
Some of that vertigo is probably due to your playing environment being TOO immersive.
Try playing in a well-lit room (where the stuff *around* the screen is as bright as the screen itself), on a display that fills 1/4 your field of vision (max).
Playing modern first-person 3D games in a darkened room a few feet away from a big display is almost a guaranteed way to get vertigo within minutes. The key is to give your brain plenty of nonstop cues that it's watching motion on a screen, and not real motion involving YOU.
All kidding aside, try the Lego videogames. They're oddly satisfying, not terribly complex (no need to spend 3 weeks on training missions just to learn how to play), and not particularly vertigo-inducing.
And make it less obvious if a TV advertised as "4k" achieves it using RGBG subpixels. And to give them more ways to avoid disclosing the actual, physical resolution of the display (eg, calling a display with 1280 red, 1280 blue, and 2560 green subpixels per row "4k class" to hide the fact that it's not going to display 3840x2160 with 1:1 mapping).
If they called it "2160p", they could still fudge the horizontal resolution, but they'd at least get fined by the EU if they tried to pawn off a display advertised as "4k class" that only had 1920x1080 physical resolution by muttering bullshit about how the "4k" refers to the "internal" video-processing resolution.
I refuse to buy a new TV until I can buy one (in the US) capable of natively displaying (and being directly driven at) 23.976, 24, 25, 29.94, 30, 48, 50, 59.94, 60, 72, 96, 100, and 120fps.
It's fucking ABSURD that modern displays are still forced into 50hz or 60hz jails. There's NO good technical reason why any new US TV shouldn't be able to display a show natively shot at 25fps or 50fps AT the show's original framerate, without mangling frames with pulldown or dropped/repeated frames. Temporal rate conversion still universally looks like ass, and always will. The best way to convert 720p50 to 720p60 is... leave it as 720p50 & let the display itself support it directly.
European TVs have natively-supported 50 and 60 (at least, via SCART) since the goddamn CRT era, but most new American TVs STILL give you a blue "no signal" screen & shut off if you try feeding them 720p50 via HDMI. It's BULLSHIT.
It's also absurd how many "240hz" TVs can't deal with 720p120 via HDMI. And have no way to tell the video processor, "I'm feeding you fake-3d SBS 720p60... treat it like 640x720 at 120fps & show each half once for 1/120th of a second".
IMHO, the ideal "native" framerate for video is ~150fps... simultaneous 60 and 100fps (captured with 300fps camera framerate), with overlapping 60/100fps frames removed. You can simulcast 50fps by using every other 100fps frame. You can simulcast 60fps by using the 60fps-timed frames. You can get 100fps by ignoring the 60fps frames. You can get 150fps with non-equal timing by displaying frames wherever they fall within 300fps timing. And you can use all 150fps to derive 120fps (taking the 60fps-timed frames as-is, and using the 100fps-timed frames with them to tween the remaining 60fps)
(300fps is the least common multiple of 50 & 60, but if you had a camera that could capture at 300fps and saved ONLY the frames falling on 50fps and 60fps timing, you'd only need to save 100fps, because every 100ms both timings would line up, so you'd need 60+50 - 10 frames. Adding frames needed to increase it to 100fps (at 10ms/frame) would add somewhere between 40 and 50 frames. And HFR only requires slightly more bits if you also double the GOP length (since the frame-to-frame delta is much smaller, it compresses more efficiently).
That's partially because it usually ends up costing the telco MORE money to provide slow DSL than faster DSL. If the fastest available at any price is 768k/128k, you're already running on the bleeding edge of what ADSL can handle at that distance... your line is going to require more tweaking to get working, and is probably going to require more follow-up service over the long run compared to someone with 18mbps/1.5mbps U-verse VDSL2 from a VRAD that's 500 feet away.
That's part of the reason why AT&T used to not allow people who were too far from the CO to qualify for 1.5mbps/128kbps g.LITE ADSL to get it AT ALL... they didn't want to deal with people bitching about how they were paying the same amount for 420kbps/80kbps that others were paying for 1.5mbps/128kbps. So if AT&T said 'no', but you were technically close enough to get 420kbps/80kbps, your basically had three options:
a) go around AT&T and pay a company like Northpoint roughly $200/month to lease a "dry pair" of wires from AT&T and wire it up to their DSLAM (at the time, AT&T hadn't yet installed a DSLAM at MY local central office, so the only way to get anything faster than ISDN or dialup was to pay Northpoint to connect me to the next-nearest CO, which had a DSLAM about a year before my own did).
b) settle for 112kbps ISDN (112kbps, because with Florida ISDN, local "voice" calls were free, but local "data" calls were 3 cents per minute per 64kbps channel... with a little tweaking, you could get the modem to fake two voice calls with 56kbps data and spend unlimited amounts of time online for free). This is what I ended up doing.
c) pay for two voice lines, use it with a shotgun modem, and pray to ${deity} the phone company didn't just throw a PairGain line concentrator on your original pair to get two useless phone lines that maxed out at ~31kbps apiece. With shotgunning, you could get about 107kbps down and 48kbps up. Thankfully, I didn't have to go with this option.
For what it's worth, NorthPoint no longer exists, I don't think anybody supports shotgun modems anymore, and given that a regular landline is now almost $50/month after taxes, I'd be afraid to even ask how much ISDN now costs per month (I think I paid around $100/month just for ISDN circa 1997, back when landline phone service cost about $30/month after taxes).
No it WAS *NOT*. It was Lego Legends of Chima for 3DS. The first time it ran -- from cartridge, on a 3DS not connected to the internet (because we were in a car), it announced that "an update is available that must be installed before the game can run".
My whole point was, you now can't even assume a GODDAMN FUCKING *CARTRIDGE* game will allow you to play it until after it's gotten to access the internet even once.
Imagine if you were a parent taking your kid on a long transpacific or transatlantic flight, bought him a new shrinkwrapped cartridge game, and gave it to him to play on his 3DS once the plane was at cruising altitude... then that shit happened.
Cartridges are EXPECTED by consumers to be self-sufficient to at least some sane degree. Forcing an update before allowing a cartridge (or disc) game to run AT ALL (bugs or not) is bullshit.
> 90s-early 00s era recievers are still probably the best, > unless you need more than 5.1 or 7.1 sound.
Actually, their ability to do even 5.1 surround is likely to diminish over time:
* Dolby designed DD+7.1 to be easy to downconvert to 5.1, but few/no receivers that ONLY know how to handle DD5.1 can do it.
* Few AVRs made prior to ~2012 (and basically NONE prior to ~2009) can do 5.1 PCM, let alone 7.1 PCM.
* Toslink & coaxial SPDIF can't do PCM 5.1 on consumer gear (there IS a way to kludge it with pro audio mixing gear, but it's either forbidden by licence terms or too expensive/niche for AVR manufacturers to use in consumer gear.
* The only real way to get PCM 5.1/7.1 into your AVR is via HDMI... but there's lots of gear made prior to ~2014 that can SWITCH HDMI, but can't actually decode 5.1 or 7.1 AUDIO from HDMI. And plenty that are supposed to, but fucked up their implementation or firmware (e.g, EDID spofing of downstream sinks to keep the source from seeing a PCM2.0(stereo) sink & falling back to PCM2.0 for EVERYTHING (HDMI makes no provision for sending multiple audio streams, so it's up to the AVR to hide the PCM2.0-ness of downstream TVs from upstream sources).
I'm aware of EXACTLY ONE box that can successfully extract 5.1 or 7.1 PCM from HDMI and output it as analog 5.1 or 5.7... and it costs almost as much as a cheap DD+ capable AVR (it's basically a 1-watt amp with a single HDMI input & four 1/8" stereo jack outputs they pretend are 'for headphones' to dance around DRM restrictions... and I'm not 100% confident it can downmix 7.1 to 5.1, so if you're watching a source that supports ONLY DD+7.1 (like Netflix on Roku) & have a 5.1 amp, you're still fucked.
So... you can forget about having surround sound from most HDMI-only streaming clients (like Roku), any recent Nintendo gear (Wii-u & Switch), and probably MOST post-2009 & future Blu-Ray & DVD players and cable boxes (even if the player has SPDIF outputs, if the studio masters the disc with ONLY PCM 7.1, no post-2009 player I'm aware of can/will re-encode it as DD5.1 or DD+7.1 and output it via SPDIF... all you'll get is flat 2.0 stereo).
The thing that sucks the worst is that the lack of PCM5.1/7.1-via-HDMI to analog or re-encoded DD-via-SPDIF is entirely due to DRM. As if being able to record the analog 5.1 surround sound from a movie whose video I can't capture is going to make even the SLIGHTEST fucking difference to studios' bottom lines.
You're assuming a future smart TV won't do bullshit, like refuse to do anything when powered up for the first time because it's hellbent on checking for updated firmware (read: the TV went to manufacturing 6 months before it even HAD working firmware, so they manufactured it with little more than an internet-connected bootloader on the assumption that by the time it ended up in stores, they'd (hopefully) have working firmware for it ready for buyers to download.
Think it can't happen? Hardware like that already exists. One of my friends has a Nintendo 3DS. He bought a new game for it to play in the car on a weekend road trip the night before we left, and ran it for the first time after we were on the road. The game came on cartridge. He put in the cartridge, powered up the system, and had a "fuck my life" moment when it refused to let him do anything until he downloaded an update. If he hadn't been able to tether to my phone, he would have been screwed and unable to play it for several hours. This was a CARTRIDGE GAME that effectively refused to run until it managed to connect to the internet and download something.
By the same token, I can't think of a single time... EVER... when I've been able to stick in a game disc for an Xbox 360, Xbox One, or Wii-U & just PLAY the goddamn game without having to endure 2-20 minutes of mandatory downloads and updates before being allowed to continue. When I plugged in by XB1 for the first time on Christmas Day, I spent my first hour and a half as a new owner staring at the glacially-slow download meter. Why? Games now go to manufacturing LONG before they're anywhere close to being play-ready. Physical media is now just proof of having a license.
Christmas 1983, brand new c64. Plugged it in, turned it on, and wrote my first program in about 20 minutes.
Christmas 2016, brand new dell laptop. Pluged it in, booted it up, and spent the next 2 hours watching Windows Update install update after update after update.
We're frogs getting boiled slowly, one shitty piece of hardware at a time.
I think his main complaint is that it did something that has permanent & profound consequences without making it abundantly clear that he was asking it to DO something with permanent and profound consequences.
I might be wrong, but I'm pretty sure the standard git client and library (used by almost everyone, including Windows) intentionally has NO WAY to literally purge files AND THEIR HISTORY from an existing repo "in place". If you have some need to rewrite history and physically purge all evidence that some file ever existed from the repo, you have to clone the repo with a filter that omits those files, so you'll end up with TWO local copies of the repo... the old one, with everything intact, and the new one, with rewritten history.
"A hacked touchscreen can inject pre-scripted touch events into the event screen"
Of course, this assumes:
a) the device is unlocked
b) the malicious driver can guess where the required touch zones are located (no small feat, considering the diversity of softkey layouts (e.g, Samsung vs Nexus vs LG vs HTC), homescreen launchers, and the layout of app drawers (depending upon what the user installed).
c) Since malware (in addition to the driver itself) is almost a requirement (given a & b), the hardware itself is almost superfluous. At most, it might log touch events to its own local ram, then make them available to malware that knows how to use the attack chip (events Android itself might otherwise choose to not share with the malware).
Put another way, under precisely the right circumstances, a mouse can be used to completely hijack a device's security (by guessing where to move & generating phantom clicks). And if pigs had gills, they could breathe underwater.
The more likely scenario: a state espionage agency replaces touchscreen controller chips with hand-crafted replacements that include a simple radio transmitter so they can remotely monitor & log touch events. That's an ENTIRELY different challenge than implementing your own network stack or attempting to do naughty things over the i2c bus or as a USB peripheral.
Put another way, this is a multi-stage attack that's SO outrageously complex, requiring so many resources from the attacker, and requiring so much knowledge about the state of the target victim's phone, even taking it seriously as a possibility of something that has happened to you requires venturing into the realm of conspiracy-theory paranoia. There are easier, cheaper, and more profitable ways to compromise a user's device without going so far off the complexity deep-end.
Gold is kind of like petroleum -- we've already mined the easy stuff, but the amount STILL LEFT is enormous, limited mainly by how much money it's worth spending to extract. Kind of like how we were officially "running out" of oil when it was cheap, but at 2-3 times the "cheap" price, the US has actually become a net EXPORTER of petroleum (because it's now valuable enough to refine from tar sand, at substantially higher cost than pumping it from a Saudi oil well). The same is true for gold. At current prices, it's sufficiently valuable to extract a few molecules at a time from large volumes of rock or water.
The fact that phones have no direct equivalent of a standard PC BIOS or ISA architecture complicates things quite a bit.
Today's Linux & Windows might use the BIOS mainly as a stage 1 bootloader to launch their stage 2 bootloader (Grub, Windows' boot manager, etc), but devices like Android phones & tablets don't even have *that* benefit... in ARM-land, every platform is different & proprietary to the device vendor (or semi-proprietary to the device vendor, and totally proprietary to the SoC vendor).
There is literally NO vendor-agnostic "right way" to lay out the boot code in flash... or even any vendor-agnostic standard way to WIRE UP that flash. Literally everything that made it possible for Linux, DOS, Windows, OS/2, FreeBSD, etc to be installed on a random "PC" doesn't EXIST in the mobile-device realm. And it probably WON'T ever exist. The fact that "PC" (as a generic, vendor-agnostic platform) even EXISTS is basically a lucky accident.
At best, two Android devices built around the same Qualcomm SoC by different Chinese vendors cranking out variations of the same reference design MIGHT be about as mutually-compatible (at the "bare metal" level) as an IBM PC-AT and a Tandy 2000 were (ie, "sort of"). And most modern mobile devices actively try to prevent you from running other operating systems (usually, in the holy name of DRM-enforcement or one-sided enterprise security).
I can't quote a URL, but I used to work for a major telco & had a role in writing our billing software. Circa 2009, it cost *us* (in taxes and Tariff-mandated fees) more to terminate a landline call from Fort Lauderdale to Boca Raton than it cost for us to terminate a call from a landline phone in Fort Lauderdale to a landline phone in BRITAIN --
because intra-LATA calls (a/k/a "local long-distance" calls) were among the most expensive ones you could make, while international calls actually had the least taxes.
The new inability to poll in the background has at least two drawbacks:
1. increased latency. This is why, with devices like a 'Ring' doorbell, your most likely view -- after the visitor presses the button, the doorbell notifies their server, their server sends a push notification, your phone gets the notification & notifies you, you react to it, unlock the phone, and launch their app -- is (...drumroll...) streaming video of the visitor WALKING AWAY (because they pressed the button 30 seconds ago).
2. Small independent developers might not be able to publish free apps that are only ABLE to be legally free of licensing & service fees because they're directly polling third-party servers for themselves. There are quite a few commercial services that are free of charge to individuals to use, but cost real money for commercial use. If you're using their service as a middleman on behalf of your app's users & redistributing the data to them, it's considered 'commercial' & costs money... potentially, more money than you could realistically make by throwing AdMob banner ads at the bottom of the screen.
If I give away a free app that depends upon data from NOAA's servers & NOAA has an outage, I can shrug & say, "Tough. Go bitch at NOAA. It's out of my hands." And I can abandon it tomorrow if I get bored of maintaining it.
If I'm SELLING an app that depends upon having ME run a server, and MY server goes down, I could be sued, even if I'm losing money on it. And I can't just walk away from the app or its required web service, because charging money implies a commitment to *keeping* the app working for at least a few years.
The personal computers of the 80s weren't disruptive because they were powerful, they were disruptive because the took away the power of centralized servers to act as gatekeepers & chaperones. This is a lesson too many people have forgotten. Does *anyone* thing we'd have stuff like the nearly-infinite variety of streaming porn we have today if we'd gone straight from 16mm film to streaming by large corporations like Netflix, without VHS & DVD along the way? An entire INDUSTRY emerged in the 80s and 90s PRECISELY BECAUSE nobody was in a position of control to say, "No, you can't do that. Our legal dept. won't approve it because it might violate the law somewhere in the Bible Belt, and senior management would veto it anyway due to the risk of bad press". Ditto for Bulletin Board systems back in the 80s & 90s, that anyone could self-host with a spare computer & a phone line.
Why would the carrier even CARE anymore? Actual voice calls are NOW almost more trouble & taxes than they're worth.
Data, on the other hand, is their new big-ticket billable item... they LOVE apps that constantly poll for data, because a single-byte payload in a TCP/IP request generates a few hundred billable bytes of data transfer. Carriers would abandon voice & MAKE you find your own VoIP service if they thought they could get away with it. Voice calls are now just a loss-leader to sell data.
With someone like AT&T, T-mobile, Verizon, or Sprint (where voice calls are free), they LOSE money (in state & federal taxes) every time someone makes a voice call. If you use some other VoIP service, it's win-win for the telco.
I think 96khz was motivated by filter design, but 192khz was primarily to minimize bit jitter with realtime digital mixing (even with a shared clock source, it's *really hard* to get multiple sources outputting serial bitstreams to have every single bit line up *precisely* in realtime (ie, no buffering to add latency). 192khz gives more headroom to tolerate slightly-sloppy timing.
It's not "to nowhere" -- it's the new, high-speed middle segment of a route with existing tracks at both ends.
Long before CAHSR starts to officially run its OWN trains, Amtrak will be able to put the new tracks to good use. Once the first segment through the Central Valley is done (around 2019), it'll let Amtrak shave about 2-3 hours from their LA-Oakland travel time (via the San Joaquin train). Once the second segment (to a point somewhere around Merced) is done, it'll reduce Amtrak's LA-Oakland travel time to a semi-tolerable 5-6 hours.
It's no different than how I-4 was built in Florida. When the first segment of I-4 opened (between... Plant City and Lakeland...), people angrily called it a "boondoggle" and a "freeway to nowhere", even though it was common knowledge that FDOT already had plans to build it all the way from Daytona Beach through Orlando & Tampa to St. Petersburg (the St. Pete segment is now part of I-275). It didn't matter. People bitched about it anyway, just like people are bitching about California HSR now.
50 years from now, the fight over CalHSR is going to seem as absurd & silly as the fights over I-4 and the Florida Turnpike were back in the 50s and 60s.
Signage won't always save you. Especially in Texas (kick-ass roads, awful signage)
Years ago, I was on a freeway in downtown Dallas. I think I was on westbound I-30, heading to northbound I-35E. There's a section where westbound I-30 merges briefly with northbound I-35E.
In Florida, there would have been two huge signs spanning the road with arrows pointing at specific lanes... one that said something like "I-30 West (to I-35 North & Woodall Rodgers Fwy)", and one that said "exit to I-35E South".
In Dallas? The road split in two, with a single sign between them off in the distance. It said "Waco" and some other city & had arrows pointing left & right. No highway names or numbers. No compass direction. Just two fsck'ing city names a visitor was apparently expected to know the locations of relative to a ~10 lane freeway in downtown Dallas.
I'm glad I saved my Voom Satellite TV boxes when they went under... I'm now using two of them on secondary TVs in the house. Their ATSC tuners are FANTASTIC.
They probably do it because they know that most purchasers don't actually USE the OTA tuner, but they're required to provide it by law. By requiring a free code, they can get away with only paying royalties to MPEG-LA and/or ATSC for the TVs that have the feature enabled. AFAIK, those royalties aren't cheap, so being able to avoid them for most of the TVs they sell can save the manufacturer quite a bit of money.
> So use your genius-level brain and learn that foreign language
It would help a lot if foreign-language channels ALSO had subtitles (I personally can read Spanish pretty well, but suck at understanding spoken Spanish, unless the speaker is another American who learned Spanish as a second language). Until fairly recently, not even popular primetime shows on Univision and Telemundo had subtitles. Apparently, despite collectively having a greater market share in Miami than ABC, NBC, CBS, and Fox, they were legally classified as "minority" stations & exempted from having to provide subtitles like English-language stations have been required to do since the 80s. And even now, it's obvious that most of their subtitles are done with speech-recognition software and have no human proofreading at all.
One reason for TV channels that break up is the fact that lots of TV stations use insanely long MPEG2 GOPs as a way to decrease the bitrate of their main HD channel & free up more bits for their SD subchannels. Historically, 15-frame GOPs were the generally-accepted norm. Nowadays, stations commonly use GOPs with 60 frames or more.
MPEG2 has 3 kinds of frames... I, B, and P. An I-frame is basically like a JPEG image... it contains all the data you need to display it. B and P frames are derived from adjacent frames, and individually require significantly fewer bits to encode than an I-frame.
So... suppose you have a broadcaster whose main channel is 1080i60, with 2 or 3 480i60 subchannels. To make room for those subchannels, the broadcaster might use 60-frame GOPs. Since 1080i60 has 30 real frames per second, this means that if a burst of RF noise corrupts the first frame after an I-frame, the picture could conceivably be corrupted for two whole seconds before it gets another I-frame and is able to recover.
I've never seen it done "in the wild" by an actual broadcaster, but in theory, there's a way to make this more tolerable. Basically, you make the GOP longer, but encode redundant bands of complete data into the B & P frames (spread around, so each frame in the GOP has different bands). That way, if a frame gets badly corrupted early in the GOP, the details will fill back in (kind of like the old Apple II "venetian blind" effect) starting with the next frame, instead of remaining corrupted until the next I-frame.
> Not sure what I'll do when MSFT stops providing automatically updated program listings for local TV stations
You might have to edit the registry to get guide data from someone besides Microsoft, but it's not hard to do, and there's already at least one company that will independently provide guide data for around $25/year.
In retrospect, it's pretty amazing how Windows Media Center has taken on a life of its own and remained viable literally YEARS after Microsoft officially abandoned it, thanks mostly to the fact that they made it so open-ended and user-extensible to begin with. IMHO, WMC is probably one of the best products Microsoft has ever made.
Personally, I wish SlingTV would just pay SiliconDust to write them server code to emulate a HDHR Prime, coupled with a virtual WMC tuner that connects to SlingTV over the internet as if it were a HDHR Prime. Then, SlingTV customers could just use WMC as their DVR. I'd venture a guess that probably 99% of the client-side code could be recycled from the HDHR Prime's drivers, and writing the server-side code at SlingTV's end would be fairly straightforward (compared to the server-side code they've ALREADY had to write to make the service exist at all).
This is a HUGE, under-appreciated advantage. It's a lot harder to "cut the cord" (or switch providers) if doing so means losing the all of the recorded TV shows locked into your current DVR. With a cablecard-ready HDHomeRun, you can subscribe to Comcast for a year using a cablecard, record shows using Windows Media Center, then cancel Comcast at the end of the year and spend the next 2 years watching shows you recorded... then resubscribe to Comcast for another year once you're eligible for "new subscriber" pricing again.
Up until around 2012, the only way to get a cablecard-compatible PC tuner was to buy a complete, certified HTPC from someone like Dell (at staggering cost that pretty much destroyed the economics of doing this). At some point, CableLabs quit requiring that the ENTIRE system be certified & approved, and allowed you to build your own computer running Windows 7, attach it to something like a HDHomeRun Prime, and use it to record copy-protected shows. The recordings themselves are still inextricably bound to the computer used to record them (at least, if they're flagged COPY_ONCE by the cable company), but the cablecard only governs whether or not WMC is allowed to RECORD them... once they're recorded, they're yours to enjoy forever, as long as the computer itself doesn't break.
If you have an old computer (or moderately high-end laptop from sometime after 2008) that already has Windows 7, you can pick up a used HDHomeRun Prime on eBay for around $90 (more, if you're in a hurry... less, if you can deal with losing a few auctions until you get lucky). For another $10-25, you can buy an official Windows Media Center remote & USB IR receiver on Amazon. For another $125 or so, you can add a 3 or 4 terabyte USB hard drive, and have probably 4-20 times the recording space you EVER got to have with a DVR leased from the cable company.
Once you have the hardware, subscribe to cable with one outlet, no box, no DVR service (the guide data comes from Microsoft for free), and a single cablecard. For other TVs, go on Craigslist and buy a used XBOX 360 for around $40-50, which you can then use over your home's LAN as a media center extender (to watch shows recorded on that DVR, or even watch live TV using one of the HTPC's tuners). As an added perk, if you have an older amp that can decode Dolby Digital over SPDIF, but doesn't have HDMI inputs, the XB360 is one of the only ways I know of to get DD5.1 surround sound via SPDIF from Netflix. Win-win.
> put another antenna up there, and wire them together to try to get a distant > (but in-market!) channel in a different direction
Doesn't work. Or more precisely, it's a LOT more complicated than just feeding two antennas into a diplexer to combine them into a single cable.
Using a diplexer to combine VHF & UHF from an antenna with DVB-S from a satellite dish works, because the frequency band of the signals coming from the antenna doesn't overlap with the frequency band of the signals coming from the dish.
Using a diplexer to combine an antenna tuned to VHF with an antenna tuned to UHF works, because the two frequency bands are still separate, both antennas are pointed in exactly the same direction, and the manufacturer can precisely balance the impedance between the two.
Using a diplexer to combine two VHF+UHF antennas pointing in different directions usually makes matters worse. Assuming you're able to properly match the impedance between both antenna circuits (not guaranteed), there's still the matter of multipath interference.
Suppose you have two antennas... one aimed northeast, and one aimed west. To the northwest and north, there's a cluster of skyscrapers or a mountain. You want to watch channel 35, whose transmitter is 15 miles northeast of you.
If you connect only the antenna that's aimed northeast, and it's a directional antenna, you'll probably get a good, strong signal. Some of channel 35's signal will reflect off of the skyscrapers or mountain at an angle, but your northeastward-pointing antenna won't even see most of those weak reflections.
HOWEVER... your antenna that's aimed westward IS going to scoop up some of those reflections. Because radio waves propagate at the speed of light, the reflected signals will arrive a fraction of a second later than the ones traveling in a straight line. If you combine the signals from both antennas, you'll NOW end up with a signal that has strong multipath interference. With analog TV, multipath interference causes ghosting. With digital TV, it either makes no difference at all, or leaves you with an unwatchable signal that stutters and breaks up.
Moral of the story: if you have two antennas, give each antenna its own dedicated cable all the way to the tuner. Combining the signals from two antennas into one cable using a diplexer rarely works well.
Slashdot Mirror
Took Amtrak to Columbia, SC from Miami (adding, "fun train trip" to "eclipse"). The train hit a guy on a bike & got delayed ~3.5 hours (tragic, but it meant we had a few more hours to sleep, and got to see SC in daylight instead of arriving at 4am). Got to the hotel at 9, had breakfast, then took a nap for another hour or so.
Spent Sunday at the SC State Museum (an impressive, top-notch museum, I might add), grabbed dinner, hit the observatory, then partied in downtown Columbia (not exactly South Beach, but fun nonetheless).
Monday, went back downtown to watch the eclipse. Enjoyed the "pre-clipse", started recording the crowd ~10 minutes before totality (exposure-locked, so it wouldn't keep increasing the exposure time as the sun dimmed). Was slightly disappointed by relative non-darkness... it was more like "twilight, right after the sun dips below the horizon (but without the red hue... kind of like an older dimmable LED)", and the corona was a lot more prominent than I thought it would be (frankly, I was expecting the sun to be more blocked... it actually looked more like a half-total, half-annular eclipse). Was initially worried about clouds, but the sky totally cleared up around 2:15 & stayed clear until well after totality ended (followed by a downpour about an hour later).
The trip home was uneventful & fun. The crowd at Columbia Station was probably the biggest in Amtrak history. All in all, a fun & worthwhile trip. Definitely planning to go see the next eclipse in 2024.
Some of that vertigo is probably due to your playing environment being TOO immersive.
Try playing in a well-lit room (where the stuff *around* the screen is as bright as the screen itself), on a display that fills 1/4 your field of vision (max).
Playing modern first-person 3D games in a darkened room a few feet away from a big display is almost a guaranteed way to get vertigo within minutes. The key is to give your brain plenty of nonstop cues that it's watching motion on a screen, and not real motion involving YOU.
All kidding aside, try the Lego videogames. They're oddly satisfying, not terribly complex (no need to spend 3 weeks on training missions just to learn how to play), and not particularly vertigo-inducing.
And make it less obvious if a TV advertised as "4k" achieves it using RGBG subpixels. And to give them more ways to avoid disclosing the actual, physical resolution of the display (eg, calling a display with 1280 red, 1280 blue, and 2560 green subpixels per row "4k class" to hide the fact that it's not going to display 3840x2160 with 1:1 mapping).
If they called it "2160p", they could still fudge the horizontal resolution, but they'd at least get fined by the EU if they tried to pawn off a display advertised as "4k class" that only had 1920x1080 physical resolution by muttering bullshit about how the "4k" refers to the "internal" video-processing resolution.
I refuse to buy a new TV until I can buy one (in the US) capable of natively displaying (and being directly driven at) 23.976, 24, 25, 29.94, 30, 48, 50, 59.94, 60, 72, 96, 100, and 120fps.
It's fucking ABSURD that modern displays are still forced into 50hz or 60hz jails. There's NO good technical reason why any new US TV shouldn't be able to display a show natively shot at 25fps or 50fps AT the show's original framerate, without mangling frames with pulldown or dropped/repeated frames. Temporal rate conversion still universally looks like ass, and always will. The best way to convert 720p50 to 720p60 is... leave it as 720p50 & let the display itself support it directly.
European TVs have natively-supported 50 and 60 (at least, via SCART) since the goddamn CRT era, but most new American TVs STILL give you a blue "no signal" screen & shut off if you try feeding them 720p50 via HDMI. It's BULLSHIT.
It's also absurd how many "240hz" TVs can't deal with 720p120 via HDMI. And have no way to tell the video processor, "I'm feeding you fake-3d SBS 720p60... treat it like 640x720 at 120fps & show each half once for 1/120th of a second".
IMHO, the ideal "native" framerate for video is ~150fps... simultaneous 60 and 100fps (captured with 300fps camera framerate), with overlapping 60/100fps frames removed. You can simulcast 50fps by using every other 100fps frame. You can simulcast 60fps by using the 60fps-timed frames. You can get 100fps by ignoring the 60fps frames. You can get 150fps with non-equal timing by displaying frames wherever they fall within 300fps timing. And you can use all 150fps to derive 120fps (taking the 60fps-timed frames as-is, and using the 100fps-timed frames with them to tween the remaining 60fps)
(300fps is the least common multiple of 50 & 60, but if you had a camera that could capture at 300fps and saved ONLY the frames falling on 50fps and 60fps timing, you'd only need to save 100fps, because every 100ms both timings would line up, so you'd need 60+50 - 10 frames. Adding frames needed to increase it to 100fps (at 10ms/frame) would add somewhere between 40 and 50 frames. And HFR only requires slightly more bits if you also double the GOP length (since the frame-to-frame delta is much smaller, it compresses more efficiently).
That's partially because it usually ends up costing the telco MORE money to provide slow DSL than faster DSL. If the fastest available at any price is 768k/128k, you're already running on the bleeding edge of what ADSL can handle at that distance... your line is going to require more tweaking to get working, and is probably going to require more follow-up service over the long run compared to someone with 18mbps/1.5mbps U-verse VDSL2 from a VRAD that's 500 feet away.
That's part of the reason why AT&T used to not allow people who were too far from the CO to qualify for 1.5mbps/128kbps g.LITE ADSL to get it AT ALL... they didn't want to deal with people bitching about how they were paying the same amount for 420kbps/80kbps that others were paying for 1.5mbps/128kbps. So if AT&T said 'no', but you were technically close enough to get 420kbps/80kbps, your basically had three options:
a) go around AT&T and pay a company like Northpoint roughly $200/month to lease a "dry pair" of wires from AT&T and wire it up to their DSLAM (at the time, AT&T hadn't yet installed a DSLAM at MY local central office, so the only way to get anything faster than ISDN or dialup was to pay Northpoint to connect me to the next-nearest CO, which had a DSLAM about a year before my own did).
b) settle for 112kbps ISDN (112kbps, because with Florida ISDN, local "voice" calls were free, but local "data" calls were 3 cents per minute per 64kbps channel... with a little tweaking, you could get the modem to fake two voice calls with 56kbps data and spend unlimited amounts of time online for free). This is what I ended up doing.
c) pay for two voice lines, use it with a shotgun modem, and pray to ${deity} the phone company didn't just throw a PairGain line concentrator on your original pair to get two useless phone lines that maxed out at ~31kbps apiece. With shotgunning, you could get about 107kbps down and 48kbps up. Thankfully, I didn't have to go with this option.
For what it's worth, NorthPoint no longer exists, I don't think anybody supports shotgun modems anymore, and given that a regular landline is now almost $50/month after taxes, I'd be afraid to even ask how much ISDN now costs per month (I think I paid around $100/month just for ISDN circa 1997, back when landline phone service cost about $30/month after taxes).
No it WAS *NOT*. It was Lego Legends of Chima for 3DS. The first time it ran -- from cartridge, on a 3DS not connected to the internet (because we were in a car), it announced that "an update is available that must be installed before the game can run".
My whole point was, you now can't even assume a GODDAMN FUCKING *CARTRIDGE* game will allow you to play it until after it's gotten to access the internet even once.
Imagine if you were a parent taking your kid on a long transpacific or transatlantic flight, bought him a new shrinkwrapped cartridge game, and gave it to him to play on his 3DS once the plane was at cruising altitude... then that shit happened.
Cartridges are EXPECTED by consumers to be self-sufficient to at least some sane degree. Forcing an update before allowing a cartridge (or disc) game to run AT ALL (bugs or not) is bullshit.
> 90s-early 00s era recievers are still probably the best,
> unless you need more than 5.1 or 7.1 sound.
Actually, their ability to do even 5.1 surround is likely to diminish over time:
* Dolby designed DD+7.1 to be easy to downconvert to 5.1, but few/no receivers that ONLY know how to handle DD5.1 can do it.
* Few AVRs made prior to ~2012 (and basically NONE prior to ~2009) can do 5.1 PCM, let alone 7.1 PCM.
* Toslink & coaxial SPDIF can't do PCM 5.1 on consumer gear (there IS a way to kludge it with pro audio mixing gear, but it's either forbidden by licence terms or too expensive/niche for AVR manufacturers to use in consumer gear.
* The only real way to get PCM 5.1/7.1 into your AVR is via HDMI... but there's lots of gear made prior to ~2014 that can SWITCH HDMI, but can't actually decode 5.1 or 7.1 AUDIO from HDMI. And plenty that are supposed to, but fucked up their implementation or firmware (e.g, EDID spofing of downstream sinks to keep the source from seeing a PCM2.0(stereo) sink & falling back to PCM2.0 for EVERYTHING (HDMI makes no provision for sending multiple audio streams, so it's up to the AVR to hide the PCM2.0-ness of downstream TVs from upstream sources).
I'm aware of EXACTLY ONE box that can successfully extract 5.1 or 7.1 PCM from HDMI and output it as analog 5.1 or 5.7... and it costs almost as much as a cheap DD+ capable AVR (it's basically a 1-watt amp with a single HDMI input & four 1/8" stereo jack outputs they pretend are 'for headphones' to dance around DRM restrictions... and I'm not 100% confident it can downmix 7.1 to 5.1, so if you're watching a source that supports ONLY DD+7.1 (like Netflix on Roku) & have a 5.1 amp, you're still fucked.
So... you can forget about having surround sound from most HDMI-only streaming clients (like Roku), any recent Nintendo gear (Wii-u & Switch), and probably MOST post-2009 & future Blu-Ray & DVD players and cable boxes (even if the player has SPDIF outputs, if the studio masters the disc with ONLY PCM 7.1, no post-2009 player I'm aware of can/will re-encode it as DD5.1 or DD+7.1 and output it via SPDIF... all you'll get is flat 2.0 stereo).
The thing that sucks the worst is that the lack of PCM5.1/7.1-via-HDMI to analog or re-encoded DD-via-SPDIF is entirely due to DRM. As if being able to record the analog 5.1 surround sound from a movie whose video I can't capture is going to make even the SLIGHTEST fucking difference to studios' bottom lines.
You're assuming a future smart TV won't do bullshit, like refuse to do anything when powered up for the first time because it's hellbent on checking for updated firmware (read: the TV went to manufacturing 6 months before it even HAD working firmware, so they manufactured it with little more than an internet-connected bootloader on the assumption that by the time it ended up in stores, they'd (hopefully) have working firmware for it ready for buyers to download.
Think it can't happen? Hardware like that already exists. One of my friends has a Nintendo 3DS. He bought a new game for it to play in the car on a weekend road trip the night before we left, and ran it for the first time after we were on the road. The game came on cartridge. He put in the cartridge, powered up the system, and had a "fuck my life" moment when it refused to let him do anything until he downloaded an update. If he hadn't been able to tether to my phone, he would have been screwed and unable to play it for several hours. This was a CARTRIDGE GAME that effectively refused to run until it managed to connect to the internet and download something.
By the same token, I can't think of a single time... EVER... when I've been able to stick in a game disc for an Xbox 360, Xbox One, or Wii-U & just PLAY the goddamn game without having to endure 2-20 minutes of mandatory downloads and updates before being allowed to continue. When I plugged in by XB1 for the first time on Christmas Day, I spent my first hour and a half as a new owner staring at the glacially-slow download meter. Why? Games now go to manufacturing LONG before they're anywhere close to being play-ready. Physical media is now just proof of having a license.
Christmas 1983, brand new c64. Plugged it in, turned it on, and wrote my first program in about 20 minutes.
Christmas 2016, brand new dell laptop. Pluged it in, booted it up, and spent the next 2 hours watching Windows Update install update after update after update.
We're frogs getting boiled slowly, one shitty piece of hardware at a time.
I think his main complaint is that it did something that has permanent & profound consequences without making it abundantly clear that he was asking it to DO something with permanent and profound consequences.
I might be wrong, but I'm pretty sure the standard git client and library (used by almost everyone, including Windows) intentionally has NO WAY to literally purge files AND THEIR HISTORY from an existing repo "in place". If you have some need to rewrite history and physically purge all evidence that some file ever existed from the repo, you have to clone the repo with a filter that omits those files, so you'll end up with TWO local copies of the repo... the old one, with everything intact, and the new one, with rewritten history.
"A hacked touchscreen can inject pre-scripted touch events into the event screen"
Of course, this assumes:
a) the device is unlocked
b) the malicious driver can guess where the required touch zones are located (no small feat, considering the diversity of softkey layouts (e.g, Samsung vs Nexus vs LG vs HTC), homescreen launchers, and the layout of app drawers (depending upon what the user installed).
c) Since malware (in addition to the driver itself) is almost a requirement (given a & b), the hardware itself is almost superfluous. At most, it might log touch events to its own local ram, then make them available to malware that knows how to use the attack chip (events Android itself might otherwise choose to not share with the malware).
Put another way, under precisely the right circumstances, a mouse can be used to completely hijack a device's security (by guessing where to move & generating phantom clicks). And if pigs had gills, they could breathe underwater.
The more likely scenario: a state espionage agency replaces touchscreen controller chips with hand-crafted replacements that include a simple radio transmitter so they can remotely monitor & log touch events. That's an ENTIRELY different challenge than implementing your own network stack or attempting to do naughty things over the i2c bus or as a USB peripheral.
Put another way, this is a multi-stage attack that's SO outrageously complex, requiring so many resources from the attacker, and requiring so much knowledge about the state of the target victim's phone, even taking it seriously as a possibility of something that has happened to you requires venturing into the realm of conspiracy-theory paranoia. There are easier, cheaper, and more profitable ways to compromise a user's device without going so far off the complexity deep-end.
Gold is kind of like petroleum -- we've already mined the easy stuff, but the amount STILL LEFT is enormous, limited mainly by how much money it's worth spending to extract. Kind of like how we were officially "running out" of oil when it was cheap, but at 2-3 times the "cheap" price, the US has actually become a net EXPORTER of petroleum (because it's now valuable enough to refine from tar sand, at substantially higher cost than pumping it from a Saudi oil well). The same is true for gold. At current prices, it's sufficiently valuable to extract a few molecules at a time from large volumes of rock or water.
The fact that phones have no direct equivalent of a standard PC BIOS or ISA architecture complicates things quite a bit.
Today's Linux & Windows might use the BIOS mainly as a stage 1 bootloader to launch their stage 2 bootloader (Grub, Windows' boot manager, etc), but devices like Android phones & tablets don't even have *that* benefit... in ARM-land, every platform is different & proprietary to the device vendor (or semi-proprietary to the device vendor, and totally proprietary to the SoC vendor).
There is literally NO vendor-agnostic "right way" to lay out the boot code in flash... or even any vendor-agnostic standard way to WIRE UP that flash. Literally everything that made it possible for Linux, DOS, Windows, OS/2, FreeBSD, etc to be installed on a random "PC" doesn't EXIST in the mobile-device realm. And it probably WON'T ever exist. The fact that "PC" (as a generic, vendor-agnostic platform) even EXISTS is basically a lucky accident.
At best, two Android devices built around the same Qualcomm SoC by different Chinese vendors cranking out variations of the same reference design MIGHT be about as mutually-compatible (at the "bare metal" level) as an IBM PC-AT and a Tandy 2000 were (ie, "sort of"). And most modern mobile devices actively try to prevent you from running other operating systems (usually, in the holy name of DRM-enforcement or one-sided enterprise security).
I can't quote a URL, but I used to work for a major telco & had a role in writing our billing software. Circa 2009, it cost *us* (in taxes and Tariff-mandated fees) more to terminate a landline call from Fort Lauderdale to Boca Raton than it cost for us to terminate a call from a landline phone in Fort Lauderdale to a landline phone in BRITAIN --
because intra-LATA calls (a/k/a "local long-distance" calls) were among the most expensive ones you could make, while international calls actually had the least taxes.
The new inability to poll in the background has at least two drawbacks:
1. increased latency. This is why, with devices like a 'Ring' doorbell, your most likely view -- after the visitor presses the button, the doorbell notifies their server, their server sends a push notification, your phone gets the notification & notifies you, you react to it, unlock the phone, and launch their app -- is (...drumroll...) streaming video of the visitor WALKING AWAY (because they pressed the button 30 seconds ago).
2. Small independent developers might not be able to publish free apps that are only ABLE to be legally free of licensing & service fees because they're directly polling third-party servers for themselves. There are quite a few commercial services that are free of charge to individuals to use, but cost real money for commercial use. If you're using their service as a middleman on behalf of your app's users & redistributing the data to them, it's considered 'commercial' & costs money... potentially, more money than you could realistically make by throwing AdMob banner ads at the bottom of the screen.
If I give away a free app that depends upon data from NOAA's servers & NOAA has an outage, I can shrug & say, "Tough. Go bitch at NOAA. It's out of my hands." And I can abandon it tomorrow if I get bored of maintaining it.
If I'm SELLING an app that depends upon having ME run a server, and MY server goes down, I could be sued, even if I'm losing money on it. And I can't just walk away from the app or its required web service, because charging money implies a commitment to *keeping* the app working for at least a few years.
The personal computers of the 80s weren't disruptive because they were powerful, they were disruptive because the took away the power of centralized servers to act as gatekeepers & chaperones. This is a lesson too many people have forgotten. Does *anyone* thing we'd have stuff like the nearly-infinite variety of streaming porn we have today if we'd gone straight from 16mm film to streaming by large corporations like Netflix, without VHS & DVD along the way? An entire INDUSTRY emerged in the 80s and 90s PRECISELY BECAUSE nobody was in a position of control to say, "No, you can't do that. Our legal dept. won't approve it because it might violate the law somewhere in the Bible Belt, and senior management would veto it anyway due to the risk of bad press". Ditto for Bulletin Board systems back in the 80s & 90s, that anyone could self-host with a spare computer & a phone line.
Decentralization is a feature, not a bug.
Why would the carrier even CARE anymore? Actual voice calls are NOW almost more trouble & taxes than they're worth.
Data, on the other hand, is their new big-ticket billable item... they LOVE apps that constantly poll for data, because a single-byte payload in a TCP/IP request generates a few hundred billable bytes of data transfer. Carriers would abandon voice & MAKE you find your own VoIP service if they thought they could get away with it. Voice calls are now just a loss-leader to sell data.
With someone like AT&T, T-mobile, Verizon, or Sprint (where voice calls are free), they LOSE money (in state & federal taxes) every time someone makes a voice call. If you use some other VoIP service, it's win-win for the telco.
I think 96khz was motivated by filter design, but 192khz was primarily to minimize bit jitter with realtime digital mixing (even with a shared clock source, it's *really hard* to get multiple sources outputting serial bitstreams to have every single bit line up *precisely* in realtime (ie, no buffering to add latency). 192khz gives more headroom to tolerate slightly-sloppy timing.
It's not "to nowhere" -- it's the new, high-speed middle segment of a route with existing tracks at both ends.
Long before CAHSR starts to officially run its OWN trains, Amtrak will be able to put the new tracks to good use. Once the first segment through the Central Valley is done (around 2019), it'll let Amtrak shave about 2-3 hours from their LA-Oakland travel time (via the San Joaquin train). Once the second segment (to a point somewhere around Merced) is done, it'll reduce Amtrak's LA-Oakland travel time to a semi-tolerable 5-6 hours.
It's no different than how I-4 was built in Florida. When the first segment of I-4 opened (between... Plant City and Lakeland...), people angrily called it a "boondoggle" and a "freeway to nowhere", even though it was common knowledge that FDOT already had plans to build it all the way from Daytona Beach through Orlando & Tampa to St. Petersburg (the St. Pete segment is now part of I-275). It didn't matter. People bitched about it anyway, just like people are bitching about California HSR now.
50 years from now, the fight over CalHSR is going to seem as absurd & silly as the fights over I-4 and the Florida Turnpike were back in the 50s and 60s.
Signage won't always save you. Especially in Texas (kick-ass roads, awful signage)
Years ago, I was on a freeway in downtown Dallas. I think I was on westbound I-30, heading to northbound I-35E. There's a section where westbound I-30 merges briefly with northbound I-35E.
In Florida, there would have been two huge signs spanning the road with arrows pointing at specific lanes... one that said something like "I-30 West (to I-35 North & Woodall Rodgers Fwy)", and one that said "exit to I-35E South".
In Dallas? The road split in two, with a single sign between them off in the distance. It said "Waco" and some other city & had arrows pointing left & right. No highway names or numbers. No compass direction. Just two fsck'ing city names a visitor was apparently expected to know the locations of relative to a ~10 lane freeway in downtown Dallas.
I'm glad I saved my Voom Satellite TV boxes when they went under... I'm now using two of them on secondary TVs in the house. Their ATSC tuners are FANTASTIC.
They probably do it because they know that most purchasers don't actually USE the OTA tuner, but they're required to provide it by law. By requiring a free code, they can get away with only paying royalties to MPEG-LA and/or ATSC for the TVs that have the feature enabled. AFAIK, those royalties aren't cheap, so being able to avoid them for most of the TVs they sell can save the manufacturer quite a bit of money.
> So use your genius-level brain and learn that foreign language
It would help a lot if foreign-language channels ALSO had subtitles (I personally can read Spanish pretty well, but suck at understanding spoken Spanish, unless the speaker is another American who learned Spanish as a second language). Until fairly recently, not even popular primetime shows on Univision and Telemundo had subtitles. Apparently, despite collectively having a greater market share in Miami than ABC, NBC, CBS, and Fox, they were legally classified as "minority" stations & exempted from having to provide subtitles like English-language stations have been required to do since the 80s. And even now, it's obvious that most of their subtitles are done with speech-recognition software and have no human proofreading at all.
One reason for TV channels that break up is the fact that lots of TV stations use insanely long MPEG2 GOPs as a way to decrease the bitrate of their main HD channel & free up more bits for their SD subchannels. Historically, 15-frame GOPs were the generally-accepted norm. Nowadays, stations commonly use GOPs with 60 frames or more.
MPEG2 has 3 kinds of frames... I, B, and P. An I-frame is basically like a JPEG image... it contains all the data you need to display it. B and P frames are derived from adjacent frames, and individually require significantly fewer bits to encode than an I-frame.
So... suppose you have a broadcaster whose main channel is 1080i60, with 2 or 3 480i60 subchannels. To make room for those subchannels, the broadcaster might use 60-frame GOPs. Since 1080i60 has 30 real frames per second, this means that if a burst of RF noise corrupts the first frame after an I-frame, the picture could conceivably be corrupted for two whole seconds before it gets another I-frame and is able to recover.
I've never seen it done "in the wild" by an actual broadcaster, but in theory, there's a way to make this more tolerable. Basically, you make the GOP longer, but encode redundant bands of complete data into the B & P frames (spread around, so each frame in the GOP has different bands). That way, if a frame gets badly corrupted early in the GOP, the details will fill back in (kind of like the old Apple II "venetian blind" effect) starting with the next frame, instead of remaining corrupted until the next I-frame.
> Not sure what I'll do when MSFT stops providing automatically updated program listings for local TV stations
You might have to edit the registry to get guide data from someone besides Microsoft, but it's not hard to do, and there's already at least one company that will independently provide guide data for around $25/year.
In retrospect, it's pretty amazing how Windows Media Center has taken on a life of its own and remained viable literally YEARS after Microsoft officially abandoned it, thanks mostly to the fact that they made it so open-ended and user-extensible to begin with. IMHO, WMC is probably one of the best products Microsoft has ever made.
Personally, I wish SlingTV would just pay SiliconDust to write them server code to emulate a HDHR Prime, coupled with a virtual WMC tuner that connects to SlingTV over the internet as if it were a HDHR Prime. Then, SlingTV customers could just use WMC as their DVR. I'd venture a guess that probably 99% of the client-side code could be recycled from the HDHR Prime's drivers, and writing the server-side code at SlingTV's end would be fairly straightforward (compared to the server-side code they've ALREADY had to write to make the service exist at all).
> it's not trapped inside your box
This is a HUGE, under-appreciated advantage. It's a lot harder to "cut the cord" (or switch providers) if doing so means losing the all of the recorded TV shows locked into your current DVR. With a cablecard-ready HDHomeRun, you can subscribe to Comcast for a year using a cablecard, record shows using Windows Media Center, then cancel Comcast at the end of the year and spend the next 2 years watching shows you recorded... then resubscribe to Comcast for another year once you're eligible for "new subscriber" pricing again.
Up until around 2012, the only way to get a cablecard-compatible PC tuner was to buy a complete, certified HTPC from someone like Dell (at staggering cost that pretty much destroyed the economics of doing this). At some point, CableLabs quit requiring that the ENTIRE system be certified & approved, and allowed you to build your own computer running Windows 7, attach it to something like a HDHomeRun Prime, and use it to record copy-protected shows. The recordings themselves are still inextricably bound to the computer used to record them (at least, if they're flagged COPY_ONCE by the cable company), but the cablecard only governs whether or not WMC is allowed to RECORD them... once they're recorded, they're yours to enjoy forever, as long as the computer itself doesn't break.
If you have an old computer (or moderately high-end laptop from sometime after 2008) that already has Windows 7, you can pick up a used HDHomeRun Prime on eBay for around $90 (more, if you're in a hurry... less, if you can deal with losing a few auctions until you get lucky). For another $10-25, you can buy an official Windows Media Center remote & USB IR receiver on Amazon. For another $125 or so, you can add a 3 or 4 terabyte USB hard drive, and have probably 4-20 times the recording space you EVER got to have with a DVR leased from the cable company.
Once you have the hardware, subscribe to cable with one outlet, no box, no DVR service (the guide data comes from Microsoft for free), and a single cablecard. For other TVs, go on Craigslist and buy a used XBOX 360 for around $40-50, which you can then use over your home's LAN as a media center extender (to watch shows recorded on that DVR, or even watch live TV using one of the HTPC's tuners). As an added perk, if you have an older amp that can decode Dolby Digital over SPDIF, but doesn't have HDMI inputs, the XB360 is one of the only ways I know of to get DD5.1 surround sound via SPDIF from Netflix. Win-win.
> put another antenna up there, and wire them together to try to get a distant
> (but in-market!) channel in a different direction
Doesn't work. Or more precisely, it's a LOT more complicated than just feeding two antennas into a diplexer to combine them into a single cable.
Using a diplexer to combine VHF & UHF from an antenna with DVB-S from a satellite dish works, because the frequency band of the signals coming from the antenna doesn't overlap with the frequency band of the signals coming from the dish.
Using a diplexer to combine an antenna tuned to VHF with an antenna tuned to UHF works, because the two frequency bands are still separate, both antennas are pointed in exactly the same direction, and the manufacturer can precisely balance the impedance between the two.
Using a diplexer to combine two VHF+UHF antennas pointing in different directions usually makes matters worse. Assuming you're able to properly match the impedance between both antenna circuits (not guaranteed), there's still the matter of multipath interference.
Suppose you have two antennas... one aimed northeast, and one aimed west. To the northwest and north, there's a cluster of skyscrapers or a mountain. You want to watch channel 35, whose transmitter is 15 miles northeast of you.
If you connect only the antenna that's aimed northeast, and it's a directional antenna, you'll probably get a good, strong signal. Some of channel 35's signal will reflect off of the skyscrapers or mountain at an angle, but your northeastward-pointing antenna won't even see most of those weak reflections.
HOWEVER... your antenna that's aimed westward IS going to scoop up some of those reflections. Because radio waves propagate at the speed of light, the reflected signals will arrive a fraction of a second later than the ones traveling in a straight line. If you combine the signals from both antennas, you'll NOW end up with a signal that has strong multipath interference. With analog TV, multipath interference causes ghosting. With digital TV, it either makes no difference at all, or leaves you with an unwatchable signal that stutters and breaks up.
Moral of the story: if you have two antennas, give each antenna its own dedicated cable all the way to the tuner. Combining the signals from two antennas into one cable using a diplexer rarely works well.