Thank you very much Dan,
Highly Appreciated…
Will let you know the results…
1 Like
Hi dan, Just noticed the below error while editing the update interval on the layout ticker from 120 to 2 minutes,
hope nothing serious.
ob_end_flush(): failed to delete and flush buffer. No buffer to delete or flush
8
Notice
C:\xampp\htdocs\xibo\lib\data\layout.data.class.php
1926
thanks
That isn’t a problem (it is expected in some circumstances) and actually happened when you exported a layout.
Just stumbled upon this thread as i had my Nth call today about locked up 1.7.7 clients. I’m late to the party so I don’t have the testing done like irfan or Jasmina but the symptoms I have been having are exactly the same. Was on 1.6.1 and rock solid. Built new CMS on 1.7.7 upgraded the clients and connected them to the new server. Ever since they lock up, totally randomly, sometimes hourly, sometimes daily, sometimes weekly. And they freeze hard. Reboot scripts dont run plus RDP, MS Remote Control, and VNC all will not connect in the locked state so they stay froze until the box is hard reset. Edit: can still connect remotely to the file system to check logs however my new 1.7.7 server has the logging disabled as i am only seeing logs from the 1.6.1 days. Grrr, But this shows that it is not locking more like stalling windows. Some things still work, unfortunately nothing that can be used to kick start the client again does.
Glad to see this thread as I hope you guys can fix this for the next release. Would be happy to test as well now that I am here.
Very happy for you to run some tests too, but it does sound to me like you have a different problem. In the OP’s case the word “freeze” is perhaps not the correct word. The player is still running and responsive to user interaction (for example you can open the info window, etc).
It sounds like in your case the UI has hard locked - for RDC/VNC to be locked you’d be looking at something in Windows locking rather than something in the Xibo executable (not saying it isn’t being caused by Xibo).
If my above suspicious are correct, then we should discuss on another topic (just hit reply as linked topic to the right of this message) - my first instinct would be to check the disk usage on the player. Xibo may have eaten it all which caused windows to become unstable.
Thanks for your time and effort Dan regarding this issue, I’m surprised there are no more reports of this since I see many people talking about running Intel Compute sticks and such, which are very similar HW to our clients.
Anyhow, to answer Irfan, yes we were (and are) running the maintenance script all along, from cron every 5 minutes; our CMS is Debian based.
We continue to have this happen to several (one or two, each time different) clients approximately once per day, and as suspected running the “result” filter did not catch anything due to the mentioned filter column drop/timing “problem” with the process monitor.
We will definitely implement your modified client with Handle tie-in on a couple of machines but I’d like to wait out the current setup with our test client (it’s bound to crash sooner or later :)). Filtering by [PATH contains XLF] is accumulating a manageable amount of real-time data and clearing the log once or twice a day (assuming no “crash”) is not problematic, and this will definitely catch the offender since we’re logging everything before and after the event (you’re right that saying “crash” or “freeze” may be slightly misleading as to what we’re talking about in this case).
I have no doubt that you know exactly what you’re doing but I’m slightly concerned that calling Handle after the Xibo client has already logged the error may miss the problem event if the lock is indeed some split-second thing?
Also I think we should keep in mind that either Irfans registry tweak and/or our setup of folder options regarding thumbnails have UNDOUBTEDLY reduced the frequency at which the problem occurs.
We’ll report back as soon as there’s any results.
We will definitely be adding that fact to the manual - and if at all possible as a checkbox option in the installer. I’ve added a 
report so I don’t forget.
I was worried about that too - hence the disclaimer 
- I’ve executed handle as soon after the IOException as I possibly can… if that doesn’t catch it, then it might be as simple as a quick retry loop to open the file.
I appreciate you want to wait for the error to occur with your other test set up - I do actually think it will produce better results, although you obviously have to look at it more frequently to detect it.
And thanks for your patience and your own investigation - it is excellent to have someone (both of you actually), willing to do some serious debugging 
Good Morning Dan and Jasmina,
Yep the same error has popped up in my environment, this time with the expected error result as Dan was looking for as below… i hope this would help to get there and resolve the issue… and this is the only issue i’m having which is not allowing me to run the services 24/7 as expected…
one more thing i have noticed this error dosent loggged on the CMS until the xibo player have been restarted…
thanks Dan / Jasmina
9 16-05-26 08:34:16 TRD-SP-SMIT-04 Client [UI Thread] MainForm -
ChangeToNextLayout Layout Change to C:\Xibo Library\32.xlf failed. Exception
raised was: The process cannot access the file 'C:\Xibo Library\32.xlf' because
it is being used by another process.
8 16-05-26 08:34:16 TRD-SP-SMIT-04 Client [UI Thread] MainForm -
ChangeToNextLayout Prepare Layout Failed. Exception raised was: The process
cannot access the file 'C:\Xibo Library\32.xlf' because it is being used by
another process.
7 16-05-26 08:34:16 TRD-SP-SMIT-04 Client [UI Thread] MainForm - PrepareLayout
Handle Output: Handle v4.0Copyright (C) 1997-2014 Mark RussinovichSysinternals -
www.sysinternals.comusage: handle [[-a [-l]] [-u] | [-c <handle> [-y]] | [-s]]
[-p <process>|<pid>] [name] -a Dump all handle information. -l Just show
pagefile-backed section handles. -c Closes the specified handle (interpreted as
a hexadecimal number). You must specify the process by its PID. WARNING: Closing
handles can cause application or system instability. -y Don't prompt for close
handle confirmation. -s Print count of each type of handle open. -u Show the
owning user name when searching for handles. -p Dump handles belonging to
process (partial name accepted). name Search for handles to objects with <name>
(fragment accepted).No arguments will dump all file references.
6 16-05-26 08:34:16 TRD-SP-SMIT-04 Client [UI Thread] MainForm - PrepareLayout
IOException: System.IO.IOException: The process cannot access the file 'C:\Xibo
Library\32.xlf' because it is being used by another process. at
System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at
System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32
rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions
options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy,
Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String
path, FileMode mode, FileAccess access, FileShare share) at
System.IO.File.Open(String path, FileMode mode, FileAccess access, FileShare
share) at XiboClient.MainForm.PrepareLayout(String layoutPath) in
c:\Users\dan\www\xibo-dotnetclient\MainForm.cs:line 553
5 16-05-26 07:59:48 TRD-SP-SMIT-07 Client [UI Thread] MainForm -
ChangeToNextLayout Layout Change to C:\Xibo Library\35.xlf failed. Exception
raised was: The process cannot access the file 'C:\Xibo Library\35.xlf' because
it is being used by another process.
4 16-05-26 07:59:48 TRD-SP-SMIT-07 Client [UI Thread] MainForm -
ChangeToNextLayout Prepare Layout Failed. Exception raised was: The process
cannot access the file 'C:\Xibo Library\35.xlf' because it is being used by
another process.
3 16-05-26 07:59:48 TRD-SP-SMIT-07 Client [UI Thread] MainForm - PrepareLayout
Handle Output: Handle v4.0Copyright (C) 1997-2014 Mark RussinovichSysinternals -
www.sysinternals.comusage: handle [[-a [-l]] [-u] | [-c <handle> [-y]] | [-s]]
[-p <process>|<pid>] [name] -a Dump all handle information. -l Just show
pagefile-backed section handles. -c Closes the specified handle (interpreted as
a hexadecimal number). You must specify the process by its PID. WARNING: Closing
handles can cause application or system instability. -y Don't prompt for close
handle confirmation. -s Print count of each type of handle open. -u Show the
owning user name when searching for handles. -p Dump handles belonging to
process (partial name accepted). name Search for handles to objects with <name>
(fragment accepted).No arguments will dump all file references.
2 16-05-26 07:59:48 TRD-SP-SMIT-07 Client [UI Thread] MainForm - PrepareLayout
IOException: System.IO.IOException: The process cannot access the file 'C:\Xibo
Library\35.xlf' because it is being used by another process. at
System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at
System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32
rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions
options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy,
Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String
path, FileMode mode, FileAccess access, FileShare share) at
System.IO.File.Open(String path, FileMode mode, FileAccess access, FileShare
share) at XiboClient.MainForm.PrepareLayout(String layoutPath) in
c:\Users\dan\www\xibo-dotnetclient\MainForm.cs:line 553
1 16-05-22 08:47:41 TRD-WS-IT-04 Client [LibraryAgent] LibraryAgent - Run
Exception in Run: The process cannot access the file 'C:\Xibo
Library\stats.xml_131081078169868325' because it is being used by another
process.
That is normal during a crash - the shut down code won’t be called so the logs won’t be sent before the application ends.
Unfortunately the call to handle.exe didn’t work, which is a real shame. It is printing out usage instructions, which implies that it doesn’t understand a command switch that I’ve passed in. My guess is that the file path needs quoting.
I’ve done that and will provide a new XiboClient.exe for you to try again in the PM.
It is also interesting that stats.xml_131081078169868325 was also locked! I am sure there is something else locking your files now
Thanks Dan, for the feedback… will wait for the new exe, just is it ok to install it over the existing one or do i need to uninstall the previous version.
as i noticed that if you install over it in the watchdog folder it leaves x68 folder i believe it was a mistake in v1.7.7
It will be a single file that you copy over the top and restart the player.
No mistake, someone wanted a 64 bit watchdog.
i see… 
thanks
downloaded the exe… will let you know the result as soon as it happens…
1 Like
Dear Dan, since past 3 hours i have not yet face the error,
however as soon as i replaced new .exe, one of the players gave the below error, and after that player restart was done, since then no errors encountered…
i’m keeping it under observation…
i hope the below error is useful in finding the error source…
once again thank you.
@ Jasmina, FYI i close the process monitor, as now the new new exe that Dan has uploaded is capable of finding the locked file…
Interesting - that would imply that even though Handle was executed immediately on error, it couldn’t find anything locking that file which was previously locked.
Lets see if you get any “hits” next time or if Jasmina finds something with process monitor.
Maybe i went a bit too in depth and gave you the wrong idea. The ui can still be interacted with. Here are the logs from when the player freezes:
UI Thread|5/26/2016 1:27:07 PM|Error|MainForm - ChangeToNextLayout|Prepare Layout Failed. Exception raised was: The process cannot access the file ‘C:\Users\signs\Documents\Xibo Library\38.xlf’ because it is being used by another process.
UI Thread|5/26/2016 1:27:10 PM|Error|MainForm - ChangeToNextLayout|Layout Change to C:\Users\signs\Documents\Xibo Library\38.xlf failed. Exception raised was: The process cannot access the file ‘C:\Users\signs\Documents\Xibo Library\38.xlf’ because it is being used by another process.
So throwing my hat in the ring for the exact same problem.
The good news: we got tired of waiting for test to crash, so we ran the process monitor on 6 more production clients, and we (finally) caught it!
The bad news: as far as we can tell, it seems to be the Xibo client?
The only thing process monitor (running the “PATH contains XLF” filter) caught was indeed a “SHARING VIOLATION” and no other process is accessing XLF files at any time before or after the event.
We’ve trimmed and exported the logs for the time period around the crash and will PM you the file in .PML format (that can be opened and explored with the Sysinternals process monitor itself). If you’d like the .CSV or .XML please let us know (XML is really large though).
Dear All
A Very Good Morning to u all…
Dan, after running the new exe for over 24 hrs, below is the log from one of the players, and one of the player constantly sending the memory error all the night,
hope this error description fro the handle.exe is worth it…
OK great, thanks. I’ll add you to the PM with the MSI when I have a new one to try.
Yes, this does look like bad news - you didn’t mention the actual time of the locked file message? I assume it coincides with the sharing violation at 6:45:21?
Nope, sorry. I think the handle experiment can be considered a failure - handle is saying that there isn’t anything locking the file immediately after the message occurs, which must mean that the lock time is very short indeed.
I just want to go back to first principles - when we were first discussing this issue you both indicated that you would get this error message repeating over and over, leading to the player never showing the next layout. (maybe this was my assumption)
When Xibo fails to load a layout, it will try the next one in the schedule. If there isn’t another one it will try the default layout, if that isn’t available it will load the splash screen. Once it has a layout loaded and then that expires, it will try again with the layouts in its expected schedule.
Hence the message repeating over and over.
Is that still happening? In your logs irfan there is a big gap between the instances of the error message? The same sounds true in your case Jasmina - after the sharing violation the exact same file goes on the be successfully accessed many times.
If it does indeed recover itself when the layout reloads, then I think a quick retry loop would be sufficient to solve the issue. This is backed up by handle not showing any current “handles” in ifran’s test.
Yes, the client reports the error at the same moment sharing violation occurs, and no the error would actually NOT repeat in the client logs, it would show up once, and really only by looking at the display can you tell that something is wrong.
To summarize: the offending layout is indeed always the NEXT one in sequence and not the one on which the display stops, if there is a region on the current layout it will time out and disapear, leaving only the background image, if it is an image only layout, it will just show that indefinitely (until something is added to the schedule, priority slide comes up, or the client is restarted).
Not sure if it helps (or if it is indeed the universal case) but if you look at the PML log carefully, we noticed that the process sequence for the layouts is always create file/close file, with read and network query and other processes, thrown in there at the appropriate times, except at the instance sharing violation occurs.
So maybe the error itself is not the sharing violation but rather the lack of “close file” for XLF at that time (150 in this case). You can see the processes starting at 7:45:21 (or rather 6 by your time-zone) for XLF 150, the sequence is: create, query network…, close, create, query network…, close, CREATE, query standard…, read, CREATE; and that’s when the sharing violation occurs.
I cannot locate another place in the log where the same xlf is being created twice, without being closed in the meantime. As I said, not sure if it helps, just noticing
OK, so the first thing to try and solve is why it gets stuck…
I’ve been working under the impression that something is locking the file and then keeping it locked each time Xibo tries to run the layout. However it seems more likely that it gets locked once as a one off and Xibo never tries to advance to the next layout as a result.
I’ll look into that first