Do you really read them entirely? I mean, when I buy a TV, I download the manuals first and check if the features in the menu are what I expect from it. Same goes for a mainboard, monitor or a car, things where the capabilities are important to me.
But when something arrives I don't read the manual unless a question arises, then I search for it specifically in that section. For example how exactly did that microwave/grill-combo work? What exactly did this setting in the washing machine do?
I mean, people say the same thing about me, but I think that this is because they never even consider picking up the manual when they have a problem, while for me it's normal to tell them to read the manual. Maybe I should tell them "maybe you can find the answer in the manual", instead of "read the manual".
But some don't even look the "getting started mini-manual". This drives me crazy, specially when they then struggle using the scanning functionality of the printer or stuff like that.
Yes I really do read them cover to cover and when I find something interesting I make a note of it. Perhaps I'm unusual in that I like reading manuals and documentation. For me it is part of my enjoyment of learning how things work.
I used to do this (stopped checking every manual but still do it for tech stuff with a bunch of features) and nowadays it pays off a lot for my hobby of electronic music production, reading manuals for the synths I want to buy helps a lot to visualise the potential.
It's a fairly common convention for the filename '-' to mean stdin or stdout. However, it's only a convention, and many things don't seem to follow it, particularly things ported from a non-unix-like OS (looking at you, pico2wave).
As someone who's never read a manual for anything I owned in my entire life I find this fascinating.
Is there anything I'm missing out on, and if I wouldn't read manuals cover-to-cover, what parts would you recommend reading?
Also, assuming many are like me, do you find a lot of quality issues or inconsistencies in documentation just because it's a "tick-in-the-box" exercise to provide a documentation and maybe an overlooked part of the product development?
not the original comment author but I also read most manuals when I buy something. If you buy electronics/products from decent companies, you will be surprise how well the documentation is done.
Numerous times I found warnings of how to use or not a certain product, that further expanded by understanding of how certain things works. Even the most boring product can have instructions that you might don't know and could use to learn them.
Example, my local shop sells tomatoes in a box, written with bold letters, don't store in fridge. I bought from that shop for 2 years, and always store them in the fridge until I took notice of the warning and it pushed me to read why.
I really recommend reading the manual. For instance, the one for my Weber grill had quite a few tips in there that I wouldn't have come across otherwise.
I'm not a manual reader in the same way as you, but I've got fond memories of reading man pages on my way down to art school (before I switched courses!). Love cli programs with tonnes of flags and heaps of features, like curl, socat and rsync.
So this (and I assume every other solution people have mentioned) are using youtube-dl -- which means the chromecast is playing a stream from the device initiating the cast.
When I cast from my Android phone to a cast receiver, my understanding is it's basically sending the URL to the receiver and my phone is no longer involved, other than as a remote to control position. (And frustratingly, I find my phone will often get disconnected even though the video is still playing, so I have to spend several seconds waiting or forcing it to reconnect to be able to pause/stop).
What's the difference between these two modes? Is there something preventing the URL method from working, or is there a reason it's preferable to download + stream?
I’m so sick of my chromecast. The audio and video issues are absurd. I have a fibre connection but I can’t manage to keep a 1080p cast working from my machine, and Youtube frequently stutters and lags.
Sometimes I go to Apple’s website and almost buy an Apple TV, other times I think about something more DIY like a raspberry pi media centre.
But what I wonder is... is all of this stuff shit? Do I just stick with my chromecast? Maybe I’m just fooling myself that spending money and switching would be any better.
Reading this just reminded me of how obnoxious my chromecast is.
I’ve been looking at this for a while and not seen anything better than chromecast :( (For the specific use-case of “streaming from phone / laptop to TV”)
I really wish Kodi had a chromecast-server plugin, as Kodi is way better at everything else in the media-playback realm; but having a single-click button for “take this video I’m viewing on my phone and show it on my TV” is just so convenient that it’s ended up becoming the default way of viewing media in my house.
"I think about something more DIY like a raspberry pi"
I've had terrible experiences with Raspberry Pi video playback. Video stutters and lags, I tried both VLC in Raspbian OS and also LibreElec OS. LibreElec OS is a bit better since it loads only what's necessary for Kodi.
I don't recommend it at all.
Chromecast 2nd gen has worked well for me on a 1080p TV. My only complaint is that when idle, it disconnects frequently (once every few hours), but I suspect it's due to my shitty Arris modem.
Every time I have friends or family who are struggling with playback on devices such as these my first question is if they’re on WiFi. Eliminate the WiFi factor and see if you’re still having issues. 9 times out of 10 WiFi is the problem.
Seems likethere might be an issue with the device itself. I've been using my Chromecast on a shared hospital room connection for weeks and it's been suberb.
Thus is the answer. Some revisions of Chromecast have a slow CPU, and poor thermals so the CPU throttles even slower.
That normally isn't an issue, because all the video decoding is done in hardware, but enqueueing the video data chunks to be played is done by software. If the software is delayed because the CPU is very slow and the same event loop is processing loads of other crap (which it is), the video can glitch every few minutes.
The solution is for Google to do less crap on the main thread, increase the hardware video buffer size, or to get a faster CPU or have a better heatsink. The reason some videos do it while others don't is because the chunking is different sizes for different videos.
The problem is worst on the original v1 Chromecast. The latest software update reduced the clock speed because some devices were overheating and kernel panicking. You can still make the problem almost vanish if you do water cooling or take the case off and fit a fan.
Presumably this just tells the Chromecast to stream that video from YouTube directly. But OP's problem is that this doesn't work well for some specific videos.
So OP is using catt not just to send a video URL to the Chromecast, but also to actually serve the content.
I’ve never figured out if it’s possible to stream to anything that’s not a chromecast, e.g pc -> phone, or phone -> pc. Are these possible using ‘cast’ technologies available in iOS and Android?
When they went to the CASTV2 protocol it became very difficult to do anything unofficial as a server side implementation since official Cast SDK clients try to authenticate the server as an authentic device.
Re seeking: instead of pipes one could probably use youtube-dl to dump the url and use a fuse filesystem to mount the url as a seekable file (it is typically implemented as range requests). I found httpfs2 [1] in the Debian repositories [2].
Most often, final means not only that something is currently the last item in a sequence but also that there will not be any more items in the sequence in the future. However, sometimes people use (misuse?) it to mean merely the last time in the sequence for now.
The generation 1 chromecast is pretty old and underpowered (can't run YouTube TV DRM fast enough apparently) so I wouldn't be surprised, however I can't find anything about it no longer receiving uodates.
The main problem I have is that it is not possible to easily resume the stream when youtube-dl stops working and you use a pipe or mkfifo. It would be cool to be able to rerun the program again and continue from where it left, but some streams are not seekable, so you would need to restart the software automatically, consume or skip the first part and start adding the new content at the end of the FIFO device.
This line requires some mdns server setup I believe. I didn't like running avahi and thought there should be some super simple client for this, but after searching I didn't find anything.
I wrote up 10 lines of go which spits out chromecast devices as json and use jq to get the appropriate IP. Works quit well and now I have a fairly seemless way to play videos to my chromecast from qutebrowser.
It's a nice solution to a problem that the author found. I am afraid that knowing Google's walled garden around Chromecast, the `castnow` and `catt` utilities might have trouble staying afloat.
This lets you create programs that run on the Chromecast, and programs that can send data to the Chromecast. Programs that run on the Chromecast must be "registered" on Google's cloud platform, and "published" on Google's Chromecast platform. https://developers.google.com/cast/docs/registration
The only way to run code on the device is to either serve your code through Google's platform, or root the device and own it like the Linux box it is.
None of Google's documentation speaks about the Cast protocol itself. It's against the Chromecast TOS to create a custom receiver device. You must buy the Chromecast hardware. There have been several attempts to reverse-engineer the receiver protocol and create custom receiver devices, but none of them work with the current protocol.
Technically, they're the same kind of pipe as the anonymous ones you create in a shell.
But you can give them a name yourself, and you can create one, then later have a program listening to it, and then later send data to it, from different programs if you want.
You can also create them, send some data to them, and then later start a program to read that out, but you're likely to run into buffering issues with that.
Also, don't forget to remove one when you don't use it anymore.
I really like this informative blog post on unix pipes, but reading the readme would have saved some time.
It contains the answer in a simple form: