December 07, 2019, 09:20:27 PM
Welcome, Guest. Please login or register
News: Join us for a FREE Webinar this Thursday at http://webinar.digitalsignage.com

MediaSignage support forum



Author Topic: Failed Resource download but still saved as though resource download successful  (Read 3490 times)

indecided

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
I've noticed an increasing trend of this happening.

When we push out a change with new resources, the signageplayers start downloading them as xxx.extension.tmp files. What we see is that if the download isn't successful (eg a 20MB flv but only 10MB made it through), more then often the signageplayer does not check that the filesize is incorrect and renames it to xxx.extension anyways (as thought it is a valid file). As a result, those videos/images/flash files do not play.

I can do a directory listing of all my players and some 10-20 of them have varying sizes even though they are running the same campaign. If they are missing a couple of kilobytes of data, they still play. But very often only 5-10% of the full file was downloaded but still put in like the resource was ok!

Is there no hash checking for files? Nevermind that, not even hash checking, but simple filesize comparison?

admin

  • Administrator
  • Hero Member
  • *****
  • Posts: 5010
  • Karma: +35/-8
    • View Profile
hello,
we haven't had any issues of this sort reported, are you using a 3G or very weak wifi connections at the location?

indecided

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Wifi is stable, slow maybe at 54mbps but steady.

Even if Wifi is slow - under no circumstances should the temporary resource download be renamed to the actual resource unless the file size matches!

admin

  • Administrator
  • Hero Member
  • *****
  • Posts: 5010
  • Karma: +35/-8
    • View Profile
I was thinking maybe there is a corruption due to network drops.

indecided

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
I understand that..

My point is, The mechanism is broken. It should not rename the resource if it is not sized right or if a hash does not tally.

This is a pretty basic scenario. The current mechanism seems to simply rename the file irregardless of its status,
which leaves us in a deeper quandry of having to clear out the entire cache and in turn leave us with more half-downloaded and corrupted resources.

We would like to see this bug fixed (ie. when downloading a resource, the filesize or a MD5 hash should match, otherwise delete the tmp file and retry the download).

admin

  • Administrator
  • Hero Member
  • *****
  • Posts: 5010
  • Karma: +35/-8
    • View Profile
I checked with the dev team and the file download is actually verified through MD5 checksum.
So if you had corrupted files, the only possible way is due to the re-try mechanism that eventually timeout due to network failure. I would suggest you check the local network for unusual drop packets in the switch or router.

indecided

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Sorry to beat a dead horse, but...

If there is a timeout and it gives up trying, then why is the timeout action - to copy the corrupted file as though it was OK?

What I am trying to say is that under no circumstance should a corrupted temporary file be construed as a complete file, which is what is currently happening.

So clearly the MD5 checksum check isn't being ran as it should be.

indecided

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Admin/Levy,

Could you please raise this issue to the tech team? I've confirmed that the SignagePlayer continues to save incompletely downloaded resources as the actual file, so it is not doing proper checks.

The bottomline is that if the file doesn't match - it should never be copied in. I have one player that displays a constant black screen because one MP4 file was not fully downloaded but still renamed as though it is the full file. The entire campaign is a black screen as a result. Removing the file fixes that.

So it's important that the checking is properly implemented because in it's current state it leaves a lot of our screens unusable and unstable.

admin

  • Administrator
  • Hero Member
  • *****
  • Posts: 5010
  • Karma: +35/-8
    • View Profile
I have and confirmed that md5 algorythem is in place. The fact that no one had ever complained point to something in your network that is possibly causing re transmissions, re tries and eventually fail over of the resource. I would look into the network gear first and look for dropped packets.

indecided

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Then could you please clarify how, if the MD5 hash checking is in place, why do I have PNG, JPG and MP4 files with 0KB, 2KB sizes when the originals are 60kb to 20mb?

I understand that the network might have latency or dropped packets, but if that is the case, the MD5 hash should not match, and the files should not be copied over, right?

I have a control unit set up here with excellent wifi in my office and it occurs too. What I notice is that this happens especially if the resource is not loaded in the timeframe that it is to be displayed (ie it starts downloading with the progress bar, if it doesn't complete by the end of the timeframe, this problem is more likely to happen)

I have a few dozen setups on different connections and I even see this problem on machines that are wired in...

Is there any sort of debugging I can switch on to see the error messages so I can have a log?

admin

  • Administrator
  • Hero Member
  • *****
  • Posts: 5010
  • Karma: +35/-8
    • View Profile
I am really not sure. Again if this was a global issues we would get thousands of posts.
try creating a new account, and are you using the same hadrware in all configs?
« Last Edit: October 28, 2013, 01:36:54 PM by admin »

 

Carbonate design by Bloc
variant: carbon
SMF 2.0.12 | SMF © 2016, Simple Machines