0

What is going on with BrightSign file Caching lately???

JRB Technical

October 20, 2014 16:32

None

Follow

Hello:

I have a large number of BrightSign players all over the world that have been accessing Media RSS feeds for weather from my servers for several years now.  They all have been caching images correctly, only downloading them once when the images update, and using the cached image for each subsequent pass of the playlist.

It seems with either recent changes in BrightAuthor or BrightSign firmware, the players are now downloading new images every single pass of the playlist.  My bandwidth has almost tripled from around 1TB a month on one server, to now almost 4TB a month!

The only change I made a while back to my feeds, was to add "filesize" to each item in the feed, at the suggestion of BrightSign support.  But this doesn't seem to have caused any issues with the Player/BA/Firmware combination I am trying here right now. But Players using content authored with newer Versions of BA and newer firmware are definitely downloading a new file every pass of the playlist, when the file hasn't changed.

The clients that aren't having issues are using BA and firmware that is a year or more old. The client that is having the most problems with this keeps everything up to date, mainly because of need of features that have been lacking, and have only been in the more recent versions.

The players are either ignoring feed "ttl" or the "guid" for each item or something else. It's frustrating trying to track down.

There is also an issue with HTML content not properly caching images, like browsers do.  Images are not being cached anywhere I can find, and are being loaded every time the HTML page is being loaded.  I have requested from BrightSign Support detailed information on how HTML caching is supposed to work, and where HTML files are stored in cache on the SD card file directories.  I still have not heard anything back in a long time.

I'm trying to figure out what versions of BrightAuthor and BrightSign Player firmware are doing this, but with all the updates over the last year, there are dozens of possible combinations. Too many to try and keep track of.

Why is it that the Players are not caching files received from the Internet properly as they should???

Why is BrightSign making changes to the way files are cached, if it has been working correctly all this time?

I would like to know what is going on, and my clients would like to know what is going on.  I don't like having to pay for extra  server bandwidth now because of a bug in updates from BrightSign. 

John

• Facebook
• Twitter
• LinkedIn

9 comments

• 0
  
  GD October 24, 2014 09:08

  following to keep track of updates.

  GUID: how are you creating the guid? i put the sha1 hashcode of the file in there. If the guid changes, the player will fetch the image.

   

  Testing: You could create a test setup, with PHP, Python or other server-side script. Instead of linking to an image from the "testfeed.php", link to an image script "testimage.php" that just passes thru the image data. You can then dump the $_SERVER array with headers to a file. This might give insight if the player sends a "modified-since" header and/or other header information the player might send. You can then try sending "expires: date()" headers and/or experiment with 304 status (not-modified) headers.

• 0
  
  JRB Technical October 24, 2014 12:48

  I have been using the sha1 hash in the GUID for years. And feeds Validate properly with W3C Feed Validator.

  There seem to be all kinds of bugs in the most recent Beta versions with Media RSS.

  I have another new client that is using BrgihtAuthor 3.8.0.39 and firmware 4.7.151 on a XD player, and it is only downloading images the very first time from putting a new project on the player. The player is getting the new XML files every pass of the Playlist, but keeps using the images it got the first time, and never downloading the changed images when they change every hour for weather images, and every 5 minutes for radar images.  I was able to replicate here.  I tried and I am having them try the most recent BrightAuthor BETA version/firmware to see if that solves that issue.

  I still have the issue with one clients players downloading new images every single pass of the playlist, and log files are also showing this, with HTTP Status Code 200 every time.

  Like I said, these feeds have been running fine for over two years, and behave as expected on older players with older versions of BrightAuthor and player firmware without any issues. 

  It's only customers that are need to use the most recent versions to solve issues (Media RSS in more than one Zone for example), that are having issues with the same feeds that are running fine on older versions.

  John

• 0
  
  GD October 24, 2014 13:30

  Open up chrome devtools or Firebug and load the image, take a look at the request and response headers. for instance if i open devtools here on this support page, then go to network and reload the page, most of the images respond with a 304 not modified header.

  Can you put up a sample feed somewhere?

