Problem solved (for now).
I don’t know what exactly solved the problem (have changed and installed/activated too much also in windows). After reinstalling everything the error is gone! (I think there was something wrong in the cms backend)
For now, i have not made further tests. Only imported the nasa-feed in the fresh installation.
Thank you very much for the help.
And here is a packet i captured with wireshark (old installation - thats why i installed everything new):
Is it ok that chunkOffset is 48000?
Ok, error appears again after creating a new layout/ticker with the following feed:
https://www.nasa.gov/rss/dyn/lg_image_of_the_day.rss
It’s an odd offset but not impossible. You’d see that if a download failed and the client tried to resume the download from that point.
There’s definitely nothing logged CMS side when the Players download content?
No, nothing is logged. (Only on Display > Recent Logs - the same message as in the player)
I am able to reproduce the error only on the win8 installation (xibo local via xampp). The other systems i haven’t tested at the moment.
EDIT: And after deleting the “big”-image feed, no md5 error. On the first installation i got the error also for the “small”-image feed.
EDIT: Same with linux-cms and android-client:
All the CMS does is here:
https://github.com/xibosignage/xibo-cms/blob/develop/lib/service/xmdssoap4.class.php#L570
It opens the file, seeks to the offset provided and then reads the chunksize. That code hasn’t fundamentally changed in forever.
If it’s across both the Android and Windows clients it does suggest it’s a CMS side error however as we’ve only one report of this and thousands of active installations it sounds like it’s something peculiar to that CMS rather than the system as a whole?
Yes, i looked at the code for hours, the script is easy 
i changed a lot, but nothing solved the problem. I really don’t know, maybe it has something to do with the ticker. Or php flag/config
Replaced that also with http://php.net/manual/de/function.file-get-contents.php , same result.
Maybe because there are not many people using the ticker with (big) media attachments. (Most feeds have images in content, thats the next thing i will look at as soon as this problem is fixed)
Ticker downloads use exactly the same mechanism as images/videos etc uploaded directly to Xibo.
Can you replicate the issue with an image you upload?
Yes i know.
No, videos and images worked as expected, even big videos.
And for info:
i also wrote the $file to a second file with file_put_contents, and there were no duplicated parts. But i am really not sure if that is correct or not. It is binary, so i can’t read it
That makes no sense then. If the CMS isn’t sending out the wrong information, it can’t be that the Android and Windows Players, which share no common codebase, both have the exact same issue, but don’t using exactly the same download mechanism for other files.
What cache interval have you put on the ticker? I wonder here if we’re seeing those files get invalidated part way through the download and that’s what’s causing the problem.
Can you please generate a troubleshoot.txt using the report fault wizard AND enabling audit for the display in question, then get it to download the file and exhibit the problem. That should log each and every chunk request so we can see exactly what’s being requested.
I tried different values, 5, 60, 120
Ok, here is the file http://s000.tinyupload.com/index.php?file_id=31592141592648278904
(I didn’t know i have to activate “Auditing” for the Display, maybe you should write that on the ReportFault Page)
EDIT: Another Log with SQL Error http://s000.tinyupload.com/index.php?file_id=00503201515659778279
To enable Auditing on a Display, you edit the Display in the CMS and set Auditing to on.
There’s loads of errors in that log regarding filesystem permissions which certainly isn’t going to help. It looks like the CMS isn’t able to delete files from the filesystem inside the CMS library. Correcting that would be a good start.
I’m not sure what the other SQL errors mean but @dan should be able to offer some insight.
It looks like it is trying to update the cache for a layout that has been deleted… have you deleted any layouts during your testing?
Also are you deleting files directly from the CMS library folder?
No, during debug i did not deleted the layout. The debug Output is different all the time (most time not much in it)
Never deleted something in the cms manually, only on Player side the Xibo Library Folder, but not when Debugging.
It looks like you have a permissions issue then (as Alex mentioned). The web server user should have full access to the library location so that it can read, write and delete files as it needs to.
Once we correct that issue we might have more chance seeing what is happening in the logs.
Ok, i will try. but it is inside of htdocs Folder of xampp and it is somehow writing. Maybe chmod(0777) bevor the unlink?
Here is another Log
http://s000.tinyupload.com/index.php?file_id=49369641174126228828
I think Audit does not work or i am doing something wrong
It shouldn’t be inside the htdocs folder of your installation - it should be outside. If it’s inside, then anyone can just download your content with no protection!
For now you could try a chmod -R 777 /path/to/library however it really isn’t necessary. All that’s required is the folder be owned as the user your webserver runs as. So on Ubuntu that would be www-data.
Auditing works just fine. You need to run the report fault wizard, enable auditing on the display in the CMS, then have it download the content again (and presumably fail to do so). Then complete the final step of the wizard to turn of auditing, turn it off on the display and collect the troubleshoot.txt
Sure, i know, it is on localhost for testing only.
I have inserted chmod($filename, 0777); before the unlink function. No error as far as i see.
I use Windows, so no chown/chmod
Ok, if Audit works the filesystem error is gone as you can see in the latest log-file