New post
0

File download Hash mismatch

Avatar
Anders
None
Follow


Here is a snippet from the log-file from a HD210 downloading from a Hfs-server: Video Event 8 VideoFinished LaunchVideo: play file Getready2_LME_WMV_720.mpg Video Event 3 ### Download 2010/11/09 13:18:14.748 ### start_sync download ### sync already active so we'll let it continue ### File download progress ericQ3REPORT.mpg 100 2010/11/09 13:18:27.154 ### pool_event ### File failed ericQ3REPORT.mpg: Hash mismatch ### UploadDeviceError ### UploadError ### UploadError - upload already in progress 2010/11/09 13:18:28.541 ### pool_event ### reset_download_timer_to_do_retry The player tries to download the specific file over and over. What does Hash mismatch mean 1 What could cause it 1 Link to the complete log-file http://dl.dropbox.com/u/10884653/log8.2NOV2010.txt
Date Votes

5 comments

  • 0
    Avatar
    RokuLyndon


    The unit thinks there's a difference in the hash key in the current sync file and the file it's trying to download.

    You can try publishing that project again, it will create a new sync file, which will have a redone hash key.

    If you're using ftp to transfer the files, make sure the transfer method isn't set to auto or ascii. It should be set to binary.

    If you published the project, and then manually replaced one of the files, then the hash key used in the current sync won't match the file that the player is trying to download.
  • 0
    Avatar
    Anders


    "RokuLyndon" wrote:


    You can try publishing that project again, it will create a new sync file, which will have a redone hash key.

    Just publishing again don't help. But if we rename the media file ( myFilm.mpg => CopymyFilm.mpg ), replace it in the project, and publish, it helps. ( It's still the same file with the same hash code ).
    The problem only occurs if the media file already exists on the SD-card. We have compaired the hash code in the XML-file and the hash code of the file on the SD card, and they match.
    Conclusion is that the media file is changed somwhere between Bright Author makes the hash calculation, and the player makes the hash calculation of the received file.
    Question is, why does the player bother to download the file when it already got it ?

    "RokuLyndon" wrote:


    If you're using ftp to transfer the files, make sure the transfer method isn't set to auto or ascii. It should be set to binary.

    We have BrightAuthor and HFS-server on the same PC. Publishing from BrightAuthor to the folder shared to the players by HFS.

    "RokuLyndon" wrote:


    If you published the project, and then manually replaced one of the files, then the hash key used in the current sync won't match the file that the player is trying to download.

    Ok. No we are not doing that.

    Any ideas ? Any tests we can do ?
  • 0
    Avatar
    RokuLyndon


    The brightsign shouldn't download a file it already has unless it thinks the hash keys are different. Does this only occur with this file, or with any file that's already on the card? Does this occur with images and videos, or just with videos?

    THe setup you're using is the same one I use for testing local networking. I've never had this issue that you're seeing. What flash card are you using? We've had customers recently reporting problems with Transcend cards. Is yours a transcend card? Can you try a different card, or have you already seen this problem on multiple cards?
  • 0
    Avatar
    Anders


    "RokuLyndon" wrote:

    The brightsign shouldn't download a file it already has unless it thinks the hash keys are different. Does this only occur with this file, or with any file that's already on the card? Does this occur with images and videos, or just with videos?

    It could occur with any file that's on the card. But we think it's only file about 50MByte and bigger.
    Just with videos. Probably because JPG's are smaller.

    "RokuLyndon" wrote:

    What flash card are you using? We've had customers recently reporting problems with Transcend cards. Is yours a transcend card? Can you try a different card, or have you already seen this problem on multiple cards?
    We are using SanDisk cards. Yes, We have seen the problem on multiple cards.

    We have seen the following happen:

    1) The player is playing project "X" containing "MyFilm.mpg" with the hash code "XYZ123"

    2) We add the film "Film2.mpg" with the hash code "ABC578" to the project och publish.

    3) The current-sync.xml on the webserver says:

    <name>MyFilm.mpg</name>
    <hash>XYZ123</hash>
    <link>http://192.168.1.15:8080/bs_client15/MyFilm.mpg</link>

    <name>Film2.mpg</name>
    <hash>ABC578</hash>
    <link>http://192.168.1.15:8080/bs_client15/Film2.mpg</link>

    4) On the SD card in the player is a file with the hash code "XYZ123" ( = MyFilm.mpg )

    5) The player downloads current.sync.xml and decides to download MyFilm.mpg although it already on the SD-card.

    6) When download is completed it generates Error: hash mismatch.

    7) It starts allover from 5 and gets trapped in a loop.

    To break the loop, we can rename MyFilm.mpg to CopyOfMyFilm.mpg and replace MyFilm.mpg in the project in BrigtAuthor with CopyOfMyFilm.mpg, and publish.
    Since CopyOfMyFilm.mpg is the same film as MyFilm.mpg it also gets the hash code "XYZ123".
    EDIT: Just republishing, without doing any changes in the project doesn't help.

    Player download the new current_sync.xml and finds that it has already got "XYZ123" and starts playing it.

    Question is why does it start the download of MyFilm.mpg under 5) above ?
    Is it possible to get more debug info from the player to see on what data it makes the decision to start the download ?
  • 0
    Avatar
    Anders


    Another question:
    When does BrightAuthor do the hash calculation ? From the source-file in the "Media Library"-folder or from the copy in the "Publish to" - folder ?
Please sign in to leave a comment.