• 0
  
  Lyndon October 24, 2014 15:21

  John, can you send me a sample project with your feed that shows the problems you are reporting. 

   

  On the question of html caching, currently brightauthor redownloads the content in an html feed if the html widget is reloaded. So, if you go from one state to an html state, the html is reloaded. 

• 0
  
  Lyndon October 24, 2014 15:22

  For the customers having problems with the new brightauthor, do you know if they're using the settings in the storage tab? The storage tab was added to allow customers to specify how much space on the card should be dedicated to dynamic content. 

• 0
  
  JRB Technical October 28, 2014 06:26

  Sorry for delayed response - I had to fly up to Chicago over the weekend.

   

  GD - Yes, from a browser, I get the expected 304 not modified for images, it has been that way from day one.

  GD and Sr. Support - here is a Sample Feed I will leave up for a while, as long as people don't abuse:

  ds-feed(dott)info/mrss/smp20500/weather.xml       <-change the  (dott) to .

   

  Sr. Support - On the HTML - If the Player is reloading the HTML every time the page is reloaded, then your software engineers need to rethink this.  I have a customer that was using HTML content in a interactive playlist, so the same content is being downloaded every time the HTML is displayed. Content that doesn't change for an hour, but is being downloaded 30+ times an hour more than it should.

  HTML content on the player should follow standard web caching, and only re-download content that has changed/expired.

  I have tried changing the storage tab settings, but they have no change. But this is already negated by the statement that you made that ALL of the HTML content is being reloaded every time the html widget is being reloaded.  So it doesn't make sense to have storage settings, if the player isn't going to store any of the HTML content anyway in this situation.

   

  Back to the Media RSS Feeds. I have been told by BrightSign Support (at various different times in the past) that Media RSS content is cached based on:

  • the Feed Item GUID
  • the feed TTL
  • the Feed Item fileSize
  • the Server Expires Headers

  So which is it?? I am doing all of the above, yet some players do not seem to be using any of those. I don't know what else I can do that I am not already doing. There seems to be no clear answer as to how the players are determining when to download new images, and discrepancies based on BrightAuthor and Firmware Versions as to the manor in which they are, especially in the most recent Beta's. 

  This is just really frustrating.

• 0
  
  Lyndon October 30, 2014 15:29

  How mrss is stored and reloaded has changed between different brightauthor releases.

   

  Currently:

  GUID - in order for content to update, then the GUID has to change. This was true in the past as well. If you changed the content on the server, but didn't change the guid, then the player would assume the content was the same and not download it.

   

  TTL - This determines how often the player checks for new content unless brightauthor has a frequency check that's set to a shorter time period. Older versions of brightauthor didn't have a setting for how often media rss feeds should check in. Again, if the guid doesn't change, only new guids would be downloaded.

   

  Feed Item Filesize - this setting is currently required for caching to occur properly without premature deleting of pol files. In older brightauthors, it wasn't required. If there's no filesize in the feed, then the autorun script doesn't know how much space the file is taking up in the feedpool.

   

  With brightauthor 3.8, under edit, storage, the storage settings are required for caching html. It's also recommended for mrss caching as well. I will setup a test player with the feed you have to duplicate the problems your customers are reporting.

• 0
  
  Lyndon October 30, 2014 15:33

   

  Ok, so I have a 1020 running 4.8.114, and brightauthor 3.8.40. I have storage limits turned on currently. Dynamic content is set to 5%. My project has a video playing in one zone, and the weather in another zone floating in the lower right corner. I can send you the serial # of the unit I'm testing and you can check how it's downloading from your server. It's 72C24D000658. If it's working normally, I can test a different project configuration until we can find what types of playback is problematic. 

• 0
  
  BrightSign TechDocs October 31, 2014 00:42

  Hi John,

  In regards to HTML caching, we've posted an FAQ about enabling and using the HTML application cache on the BrightSign player. You can find it here: http://support.brightsign.biz/entries/58398450-Caching-HTML-content-on-a-BrightSign-player