New post
3

MRSS image caching demystified

Avatar
JRB Technical
None
Follow

Here is some helpful information for those of you who have been banging your head against the wall in regards to MRSS Feeds not updating properly.

I have asked, as well as others, as to what the method is that the BrightSign Players use to determine when to update a cached image in the MRSS Feed. There have been several responses and theories, but nothing worked, and nothing really concrete from the BrightSign folks. I even have a support ticket in about this, and I still haven't received a response to it.

So I have spent the last few days trying different things, and looking at the server log files for my server, and the files on the SD card on the player.

The key is the “guid” element, as this is what the player uses to name the cached file, and to see if it needs to be replaced.  The string in the "guid" element must be unique to the version of a image file.  Even if you alter the image every 5 minutes on your server (lets say weather radar image), if the player sees the same "guid" string that is already has a file for in the feed, it will just use the cached copy.  Only when the "guid" string is different, and not the same as any other file in the cache on the player, will the player download an updated copy of the image to store in the cache.

If you are publishing your feed with a script that you are writing on your own server, you could use the script to create a SHA1 hash of the file:

<guid isPermaLink="false">31fe231ee5f95e7c0031bbe41068f3a6ad6f163c</guid>

If you are publishing by hand, you can do something much easier that will work just as well, using your name or company name, filename, 6 digit date, and 4 digit time:

<guid isPermaLink="false">mycompany-filename-070212-2245</guid>

This is easy to remember, just update the date and time every time you make an update to the MRSS feed file, and the next time the Player checks the Feed, it will see that it needs to update the images.

The “guid” element is usually after the “description” element in each of the “item” trees.

Hopefully this will help some of you out!

Any questions, please let me know, I will try and answer them if I can.

John

Date Votes

7 comments

  • 0
    Avatar
    Tim Ellershaw

    Thanks for this, very helpful.

    It was working for me ( images updated inline with the changing GUID), but I had a problem with the cached inages being retained and the SD card filling up.

    Following a suggestion from BS support, I have upgraded to BrightAuthor 3.5.0.22 , and HD220 updated firmware to 4.4.34

    I now find that the MRSS images are still cached until the SD card fills up. However, now I see that the HD220 is continuously requesting the images from the web server. They are a set of 7 images that show on screen for 10 seconds each, and the GUID is set to change every hour, but I see from the web server logs that they are being requested by the unit every second. I have experimented the the GUID but this makes no difference.

    Something is still not right....

  • 0
    Avatar
    JRB Technical

    I have started seeing this recently as well on some versions of firmware.  It is frustrating as it has made the bandwidth go up exponentially on some units, which also means costs go up.

    Both the "guid" and the TTL in the RSS files should be honored, but it seems in some versions of BS Firmware these are being ignored.  I hope that the BrightSign team will try and keep this in check with all future firmware versions. 

    Also it would be nice if there was a setting for how long to keep cached files on the card. Something like: set cache expire days = 14.

    John

  • 0
    Avatar
    Lyndon

    I'm looking into this problem. I'll also check and see how hard it would be to add some kind of timer to allow files to be deleted on a different schedule. I'm not sure if this can be done, but it's possible. 

  • 0
    Avatar
    Werner de Boer

    Are there new findings in this matter? I also have this problem.

  • 0
    Avatar
    Tim Ellershaw

    Below is a response from Brightsign support that I received a few months ago. I am still having problems with the SD card filling up. The firmware upgrade to 4.4.34 that they originally suggested actually seemed to make things worse.

     

    BrightSign Support, Feb 17 03:49 am (PST):

    MRSS playlist logic:

    1. Unit downloads the feed.
    2. Sets a timer based on the TTL in the stream
    3. Starts to download and play the items in the stream
    4. Continues downloading and playing until TTL timer expires.
    5. After the TTL timer expires it download the feed again.
    6. It then waits until the end of the previous feed to switch to the new feed and goes to step 2


    How MRSS manages storage:

    For Images:
    The cache will allow as many images to collect up to 100MB left on the card or 4000 files. Then all in cache that aren't in the current feed are deleted.

    For Videos:
    If the size of the video is specified in the RSS feed, they will only be deleted when space is required oldest first. If the size of the video is not specified in the RSS feed, they will be cached up to 100MB left on the card, then all not in current feed will be deleted.

    The card MUST be large enough to store all the assets in a feed. If you have a 32MB card and a feed with 1000 images totaling 300MB it will not work.

    There is a setting in autorun script that determines how much free space triggers clearing of the cache. This is the line that sets the 100MB value that's referred to:
    rv.reservedAmountOnCard = 100 * 1024 *1024 'reserve 100 MB on card

  • 0
    Avatar
    JRB Technical

    For several who have tried, the BrightSign players do not seem to be deleting image files (at least Media RSS image files) when the card is full like they say it should.

    If you are having this issue, please let the BrightSign Staff know in this thread:

    http://support.brightsign.biz/entries/23056758-SD-Card-Full-Old-Cached-MRSS-files-not-being-deleted-

    Maybe if more people chime in, hopefully there will be a working solution to this issue soon.

    John

  • 0
    Avatar
    Alex Muñoz Basols

    JhonLBV do you know if this applies to TD1012. 3.10.45 soft 3.7.0.39

    Best Regards

Please sign in to leave a comment.