Correction, the 0KB files are on the client. The server uploads and stores the media fine. When I try to download via the CMS the media files that are created on the client are empty. The file that is pictured is 8,774KB. I am using Internet Explorer. The uploads to the server appear to be working as when I browse to the directory the files exist and have a Byte count, but when the player attempts to download the file, or I use the download option in the CMS is when my files are empty.
I hope this helps. Please let me know if any other supporting documentation/screenshots are necessary.
I checked the suggested settings, everything appears to be in order. My download window is open (unset). I assigned all but Full Control to the Users group on the file permissions, but the client will still not download the media.
I don’t know if it is relevant, but the client does correctly download the layout xml files from wherever that is on the CMS. I have not yet found a repository for that to see what permissions are similar.
I am only looking at Windows file permissions, is there another layer of permission within the CMS/Apache that I need to be looking at?
Well I am running out of ideas here. Far shots are security software on the client. firewall or proxy on the server or client. Active Directory permission are not preventing this kind of operation, would be on the technical side to configure such a thing.
I am assuming you have followed the post setup guide for Xibo and changed the settings for PHP.
Check library paths ie
for CMS in CMS settings -> library path, it needs to be fully qualified path, please see ‘Library Location’ section of this post - Xibo CMS Post-Installation Setup Guide
For player, it would be probably best to leave it in the default path and see if that helps, default ie C:\Users\<USERNAME>\Documents\Xibo Library
Once you make sure both paths are correct, if it still does not work, could you please show us a screenshot of status window on your device? (press ‘i’ on keyboard to display it, while Xibo for Windows has focus).
Thank you everyone, everything appears to be in the right location, as pictured below. The information screen just says “sleeping” all the time. (as pictured) I’m still confident that it will be a head-slapper. Thanks again for your assistance.
So, it would be good to run ‘verify all’ on Modules page and restart your client.
Could you also please open php.ini, find this line always_populate_raw_post_data -1 and make sure it’s not commented out (no ; before that line in php.ini)
After that, please restart your web server and client.
If not won’t help perhaps check your wamp error log and see if there is something there.
Side note: It would be also good to upgrade to 1.7.8 (both CMS and client).
Verifiy all completed. See screenshot below. I am concerned about the X next to Play Local Video. I found the item int the PHP ini file, and it WAS commented out so I removed the comment character and restarted the webserver and the client, but there is still no discernable change. Is there something specific I should look for in the WAMP logs?
You can try that, as for logs, any errors permissions related or other might help point us in the right direction.
That’s fine, the checkmark in ‘Library media’ column there is only for modules that needs files uploaded directly to the Xibo CMS library - ie images, videos etc.
Local videos are not uploaded to the library (it can be, for example, path to the video file on player’s storage, RTSP link etc), that’s why it has X there.
I will have to try the chkdsk command later today. Fingers crossed
The snippet below is from my Apache access.log. The entries are from the client IP that I have been using during this testing process. If I am reading it correctly, it appears as though the webserver thinks that the files were downloaded. Otherwise I do not see anything that appears to be a blatant error.
The apache_error.log shows nothing of note either. (see below)
[Mon Aug 08 11:21:04.927634 2016] [mpm_winnt:notice] [pid 3180:tid 332] AH00422: Parent: Received shutdown signal – Shutting down the server.
[Mon Aug 08 11:21:06.928415 2016] [mpm_winnt:notice] [pid 6368:tid 160] AH00364: Child: All worker threads have exited.
[Mon Aug 08 11:21:07.053463 2016] [mpm_winnt:notice] [pid 3180:tid 332] AH00430: Parent: Child process 6368 exited successfully.
[Mon Aug 08 11:21:11.258229 2016] [auth_digest:notice] [pid 6452:tid 332] AH01757: generating secret for digest authentication …
[Mon Aug 08 11:21:11.602113 2016] [mpm_winnt:notice] [pid 6452:tid 332] AH00455: Apache/2.4.17 (Win64) PHP/5.6.16 configured – resuming normal operations
[Mon Aug 08 11:21:11.602113 2016] [mpm_winnt:notice] [pid 6452:tid 332] AH00456: Apache Lounge VC14 Server built: Oct 11 2015 11:49:07
[Mon Aug 08 11:21:11.602113 2016] [core:notice] [pid 6452:tid 332] AH00094: Command line: ‘C:\wamp64\bin\apache\apache2.4.17\bin\httpd.exe -d C:/wamp64/bin/apache/apache2.4.17’
[Mon Aug 08 11:21:11.617745 2016] [mpm_winnt:notice] [pid 6452:tid 332] AH00418: Parent: Created child process 6372
[Mon Aug 08 11:21:12.336775 2016] [auth_digest:notice] [pid 6372:tid 160] AH01757: generating secret for digest authentication …
[Mon Aug 08 11:21:12.461824 2016] [mpm_winnt:notice] [pid 6372:tid 160] AH00354: Child: Starting 64 worker threads.
[Mon Aug 08 11:22:08.983882 2016] [mpm_winnt:notice] [pid 6452:tid 332] AH00422: Parent: Received shutdown signal – Shutting down the server.
[Mon Aug 08 11:22:15.158166 2016] [mpm_winnt:notice] [pid 6372:tid 160] AH00364: Child: All worker threads have exited.
[Mon Aug 08 11:22:15.236322 2016] [mpm_winnt:notice] [pid 6452:tid 332] AH00430: Parent: Child process 6372 exited successfully.
[Mon Aug 08 11:22:37.463746 2016] [auth_digest:notice] [pid 6668:tid 332] AH01757: generating secret for digest authentication …
[Mon Aug 08 11:22:38.088990 2016] [mpm_winnt:notice] [pid 6668:tid 332] AH00455: Apache/2.4.17 (Win64) PHP/5.6.16 configured – resuming normal operations
[Mon Aug 08 11:22:38.088990 2016] [mpm_winnt:notice] [pid 6668:tid 332] AH00456: Apache Lounge VC14 Server built: Oct 11 2015 11:49:07
[Mon Aug 08 11:22:38.088990 2016] [core:notice] [pid 6668:tid 332] AH00094: Command line: ‘C:\wamp64\bin\apache\apache2.4.17\bin\httpd.exe -d C:/wamp64/bin/apache/apache2.4.17’
[Mon Aug 08 11:22:38.104621 2016] [mpm_winnt:notice] [pid 6668:tid 332] AH00418: Parent: Created child process 6568
[Mon Aug 08 11:22:39.026856 2016] [auth_digest:notice] [pid 6568:tid 160] AH01757: generating secret for digest authentication …
[Mon Aug 08 11:22:39.245691 2016] [mpm_winnt:notice] [pid 6568:tid 160] AH00354: Child: Starting 64 worker threads.
I came across this error in the php_error.log, My php.ini has the always_populate_raw_data = -1 but it seems that I’m missing a secondary setting:
[09-Aug-2016 10:19:14 America/New_York] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream instead. in Unknown on line 0
If I am missing the mark, please give me more explicit instructions for the information. Thanks again for all your help.
I ran the chkdsk and restarted the server before I left last night. I just checked the client and restarted it, but it still is not completely downloading the required files.
I do not think so. I use RDP to connect to the displays remotely, and I can use SMB to transfer the files manually to the clients. In fact, the clients DO recieve the layout xml files from the CMS, it is only the media files that attempt to copy (read: create a 0 byte file) but do not download. I would think that there would be other anomolous networking issues if the network were a factor.
I am stumped… only thing I can think of is to upload one of your files and let someone else see if it works on their system. But I am almost certian it would work fine.
The symptom really reminds me of a firewall striping the data from a jpg file. I have seen watchguard firewalls do that.
Well now that the school season has started up sucessfully I can revisit this issue… If I were more WAMP savvy I think I may have solved this problem already. I agree with you it does appear to be stripping the data, but only from the library directory. I feel as though that WAMP must have permission to the folder becuase uploading to the CMS sends complete files. But when the client attempts to GET the files, nothing is transmitted. Could the following be in any way related? ; Whether PHP will read the POST data.
; This option is enabled by default.
; Most likely, you won’t want to disable this option globally. It causes $_POST
; and $_FILES to always be empty; the only way you will be able to read the
; POST data will be through the php://input stream wrapper. This can be useful
; to proxy requests or to process the POST data in a memory efficient fashion.
; http://php.net/enable-post-data-reading
;enable_post_data_reading = Off
It is my assumption that this is the request from a client to download some media from the CMS. I also assumed that the file in the request is some MD5 hash of the file name. So I tried to find that hash in the xibo database but did not find any matches. Could this be the root cause of my issue? Is there anything else I can provide to help figure this out?
It does appear to be a problem is the MD5. The client is requesting an MD5 that does not exist in the sql database, Do any of you have any idea why this would be? Below is an error log snippet from a client. FileAgent_media_Id_37|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Thread alive and Lock Obtained
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Thread Started
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Thread alive and Lock Obtained
RequiredFilesAgentThread|10/3/2016 4:16:47 PM|Info|RequiredFiles - ReportInventory|Reporting Inventory FileAgent_media_Id_37|10/3/2016 4:16:47 PM|Error|FileAgent - Run|Downloaded file failed MD5 check. Calculated [d41d8cd98f00b204e9800998ecf8427e] & XMDS [ 3e5ce4cb098ca820c7d49814f87c17e8] . 37.mp4
FileAgent_media_Id_37|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Releasing Lock
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|FileAgent - Run|File Downloaded Successfully. 14.xlf
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|Schedule - LayoutFileModified|Layout file changed: 14.xlf
FileAgent_layout_Id_14|10/3/2016 4:16:47 PM|Info|FileAgent - Run|Releasing Lock
Are you connecting to the cms with https? Or a proxy? I am wondering if deep packet inspection on a firewall is not the problem. If it is turned on I think that would cause the MD5 check to fail.