Announcement

Collapse
No announcement yet.

HS3Touch for iOS image caching bug

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    HS3Touch for iOS image caching bug

    This is an ongoing issue I've had, casting the net a bit wider to the general forum here to see if anyone has found a good workaround. Basically, when trying to setup a random picture screensaver on a wall-mounted iPad, I've encountered an issue where the image is persistently cached in the hs3touch client. Very persistently cached.

    I've been using the same procedure for years on Windows clients without issue.

    I only discovered this when I recently setup a wall-mounted ipad to do the same thing.

    1. create a Text or Image element, don't ignore image presses.
    2. set the URL on normal and URL on pressed to something like:
    http://my.homeseer.server.com/Random_Photos/MyImage.jpg
    where the URL is a valid path to an image in the html dir on the homeseer server.
    3. Create an Action when Released on the element to update the element's URL - set the target URL to the same URL as above.
    4. deploy the project. You should see the image.
    5. update the image to be a different image.
    6. Press and release the image. The Image should change to the new image.

    On a Windows client, this works fine. On the iOS client, once the image has been populated, it never, ever changes. It is somehow really persistently cached. If I kill the client and restart it, I STILL get the old image. The only way I have found to update the image is to DELETE Hs3Touch and reinstall the app. It then caches whatever the current image is, lather, rinse, repeat.

    After many hours of trying to come up with different workarounds, I settled on using a vbscript that comes up with a unique filename every time it changes the file (ie. adds a datestamp to the end), and then updates the touch element URL to the new unique filename.

    This works, and appeared to have solved my problem. HOWEVER, it appears have unearthed another issue. Now, after maybe 12h or so, my HS3Touch client simply dies. Once or twice a day I walk by the ipad on the wall and it's at the iOS dashboard. Pressing HS3Touch brings the client back up, and it works great..... until it dies again. **UPDATE - I'm fairly confident this is what's happening - when I changed the picture updating frequency from 2 minutes to 30 seconds, the client started dying after about 3h instead of 12h.**

    My guess is that whatever the persistent caching is that is caching the images is persistently caching every uniquely named picture and keeps going at it until it runs out of memory somewhere or another, and dies. This appears to be further corroborated when I go to System Settings -> General -> iPad Storage -> and look at HS3Touch - it's currently taking up close to 4GB of storage. (!) Presumably due to the cached images.

    I came up with another workaround - I tried wrapping the image (non changing filename version) with an html wrapper, with meta tags saying "don't cache anything". I then changed the image to load that page rather than the image itself. There's an A HREF tag in the HTML to use the API to then click through, and that all does work. HOWEVER, this one has it's own issue as well - when you click on the HTML-ified image, if you don't tap it just perfectly it will grab it and attempt to scroll the screen, rather than press the link. You have to be extra careful to just tap the screen in order to click through to get to main screen. (When you just use an image or text element with an image, you don't need that precision because it's not intended to scroll as HTML is.)

    I'm at a lost. I've opened a support ticket on the image caching bug, but I'm not holding out for that to be fixed anytime soon. Any suggestions?

    regards,

    Paul

    #2
    rjh it sounds like others have experienced caching issues too. Any thoughts on the above?

    Comment


      #3
      Use an image element and set the "IS VIDEO" property to some value. That stop any caches. The property simply tells HSTouch to fetch a new image regardless of the filename. Its mainly used for video but works for any image that changes but the filename does not. I use it for weather radar images.

      Originally posted by paul View Post
      This is an ongoing issue I've had, casting the net a bit wider to the general forum here to see if anyone has found a good workaround. Basically, when trying to setup a random picture screensaver on a wall-mounted iPad, I've encountered an issue where the image is persistently cached in the hs3touch client. Very persistently cached.

      I've been using the same procedure for years on Windows clients without issue.

      I only discovered this when I recently setup a wall-mounted ipad to do the same thing.

      1. create a Text or Image element, don't ignore image presses.
      2. set the URL on normal and URL on pressed to something like:
      http://my.homeseer.server.com/Random_Photos/MyImage.jpg
      where the URL is a valid path to an image in the html dir on the homeseer server.
      3. Create an Action when Released on the element to update the element's URL - set the target URL to the same URL as above.
      4. deploy the project. You should see the image.
      5. update the image to be a different image.
      6. Press and release the image. The Image should change to the new image.

      On a Windows client, this works fine. On the iOS client, once the image has been populated, it never, ever changes. It is somehow really persistently cached. If I kill the client and restart it, I STILL get the old image. The only way I have found to update the image is to DELETE Hs3Touch and reinstall the app. It then caches whatever the current image is, lather, rinse, repeat.

      After many hours of trying to come up with different workarounds, I settled on using a vbscript that comes up with a unique filename every time it changes the file (ie. adds a datestamp to the end), and then updates the touch element URL to the new unique filename.

      This works, and appeared to have solved my problem. HOWEVER, it appears have unearthed another issue. Now, after maybe 12h or so, my HS3Touch client simply dies. Once or twice a day I walk by the ipad on the wall and it's at the iOS dashboard. Pressing HS3Touch brings the client back up, and it works great..... until it dies again. **UPDATE - I'm fairly confident this is what's happening - when I changed the picture updating frequency from 2 minutes to 30 seconds, the client started dying after about 3h instead of 12h.**

      My guess is that whatever the persistent caching is that is caching the images is persistently caching every uniquely named picture and keeps going at it until it runs out of memory somewhere or another, and dies. This appears to be further corroborated when I go to System Settings -> General -> iPad Storage -> and look at HS3Touch - it's currently taking up close to 4GB of storage. (!) Presumably due to the cached images.

      I came up with another workaround - I tried wrapping the image (non changing filename version) with an html wrapper, with meta tags saying "don't cache anything". I then changed the image to load that page rather than the image itself. There's an A HREF tag in the HTML to use the API to then click through, and that all does work. HOWEVER, this one has it's own issue as well - when you click on the HTML-ified image, if you don't tap it just perfectly it will grab it and attempt to scroll the screen, rather than press the link. You have to be extra careful to just tap the screen in order to click through to get to main screen. (When you just use an image or text element with an image, you don't need that precision because it's not intended to scroll as HTML is.)

      I'm at a lost. I've opened a support ticket on the image caching bug, but I'm not holding out for that to be fixed anytime soon. Any suggestions?

      regards,

      Paul
      πŸ’‍♂️ Support & Customer Service πŸ™‹‍♂️ Sales Questions πŸ›’ Shop HomeSeer Products

      Comment


        #4
        Hmmmm, I seem to remember thinking that didn’t work on iOS, but it was some time ago. I’ll test it and report back...

        Comment


          #5
          rjh Ok here's what I found when using isVideo=yes. Indeed, it is allowing the image to change. That's cool, thank you. However, it appears to be adding a roughly 5 second delay to completion of a release action for the element.

          The element has an action on release Display a Screen by Itself. Effectively the element is acting as a screensaver that rotates images, touching the screen (and therefore the element) is telling it to change to the security panel screen so you can do stuff.

          With isVideo turned off, the transition to the new screen is instant. With isVideo turned on, there seems to be a delay that varies from 2 seconds to 6 seconds, with 5 seconds being the most common. Basically you touch the screen, it immediately turns the entire screen grey, hangs out for 2-6 seconds, then switches to the new screen. I tried playing isVideoRefreshRate in case zero (the default) was causing some major load constantly updating the image, but no change. (I'm assuming that zero actually means don't reload the image at an interval, only refresh it when requested (?) ).

          Any ideas?

          regards,

          Paul

          Comment


            #6
            Did you try some larger values? Smaller values will cause quick updates and that may slow down the transition. But larger ones will update less often.

            Originally posted by paul View Post
            rjh Ok here's what I found when using isVideo=yes. Indeed, it is allowing the image to change. That's cool, thank you. However, it appears to be adding a roughly 5 second delay to completion of a release action for the element.

            The element has an action on release Display a Screen by Itself. Effectively the element is acting as a screensaver that rotates images, touching the screen (and therefore the element) is telling it to change to the security panel screen so you can do stuff.

            With isVideo turned off, the transition to the new screen is instant. With isVideo turned on, there seems to be a delay that varies from 2 seconds to 6 seconds, with 5 seconds being the most common. Basically you touch the screen, it immediately turns the entire screen grey, hangs out for 2-6 seconds, then switches to the new screen. I tried playing isVideoRefreshRate in case zero (the default) was causing some major load constantly updating the image, but no change. (I'm assuming that zero actually means don't reload the image at an interval, only refresh it when requested (?) ).

            Any ideas?

            regards,

            Paul
            πŸ’‍♂️ Support & Customer Service πŸ™‹‍♂️ Sales Questions πŸ›’ Shop HomeSeer Products

            Comment


              #7
              Based on limited info I could find, it appears the value is per second, so if I do - value of 1 it would try to refresh once per second. Based on that, I tried values like 30 seconds, 600 seconds, 1000 seconds. There was no change to the behaviour when I pressed the element.

              regards,

              Paul

              Comment


                #8
                rjh I think it's worth noting, however, that I think the cache bug issue I mentioned at the top is still worth your investigating - based on what I found, it appears that with 'isVideo' = no, ALL images that are being populated to an event via a URL (ie: `http://homeseerserver.com/Random_Photos/my_photo.jpg`) will never, ever be able to be changed, without changing the name of the image and subsequent link.

                To test using isVideo=yes above, I had to change my element back from being a text element (with a url that loads a web page, which is my workaround for now) to being an image element (which is what I originally tried to use) so that I could get the isVideo flag to appear. When I did that, and with isVideo turned off still, the resulting image that appeared on my ipad is the originally cached image from FOUR months ago. The client is never, ever, under any circumstances, appearing to delete the cached image. I'm confident this is part of the reason for it crashing periodically if I change the filename of the image on each load with a random filename - I essentially run the client out of resources.

                So, certainly if there's a way to get my screen to load quickly while using isVideo, that will work for now, but I still think it would be worth Homeseer's while to pursue the bigger picture caching bug that is inherent in the client....

                regards,

                Paul

                Comment


                  #9
                  I can look at why the screen is not loading faster.

                  The caching thing is not really a bug. If you name a file and don't change it, why should we fetch a new file? Originally we always fetched the file and that created all sorts of problems since some users have devices that change often. Fetching the status image on each change caused a lot of network traffic and really slows down the drawing of the screens. So we decided to cache the images. The IsVideo property is there to allow you to force a refresh. I really don't see how I would know to fetch a new image otherwise.

                  One thing I will check is that when you start up the app it is suppose to be flushing the cached images, so I don't see how you are getting very old images.

                  Originally posted by paul View Post
                  rjh I think it's worth noting, however, that I think the cache bug issue I mentioned at the top is still worth your investigating - based on what I found, it appears that with 'isVideo' = no, ALL images that are being populated to an event via a URL (ie: `http://homeseerserver.com/Random_Photos/my_photo.jpg`) will never, ever be able to be changed, without changing the name of the image and subsequent link.

                  To test using isVideo=yes above, I had to change my element back from being a text element (with a url that loads a web page, which is my workaround for now) to being an image element (which is what I originally tried to use) so that I could get the isVideo flag to appear. When I did that, and with isVideo turned off still, the resulting image that appeared on my ipad is the originally cached image from FOUR months ago. The client is never, ever, under any circumstances, appearing to delete the cached image. I'm confident this is part of the reason for it crashing periodically if I change the filename of the image on each load with a random filename - I essentially run the client out of resources.

                  So, certainly if there's a way to get my screen to load quickly while using isVideo, that will work for now, but I still think it would be worth Homeseer's while to pursue the bigger picture caching bug that is inherent in the client....

                  regards,

                  Paul
                  πŸ’‍♂️ Support & Customer Service πŸ™‹‍♂️ Sales Questions πŸ›’ Shop HomeSeer Products

                  Comment


                    #10
                    Indeed, it makes sense to cache to an extent, but having some sort of a limit on it would be helpful - for example assuming you have a client that only very rarely gets restarted, having the image cache time out after, say, 24h, or a week, would be helpful (or maybe make it settable, even a global setting for it). It's also worth noting that I only have this problem on iOS - it doesn't occur on my Windows clients. On iOS, the image will persist forever until i uninstall and reinstall the app.

                    But yeah, definitely if you're able to resolve the slow screen load time when isVideo is turned on, that would certainly solve my main problem. To make sure the scenario is clear, basically it's:

                    - An Image Element that grabs it's image from a URL: http://myhomeseerserver.com/whatever.jpg
                    - This image is changed every couple of minutes by an external script that updates the image, and then touches another element that tells the primary element to reload it's image
                    - Touching (and releasing) the primary element initiates a "Show a new screen by itself". It's this screen change that takes a long time when isVideo is on.

                    If you need more details, or want to look at my project, don't hesitate to let me know.

                    Just another question for clarification - am I correct that if the refresh is set to zero (the default), it doesn't attempt to keep refreshing, but does ensure that any request to load the image doesn't use the cache? (in other words, for my purposes I'd likely want zero for the refresh?)

                    regards,

                    Paul


                    Originally posted by rjh View Post
                    I can look at why the screen is not loading faster.

                    The caching thing is not really a bug. If you name a file and don't change it, why should we fetch a new file? Originally we always fetched the file and that created all sorts of problems since some users have devices that change often. Fetching the status image on each change caused a lot of network traffic and really slows down the drawing of the screens. So we decided to cache the images. The IsVideo property is there to allow you to force a refresh. I really don't see how I would know to fetch a new image otherwise.

                    One thing I will check is that when you start up the app it is suppose to be flushing the cached images, so I don't see how you are getting very old images.


                    Comment


                      #11
                      The video fetching can be slow so that is what is slowing down the screen. I think I can make it load a bit faster but "IsVideo" may not be the best solution here as it sounds like you don't need an auto refresh, it only needs to load when you set the URL. So how about I change it so when you set a URL to an element it fetches a new image. I think it should really do that anyway. And also, if an element has a URL for the image just always fetch the image. I really only wanted to cache status images since there could be a ton of those. I suspect not many systems will use a ton of URL's for status images. This means that whenever you go to a screen, any elements that use a URL for an image will then update.
                      πŸ’‍♂️ Support & Customer Service πŸ™‹‍♂️ Sales Questions πŸ›’ Shop HomeSeer Products

                      Comment


                        #12
                        Hi Rich, that sounds perfect. If you’d still like to hedge and give the option to cache them, you could aways just do one more true/false option for caching/not caching, but I suspect that you’re right that if the image is being fetched from a URL it should fetch a new image regardless, so that might be the easiest. This would definitely make my life better, thank you!

                        Paul

                        Comment


                          #13
                          In build 3.0.0.55 URL's are not longer cached. The build will be in Test Flight after Apple approves it. Please test this and let me know if its ok. If so I will release this build to the App Store. I will also post here once Apple notifies me that its ready in Test Flight.
                          πŸ’‍♂️ Support & Customer Service πŸ™‹‍♂️ Sales Questions πŸ›’ Shop HomeSeer Products

                          Comment


                            #14
                            Sounds good, Many thanks Rich!

                            Originally posted by rjh View Post
                            In build 3.0.0.55 URL's are not longer cached. The build will be in Test Flight after Apple approves it. Please test this and let me know if its ok. If so I will release this build to the App Store. I will also post here once Apple notifies me that its ready in Test Flight.

                            Comment


                              #15
                              rjh saw the app appear in TestFlight, I just want to check, the email says β€œFixed iPad config not included” - the device I’m using for this is indeed an iPad. Will the cache fix work on it or will it need to wait for a version that includes the iPad config? Or will deploying my own project render it irrelevant regardless? Many thanks!

                              Paul

                              Comment

                              Working...
                              X