Mystery - rpOS - Browsers Will NOT Display Web iframe Content

You really haven't provided enough information here... like what is the code the browser is actually running?

And remember a Pi can barely display *one* video stream let alone half a dozen. Try a console screen running 'top' and then launch the browsers and see how much CPU it's chewing.

Cut it back and back - no webkit scaling or anything - until it was basically just a page.pgp ... even tried an experimental page.html. Nada. The frame border at most, no pix.

This shouldn't happen.

As said, on my MX laptop the pages display exactly what they should, promptly. But on the Pi ........

Yea ... but a p3b+ ain't THAT bad. It's really only doing ONE thing - I wanna see my cams one after the other in a loop. Tiny JavaScript bit does the timing, page1 calls page2 and so forth until page1 comes around again at the end. That part IS working, but I just get empty page after empty page.

Have a p4b sporting 'motion', for 7 (low-fps) cams, and Apache. NOT over-loaded. Kinda impressive.

Did, repeatedly. I know the drill. Apache AND 'motion' amount to less than 100% of a core. As said, impressive. Waiting for the promised Pi5s ... did they free themselves from Chinese suppliers ?

And again, on my laptop everything displays as it should, promptly. It's NOT the server end.

I could believe a problem with BookWorm - kinda new and some definite deviations from past versions - but this persists even with BullsEye.

Do NOT like BookWorm - on a Pi or anything else. It's making Deb start to stink of Canonical - too much stuff where it shouldn't be according to a decade+ of docs ... for NO real gains.

The Pi doesn't even include the Gnome network tweaker ... you have to find/install on your own. dhcpcd/wpa-supplicant weren't perfect, but you knew where you stood and there were tons of detailed docs. /etc/network/interfaces was even better, and better documented. They all worked - why change ? Canonical can do what idiocies it wants, but Deb should NOT follow. Keep it simple, consistent.

Using Chromium - has a handy CL options to start maximized and suppress "improper shutdown" messages. FireFox is just a disaster here, totally hangs ...

Anyway, interested in whether other people have seen similar problems - and HOW to fix them.

No, not doing some of those other Linux groups. Too many assholes now :-)

Did you try without the frame, or even loading the video URL directly? It sounds a lot like the video acceleration problems in web browsers on the Pi that people have talked about here often in the past, unless it really only happens when frames are involved.

Personally I don't play video in web browsers anywhere so I can't help with that, but it might narrow down the issue for others here to make suggestions.

Maybe expensive, but I'd have thought easy to get hold of now.

I can load the "motion" mjpeg stream directly, a url:port, and it displays perfectly on the Pi. But the web pages, even though they use the same url:port(s) to create the iframes ... nada on the Pi (except the surrounding frame border), but perfectly OK on an MX laptop.

Checked wifi speed, the Pi gets as good as anything else on site.

Now I HAVE this working on some 'work' units - again Pi's with Chromium showing pages of iframes loading their stuff from 'motion'. Those work very well. Some are quad-frames - 4 cams live on a page.

I created a simple test page with an iframe pointed at a YouTube video. Again, won't load it.

I'm gonna experiment with loading a couple of video-viewers, VLC, maybe MPV as well. maybe showing the frames taps some of the features of those ? Shouldn't, but ...

Using a browser was THE easiest approach. A lot of the needed capabilities just come with browsers. I'd writ several python scripts employing Pillow and the OpenCV library but never got 'em to work as smoothly as desired. Not necessarily a lost cause ... just more of a pain than I'd hoped. Best results were loading still-frames the cams generate using curl and saving them as files. Still tend to get half-frames, even with a locking scheme.

It's getting better now - Amazon was selling p4s for over $220-US at one point, and sometimes they ran out of those.

Of course the p5 is coming out next month. Don't know how long until decent supplies show up in the US retail chain. Do I want more p4s, or to wait for the p5s ???

Anyway, the p3s were not awful. Was updating an original p1b+ the other day. Still does its one little thing perfectly after all these years. Was running a REALLY old version of Raspbian, moved it up to Bullseye 32bit. It' not connected so the old old ver still would have been safe.

Followup note :

OK, found the cause. It's an authentication problem with 'motion'.

