Editorial standards
How we check a casting guide
Casting advice falls apart when it skips the details: the exact TV, the network, the app version, or the format being played. We publish those details when we have them—and say plainly when we do not.
If we did not run a workflow on a named device, we do not call it hands-on tested.
Last checked:
01 · People
Who is behind the guides
The CastBrowser Editorial Team is the organization byline for guides maintained by ROTUNDA TECH LTD, the company that publishes CastBrowser. The work covers web-video detection, receiver setup, local-network discovery, and the limits of Chromecast, Roku, Fire TV, AirPlay, DLNA, and browser receivers.
A real person is named only after they have actually reviewed the page and approved the evidence behind it. If that has not happened, the byline stays at team level. We will not put a made-up name on an article to make it look more authoritative.
02 · Labels
Three labels, three different claims
Documentation checked
We checked the workflow and limitations against current product behaviour and primary platform documentation. No device test is implied.
Hands-on tested
We ran the workflow using the exact phone, receiver, app version, network, and media conditions listed on the guide.
Updated
The guide received a meaningful technical review or correction. A formatting edit alone does not earn a new date.
03 · Method
The check, from setup to sign-off
A useful test should be repeatable. We record the environment first, then run the normal path and the failure cases that matter for that guide.
- 1
Capture the setup
Record the app version, phone, receiver, software version, Wi-Fi conditions, and media sample before testing.
- 2
Run the normal path
Check discovery, connection, playback start, pause, seeking, subtitles, and disconnect behaviour.
- 3
Push the weak points
Try the relevant failure cases: DRM, unsupported codecs, VPNs, guest isolation, expired URLs, or missing range requests.
- 4
Compare and publish
Separate what we observed from what the platform owner documents, then publish the result and its limits.
04 · Test record
“Tested on a Smart TV” is not enough
A hands-on label needs enough detail for someone else to repeat the test. These are the fields we expect to see beside a verified guide.
- ✓CastBrowser app version and mobile operating-system version
- ✓Phone or tablet model used to control the cast
- ✓TV, receiver, streaming-stick model, and receiver software version
- ✓Network setup, including Wi-Fi band or isolation conditions when relevant
- ✓Media delivery format, codec, subtitles, seeking, and live-stream behavior
- ✓Observed result, limitations, failed paths, and verification date
05 · Evidence
What wins when sources disagree
A reproducible CastBrowser test
A recorded environment and observed result come first.
Official platform documentation
Google, Roku, Amazon, Apple, and TV manufacturers define their own platform behaviour.
Current product behaviour
Release information and the app itself confirm what CastBrowser currently exposes.
Reliable technical context
Independent sources can explain edge cases, but they do not replace a direct test or primary source.
06 · Corrections
Found a result we should retest?
Tell us which guide is wrong and include the CastBrowser version, phone, receiver, and what happened. Material fixes update both the visible date and the structured-data date; cosmetic edits do not.
Report a correction