Base64 in image source

fixed
#28

and a few days later:

Added support for wide=1 in img and video

#29

Thank you thank you!!!

#30

Well that’s concerning… so we have documentation at least that src is intentionally not getting updated. Will have to see whether it’s intentional because of some sort of browser limitation or otherwise. Anyone want to dig back to original tile discussions to see if there is any context on that decision in Discourse threads?

#31

I’ve been scanning through but the above is about all I can find… will keep looking

#32

I’m checking for source code comments.

#33

What baffles me is that when the src is a jpeg, it DOES refresh at the rate set under refresh=300… but the same technique does not update when a base64 is the src

#34

Another quote:

the dashboard was never really meant for that kind of display… the tiles will also be in the visor, but they’ll have real time updates

#35

I realize that I am pushing webCoRE into new & uncharted realms… but man, my dashboard is looking sweet with mini-graphs embedded in it.

Can I be added to the beta-testing on the visor page?

#36

Oh, I understand you better now. The jpeg reference stays the same (same web address) so the refresh=300 works… but the base64 is different each time it runs, so the refresh=300 is ignored.

#37

Best I can tell here:

  1. img tag is added to tile
  2. img.osrc value is set to the original image url specified by your piston
  3. img.src value is set to the image url plus a cache buster parameter based on the current time
  4. first refresh timer hits
  5. img.osrc value is used to set img.src generate a new cache buster url

That img.osrc is the part that never gets updated, so when the tile changes it seems that it needs a way to validate whether img.osrc is equal to the new value and if not then show your new image. I’ll take a stab at making that happen.

Is it possible that the image does get updated but the refresh parameter later resets it to the original? I forget whether we’ve tried a data url without the refresh parameter but all of the above should only occur when that parameter is present.

#38

There is no beta testing for The Visors … and I don’t think there ever will be…

#39

Thanks for this. I will do a test now after removing refresh=300 from my code.

#40

I don’t suppose this clunky workaround would help?

Will trigger the spinning graphic each time but at least you’ll get your new image afterwards… maybe run every 10 minutes or something?

#41

I am really trying to avoid doing this…

#42

Just a temporary recommendation… obviously not a long term solution.

#43

The first way we tried it was without the refresh parameter. I was convinced that because this was base64, the refresh would not matter.

As for the image.osrc not updating, I imagine that since this was designed for cameras, an update to the image in a tile would cause resource usage that would be considered useless, and it was written this way (or not written at all) as a way to cut down on traffic and processing. Not to mention, if an image updated itself while the camera was running, it would have to obtrusively reconnect to the camera. Maybe instead of trying to force it to update on a piston running, a parameter of autoupdate=0|1 with a default of 0 would work better. Or maybe that’s not necessary, because how often do you change an image source when you don’t want it to update? :stuck_out_tongue:

#44

Well, I removed refresh=300 entirely from the code… I let it run once… Did a hard refresh in the browser… Then left it alone while it ran three more times over 30 minutes. The image refreshed during the hard refresh, but not afterwards, unfortunately.

#45

Thank you for checking that, I will look elsewhere tomorrow.

#46

FYI… image and video tiles were rolled out 27th July 2017, but nothing in the release notes.

It was kept hush hush for a while because green snapshots weren’t yet making the URL’s anonymous.

#47

@jcox @WCmore give it a go on staging.webcore.co. The actual problem here was caused by how the tile media metadata was extracted. It is a fairly expensive operation and the metadata is used more than a dozen times in the tile so there was an optimization to fetch it once then reuse that fetched metadata. The problem was that “only once” meant only once for the entire lifecycle of the tile element, not only once per tile update.

If this works properly for you the following changes will be included in the next release:

  • Refactored how media metadata is extracted from the piston tile data to ensure that
    1. the extracted data gets updated whenever you update the piston tile
    2. the data is processed only once per angular digest cycle (i.e. should not slow things down even if you have a lot of tiles)
  • Disable refresh behavior on data images since the cachebuster parameter added to the URL causes the image to be invalid