At the other place I'd set this up there is no auth for motion streams because none are shared with the universe. In this new application some of the streams ARE NAT-redirected, so we want authentication. The usual "http://username:passwd@111.222.111.222:12345" form in an iframe line doesn't work, at least when motion and Apache are running on the same unit. CAN bring up a frame, but have to manually authenticate. Not ideal. From afar, the usual form works perfectly to get to the exposed mjpeg stream using any browser (ok, not the ancient text-based browsers :-)

I'll have to look into the motion dox. Might be some Apache tweak too.

I am going to use another Pi to SAVE a frame from those mjpeg streams every x minutes, so I need to get the auth working as expected. Already have a good python app for that. Yea, you CAN run ZoneMinder on a Pi - but it's a real CPU hog even if you disable the motion-detection stuff. Kinda drags-down a "real PC". ZoneMinder is really just a very fancy front-end for ffmpeg ... so a home-made ffmpeg daemon is not necessarily a CPU saver here.

Hmm ... found a YouTube vid awhile ago about bringing up THE first web page (which STILL exists, it's at CERN, basically the defs for the 'www project'). The guy used a serious blend of old tech and maybe a PDP-11 computer and finally loaded the thing using a strip of PAPER TAPE with all the login stuff on it. Interesting.

My 1GB Pi4B delivered last week was £35 - say $50

before xmas for sure

If running well, leave well alone.

I built a proxy video streamer for TVheadend

This may work for you:

You pass the url to this php script as an argument: It uses name/password to open the stream on a remote server and pushes it back to the sender.

This should be enough to fool the browser that it isn't actually talking to a remote content generator...

if(!isset($_GET['channel'])) exit(); $channel=$_GET['channel']; $url = "http://192.168.0.101:9981/stream/channelid/".$channel; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL,$url); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10); curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST); curl_setopt($ch, CURLOPT_USERPWD, "name:password"); curl_setopt($ch, CURLOPT_WRITEFUNCTION, function($curl, $data) { echo $data; ob_flush(); flush(); return strlen($data); }); curl_exec($ch); curl_close($ch);

From WHERE ???

But, should I spend $$$ on a 4 when the 5s are soon to hit the market ??? They're claiming at least TWICE the performance (I guess at the same power-consumption).

I'll see what I can do with it. Apparently the standard solution is to use JavaScript to get an auth token and then pass that in the iframe URL. I really really hate JavaScript .........

Been experimenting with 'motion' ... and have had some success enabling/disabling auth on a per-camera level. 'Motion' requires a number of small config files for each cam (over one cam) and there are standard lines for enabling/disabling auth. By having two kinds of streams I can theoretically NAT-forward the auth streams but use the non-auth streams for my local application. Got 2 of 3 running so far ..... but each stream burns CPU. I can dump a couple ...

Depends whether you *need* that performance.

I am gradually assembling my home server and only the TV server is a tad marginal on CPU.

I have not run out of RAM, proving that by and large graphics is what chews up CPU and memory!

Join the club...

Unfortunately it is relatively unavoidable.

That script entirely solved it for me. Just put a call to that script on the server inside each i-frame. It is very low overhead on the server

For the record, I understand that Pi5s can be bought over the counter at the Raspberry Pi store in Cambridge. Limited to one per customer, but that rate limit may mean they can maintain stock.

(yes I know you might be allergic to Cambridge :-)

Theo

By the time I have driven in or paid the park and ride fare, and wasted a whole day, the cost of ordering online even if I have to wait a few days is far far less in time, money, and sheer waste of life that Cambridge represents these days.

Cambridge was a nice place going downhill fast when I left it in

It gets worse every time I go. Roads blocked off, car parks closed, cyclists in dark clothes without lights slamming across in front of you from off the pavements, or the wrong way up one way streets after dark, 20mh speed limits. And unsurprisingly, all the town centres shops are now restaurants or mobile phone shops.

Killed by a 'woke' Labour council and the Internet

Yes, they have stock. I bought a Pi5 with power supply and case from there this afternoon.

Although Cambridge was heaving (it’s half term, so lots of families with kids), getting in and out via Madingley Road Park and Ride electric buses was smooth, quick and very little wait either way.

Gimme a few days ... juggling too many things at the moment ... only APPROACHING retirement :-)

The 'within motion' trick does have appeal as you don't really have to do anything special. Gonna see if I can get the last two cams running without auth, for local consumption, in a few days. The forwarded streams DO still work, needing auth, as desired.