Base64 in image source

fixed
#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
#48

awesome, thanks a bunch. we’ll give that a shot and let you know. I appreciate you looking into this for us.

#49

Thanks @ipaterson, I think that resolved it.
In my test, I removed the refresh=300 completely…
and about 6 or 7 seconds after the piston ran,
the tile image updated smoothly!!!

Well done, and thanks so much for helping!!

#50

I’ve changed the thread tag to “fixed” (again)… let me know if I was premature (again) but I think @ipaterson has worked his magic nicely on this one!!

Love a happy ending :smile:

#51

That’s great! I think that rounds out the next release, so I’ll get that up to the live dashboard for everyone later this week.

It should still work fine without removing the refresh, to clarify what I posted earlier the refresh is not actually “disabled.” It will continue to run the function that refreshes the image at the interval you specify, but that function will detect and avoid modifying any image with a data url. So theoretically if you had a tile where the piston periodically switched between a data url and a normal web accessible image the dashboard would still try to refresh the web image at the specified interval.

There is a possibility that this change could affect people using normal images. Let’s say you have a piston that runs every 5 minutes and it happens to update the tile to the same URL every time it runs. In that tile you have an image that refreshes every 1 minute. The refresh is performed by adding a parameter to the URL to ensure that the browser does not reload a cached image and in the past since that original image url never updated once you loaded the dashboard. Now every 5 minutes the piston is [potentially, I haven’t tested this] setting the image back to the original URL there may be a “glitchiness” where the image reverts back to an old cached copy before the next refresh interval fires and loads it with a new URL.

The other consideration is whether that osrc property will not allow refreshing web images to be changed by the piston. I have a bit more research here before I can call this done but glad it’s on the right track!

#52

This turned out to not be a concern; Angular will not reset the image unless the URL provided by the piston changes. The refresh remains in control if the piston repeatedly sets the same image URL.

Tested with https://picsum.photos/ e.g. https://picsum.photos/200/?random

This one is a concern, the osrc is never updated so when a piston changes the URL for an image with repeat set it will revert to the previous at the next repeat. I fixed it on staging by updating this osrc if the current img.src does not contain the webCoRE cachebuster refresh parameter. Tested with a piston setting an alternating parameter https://picsum.photos/200/?random&x=0 https://picsum.photos/200/?random&x=1 back and forth.

Please refresh your staging dashboards and let me know if you see anything else that raises concern before this is released. Thanks for reporting and following up!

#53

Yes, I would say magic is definitely an understatement. Thanks a lot to both of you. @ipaterson, we will keep an eye on both versions. we will leave the URL for the saved image enabled for a whole and continue testing the data images. Since or URL call fits the description of your concern, we should hopefully see any issue if there is one.

I have big plans for the data images, working on ways for the PHP to draw all kinds of things from graphs, to weather conditions, to home conditions. The design is still in its primitive stages, but I will post when I have something usable.

thanks again for your help! I’m brand new to webcore, but I have plans to start digging through the webcore code this weekend.

#54

This should be fixed in today’s v0.3.104.20180323 release which will require updating your smartapps at ide.smartthings.com and possibly hard refreshing the dashboard.