I have a one display installation for testing.
On it is simple design
Text, Clock and a rss feed (Nasa image of the day, with a reload of 720 min)
On the Statistis report the Get File is at 106,69 GB after 24 hr of operation.
Let say I don’t understand where it is coming from.
How can I figure out what is downloading.
Is there a more detail log of what the Get File is trying to do ?
Thanks you
Your Player is downloading content over and over again from the CMS.
You need to understand why it’s not being able to write that content to the disk on your Player.
Also Nasa image of the day has HUGE photos in it so they will use significant bandwidth - although not 100GB!
Alex
Thanks you
I will install NetBalancer on the player so I will know a little bit more (like the ip and the page he is accessing)
On the Log I do have lot of
Downloaded file failed MD5 check. Calculated [e2463ee52532bc3f67f52305a234bbde] & XMDS [ ce5f80b4a1579d910e7334f72874ecd0] . ticker_14af253a3094830044e7e70539c0292c
But the “ticker_14af253a3094830044e7e70539c0292c” don’t help me a lot.
I have truncated the Bandwidths database so I start fresh between the app and the BD so if it is a miss calculation I will know (the bd is only tacking the month the bandwidth is use)
For the Nasa it is exactly 133 mb so definitively something is download again and again, the error message is pointing to part of the Nasa feed being downloaded in repetition.
I will let you know when I have more data.
Good day
Make sure you’re on the very latest version of the CMS and Player. There were problems with early 1.7 versions and downloading image RSS feeds.
The MD5 check means that the Player downloaded the file from the CMS but when it checked it the checksum didn’t match against the checksum the CMS ran.
ticker_14af etc will be files in the CMS library, so you can check them there and again in your Player’s library and see if they differ in size etc.
Ok
I’m running 1.7.4 on both the server and the client.
For the ticker_1… it look like the picture in the rss feed, I was under the impression the player was going direct to the rss feed to download, not that the CMS was downloading them and them sending them to the player.
I will go read the code of that module
In older versions the Player did go direct. In 1.7, the CMS downloads the feed and the attachments to the CMS library so that the feed will continue to play along with the images should there be no internet connection etc
How is the update to the feed trigger?
Player download then send it to the CMS or the CMS has a script, we are still in early pilot testing and I did not put in place the maintenance scripts.
(Sorry just when back to Xibo my last valid install was some years ago, at that time it was direct ;-))
I don’t have the issue right now, I look like when I deleted the RSS feed and recreated it look like to have fix whatever was broken.
Maybe I have a corrupted file on the CMS or a wrong hash.
I will continue to log, if I don’t see anything in the next 24 hr I will post back.
You define how often the feed updates. The CMS will send cached content to the Players if it has valid cache, otherwise it will download a copy from the source feed and then cache and pass that to the Players.
You absolutely must have the maintenance scripts running. Not that it will affect this but there are other key functions that they operate.
If you’ve not read and followed the CMS post installation setup guide then that’s a must
I read and follow the CMS installation guide that finish with the login screen. Accessible at your main web site.
It did not have a post installation section.
I did find the CMS maintenance page.
Were is the detail instruction ?
Thomas-Louis Laforest
https://community.xibo.org.uk/t/xibo-cms-post-installation-setup-guide/522
It’s the very top item on the front page of the Community site.
Good morning (in Canada ;-))
After the reset of the RSS feed on Monday the issue have disappeared.
I did follow the Post-Installation instruction, the only missing was the maintenance scripts.
Were the issue is resolve in term of download, on the log of the ALL picture of the tiket reported a Downloaded file failed MD5 check.
Now the file look the same on all computer and on the CMS and the player did not download them again.
I’m glad you have it working.
The Nasa feed does use very big images and sometimes the Player will get a timeout from the CMS when it tries to download the image because the CMS is still waiting for the image to download from the origin server.
In that circumstance it will simply try again and then download correctly on the second try.