It's doing, ...interesting stuff, like rendering markdown on the client, but at least all the required assets are self-served. So it works with uMatrix. Hey, that's something in 2020! 15 years ago we were complaining about the .doc files, now we have the XML based .docx files that are at the very least parseable but we lost the XML based web in between. Now every website implements their own document format which needs to be opened with the executable it sends next to the content. You can try to parse the markup bits but you'll get zero semantic content, that's for sure.
(I believe it is because of some spat between archive is and cloudflare) From the archives:
Please make your products work with URLs
I want to tell you about something I was unable to accomplish, after more than 30 minutes of concerted effort.
I have video file hosted using a web server. The file is H.264 main-profile encoded at a reasonable bitrate (<5Mbps), uses AAC audio, and is packaged in an MP4 container. The web server supports HTTP range requests. In other words, the video is basically in the least common denominator format for compatibility. It streams great in all major web browers, VLC, and everything in between.
In my living room, I have a Roku "smart" TV. It has tons of apps, full internet connectivity, and is more than capable of both connecting to and playing the video file described above. But I failed to get this to happen, after much googling and trying multiple apps (both on the Roku TV and my Android phone).
The way this type of thing is usually accomplished in 2020 is to open the video on your phone, then tap a "cast" icon and tell it to send the video to your TV. What happens behind the scenes is the phone uses some protocol (Chromecast being the most common I'm aware of) to send the URL to the TV, and the TV then plays it directly, while still letting you play/pause, seek, change volume, etc from the phone. When this works, it's like magic. The YouTube app works particularly well. However, there doesn't seem to be any widely implemented standard for playing plain URLs, only walled gardens like the YouTube app.
This whole thing was made much more frustrating by the fact that I knew the TV had all the requisite capabilities to do what I was attempting. The YouTube app is proof of that. There just wasn't any obvious way to find the correct app combination.
Here's the way this should work.
The Roku app for Android allows you to use your phone as a keyboard for the TV, rather than the awful physical remote UX for input. This is a great feature which I appreciate.
I should be able to copy a URL from my phone (possibly obtained from scanning a QR code), paste it into the Roku Android app, and the Roku should attempt to play the file at the URL. This is clunky, awkward, and not particularly easy. But it is simple, obvious, and intuitive.
Here is my plea: when you build hardware/software, please make it support the primitive, simple case. By all means, implement the slick Chromecast-style flows. It's great when it works. But there needs to be a fallback for when it doesn't work, or when the user wants to try something slightly different. HTTP is the lingua franca of the internet. When you build stuff, please make it work with simple URLs.
uBlock Origin is the only blocker running right now. Is it evil and I should run naked? All the rest were disabled for "could not be verified and was disabled" after my last browser update.
Is this site heavy on ads and other malware and won't display without totally naked openness to exploits?
The reason this breaks without Javascript is because it's rendering the Markdown clientside. That could be moved to part of the build process without increasing your hosting requirements at all.
I can see that you already have https://github.com/anderspitman/anderspitman.net/blob/master... started, so I'm assuming you know this already and that you just haven't had the time to set up rendering on build yet. It's not my intention to preach to the choir.
If you're struggling to figure out how to get this working as a SPA while still including content for non-JS users, my advice would be to include the rendered HTML in each index.html and just hide it with CSS during page load. You can still use AJAX for all of your subsequent navigation to avoid reloading the page, but if the static HTML is annotated with the correct links and content, people who request a specific URL without Javascript would still get to read.
Or you could even get fancy and skip hiding it on the initial page load, only swapping it out with AJAX for future navigation, and this would make your initial page load even faster than it currently is.
Rendering markdown client-side seems like a fine way to implement a web page. It's a cheap transformation, and it means you don't need any sort of server-side build process. Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted.
> you don't need any sort of server-side build process
OP is already using a server-side build process to generate the static site. Inserting the HTML at the same time they built the site would add very little extra code to their build process, and nothing to their static hosting requirements.
If nothing else, would OP consider inserting a <noscript> tag in each generated index.html that linked to the raw Markdown in their Github repo?
> OP is already using a server-side build process to generate the static site
The site doesn't use any build process. The gen_static script was an experiment that I didn't make it very far with. I may eventually get back to that.
> anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted.
I never whitelist sites that don't work without JS unless the site is actually critical for some reason (doing so is too risky). I expect that this means some parts of the web effectively no longer exist for people like me, and accept that, but I wonder if the authors of these badly engineered pages really know that they're excluding people.
> I wonder if the authors of these badly engineered pages really know that they're excluding people
People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. Being able to write a site in markdown with static hosting and have it instantly rendered in user's browsers is one of those things!
If you choose to browse with IE6 and complain that sites using HTML5 are excluding you, I'm not going to be sympathetic either.
> People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do.
People who choose to turn off JavaScript are protecting themselves, because JavaScript enables all sorts of attacks on one's security and privacy.
JavaScript is not part of the web platform. The Web is a web (hence the name) of interlinked documents: the core requirements for a web of interlinked documents are a protocol (we have HTTP) and a document format (HTML); a style format (CSS) is nice too, albeit not strictly necessary (one can read unstyled documents in links, lynx, elinks, eww, w3m or whatever else just fine).
There is absolutely no requirement for executing arbitrary, potentially malicious, unverified code from untrusted authors distributed globally. Are there great examples of cool JavaScript applications? Yes, certainly. Is JavaScript a core requirement to support a web of interlinked documents — i.e., the Web? No, not at all.
To the contrary, JavaScript is murdering the Web, and this page's misuse is a prime example. JavaScript delenda est!
Not the original commentor, but I'll assume this is a sincere, open question.
To start with, I'm not on the anti-Javascript hype train. I write Javascript for a living, I think it's the arguably the most important modern language of the last decade. It's made computers more accessible, it has good ideas, it's reasonably well sandboxed. I love Javascript. I do advocate for progressive enhancement for a lot of reasons, but in part because that's the foundation of web architecture, and I think it's still relevant today.
The best web developers I know that I really respect all understand what progressive enhancement really means as an architectural pattern, and they don't dismiss it out of hand.
Also to be clear, the browser is (unarguably) hands down the best consumer-facing sandbox that we've ever built. And I like sandboxes, a lot. I think sandboxing is the future of user-facing application security -- not trusted stores, or signing, or managing dependencies in a special way, or SaaS.
Having said that, I'm also using the web as it exists today. And let's just very quickly list a few major security vulnerabilities that have happened within the past few years in browsers, all of which you would have been effectively immune from if you had disabled Javascript by default on even just most sites you visited:
1. Spectre/Meltdown
2. LastPass's browser extension leaking passwords to any page you visited.
3. Firefox's most recent 0-day (that is being actively exploited)[0].
4. Targeted vulnerabilities in mobile Safari (that went unpatched for years)[1].
On top of the numerous browser vulnerabilities that pop up, disabling Javascript by default will protect you from a nontrivial number of phishing attacks and cookie-hijacking attacks. Yes, you can do these attacks without JS/ajax, but in practice a large number of them use JS/ajax. Disabling JS will also make you effectively immune from crypto-mining attacks.
Even non-malicious pages are usually not coded well in terms of CPU-power. One way you can tell a browser disables JS by default is that the non-JS setup will gracefully handle several hundred tabs at the same time in normal everyday usage for extended periods (>1 month). The other browser will eventually get caught by a rogue tab that freezes everything and forces you to restart the browser.
On the privacy front... I dunno, don't you work at Google? You should know this.
Panoptoclick[2] tells me my current browser setup is leaking about 6.6 bytes of identifying information. That's low enough that with a decent VPN setup, I can browse the web (close to) anonymously in many situations. I would challenge you to get a better result than that without disabling Javascript -- especially if you're starting from the disadvantage of using an uncommon OS like Mac or Linux.
----
So there's an interesting philosophical conflict here, which is that the web is awesome, and browsers are awesome, and Javascript is awesome, but anyone who's both technical and privacy-minded should turn Javascript off by default. And this conflict is because where security is concerned, I am trying very, very hard to be a fox, not a hedgehog.[3]
My general advice, notwithstanding my opinion on sandboxes, is that everyone should install Ublock Origin, no matter who they are. If you're technically inclined and understand the web, you should also install UMatrix, which will at least get rid of the most common attack vectors: third-party scripts. If you're technically inclined and understand the web and you worry a lot about privacy, you should use UMatrix to disable JS by default.
That's not an ideological position about sandboxes or about the web. It's not saying native apps are better (native environments are in most cases objectively worse at security). It's purely an observation that roughly 75% of the sites I visit (including many major news sites) work fine without Javascr...
This is an excellent comment, thank you. You said much of what I failed to, especially this, which was my main point:
> It's not saying that nothing should run Javascript. It is saying that if you want to run Javascript, you should have a reasonably good justification, and if you're displaying pure text you should probably provide fallbacks when possible.
> People who choose to turn off JS are excluding themselves.
It goes both ways. Yes, turning off JS means that some sites will fail to work. As I said in my comment, I expect this. On the other hand, a well-designed site should fail gracefully, so that turning off JS won't make the site fail to work, but may make certain features unavailable. Sites that don't fail gracefully (with certain exceptions) are poorly engineered sites that are excluding people unnecessarily.
> JS is part of the web platform
JS is an optional part of the web platform.
> and there are tons of amazing things it allows you to do.
Of course. The problem is that JS allows terrible things to be done as well. Just as I won't download and execute binaries from random web sites, I won't allow JS from random websites, for precisely the same reasons. JS is too risky.
> If you choose to browse with IE6 and complain that sites using HTML5 are excluding you, I'm not going to be sympathetic either.
That's a poor analogy because HTML5 will fail gracefully. If I browse to an HTML5 site with IE6, I will (with rare exceptions) still be able to read the page.
> Sites that don't fail gracefully (with certain exceptions) are poorly engineered sites that are excluding people unnecessarily.
Every time someone makes a site they're balancing a bunch of tradeoffs. For example, when I built https://trycontra.com I could have implemented the search server-side, with a query and response, but this would have involved writing active server side code. Instead I implemented the search entirely in client-side javascript. People are free to choose not to run the JS, but I don't feel any obligation to engineer the site differently to accommodate their preference and I don't think the OP should either.
> Just as I won't download and execute binaries from random web sites, I won't allow JS from random websites, for precisely the same reasons. JS is too risky.
Downloading and executing binaries from random websites is far more risky than allowing JS. A binary runs as you can can trivially do anything you could do, from keylogging to subverting your browser. If you can do similar harmful things from JS, on the other hand, you're eligible for very large bounties from browser vendors. JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS.
> That's a poor analogy because HTML5 will fail gracefully. If I browse to an HTML5 site with IE6, I will (with rare exceptions) still be able to read the page.
HTML often fails gracefully, but not always. If someone writes a site that doesn't fail gracefully and so is completely unreadable in IE6, I don't think they've done anything wrong.
JS search is not generally a critical site function.
Rendering the goddamned content is.
If you can't at a minimum give me a title, byline, dateline, main body text and/or some level of summary or description of non-textual content (as with graphics, audio, video, or interactive elements), then you're failing.
(SPAs or web applications should at least provide context for understanding what the application is/does. I'm not calling for all functionality to be rendered in HTML, but sufficient context to determine WTF the site is about.
Your "but I cannot implement search" is a strawman, and really doesn't address the core complaint.
As it stands, I'm looking at options for SSG-based blog posting, and at how it might be possible to support search. JS-based options, plus an extensive tagging / ontological classification, strike me as a reasonable compromise.
The fact that the Web is lacking a usable search-oriented standard which could bypass much of this problem, is one that's seldom noted. If sites could provide a permuted index in accessible format, and a standard mechanism for accessing it via a browser site-search function (or independent third-party search tools) ... well, the present online landscape would look remarkably different.
Sadly, we're not there, and the orientation of the leading browser developer is quite likely not going to support such development.
> If sites could provide a permuted index in accessible format
I'm not going to dismiss this out of hand, but this is a harder problem than you realize. We did have search keywords at one point. The problem was that sites started stuffing them with irrelevant values. Google removed that and started doing their own analysis, because keywords made it too easy to game SEO.
There are certainly ways that keywords could be done better today, I'm not going to say we should give up on the entire concept. But asking websites to self-categorize themselves is a very tricky problem that is very prone to abuse.
Remember that the web (currently) monetizes eyeballs, so until that situation changes there is a strong incentive to show up in every search regardless of whether or not you're relevant.
> JS search is not generally a critical site function.
Rendering the goddamned content is.
My example was a domain specific search engine. The only thing the site does is let you run searches, implemented client-side in JS. Without JS the site completely doesn't work.
> I don't feel any obligation to engineer the site differently to accommodate their preference and I don't think the OP should either.
Perhaps you misunderstand what I'm saying. I am not saying that you, or anyone else, is obligated to do anything in particular. All I did was to point out a factor that should be considered -- if your site does not work without JS, then you are excluding some people. If you don't care, fair enough.
However, I stand by my assertion that sites that do not fail gracefully are (with certain exceptions) poorly engineered sites.
> Downloading and executing binaries from random websites is far more risky than allowing JS
That does not mean that allowing JS is safe.
> JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS.
Yes, I'm well aware of that. And yet, JS is commonly used to do all sorts of nefarious things (such as tracking, for instance) anyway.
> Rendering markdown client-side seems like a fine way to implement a web page.
Requiring readers to execute arbitrary code in order to read content seems like a terrible way to implement a web page.
Nor is it cheap: it requires every single reader to execute the same code, burning CPU over and over and over when it could be done once for all readers, by the server.
> Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted.
Yes, you can require execute privileges in order to publish content, but anyone who publishes that way should expect that many people won't read what he writes.
> Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted.
Even without adding a build step, would you be willing to add a <noscript> tag to your index.html that just linked to the Github repo in general? It wouldn't even need to be specific to each individual post.
While admittedly some readers here are purely focusing on the irony of supporting "the primitive, simple case", for the most part non-JS users are willing to meet sites halfway on this. I'm totally fine manually navigating a Github repo to get at posts, I wouldn't be irritated at all in that situation, I wouldn't have even commented. Right now, your site offers nothing.
Even just the below markup would have been sufficient -- it wouldn't need to be customized per-page.
<noscript>
<div>This site requires Javascript to function. You can view the raw text of posts on <a href="https://github.com/anderspitman/anderspitman.net">Github</a>.</div>
</noscript>
Just give users something, literally anything they can use to recover when your expected use-case fails.
I agree; that is good. (It is easy enough to find the post wanted from that.)
I suggested to have a link (or just instructions, if you don't want it to be customized per post) for accessing the Markdown code for the specific post. However, a link to the Github repository also works perfectly OK, so I am not complaining.
I feel like Hacker News main purpose isn't a news aggregator anymore, it's turned in to a place to test the usability of your Web site with the kinds of people who run NoScript or browse with a terminal.
Off topic: reading back through your comments here, I was surprised to learn you're Danish. Your written English is completely native and natural: is this typical of Danish people? Can schools be that effective?
Thanks! I've been reading and writing English since I was about 10 years old, and I really like writing, so that might have something to do with it.
I think that are various levels of proficiency, but in general, most Danes have a very good grasp of it, and it's easy to live here if you only speak English.
At various times in my life I've spoken or studied Hebrew, Yiddish, Spanish, Japanese, and Italian. My proficiency is 0 in all of them. Sic transit gloria mundi....
Even worse, once the JS is whitelisted, the resulting page still can't be opened with the Firefox "Reader View" so it is unreadable for me (having the black background).
JS should not be needed to show five paragraphs of text. And even with the JS the resulting HTML is still unreadable.
> Here is my plea: when you build hardware/software, please make it support the primitive, simple case.
The OP is arguing that the primitive, simple case for this page is to not use any javascript because it's unnecessary for the core functionality of this page. The content here can be displayed simply as a few kilobytes of raw HTML.
Much like the author assumed that javascript is most primitive & simple functionality for internet users, the people who built his TV, assumed that chromecast protocol is the most primitive & simple way to send a video link to the TV.
The article entirely fails to render in Chrome, with JS disabled.
It entirely fails to render in text-mode browsers (I actually make heavy use of w3m).
It entirely fails to render in https://outline.com/, which otherwise is a good way to get fucked-up JS-dependent sites to render. I consider that stage of fuckwittedness either absolutely deliberate (which it appears to be in this case based on the authors defence of their practices), or utter incompetence. These are not mutually exclusive possibilities.
The fact that the article is apparently (I've still been unable to read it) a plea for base-level compatibility is, as initially noted, arch irony.
Heh. <waves cane> Damn whippersnapper! Get off my lawn! And button up that RCE vulnerablity of yours! Does your mother know what code you've been running? <grumbling> Kids these days...
When you build stuff, what to make it work with depend what it is, I think. HTML is not suitable for all uses, and URLs is not suitable for all uses, and PNG is not suitable for all uses, etc.
One possibility is to fix it so that there is a <noscript> block which contains a link to the Markdown source (or if the way it is set up makes that difficult, instructions for accessing it). I highly suggest doing this if you do not want to prerender it on the server. (I saw another comment which mentioned the Markdown file, and was able to read it from that.)
Sure, it's a matter of how complicated you want your workflow to be. The way things are right now, the author can edit the markdown file directly and be done with it. It's simple and straight-forward, low-effort and low cognitive load.
I would imagine it would be possible to set up their system such that they could edit the Markdown file, and a helper process would immediately pick up that the file had been edited and re-run the local rendering to static HTML.
Yes, great, now you've complicated the workflow. What if the service fails to run? Or fails to pick up the changes? Now you've got another thing to think about.
Is the overengineering so ingrained in the average HN user that they cannot see why someone might not bother with that?
In the everyday active workflow—the actions the author actually has to take each time—it doesn't add any complication. It merely adds complexity in the processing, which is certainly something worth considering.
However, in a case like this, the alternative—as we can already see—is to add complexity for every single reader on the front-end. So there's not really a perfect solution here—either the author or the reader has to deal with some complexity.
Maybe this was the whole point of the author's post.. but I'm fairly certain the reason the author's use case is not easily workable is because the OEMs mentioned are deliberately discouraging the ability to play anything that is not inside some sort of DRM control. They don't want you to just be able to play any URL. Its not a technical problem, its a content management problem.
When I first bought a Chromecast I was disappointed how much of a pain it was to play content I already had on my computer. I shouldn't have to spin up a Plex server just to get acceptable streaming capabilities.
The VideoStream chrome plugin is spectacular for this. Of all the chrome plugins I've installed over the years, this is still the only one I continue to donate towards.
AirPlay doesn't have this design philosophy and wouldn't have given this user a problem. Unfortunately AirPlay itself is proprietary and only supported by Apple devices and some TVs.
You know, I was going to reply that the AppleTV isn't a good comparison here because they specifically wanted something that worked with URLs.
But then I thought about it, and the URL thing is a red herring. That's not what they really want -- that's an implementation detail. What they really want is the ability to play something from their local server on their TV. This is totally do-able in the Apple eco-system. The URL thing is exactly what you don't want. Who wants to type a URL into their TV using their phone as a virtual keyboard or not? (Which the AppleTV + iPhone combo does this great too...)
The best option is where you could "cast" any video/media you're watching on a phone or computer up to a TV. The AppleTV + iPhone (or Mac) combo does this great.
AppleTV + iPhone + VLC iOS app will give you the URL option too. I did this to watch Terrace House Boys x Girls Next Door when I ran out of Netflix episodes.
Chromecast allows you to display any arbitrary url, no?
Also, just to understand, what does Roku get out of blocking your ability to potentially see non-DRM content? Is Neflix going to pull their app if Roku starts displaying urls?
You can't cast arbitrary things like that except through desktop/whole screen casting, which is not at all what the author is talking about (because it sucks).
I hate smart TVs with a burning passion. They accomplish literally the bare minimum to keep people happy and sometimes not even that.
Samsung’s Tizen OS is the most genuinely frustrating experience I’ve had with a consumer device outside of printing. Advertisements on my home screen that can’t be disabled, dubious privacy, bugs that require me to reboot my TV, and of course security so bad that they recommend installing a virus scanner? Yeah, that’s great. It’s got a web browser at least, though that’s the only positive thing I can really say about the web browsing experience.
Can it run software? If you can find it! There’s no app ecosystem here, just the big apps it absolutely had to have to be worthy of shipping. If you want to watch Twitch.TV streams for example you are SoL. There was an unofficial Twitch app, but it was removed from the store.
I tried to set up development for Tizen. Yeah not gonna try that again. I always thought getting started with development on Android or iOS was a little cumbersome but it really doesn’t compare. Even getting into developer mode was challenging since I had trouble finding the instructions that were pertinent to my model of TV, and that was the last thing I accomplished successfully.
So I’ve got a desktop computer hooked up to my smart TV and now I am contemplating paying more for a TV so I can get one that doesn’t have any of this dumb crap on it. The only downside? You can’t really run many 10 ft versions of things, and there’s not many good casting solutions. Lame, but every time I run into a new pathological case with the TV OS and its set of subpar apps I reconsider how much it’s even worth to have fancy 10ft interfaces and smart phone integration.
(If you are looking for a casting solution for an HTPC running Windows, I tried Reflector 3 briefly and it looks pretty good. But I personally do not run Windows on my own HTPC, so I’m stuck in the dark.)
Can't you just remove the smart TV's internet access (no wifi pw, no Ethernet) and treat it as dumb? Then attach a Chromecast or whatever "smart" dongle you think has the best UI.
This is definitely one approach, but I would actually just prefer a full computer, because I do sometimes run other software that is simply not available on any dongles.
One downside though is that I only have a couple HDMI ports to work with, so between a Nintendo Switch and a full desktop PC I'm already using all of the ports.
Also, even though I love the NVIDIA Shield, I find it does not really integrate as well as I hoped via HDMI CEC. It's a bit clunky to be honest, and though it's cool I can use the TV remote over CEC, it is definitely not as good as using the Shield remote, due to latency and some weird behavioral differences. So there are also downsides like that, too...
My shield also keeps stealing focus. When I turn on the switch, the TV turns on, then the shield turns on and steals focus from the switch, and I have to go grab the tv remote and turn it back to the Switch again.
Typically you'd buy a receiver to take all the HDMI inputs and power speakers and control which source went to the TV via a single HDMI cord. My receiver has something like 6 HDMI ports. Smart TVs have attempted to invert this relationship by accepting HDMI and splitting audio out to the receiver, but you don't have to play along.
Depends, but generally yes, for now. In the near future though you're likely to see smart TV's and similar devices with dedicated SIM cards and cellular modems that can't be disabled.
Other appliances. Set top boxes, refrigerators, washing machines, doorbells, anything someone thinks should be part of the "Internet of Things" product line they sell.
> similar devices with dedicated SIM cards and cellular modems that can't be disabled.
All such radios can be disabled, if not by removing the antenna, then by enclosing it in a faraday cage. It is chilling, though, that these things may become necessary for basic things like appliances.
I remember reading in another of these threads that the TV will try to connect to open networks or neighboring networks that they know the passwords to (like Xfinity). But I can't find any good source through a quick search, so this might just be HN rumors.
Keeping the comment in case anyone does have a source. If no response, let's assume rumor.
Worse yet, Smart TVs often brick themselves due to failed software updates. My last Sony TV did an overnight Android update, and I found it in a state where it'd show the Android boot logo and subsequently shut down. Some Google research showed that this has happened to hundreds of people (youtube videos outlining the problem, etc). Sony refused to do anything due to the TV being out of warranty, and no amount of hackery could get the TV back up and running. The end result--perfectly fine hardware being taken to an electronics recycling facility because the firmware was totally hosed. It's maddening.
That sounds incredibly frustrating, and I can't believe Sony is able to get away with that. If it's not under warranty I can understand not replacing it for parts breaking due to wear or user error, but if it's an update the company pushed out that actively broke everyone's TV it seems cut and dry that they should fix or replace them.
> Sony refused to do anything due to the TV being out of warranty.
Interestingly, apparently in the UK (or maybe EU?) there's a defined period an appliance is required to work for, to be "fit for purpose". Note - not a warranty thing, it's a consumer goods thing.
Not living in the UK any more (thanks Brexit), so don't remember off hand the period of time though.
Similar in New Zealand, although the exact time isn't defined. The parent comment's case would almost certainly fall under the protection of the Consumer Guarantees Act[1][2] and Sony would have to fix or replace it. Of course, getting a company to actually do something can be harder than just telling them the law.
In my experience the CGA is generally ignored until the Commerce Commission investigates. The best you could do is take them to the Disputes Tribunal (small claims court) and then the time and energy involved is probably outweighed by the replacement cost unless it's a ultra high end TV.
No Sony TV has ever had firmware updates for long enough that the retailer wouldn't be required to replace it under the Sale of Goods Act under UK law fwiw.
I've long since run with the notion that if you must have Smart TV features, do it with an external box. Last time I checked the Roku devices were decent for this, but there's a bunch of alternatives, and some lovely FOSS stuff (Kodi comes to mind) that is much more privacy focused.
The TV itself is a black box of mystery, and does NOT get to go on my network. It doesn't need my wifi password, and I certainly don't want it sending screenshots of my desktop (with sensitive information) off to some advertising agency. No thank you! But far more importantly, the TV will last for years as a dumb monitor, and the external box is usually much cheaper, and can be upgraded and secured separately. This just feels like the correct model.
My last TV set I bought, I specifically looked for a non-smart TV. Got it for a bit cheaper than the smart models and there's no bloat. Everything else is handled by either PS4 or laptop via hdmi. I am not sure it's even possible to find non-smart TVs anymore.
I used to do this with an Nvidia Shield, but I've since switched to a Roku TV (meaning TV with Roku software built in). With this setup, I have a single remote that turns the TV on/off, can play Netflix or other apps, adjusts the volume of external speakers, switch inputs, but still come back from any input when you hit home.
I could not figure out how to do this with any other combination, and this strikes me as fairly baseline usability.
I've gone through many incarnations of HTPC's, plus tried with SageTV, Roku[1], Chromecasts, and several others... and can absolutely recommend the Nvidia Shield. It has a good 10-foot interface via Android TV (as opposed to regular Android), is kept updated, is a Google Cast target, has official apps for all the major streaming platforms, can run Plex and Kodi (for local content), and it's also possible to sideload APKs. Most importantly, it "just works".
I was never able to build a HTPC that worked with all the video sources I wanted (Plex, Netflix, Youtube) and was possible to control without ever having to touch a keyboard/mouse (or resort to a janky air mouse/remote thing). With the Shield + a Logitech Harmony Hub, a single dead-simple remote controls entire setup (Shield, TV, external amp, plus a BluRay player that I never use anymore).
[1] Note: I only have a Roku 2nd Gen. The newer ones look a lot better and are probably a fine option now, but I still really like the Android TV "Home" experience a lot more.
That's awesome. I used to be a big fan of Sage, before they sold out / shut down. Even did the direct capture from cable boxes. I've been planning to get a Shield TV, so good to see these endorsements!
Likewise. I still have some HD300's in my basement somewhere, along with a couple Hauppauge PCI capture cards, and a Silicondust HDHomerun.
Shortly after Sage was shut down my cable company started encrypting all their channels, rendering most of my PVR setup pointless. After chasing issues with Youtube breaking API changes, I finally and begrudgingly pulled the plug on Sage. Several HTPC iterations later I feel like only now (with the Shield + Plex) do I have a comparable setup.
I did briefly play with Plex PVR with my HDHomerun and an OTA antenna, but I don't get enough channels for it to be worthwhile, and never even bothered re-installing the antenna after my roof was re-shingled last year.
I actually had the HDHomeRun that supported a cablecard and got my Shield to show channels from it, but it was never great. I eventually abandoned the Shield when I needed to add another device, and I didn't want to return to the bad old days of having to use another remote to manage inputs.
Depending on your TV, the Shield can control the TV (volume and power) via HDMI-CEC (my decade old Sony LCD TV supports it). You have to go into settings but once setup, you can power on the TV and auto switch to the Shield HDMI connection with one button.
The problem is that there is nothing else to compete on. TVs are two centimeters thick and have crisp displays. I don’t give a crap about 5k or whatever. So what can they market on except price? Apps.
Yes, having an external box can be a good idea, but some things you may want to have in the TV itself such as the picture adjustment settings. There might also be multiple inputs, and IMIDI interface which can be used to select between them and switch TV on/off and adjust volume and so on, allowing you to program other devices to control it.
> I've long since run with the notion that if you must have Smart TV features, do it with an external box
I'd go farther. I want everything to be external boxes. Right now I'm looking at having to get a new A/V receiver because mine cannot handle 4K video. It does all the audio stuff I need just fine.
If video switching and audio processing was handled by separate boxes, I'd just be looking at changing out the video switching box.
Now suppose that later I decide I would like to be able to control my receiver with Alexa or Google Home. As it is now that will be another "replace the whole damn receiver" moment. If it were all separate boxes, the preamps, amps, surround sound processor, and radio receiver would all be separate components, controlled by a controller box. If I decide I want Alexa, I'd just buy a new Alexa compatible controller box.
Or I decide I want to upgrade from 5 channels to 7 channels...buy a couple more amp boxes and speakers for the new channels (and might also need a new surround sound processor box).
Basically, take a block diagram of a complete full featured home theater system, and make every block in that a separate box so I can (1) just buy the boxes I need for my system, and (2) upgrade a box at a time.
That said, I doubt TV makers will ever stop primarily making Smart TVs. A Smart TV can function as the only component of a home theater system. Someone moving into their first apartment after school, say, wanting to start putting together their entertainment system can start with a Smart TV, stick it on their home internet, and then use the Netflix/Prime/Disney+/etc app on the TV to watch movies.
That Smart TV probably has a few HDMI in ports, so they can also use it with the cable box if they have cable, and with their gaming consoles.
With a dumb TV they'd need the TV, and they would need an A/V receiver, and speakers, and something to run the Netflix/etc. apps. Buying all that at once might be a budget buster for someone starting out.
By making the TVs smart, the TV makers greatly increase the chances that a TV will be the first component bought for a new home theater setup, and probably also increases the chances that that first TV will be a big screen, high resolution, high quality display model.
20 years ago, I was making the same argument about desktops vs laptops. I was also carefully selecting which stick of ram to buy. Now, the whole world buys laptops, except for gamers and linux users. I don't think non-enthusiasts want to think about that many boxes and arrows.
I support separate modules for everything, and am amused at the thought of connecting a Roku to an old console TV and running it through a 6-figure sound system.
I've had no problems with LG webOS. Media playback off usb and DLNA is flawless and supports every codec and container I've thrown at it, all the apps work well. I've had it playing 100mbit/sec H265 off network for example with no issues.
It's actually pretty hard to find a media player that supports Dolby Vision for example. No Android media box does, and as far as I know Windows support is very patchy. At least with webOS it supports all the video formats the TV supports.
I've tried Kodi and whatnot and found those sort of solutions to be confusing, slow, and not particularly confidence inspiring. I taken to just using mpv with --input-ipc-server==... --vo=gpu --gpu-context=drm. It can play anything from my NAS over NFS, or any URL that youtube-dl supports (which is most anything.) It works with youtube, twitch, vimeo, basically anything except netflix or amazon prime. And it doesn't need a new "app" or "plugin" for each, since youtube-dl is a nice piece of software.
I've read of "Smart" TVs that will scan for and connect to open WiFi. That's fun. Even if you don't let the thing on your network it might still be able to ruin your television watching experience.
In my experience, those networks only work if you are a Comcast subscriber. You have to have an account to authenticate.
There would be some kind of backlash if those TVs connected to one and was able to phone home. Don't know how bad, probably on the order of the smart TV that was phoning home with the name of the contents of and flash drives you connected.
Never experienced those problems with Tizen but sometimes it lags like hell. After it warms up it's pretty fast; Unfortunately there's no Crunchyroll app yet.
I have a Tizen Samsung TV. It is super laggy. Like 3+ seconds to respond to a button press on the remote. I found some anti-virus options (?!) deep in the TV settings. Turning real-time anti-virus scanning off made that TV almost usable again.
There are set top boxes (Apple TV, Nvidia Shield, etc.) that offer a much better user experience with thriving app ecosystems and regular feature updates, if you don't want the rigamarole of trying to use desktop software in a living room.
I used to do the whole HTPC thing but having to use an actual web browser to access half my content felt obnoxious and cumbersome.
As for avoiding smart TVs, I found it pretty easy to just ignore the WebOS garbage on my LG. I don't see why I would want to pay more to get rid of a feature I haven't had to interact with since setting the device up.
Trusted with your viewing history? With a trivially regeneratable netflix password?
I like keeping privacy private, but I'm having a hard time imagining what sorts of private data you are concerned with that would be going over a set top box.
Or were you more worried about the STB being an attack vector into your home and other machines?
Almost certainly not, they're very likely collecting viewership data unless not doing that is explicitly called out. But there is some good news! Since you're watching a lot of things that are being served over the interwebs your data has likely already been entirely harvested by the provider companies anyways!
Trust is relative. They can certainly be trusted more than the Smart TVs because their incentives align at least marginally better with yours. They need to justify their price. The TVs are for the most part doing the minimum possible to check the "Smart" box.
Apple TV is a pragmatic option for the sort of person that doesn't mind the Apple Walled Garden.
Xbox One is a pragmatic option for the sort of person that doesn't mind the Xbox/Microsoft Walled Garden.
NVidia Shield and FireTV are pragmatic options for folks that prefer the more Android-ish "mostly a Walled Garden, but".
If your threat model is anything with a corporate or walled garden smell, then sure none of them can be trusted and just build your own media PC with Linux and whichever apps you feel you can trust.
Check out Vero 4k+, it runs on OSMC (open source media center) with Kodi installed. I run it on my 4k Philips TV and it works perfectly for any kind of media content...
I have an Apple TV and two Rokus. According to my PiHole and my UniFi controller, the Rokus (attempt) to do an awful lot of talking to domains associated with telemetry and advertising all throughout the day. My Apple TV is pretty quiet, though I do catch some ad/telemetry traffic when using individual apps.
A Sony Android TV would - you could paste the URL into either VLC or the Internet Browser provided with the TV using the Android TV remote app on your phone, as you can paste into that.
Ah so you can just cast whatever is on VLC? That was the first thing I tried with Roku but my TV doesn't support it, and I was disappointed there wasn't any VLC companion app.
Well, VLC does have casting, but here I more meant you can run VLC on the TV itself, and you can enter a URL directly into VLC on the TV itself. While that's a bit clunky, if you use the remote app on a phone you can enter keyboard data and, most importantly, paste keyboard data from your phone into an input field on the TV itself. So no casting would be required.
Most monitors, except for the most bare-bones models, will have a standardized mounting hole pattern on the back called a "VESA mount" for which you can obtain a wall mounting bracket. It's the same way you attach a monitor to a desk-mounted arm.
Sure... if you want to pay twice as much as the similar sized TV.[1] I actually just buy 4k TVs and use them as computer monitors instead. As long as you research to find one that has low response times (rtings.com helps with that), it works fine.
Yeah another person brought up that the cost is reduced based on the data their mining for usage.
I'd also like to point out that most of the sub-$400 Smart TVs on Amazon don't have any DisplayPorts, and the display is probably of a lower quality than something that's designed to be looked at from a couple of feet away rather than dozens of feet.
You can turn off the content detection features in most (all?) smart TVs that include it. I've turned it off on mine.
What's the main benefit of DisplayPort when most new hardware supports Hdmi 2.0, which does 4k at 60Hz?
How would you define lower quality based on viewing distance? What metrics are we going by that we might expect to be worse? There probably are some, but I can't think of any off the top of my head.
Reaponse time is the one that comes to mind, not because of viewing distance but because of different intended use cases, but I specifically account for that when looking for a TV to use as a monitor.
Huh. I will admit, I always kind of dismissed monitors out of a blanket assumption that they'd be wildly expensive, but $550 for 4K support is not that bad.
Yes, it's more expensive than a smart TV, but the only reason is because smart TVs are very literally subsidized by future data collection and monetization.
Not trying to minimize that this could still be too much money for some people, but frankly, a one-time extra $250-300 to permanently escape that whole tracking situation is just a lot less than I expected.
I also thought of using a computer monitor. Also it may help to reduce the lag (I know some people use a computer monitor for their games due to this). Also I don't need such a huge TV set, I think.
> So I’ve got a desktop computer hooked up to my smart TV and now I am contemplating paying more for a TV so I can get one that doesn’t have any of this dumb crap on it.
Yeah, call me when you find one…
I have an nvidia shield which more than fulfills the "smart tv" needs, and I think that's probably the way it should be and stay. I love this setup and just want to disable all the smart features now. It's not like they're in the way but sometimes the tv does decide that "I see you're watching a movie. Now might be a good time to ask you to reboot for the latest software update innit?"
Me too! When I bought a new Samsung 32" last year, I went very, very slowly as I set it up, so as not to inadvertently connect it to the internet. I succeeded in not connecting and life is good.
Yes! As I recall, a screen came up with a bunch of local wifi networks — including my own two — asking me to put in a password to connect. I was able to move on to the next screen without doing so, and I was home free.
> You can’t really run many 10 ft versions of things ...
Huh?
My media server is in a ventilated closet, so I'm using ~15 meter HDMI, USB and audio cables. It was admittedly an expensive HDMI cable, but it seems to work well enough.
TV makers should stop embedding the Smart TV features, and focus on either bundling an external box on dongle, or establish a standard for smartTV circuit board that you can replace by a third-party or pull out completely when the inevitable happens (system is unsupported/EOL, has some security flaws the manufacturer doesn't take seriously, etc. And more importantly, make the display works without such card.
Unless average Joes start clamoring for that, all of the cost associated with what you're asking for wouldn't help them sell a significantly larger number of TVs.
Commercial grade NEC digital signage displays use the Open Pluggable Standard. You can insert a number of modules into the OPS slot, from a SDI video receiver, to a nasty Android based media player, or even a full x86 PC.
I've said it before here, but I'm getting a second hand NEC commercial display as my next TV. I've used them at work and they are excellent panels.
Yes, me too. I have an old dumb TV, and will use that until it breaks. When that happens, I won't be buying another TV at all, since as near as I can tell, the "smart" kind will be the only kind on the market.
A few years back I bought a cheap one at a black friday sell and it is plain ol' dumb model. I feed in an HDMI from a laptop and all I use the remote for is on/off and volume.
A while ago I just rejected the concept of smart TVs (and TVs wholesale) in my residence. Hook a projector up to a computer, have a wireless mouse floating around and either use on-screen key entry or a keyboard to interact with the browser when not just working off of pre-set sources and call it a day. If you wanted to go above and beyond I guess you could set up remote desktop and get into the system from your phone, but I have never felt the need.
The computer can be as cheap as the video quality you want to view... and a decent 1080p projector can easily be had for ~300 USD, bump up the computer to gaming specs and run your entertainment off of it and you've got a nice multi-use solution for the house... unless there is competition for resources.
The last time I tried to buy a decent TV, I really wanted a non-smart version. It seems that this is an impossible ask. I was even willing to pay extra. Now that I have a smart TV, I really don't understand most of what it does. Whenever I turn it on it is playing some Soccer (Futbol) station. How? I don't know. I don't have cable or an internet connection to the TV. I assume it must be getting it over the air. Can I turn it off. I don't know. I haven't found anyway to do so so far.
This Christmas I finally took the time (which admittedly didn't take long; I was just lazy until now) to set up LibreElec on my pi and hook it up to my TV, and I honestly don't know how I've overlooked this for so many years.
It's a DLNA/UPNP client so I can cast anything I want from my media server on my computer to it (Bubble UPNP is a great app to control all this from my phone) and even though it doesn't have "cast" built into apps like Youtube and Twitch, they're all supported as addons so you can still get 90% of the functionality, so I can finally throw away my Chromecasts. Plus you can either use the TV's remote with HDMI-CEC out of the box, or hook up a wireless keyboard.
With another pi running TVHeadEnd that I feed my aerial into, I basically don't need any of the builtin TV software anymore, Kodi just controls it all. It's a pretty liberating feeling.
I use Kodi, and while it probably isn't a complete replacement for Roku (Netflix doesn't work out of the box but I have to admit I haven't looked into getting it to work because it's one of the few "smart" things I let my smart TV do), it's pretty good for showing content.
There's a Firefox extension called "Send to Kodi" that I use to quickly cast Youtube videos and other videos from my PC to my Kodi.
On my phone I use Kore, which can send a URL to Kodi using the standard Android share menu (hold a link, Share > Play on Kodi).
Kodi also supports UPNP so you can use one of the million available apps for that to allow some other media servers as well.
It's not perfect, but Kodi has managed to satisfy my video consumption needs quite well. I'm using an outdated version (it's running on my server which runs Debian stable) but I haven't run into problems thus far.
How have you found DLNA? I tried it briefly with the built-in PS4 client and MiniDLNA/ReadyMedia on a headless Ubuntu machine and I found it to be awful— the server side needed to be rebooted in order to discover new media in the folder, the PS4 client was clunky to use (missing obvious stuff like picking up playing a file where you left off), and iTunes instances on the same network would do weird stuff like suddenly peg the processor and burn themselves to the ground, apparently due to something in the protocol.
I haven't yet circled back, but my conclusion was to give up on it and instead pursue an end-to-end solution like Plex or Jellyfin.
The PS4 renderer is pretty bare boned, no getting around that. The newer versions of UMS support resuming and FF/RW, depending on the way the file has been encoded.
FWIW, I use a minidlna instance on a Raspberry Pi to serve my media around the house and I have never had an issue with it discovering newly downloaded media.
It currently serves around 3TB of video and audio files, and new files are added daily. I haven't restarted either the Pi or the minidlna service for many months.
I choose this option because it is a very light-weight solution with no features that I will never use (like trans-coding or metadata downloading, poster art etc).
While I agree, and know of all the evil repercussions of smart TVs, Samsung's software is terrible but LG's is pretty good, because I believe it's just WebOS from Palm Days. It's easily been my most positive "TV OS" experience yet.
I agree with your frustrations about smart TVs but I also like the setup I have with my TV.
I bought an LG OLED last summer (a 55" C9) and to be honest I don't hate the software (webOS) on it. However my setup is not really normal.
Firstly my TV is connected via Ethernet to my router and is restricted to only Netflix, the LG web store and my internal network.
I don't watch live TV, instead my viewing is limited to Netflix and content on my Plex server. Turns out the LG Plex app is very good. The TV supports pretty much every video and audio codec so I can do Direct Play from my Plex server. I mostly have direct Blu-ray streams extracted and remuxed into mkv files so there is no quality difference with using Plex vs. the actual Blu-ray. The rest is a mixture of H.264 and H.265 video with AAC and DTS audio in mp4 or mkv files. Everything plays perfectly with quality on par with or exceeding Netflix to give a comparison.
This setup works great for me. I only really interact with the TV OS to switch between Netflix and Plex which isn't a big deal and the picture quality of the OLED panel is incredible with 4K HDR content.
The real star of the show is Plex though which is just god damn fantastic. As everything I have is Direct Play compatible I can (and have) run the Plex server on a Raspberry Pi with a USB HDD attached and it works perfectly. Even for 80GB 4K HDR movies (direct Blu-ray remux files are large!) plays back from a Pi running openmediavault and Plex media server in Docker.
In the past I have tried a few different solutions such as a HTPC running Windows plugged directly into the TV but nothing gave me as good picture quality with the same flexibility as using the native TV apps.
In fact the Plex on a Pi setup works so well for me I set one up for my mother when I visited over the new year. She can watch any content on my Plex server as well as anything I upload to hers (as she often wants things I don't care for so don't want using up my disk space :)
If you haven't looked into Plex I highly recommend you check it out. It really does 'just work' which is so nice when you want to sit down and watch a movie without having to deal with all the adverts and junk before the movie on a Blu-ray disc.
I fear that soon we're going to need an open-source alternative to Plex. Increasingly aggressive monetization seems to be creeping into the Plex experience. I keep finding things I don't own and don't want showing up on my home screen. "Suggested movies" and "Suggested podcasts" and the like. You can prune them back but a few months later you find some other garbage you don't want.
This is a very valid complaint however I understand their need to monetise and at least you can remove that items. At least so far.
I am always open to alternatives however with everything I have tried over the years nothing has come close to how well Plex works. From the flexibility of running the server to the superb automatic content identification to the frame perfect delivery to my TV it has been flawless for me.
However I feel I should point out again that I don't use the transcoding feature so I cannot comment on how well that works.
Eh, it's gotten noticeably worse of late, almost as if their resources are going somewhere other than UX. The client as picked up a habit of hard-crashing on certain files when "Automatic" transcoding or "original" is selected instead of manually choosing a certain bitrate.
I do not use the transcoding feature (it murders HDR content) so have never experienced any crashes.
The only UI prompt I recall seeing is some new streaming feature which I haven't looked into but appears to be some kind of partnership with content providers? I was able to get rid of it easily enough to not even remember how I did it and haven't seen it since.
Perhaps the mobile apps (which I assume are updated more regularly?) have had some more prompts? I only ever use the app on my TV.
The gist is that they went from being open to closed source, mostly because they had to invest heavily into transcoding and client support. Naturally, some folks didn't like that and forked.
I miss the days when my TV didn't need rebooted and didn't crash. I want a TV that is basically just a multiple input dumb monitor. I don't even want a tuner built in.
I used to write software for samsung smart tvs along with other TV OSes and games consoles.
Samsung/Tizen was one of the worst in my experience (the only thing I found more annoying was PlayStation only giving a windows sdk when the box itself is basically a BSD. Let me develop on Linux dammit!)
Tizen could be a great OS if Samsung did not lock it down and enabled building from source. It is a lot closer to Linux than Android. I use it on a watch/fitness-tracker and the whole package would be great if the development was not hamstrung by Samsung.
You need to sign packages with a certificate you get from Samsung and tie it to your device ids for sideloading. For that, you need Tizen Studio, which is a custom outdated version of eclipse, depending on outdated versions of some external libraries. I tried it in a container, which worked fine, except for the signature generation. So I ran it in a sufficiently outdated VM.
Unfortunately, this developer cert will only get you so far and for the complete API, you need a partner level cert.
If you put up with all this, there's the documentation[0]. It takes ages to load and you can't easily download the damn thing, because they pull in the content via XHR. Why, Samsung, why?
Pretty sure they stopped shipping ads enabled by default a while ago. Pretty sure both of the Samsung smart TVs in the house didn't have them enabled out of the box.
I've had two Samsung smart TVs, neither of which were capable of letting me share my screen from a Samsung Galaxy phone..... (well, technically, I did get it to work once or twice, but I'm very good at troubleshooting and it took me over an hour and three different apps).
> If you want to watch Twitch.TV streams for example you are SoL. There was an unofficial Twitch app, but it was removed from the store.
I still get worked up about this. I was able to watch streams on my TV using this app and someone somewhere just decided I shouldn't be able no more. The TV has lost value with this change, to me at least.
Inefficient compared to what? Fundamentally you have to shift the same N bits per second at a reasonably uniform speed regardless of how the transfer is done.
Your main enemy in this process is, as usual, middleboxes, which may be a bigger problem for the advanced protocols. This is why Apple created the bizarre but effective HLS system: https://en.wikipedia.org/wiki/HTTP_Live_Streaming
I'm assuming most video streaming is done over HTTP these days, as sad as that is. But now you have me wondering if the big boys are using something different.
URLs are an utter failure, normal people don't understand them, the only protocol they are ever used for is HTTP, special characters are a mess, IPv6 turns the insanity up to 11. The one other use of URLs has been tricking unwitting users into launching vulnerable applications with malicious input, because applications registering themselves for protocols was a thing once added, then never critically thought about, ever.
URLs are used for protocols other than HTTP(S), although it is most common with HTTP(S). Other URI schemes are sometimes used where a URL is needed to make a link to something else (such as in a HTML document, or a Gopher menu item that links to something using a protocol which Gopher does not support linking to (HTTP being one of these protocols), or opening local files or other stuff in a web browser, or for some uses in RDF).
But I agree that IPv6 makes it messy. (I had my own idea which is version 10 (numbers 7, 8, 9 are unusable) which uses the same format like version 4 but with sixteen octets instead of four, and some other differences too.)
No, this is very much an HTTP thing. When you request a resource over a URL, you should get the resource... instead with their site you get an HTML page with a bunch of javascript includes... that then retrieves content. It works, but it is opposite of what they are arguing for.
Now, this is this person's personal site... they can do what they want. But it's pretty ironic to put a rant about working with URLs on a site with a design like this that doesn't work with simple URLs.
The URL does work. I don't say anything in the post about reading what's on the other end. What you're saying would be like if I had said in the article that I should be able to give the Roku a video format it doesn't support and expect it to work. My website should work for anyone using a browser with default settings. I never claimed it was a static HTML site. It's an interactive JavaScript application.
That's exactly my point. It's a website. It's meant to be consumed by browsers, so it's fine if the served resource is a SPA that renders the content lazily or whatever. The claim that SPAs somehow violate HTTP seems weird to me.
FWIW I actually agree with the underlying principle. It's just that I have specific things I'm aiming for with my site that require JS. I wish browsers were simpler. But that ship has sailed. In my perfect world, the JS-app functionality of browsers would be broken off into a separate "app player" application that users would download, and browsers would be stripped down to basic HTML and a subset of CSS (essentially fonts, colors, and flexbox). In that world I would definitely have an HTML-only version of my blog.
I feel like you’re arguing for two completely orthogonal ideas. Either you get the resource with the request or you don’t.
The resource you get with your site is the same thing regardless of what the URL requested is. There is then JavaScript logic that loads more information based on the path. The content is then dynamically added to the DOM. This is how your site works, right?
In this model, you never actually get the content with an HTTP request. You get code that runs that contains/displays the content. From the HTTP point of view, the resource is the code. If you don’t execute the code, you don’t get the content.
This is a perfectly fine way to run a website. I have zero issues with this. And as you say, this ship has largely sailed.
But — what you are asking for in your post is the ability to hand a URL to a media player and have that content play. What would happen if the content site had the same setup as your site (without any special configuration like supporting YouTube URLs, etc)? What is the HTTP request returned a JavaScript wrapper around everything and not the actual video?
The Roku could very well support a video format and still not be able to play the content on such a site. And the kicker is — a web browser would probably work just fine and the user would have no idea why their URL wasn’t working on their TV.
This is why there have to be tools to extract YouTube videos to download. For sites like YouTube, the URL isn’t a simple resource locator. It’s a link to a bunch of code that needs to be run to get to the video.
What I think you’re missing is that it isn’t just the client authors who need to support URLs, but also the server authors. If you have a small local HTTP server that just sends raw files, that’s easy. But loading something like YouTube isn’t as simple as supporting HTTP requests. And there is a certain irony in publishing a post that asks for clients to support working with URLs on such a site design.
JS vs pure data (a video file) is an important distinction. I will grant you that. My point is that it's perfectly reasonable to assume users can access this blog post just fine (and my analytics show that is the case for the vast majority of them), because the functionality is built-in to every browser on the planet. You literally have to take action to circumvent the way your browser is intended to work, in order for my site to not work.
Yes, please. I was at an Airbnb in Austin last week, which had a Roku device attached to the TV. I usually bring along a Chromcast (or at least the proper adapters to get HDMI out of my laptop) when I travel, but this time I forgot.
I just wanted to play a video file I had on my laptop. I googled around, found that Roku appears to support DLNA, and tried to use Universal Media Server on my laptop. The Roku did find the media server, but kept claiming that there were no files available. Not sure if it was a video format issue (main-profile h264, ac3, and mkv are listed as supported by Roku) or something else, but at the end of the day I just couldn't get it to work, and I was bummed and frustrated.
Maybe play-this-URL functionality wouldn't've helped, but at least I would have felt more confident that it was a format issue rather than just some dumb problem with the huge DLNA tech stack.
> However, there doesn't seem to be any widely implemented standard for playing plain URLs, only walled gardens like the YouTube app.
I've had experience overseeing the implementation of a simple Chromecast application. It was a relatively painless process and worked pretty flawlessly with minimal code. It may not be a standard but it is totally accessible to anyone with a bit of Javascript experience.
I could imagine an evening hack session that would be a Chromecast application (maybe a browser extension) that you can paste urls into and it would play that way. Without even bothering looking, I would bet such an extension already exists in the Chrome Web Store.
I wrote this five years ago, and it actually made from the front page of Hacker News back then.
"We Suck At HTTP"
>"We have broken HTTP. We’ve done it for years in fits and starts, but apps have completely broken it. HTTP was a good specification which we’ve steadily whittled away."
> Here is my plea: when you build hardware/software, please make it support the primitive, simple case.
Says a webpage that is just a couple empty divs w/o JS, and, with JS, is 4 hyperlinks, a few paragraphs of text, and absolutley nothing (aside from google-analytics) that ever needed any JS in the first place, let alone 5 or 6 files' worth of it.
But, I think that conflict really speaks to the funamental issue, here: Thinking about the primitive, simple case is often, from the creator's perspective, more work than it's worth.
I mean, if you're going to wax lyrical about how what your making should support that basics, you should at least first make sure you're doing the same thing.
Otherwise, you're just demonstrating exactly why Roku doesn't have a way to input a URL to play media.
JS can be a highly supported tool, but it isn't itself a primitive use-case. It is an enabler of use-cases and, to OP's point, JS for the sake of loading JS isn't useful if the content of the site really didn't need it.
The very purpose of JavaScript is to be dynamic and changing. "Primitive" and "Basic" are not apt adjectives, especially when the page in question is entirely static.
Yep. Your reasoning is valid, and further illustrates my point: From your perspective, pasting a URL to some media is a really basic use case. From mine, a stripped-down browsing experience is. The common element is that, no matter how simple and straightforward we think our preferred way of doing things is, it's still not particularly interesting - and therefore not particularly worth worrying about - to someone upstream.
I have two standalone Rokus that are a major PITA because of this. There's no way to connect to an NFS share, SMB share, or other local storage directly from the system itself. There's no VLC app for Roku. The best you can do is use the rudimentary "Roku Media Browser" to page through a DLNA server, which means you have to set up either something like Plex (which sucks for a lot of reasons) or at least miniDLNA to access files. It's really disappointing.
I've recently installed Jellyfin and even put the Roku in "Developer Mode" so I could install the Jellyfin Roku app from GitHub. This is better because unlike Plex, it won't transcode arbitrarily, but it's far worse because the Jellyfin Roku app crashes frequently, has only basic page-based navigation ("go to page 23 for media that starts with 'T'"), and it requires running a heavy media server for no real reason. I'm still reluctantly using Plex for the time being.
When I need something that I haven't put in Plex, I fall back to the Android interface on the FireTV and use VLC to access the NAS over SMB. It still rankles that Roku won't allow an easy way to access local media.
I don't have a Chromecast. I have a Roku TV. One of the implied points of this article is that the solution I'm suggesting would work for any device as a fallback, let them implement whatever other fancy protocols they want.
> However, there doesn't seem to be any widely implemented standard for playing plain URLs, only walled gardens like the YouTube app.
But chromecast is essentially that standard you ask for, otherwise "apps" like I linked wouldn't work. Heck, as far as I know (I'm not really a Chrome user), Chrome has this functionality built-in, so you can send URLs directly from browser to a chromecast device.
This is the sort of use-case that the DLNA specification was intended for. It's not quite as simple as the author might want, but it is well supported. The TV can act as a Renderer for content pushed to it, or as a Player for content pulled from a Server.
All the smart TVs I've used implement this functionality.
VLC and Kodi support this too.
DLNA is slightly maddening because it's clearly supposed to be the solution, but was built by set-top-box UI people and therefore has terrible UX. Basically Chromecast exists because DLNA is too fiddly for the average user.
I think it should be possible to do this with the browser and the Chromecast protocol, since my understanding is "play a video from this URL" is the core of the protocol. Someone could build a website following https://developers.google.com/cast/docs/chrome_sender/integr... where you paste the URL of a video and are given the option to "cast" it to the TV.
This would be some work, but only one person would need to do it and then anyone could "cast" a URL.
(Disclosure: I work at Google, speaking only for myself)
Does it work with videos? The product description mentions HTML and static image formats. Neither the description nor any of the reviews mention videos.
I guess I could just spend 99 cents and 2 minutes to find out...
> However, there doesn't seem to be any widely implemented standard for playing plain URLs, only walled gardens like the YouTube app.
Actually, I think the standard is UPnP / DLNA. After setting up a UPNP server I can "cast" most things from Android by using the share button, and then choosing a UPnP app, such as Bubble UPnP. I don't know if the author's tv supports this, but many do.
There's an android/roku app that makes this fairly seamless in all the instances I've tried. It even does a good job of finding videos in a web page if you don't have a direct link.
352 comments
[ 4.6 ms ] story [ 243 ms ] threadBased on this web site, this is a definition of "software engineer" of which I was previously unaware.
Edit: Actually https://raw.githubusercontent.com/anderspitman/anderspitman.... works fine already; can we change the submission URL to that?
View source indicates about half is some Google analytics boilerplate, the other half is a body consisting entirely of non-functional JS pulls.
OP, where is the content stored?
Please make your products work with URLs
I want to tell you about something I was unable to accomplish, after more than 30 minutes of concerted effort. I have video file hosted using a web server. The file is H.264 main-profile encoded at a reasonable bitrate (<5Mbps), uses AAC audio, and is packaged in an MP4 container. The web server supports HTTP range requests. In other words, the video is basically in the least common denominator format for compatibility. It streams great in all major web browers, VLC, and everything in between.
In my living room, I have a Roku "smart" TV. It has tons of apps, full internet connectivity, and is more than capable of both connecting to and playing the video file described above. But I failed to get this to happen, after much googling and trying multiple apps (both on the Roku TV and my Android phone).
The way this type of thing is usually accomplished in 2020 is to open the video on your phone, then tap a "cast" icon and tell it to send the video to your TV. What happens behind the scenes is the phone uses some protocol (Chromecast being the most common I'm aware of) to send the URL to the TV, and the TV then plays it directly, while still letting you play/pause, seek, change volume, etc from the phone. When this works, it's like magic. The YouTube app works particularly well. However, there doesn't seem to be any widely implemented standard for playing plain URLs, only walled gardens like the YouTube app. This whole thing was made much more frustrating by the fact that I knew the TV had all the requisite capabilities to do what I was attempting. The YouTube app is proof of that. There just wasn't any obvious way to find the correct app combination.
Here's the way this should work.
The Roku app for Android allows you to use your phone as a keyboard for the TV, rather than the awful physical remote UX for input. This is a great feature which I appreciate. I should be able to copy a URL from my phone (possibly obtained from scanning a QR code), paste it into the Roku Android app, and the Roku should attempt to play the file at the URL. This is clunky, awkward, and not particularly easy. But it is simple, obvious, and intuitive.
Here is my plea: when you build hardware/software, please make it support the primitive, simple case. By all means, implement the slick Chromecast-style flows. It's great when it works. But there needs to be a fallback for when it doesn't work, or when the user wants to try something slightly different. HTTP is the lingua franca of the internet. When you build stuff, please make it work with simple URLs.
Cloudflare and archive.fo don't play well together. Each blames the other.
I've explicitly coded an exception for the domain on my own networking kit, but that fix hasn't been working for a while, which is ... annoying.
Ordinarily, though, it's a useful fix. If you can point DNS at a provider other than Cloudflare (1.1.1.1), it should work.
Is this site heavy on ads and other malware and won't display without totally naked openness to exploits?
(Note: works for me too, with default uBlock and Pi-Hole blocklists)
Note for OP:
The reason this breaks without Javascript is because it's rendering the Markdown clientside. That could be moved to part of the build process without increasing your hosting requirements at all.
I can see that you already have https://github.com/anderspitman/anderspitman.net/blob/master... started, so I'm assuming you know this already and that you just haven't had the time to set up rendering on build yet. It's not my intention to preach to the choir.
If you're struggling to figure out how to get this working as a SPA while still including content for non-JS users, my advice would be to include the rendered HTML in each index.html and just hide it with CSS during page load. You can still use AJAX for all of your subsequent navigation to avoid reloading the page, but if the static HTML is annotated with the correct links and content, people who request a specific URL without Javascript would still get to read.
Or you could even get fancy and skip hiding it on the initial page load, only swapping it out with AJAX for future navigation, and this would make your initial page load even faster than it currently is.
OP is already using a server-side build process to generate the static site. Inserting the HTML at the same time they built the site would add very little extra code to their build process, and nothing to their static hosting requirements.
If nothing else, would OP consider inserting a <noscript> tag in each generated index.html that linked to the raw Markdown in their Github repo?
Yes, if you're going to have a build process, converting Markdown to HTML server-side makes a lot more sense.
The site doesn't use any build process. The gen_static script was an experiment that I didn't make it very far with. I may eventually get back to that.
I never whitelist sites that don't work without JS unless the site is actually critical for some reason (doing so is too risky). I expect that this means some parts of the web effectively no longer exist for people like me, and accept that, but I wonder if the authors of these badly engineered pages really know that they're excluding people.
People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. Being able to write a site in markdown with static hosting and have it instantly rendered in user's browsers is one of those things!
If you choose to browse with IE6 and complain that sites using HTML5 are excluding you, I'm not going to be sympathetic either.
People who choose to turn off JavaScript are protecting themselves, because JavaScript enables all sorts of attacks on one's security and privacy.
JavaScript is not part of the web platform. The Web is a web (hence the name) of interlinked documents: the core requirements for a web of interlinked documents are a protocol (we have HTTP) and a document format (HTML); a style format (CSS) is nice too, albeit not strictly necessary (one can read unstyled documents in links, lynx, elinks, eww, w3m or whatever else just fine).
There is absolutely no requirement for executing arbitrary, potentially malicious, unverified code from untrusted authors distributed globally. Are there great examples of cool JavaScript applications? Yes, certainly. Is JavaScript a core requirement to support a web of interlinked documents — i.e., the Web? No, not at all.
To the contrary, JavaScript is murdering the Web, and this page's misuse is a prime example. JavaScript delenda est!
Could you say more about this?
To start with, I'm not on the anti-Javascript hype train. I write Javascript for a living, I think it's the arguably the most important modern language of the last decade. It's made computers more accessible, it has good ideas, it's reasonably well sandboxed. I love Javascript. I do advocate for progressive enhancement for a lot of reasons, but in part because that's the foundation of web architecture, and I think it's still relevant today.
The best web developers I know that I really respect all understand what progressive enhancement really means as an architectural pattern, and they don't dismiss it out of hand.
Also to be clear, the browser is (unarguably) hands down the best consumer-facing sandbox that we've ever built. And I like sandboxes, a lot. I think sandboxing is the future of user-facing application security -- not trusted stores, or signing, or managing dependencies in a special way, or SaaS.
Having said that, I'm also using the web as it exists today. And let's just very quickly list a few major security vulnerabilities that have happened within the past few years in browsers, all of which you would have been effectively immune from if you had disabled Javascript by default on even just most sites you visited:
1. Spectre/Meltdown
2. LastPass's browser extension leaking passwords to any page you visited.
3. Firefox's most recent 0-day (that is being actively exploited)[0].
4. Targeted vulnerabilities in mobile Safari (that went unpatched for years)[1].
On top of the numerous browser vulnerabilities that pop up, disabling Javascript by default will protect you from a nontrivial number of phishing attacks and cookie-hijacking attacks. Yes, you can do these attacks without JS/ajax, but in practice a large number of them use JS/ajax. Disabling JS will also make you effectively immune from crypto-mining attacks.
Even non-malicious pages are usually not coded well in terms of CPU-power. One way you can tell a browser disables JS by default is that the non-JS setup will gracefully handle several hundred tabs at the same time in normal everyday usage for extended periods (>1 month). The other browser will eventually get caught by a rogue tab that freezes everything and forces you to restart the browser.
On the privacy front... I dunno, don't you work at Google? You should know this.
Panoptoclick[2] tells me my current browser setup is leaking about 6.6 bytes of identifying information. That's low enough that with a decent VPN setup, I can browse the web (close to) anonymously in many situations. I would challenge you to get a better result than that without disabling Javascript -- especially if you're starting from the disadvantage of using an uncommon OS like Mac or Linux.
----
So there's an interesting philosophical conflict here, which is that the web is awesome, and browsers are awesome, and Javascript is awesome, but anyone who's both technical and privacy-minded should turn Javascript off by default. And this conflict is because where security is concerned, I am trying very, very hard to be a fox, not a hedgehog.[3]
My general advice, notwithstanding my opinion on sandboxes, is that everyone should install Ublock Origin, no matter who they are. If you're technically inclined and understand the web, you should also install UMatrix, which will at least get rid of the most common attack vectors: third-party scripts. If you're technically inclined and understand the web and you worry a lot about privacy, you should use UMatrix to disable JS by default.
That's not an ideological position about sandboxes or about the web. It's not saying native apps are better (native environments are in most cases objectively worse at security). It's purely an observation that roughly 75% of the sites I visit (including many major news sites) work fine without Javascr...
Excellent response and more patience than I could muster.
> It's not saying that nothing should run Javascript. It is saying that if you want to run Javascript, you should have a reasonably good justification, and if you're displaying pure text you should probably provide fallbacks when possible.
It goes both ways. Yes, turning off JS means that some sites will fail to work. As I said in my comment, I expect this. On the other hand, a well-designed site should fail gracefully, so that turning off JS won't make the site fail to work, but may make certain features unavailable. Sites that don't fail gracefully (with certain exceptions) are poorly engineered sites that are excluding people unnecessarily.
> JS is part of the web platform
JS is an optional part of the web platform.
> and there are tons of amazing things it allows you to do.
Of course. The problem is that JS allows terrible things to be done as well. Just as I won't download and execute binaries from random web sites, I won't allow JS from random websites, for precisely the same reasons. JS is too risky.
> If you choose to browse with IE6 and complain that sites using HTML5 are excluding you, I'm not going to be sympathetic either.
That's a poor analogy because HTML5 will fail gracefully. If I browse to an HTML5 site with IE6, I will (with rare exceptions) still be able to read the page.
Every time someone makes a site they're balancing a bunch of tradeoffs. For example, when I built https://trycontra.com I could have implemented the search server-side, with a query and response, but this would have involved writing active server side code. Instead I implemented the search entirely in client-side javascript. People are free to choose not to run the JS, but I don't feel any obligation to engineer the site differently to accommodate their preference and I don't think the OP should either.
> Just as I won't download and execute binaries from random web sites, I won't allow JS from random websites, for precisely the same reasons. JS is too risky.
Downloading and executing binaries from random websites is far more risky than allowing JS. A binary runs as you can can trivially do anything you could do, from keylogging to subverting your browser. If you can do similar harmful things from JS, on the other hand, you're eligible for very large bounties from browser vendors. JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS.
> That's a poor analogy because HTML5 will fail gracefully. If I browse to an HTML5 site with IE6, I will (with rare exceptions) still be able to read the page.
HTML often fails gracefully, but not always. If someone writes a site that doesn't fail gracefully and so is completely unreadable in IE6, I don't think they've done anything wrong.
Rendering the goddamned content is.
If you can't at a minimum give me a title, byline, dateline, main body text and/or some level of summary or description of non-textual content (as with graphics, audio, video, or interactive elements), then you're failing.
(SPAs or web applications should at least provide context for understanding what the application is/does. I'm not calling for all functionality to be rendered in HTML, but sufficient context to determine WTF the site is about.
Your "but I cannot implement search" is a strawman, and really doesn't address the core complaint.
As it stands, I'm looking at options for SSG-based blog posting, and at how it might be possible to support search. JS-based options, plus an extensive tagging / ontological classification, strike me as a reasonable compromise.
The fact that the Web is lacking a usable search-oriented standard which could bypass much of this problem, is one that's seldom noted. If sites could provide a permuted index in accessible format, and a standard mechanism for accessing it via a browser site-search function (or independent third-party search tools) ... well, the present online landscape would look remarkably different.
Sadly, we're not there, and the orientation of the leading browser developer is quite likely not going to support such development.
I'm not going to dismiss this out of hand, but this is a harder problem than you realize. We did have search keywords at one point. The problem was that sites started stuffing them with irrelevant values. Google removed that and started doing their own analysis, because keywords made it too easy to game SEO.
There are certainly ways that keywords could be done better today, I'm not going to say we should give up on the entire concept. But asking websites to self-categorize themselves is a very tricky problem that is very prone to abuse.
Remember that the web (currently) monetizes eyeballs, so until that situation changes there is a strong incentive to show up in every search regardless of whether or not you're relevant.
My example was a domain specific search engine. The only thing the site does is let you run searches, implemented client-side in JS. Without JS the site completely doesn't work.
Perhaps you misunderstand what I'm saying. I am not saying that you, or anyone else, is obligated to do anything in particular. All I did was to point out a factor that should be considered -- if your site does not work without JS, then you are excluding some people. If you don't care, fair enough.
However, I stand by my assertion that sites that do not fail gracefully are (with certain exceptions) poorly engineered sites.
> Downloading and executing binaries from random websites is far more risky than allowing JS
That does not mean that allowing JS is safe.
> JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS.
Yes, I'm well aware of that. And yet, JS is commonly used to do all sorts of nefarious things (such as tracking, for instance) anyway.
Requiring readers to execute arbitrary code in order to read content seems like a terrible way to implement a web page.
Nor is it cheap: it requires every single reader to execute the same code, burning CPU over and over and over when it could be done once for all readers, by the server.
> Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted.
Yes, you can require execute privileges in order to publish content, but anyone who publishes that way should expect that many people won't read what he writes.
JS is enabled here and it doesn't render.
While admittedly some readers here are purely focusing on the irony of supporting "the primitive, simple case", for the most part non-JS users are willing to meet sites halfway on this. I'm totally fine manually navigating a Github repo to get at posts, I wouldn't be irritated at all in that situation, I wouldn't have even commented. Right now, your site offers nothing.
Even just the below markup would have been sufficient -- it wouldn't need to be customized per-page.
Just give users something, literally anything they can use to recover when your expected use-case fails.Absolutely! Should be working now (or as soon as CloudFlare cache is purged). Thanks for the snippet.
As long as I know how to get to the text in some format, I'm usually fine with the rest, and markdown is a format that's very easy to read.
I suggested to have a link (or just instructions, if you don't want it to be customized per post) for accessing the Markdown code for the specific post. However, a link to the Github repository also works perfectly OK, so I am not complaining.
I think that are various levels of proficiency, but in general, most Danes have a very good grasp of it, and it's easy to live here if you only speak English.
JS should not be needed to show five paragraphs of text. And even with the JS the resulting HTML is still unreadable.
FF72, uBlock Origin in medium mode, no whitelisting => site renders just fine both in normal and in reader view.
His "noscript" is also broken as it still doesn't show the darned 5 paragraphs of text. It's that hard for him, as he writes what others should do.
The OP is arguing that the primitive, simple case for this page is to not use any javascript because it's unnecessary for the core functionality of this page. The content here can be displayed simply as a few kilobytes of raw HTML.
Much like the author assumed that javascript is most primitive & simple functionality for internet users, the people who built his TV, assumed that chromecast protocol is the most primitive & simple way to send a video link to the TV.
It entirely fails to render in text-mode browsers (I actually make heavy use of w3m).
It entirely fails to render in https://outline.com/, which otherwise is a good way to get fucked-up JS-dependent sites to render. I consider that stage of fuckwittedness either absolutely deliberate (which it appears to be in this case based on the authors defence of their practices), or utter incompetence. These are not mutually exclusive possibilities.
The fact that the article is apparently (I've still been unable to read it) a plea for base-level compatibility is, as initially noted, arch irony.
With NoScript blocking both the site and Google.
By "w/o JS" do you mean totally disabled? Or just NoScript?
And you're right, I wasn't paying attention. I did temporarily allow the site.
This is a simple text-only web page (in courier new ffs) and it refuses to load with JavaScript disabled. There is no valid reason for this.
> Here is my plea: when you build hardware/software, please make it support the primitive, simple case.
Just render the markdown to HTML once on the server and upload it for the love of God.
That being said, the article is entirely correct.
Is the overengineering so ingrained in the average HN user that they cannot see why someone might not bother with that?
However, in a case like this, the alternative—as we can already see—is to add complexity for every single reader on the front-end. So there's not really a perfect solution here—either the author or the reader has to deal with some complexity.
https://getvideostream.com/
But then I thought about it, and the URL thing is a red herring. That's not what they really want -- that's an implementation detail. What they really want is the ability to play something from their local server on their TV. This is totally do-able in the Apple eco-system. The URL thing is exactly what you don't want. Who wants to type a URL into their TV using their phone as a virtual keyboard or not? (Which the AppleTV + iPhone combo does this great too...)
The best option is where you could "cast" any video/media you're watching on a phone or computer up to a TV. The AppleTV + iPhone (or Mac) combo does this great.
Also, just to understand, what does Roku get out of blocking your ability to potentially see non-DRM content? Is Neflix going to pull their app if Roku starts displaying urls?
Samsung’s Tizen OS is the most genuinely frustrating experience I’ve had with a consumer device outside of printing. Advertisements on my home screen that can’t be disabled, dubious privacy, bugs that require me to reboot my TV, and of course security so bad that they recommend installing a virus scanner? Yeah, that’s great. It’s got a web browser at least, though that’s the only positive thing I can really say about the web browsing experience.
Can it run software? If you can find it! There’s no app ecosystem here, just the big apps it absolutely had to have to be worthy of shipping. If you want to watch Twitch.TV streams for example you are SoL. There was an unofficial Twitch app, but it was removed from the store.
I tried to set up development for Tizen. Yeah not gonna try that again. I always thought getting started with development on Android or iOS was a little cumbersome but it really doesn’t compare. Even getting into developer mode was challenging since I had trouble finding the instructions that were pertinent to my model of TV, and that was the last thing I accomplished successfully.
So I’ve got a desktop computer hooked up to my smart TV and now I am contemplating paying more for a TV so I can get one that doesn’t have any of this dumb crap on it. The only downside? You can’t really run many 10 ft versions of things, and there’s not many good casting solutions. Lame, but every time I run into a new pathological case with the TV OS and its set of subpar apps I reconsider how much it’s even worth to have fancy 10ft interfaces and smart phone integration.
(If you are looking for a casting solution for an HTPC running Windows, I tried Reflector 3 briefly and it looks pretty good. But I personally do not run Windows on my own HTPC, so I’m stuck in the dark.)
One downside though is that I only have a couple HDMI ports to work with, so between a Nintendo Switch and a full desktop PC I'm already using all of the ports.
Also, even though I love the NVIDIA Shield, I find it does not really integrate as well as I hoped via HDMI CEC. It's a bit clunky to be honest, and though it's cool I can use the TV remote over CEC, it is definitely not as good as using the Shield remote, due to latency and some weird behavioral differences. So there are also downsides like that, too...
All such radios can be disabled, if not by removing the antenna, then by enclosing it in a faraday cage. It is chilling, though, that these things may become necessary for basic things like appliances.
Keeping the comment in case anyone does have a source. If no response, let's assume rumor.
Interestingly, apparently in the UK (or maybe EU?) there's a defined period an appliance is required to work for, to be "fit for purpose". Note - not a warranty thing, it's a consumer goods thing.
Not living in the UK any more (thanks Brexit), so don't remember off hand the period of time though.
I always laugh when I see something say "1 year warranty" as I know two years is required.
[1] https://www.consumerprotection.govt.nz/general-help/consumer...
[2] http://www.legislation.govt.nz/act/public/1993/0091/24.0/DLM...
The TV itself is a black box of mystery, and does NOT get to go on my network. It doesn't need my wifi password, and I certainly don't want it sending screenshots of my desktop (with sensitive information) off to some advertising agency. No thank you! But far more importantly, the TV will last for years as a dumb monitor, and the external box is usually much cheaper, and can be upgraded and secured separately. This just feels like the correct model.
lets hope they can deliver.
https://www.swedx.se/#horizontalTab2
I could not figure out how to do this with any other combination, and this strikes me as fairly baseline usability.
I was never able to build a HTPC that worked with all the video sources I wanted (Plex, Netflix, Youtube) and was possible to control without ever having to touch a keyboard/mouse (or resort to a janky air mouse/remote thing). With the Shield + a Logitech Harmony Hub, a single dead-simple remote controls entire setup (Shield, TV, external amp, plus a BluRay player that I never use anymore).
[1] Note: I only have a Roku 2nd Gen. The newer ones look a lot better and are probably a fine option now, but I still really like the Android TV "Home" experience a lot more.
Shortly after Sage was shut down my cable company started encrypting all their channels, rendering most of my PVR setup pointless. After chasing issues with Youtube breaking API changes, I finally and begrudgingly pulled the plug on Sage. Several HTPC iterations later I feel like only now (with the Shield + Plex) do I have a comparable setup.
I did briefly play with Plex PVR with my HDHomerun and an OTA antenna, but I don't get enough channels for it to be worthwhile, and never even bothered re-installing the antenna after my roof was re-shingled last year.
I'd go farther. I want everything to be external boxes. Right now I'm looking at having to get a new A/V receiver because mine cannot handle 4K video. It does all the audio stuff I need just fine.
If video switching and audio processing was handled by separate boxes, I'd just be looking at changing out the video switching box.
Now suppose that later I decide I would like to be able to control my receiver with Alexa or Google Home. As it is now that will be another "replace the whole damn receiver" moment. If it were all separate boxes, the preamps, amps, surround sound processor, and radio receiver would all be separate components, controlled by a controller box. If I decide I want Alexa, I'd just buy a new Alexa compatible controller box.
Or I decide I want to upgrade from 5 channels to 7 channels...buy a couple more amp boxes and speakers for the new channels (and might also need a new surround sound processor box).
Basically, take a block diagram of a complete full featured home theater system, and make every block in that a separate box so I can (1) just buy the boxes I need for my system, and (2) upgrade a box at a time.
That said, I doubt TV makers will ever stop primarily making Smart TVs. A Smart TV can function as the only component of a home theater system. Someone moving into their first apartment after school, say, wanting to start putting together their entertainment system can start with a Smart TV, stick it on their home internet, and then use the Netflix/Prime/Disney+/etc app on the TV to watch movies.
That Smart TV probably has a few HDMI in ports, so they can also use it with the cable box if they have cable, and with their gaming consoles.
With a dumb TV they'd need the TV, and they would need an A/V receiver, and speakers, and something to run the Netflix/etc. apps. Buying all that at once might be a budget buster for someone starting out.
By making the TVs smart, the TV makers greatly increase the chances that a TV will be the first component bought for a new home theater setup, and probably also increases the chances that that first TV will be a big screen, high resolution, high quality display model.
It's actually pretty hard to find a media player that supports Dolby Vision for example. No Android media box does, and as far as I know Windows support is very patchy. At least with webOS it supports all the video formats the TV supports.
Setup sound bar.
Connect new TV to HDMI switch.
Get the TV working with my remote.
Throw TV remote in a corner somewhere....
I don't even try to use a smart TV's internal functions anymore. They're just big monitors to me.
Guessing they haven't started shipping with a dictionary to try brute forcing the most common passwords. :D
I do worry that one day someone is going to buy one of those Comcast modems that has the automatic Xfinity guest networks and it will find that ...
There would be some kind of backlash if those TVs connected to one and was able to phone home. Don't know how bad, probably on the order of the smart TV that was phoning home with the name of the contents of and flash drives you connected.
I used to do the whole HTPC thing but having to use an actual web browser to access half my content felt obnoxious and cumbersome.
As for avoiding smart TVs, I found it pretty easy to just ignore the WebOS garbage on my LG. I don't see why I would want to pay more to get rid of a feature I haven't had to interact with since setting the device up.
But can any of them be trusted? Serious question...
I like keeping privacy private, but I'm having a hard time imagining what sorts of private data you are concerned with that would be going over a set top box.
Or were you more worried about the STB being an attack vector into your home and other machines?
Apple TV is a pragmatic option for the sort of person that doesn't mind the Apple Walled Garden.
Xbox One is a pragmatic option for the sort of person that doesn't mind the Xbox/Microsoft Walled Garden.
NVidia Shield and FireTV are pragmatic options for folks that prefer the more Android-ish "mostly a Walled Garden, but".
If your threat model is anything with a corporate or walled garden smell, then sure none of them can be trusted and just build your own media PC with Linux and whichever apps you feel you can trust.
Avoiding tracking and phone-home things.
I intend to replace the Rokus.
Kodi would also enable the same use case.
I don't think this is a use case on Roku. Roku has zero international market share, so I don't think there's much of a developer market for it.
https://play.google.com/store/apps/details?id=com.rabidgreml...
https://www.amazon.com/s?k=42+inch+computer+monitor
1: https://www.vizio.com/tvs/v405g9.html
I'd also like to point out that most of the sub-$400 Smart TVs on Amazon don't have any DisplayPorts, and the display is probably of a lower quality than something that's designed to be looked at from a couple of feet away rather than dozens of feet.
Bigger than 42", I'd just recommend a projector.
What's the main benefit of DisplayPort when most new hardware supports Hdmi 2.0, which does 4k at 60Hz?
How would you define lower quality based on viewing distance? What metrics are we going by that we might expect to be worse? There probably are some, but I can't think of any off the top of my head.
Reaponse time is the one that comes to mind, not because of viewing distance but because of different intended use cases, but I specifically account for that when looking for a TV to use as a monitor.
Yes, it's more expensive than a smart TV, but the only reason is because smart TVs are very literally subsidized by future data collection and monetization.
Not trying to minimize that this could still be too much money for some people, but frankly, a one-time extra $250-300 to permanently escape that whole tracking situation is just a lot less than I expected.
Yeah, call me when you find one…
I have an nvidia shield which more than fulfills the "smart tv" needs, and I think that's probably the way it should be and stay. I love this setup and just want to disable all the smart features now. It's not like they're in the way but sometimes the tv does decide that "I see you're watching a movie. Now might be a good time to ask you to reboot for the latest software update innit?"
Me too! When I bought a new Samsung 32" last year, I went very, very slowly as I set it up, so as not to inadvertently connect it to the internet. I succeeded in not connecting and life is good.
Not sure if Samsung is one of the manufacturers of those though.
> You can’t really run many 10 ft versions of things ...
Huh?
My media server is in a ventilated closet, so I'm using ~15 meter HDMI, USB and audio cables. It was admittedly an expensive HDMI cable, but it seems to work well enough.
Isn't it easy to tweak all that? It is in Debian, anyway.
Unless average Joes start clamoring for that, all of the cost associated with what you're asking for wouldn't help them sell a significantly larger number of TVs.
I've said it before here, but I'm getting a second hand NEC commercial display as my next TV. I've used them at work and they are excellent panels.
Yes, me too. I have an old dumb TV, and will use that until it breaks. When that happens, I won't be buying another TV at all, since as near as I can tell, the "smart" kind will be the only kind on the market.
The computer can be as cheap as the video quality you want to view... and a decent 1080p projector can easily be had for ~300 USD, bump up the computer to gaming specs and run your entertainment off of it and you've got a nice multi-use solution for the house... unless there is competition for resources.
It's a DLNA/UPNP client so I can cast anything I want from my media server on my computer to it (Bubble UPNP is a great app to control all this from my phone) and even though it doesn't have "cast" built into apps like Youtube and Twitch, they're all supported as addons so you can still get 90% of the functionality, so I can finally throw away my Chromecasts. Plus you can either use the TV's remote with HDMI-CEC out of the box, or hook up a wireless keyboard.
With another pi running TVHeadEnd that I feed my aerial into, I basically don't need any of the builtin TV software anymore, Kodi just controls it all. It's a pretty liberating feeling.
There's a Firefox extension called "Send to Kodi" that I use to quickly cast Youtube videos and other videos from my PC to my Kodi. On my phone I use Kore, which can send a URL to Kodi using the standard Android share menu (hold a link, Share > Play on Kodi).
Kodi also supports UPNP so you can use one of the million available apps for that to allow some other media servers as well.
It's not perfect, but Kodi has managed to satisfy my video consumption needs quite well. I'm using an outdated version (it's running on my server which runs Debian stable) but I haven't run into problems thus far.
I haven't yet circled back, but my conclusion was to give up on it and instead pursue an end-to-end solution like Plex or Jellyfin.
It currently serves around 3TB of video and audio files, and new files are added daily. I haven't restarted either the Pi or the minidlna service for many months.
I choose this option because it is a very light-weight solution with no features that I will never use (like trans-coding or metadata downloading, poster art etc).
That said, I wish there was a dumb TV option.
I bought an LG OLED last summer (a 55" C9) and to be honest I don't hate the software (webOS) on it. However my setup is not really normal.
Firstly my TV is connected via Ethernet to my router and is restricted to only Netflix, the LG web store and my internal network.
I don't watch live TV, instead my viewing is limited to Netflix and content on my Plex server. Turns out the LG Plex app is very good. The TV supports pretty much every video and audio codec so I can do Direct Play from my Plex server. I mostly have direct Blu-ray streams extracted and remuxed into mkv files so there is no quality difference with using Plex vs. the actual Blu-ray. The rest is a mixture of H.264 and H.265 video with AAC and DTS audio in mp4 or mkv files. Everything plays perfectly with quality on par with or exceeding Netflix to give a comparison.
This setup works great for me. I only really interact with the TV OS to switch between Netflix and Plex which isn't a big deal and the picture quality of the OLED panel is incredible with 4K HDR content.
The real star of the show is Plex though which is just god damn fantastic. As everything I have is Direct Play compatible I can (and have) run the Plex server on a Raspberry Pi with a USB HDD attached and it works perfectly. Even for 80GB 4K HDR movies (direct Blu-ray remux files are large!) plays back from a Pi running openmediavault and Plex media server in Docker.
In the past I have tried a few different solutions such as a HTPC running Windows plugged directly into the TV but nothing gave me as good picture quality with the same flexibility as using the native TV apps.
In fact the Plex on a Pi setup works so well for me I set one up for my mother when I visited over the new year. She can watch any content on my Plex server as well as anything I upload to hers (as she often wants things I don't care for so don't want using up my disk space :)
If you haven't looked into Plex I highly recommend you check it out. It really does 'just work' which is so nice when you want to sit down and watch a movie without having to deal with all the adverts and junk before the movie on a Blu-ray disc.
I am always open to alternatives however with everything I have tried over the years nothing has come close to how well Plex works. From the flexibility of running the server to the superb automatic content identification to the frame perfect delivery to my TV it has been flawless for me.
However I feel I should point out again that I don't use the transcoding feature so I cannot comment on how well that works.
The only UI prompt I recall seeing is some new streaming feature which I haven't looked into but appears to be some kind of partnership with content providers? I was able to get rid of it easily enough to not even remember how I did it and haven't seen it since.
Perhaps the mobile apps (which I assume are updated more regularly?) have had some more prompts? I only ever use the app on my TV.
Alternative: Emby https://emby.media/
Open-Source Alternative: Jellyfin (fork of Emby v3) https://jellyfin.org/
Subtle. :) Anyone know the motivation for this fork / dig against Emby, other than the premium licensing?
Samsung/Tizen was one of the worst in my experience (the only thing I found more annoying was PlayStation only giving a windows sdk when the box itself is basically a BSD. Let me develop on Linux dammit!)
You need to sign packages with a certificate you get from Samsung and tie it to your device ids for sideloading. For that, you need Tizen Studio, which is a custom outdated version of eclipse, depending on outdated versions of some external libraries. I tried it in a container, which worked fine, except for the signature generation. So I ran it in a sufficiently outdated VM.
Unfortunately, this developer cert will only get you so far and for the complete API, you need a partner level cert.
If you put up with all this, there's the documentation[0]. It takes ages to load and you can't easily download the damn thing, because they pull in the content via XHR. Why, Samsung, why?
[0]: https://developer.tizen.org/development/api-references/nativ...
I still get worked up about this. I was able to watch streams on my TV using this app and someone somewhere just decided I shouldn't be able no more. The TV has lost value with this change, to me at least.
- How inefficient is video streaming when you're downloading chunks of a compressed, static file over a flaky Internet connection?
- Was it worse before? Would it work better with QUIC or HTTP/3?
Your main enemy in this process is, as usual, middleboxes, which may be a bigger problem for the advanced protocols. This is why Apple created the bizarre but effective HLS system: https://en.wikipedia.org/wiki/HTTP_Live_Streaming
I'm wondering how much you lose by doing it the simple way?
URLs are simply not the forward case.
But I agree that IPv6 makes it messy. (I had my own idea which is version 10 (numbers 7, 8, 9 are unusable) which uses the same format like version 4 but with sixteen octets instead of four, and some other differences too.)
Says the one who can't have a simple HTTP only site and I had to enable JS on NoScript in order to read his rant.
Now, this is this person's personal site... they can do what they want. But it's pretty ironic to put a rant about working with URLs on a site with a design like this that doesn't work with simple URLs.
The resource you get with your site is the same thing regardless of what the URL requested is. There is then JavaScript logic that loads more information based on the path. The content is then dynamically added to the DOM. This is how your site works, right?
In this model, you never actually get the content with an HTTP request. You get code that runs that contains/displays the content. From the HTTP point of view, the resource is the code. If you don’t execute the code, you don’t get the content.
This is a perfectly fine way to run a website. I have zero issues with this. And as you say, this ship has largely sailed.
But — what you are asking for in your post is the ability to hand a URL to a media player and have that content play. What would happen if the content site had the same setup as your site (without any special configuration like supporting YouTube URLs, etc)? What is the HTTP request returned a JavaScript wrapper around everything and not the actual video?
The Roku could very well support a video format and still not be able to play the content on such a site. And the kicker is — a web browser would probably work just fine and the user would have no idea why their URL wasn’t working on their TV.
This is why there have to be tools to extract YouTube videos to download. For sites like YouTube, the URL isn’t a simple resource locator. It’s a link to a bunch of code that needs to be run to get to the video.
What I think you’re missing is that it isn’t just the client authors who need to support URLs, but also the server authors. If you have a small local HTTP server that just sends raw files, that’s easy. But loading something like YouTube isn’t as simple as supporting HTTP requests. And there is a certain irony in publishing a post that asks for clients to support working with URLs on such a site design.
I just wanted to play a video file I had on my laptop. I googled around, found that Roku appears to support DLNA, and tried to use Universal Media Server on my laptop. The Roku did find the media server, but kept claiming that there were no files available. Not sure if it was a video format issue (main-profile h264, ac3, and mkv are listed as supported by Roku) or something else, but at the end of the day I just couldn't get it to work, and I was bummed and frustrated.
Maybe play-this-URL functionality wouldn't've helped, but at least I would have felt more confident that it was a format issue rather than just some dumb problem with the huge DLNA tech stack.
I've had experience overseeing the implementation of a simple Chromecast application. It was a relatively painless process and worked pretty flawlessly with minimal code. It may not be a standard but it is totally accessible to anyone with a bit of Javascript experience.
I could imagine an evening hack session that would be a Chromecast application (maybe a browser extension) that you can paste urls into and it would play that way. Without even bothering looking, I would bet such an extension already exists in the Chrome Web Store.
"We Suck At HTTP"
>"We have broken HTTP. We’ve done it for years in fits and starts, but apps have completely broken it. HTTP was a good specification which we’ve steadily whittled away."
https://gadgetopia.com/post/9236
Says a webpage that is just a couple empty divs w/o JS, and, with JS, is 4 hyperlinks, a few paragraphs of text, and absolutley nothing (aside from google-analytics) that ever needed any JS in the first place, let alone 5 or 6 files' worth of it.
But, I think that conflict really speaks to the funamental issue, here: Thinking about the primitive, simple case is often, from the creator's perspective, more work than it's worth.
Otherwise, you're just demonstrating exactly why Roku doesn't have a way to input a URL to play media.
Such is the way of things.
I've recently installed Jellyfin and even put the Roku in "Developer Mode" so I could install the Jellyfin Roku app from GitHub. This is better because unlike Plex, it won't transcode arbitrarily, but it's far worse because the Jellyfin Roku app crashes frequently, has only basic page-based navigation ("go to page 23 for media that starts with 'T'"), and it requires running a heavy media server for no real reason. I'm still reluctantly using Plex for the time being.
When I need something that I haven't put in Plex, I fall back to the Android interface on the FireTV and use VLC to access the NAS over SMB. It still rankles that Roku won't allow an easy way to access local media.
http://movies.foamsnet.com/url/
discussed at https://news.ycombinator.com/item?id=7365256
But chromecast is essentially that standard you ask for, otherwise "apps" like I linked wouldn't work. Heck, as far as I know (I'm not really a Chrome user), Chrome has this functionality built-in, so you can send URLs directly from browser to a chromecast device.
All the smart TVs I've used implement this functionality. VLC and Kodi support this too.
https://en.wikipedia.org/wiki/Digital_Living_Network_Allianc...
This would be some work, but only one person would need to do it and then anyone could "cast" a URL.
(Disclosure: I work at Google, speaking only for myself)
https://chromecast.link/
I guess I could just spend 99 cents and 2 minutes to find out...
Actually, I think the standard is UPnP / DLNA. After setting up a UPNP server I can "cast" most things from Android by using the share button, and then choosing a UPnP app, such as Bubble UPnP. I don't know if the author's tv supports this, but many do.
https://play.google.com/store/apps/details?id=com.instantbit...
http://www.webvideocaster.com/