Xibo

Damaged cachemanager

Asked by Bartek

Hello guys,

I'm trying to find a reason why windows client sometimes damages cachemanager, that situation leads to crash that was already reported and fixed (crashing when cachemanager damaged)

Please check that log snip:

Jan 18 22:57:20 10.168.65.238 XiboClient[496]: There are 2 files to get
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Getting the file : 327 chunk : 0
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Info: <message>About to Write the Cache Manager</message><method>CacheManager -
 WriteCacheManager</method>
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Get File Completed
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Comparing MD5 of completed download [dfce3bf095f04cb3a050c7961fa0ff1e] with giv
en MD5 [dfce3bf095f04cb3a050c7961fa0ff1e]
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Info: <message>Adding new MD5 to CacheManager</message><method>Add</method>
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Layout file changed
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Schedule - Next Layout: Next layout: C:\Documents and Settings\Default User\Moj
e dokumenty\Xibo Library\327.xlf
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: MainForm - ScheduleChangeEvent: Schedule Changing to C:\Documents and Settings\
Default User\Moje dokumenty\Xibo Library\327.xlf
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Audit: Recording a Stat Record. Current Count = 17
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: MainForm - DestoryLayout: Destroying Layout
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Audit: Recording a Stat Record. Current Count = 18
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: MainForm - DestoryLayout: Calling Dispose Region
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Region - Dispose: Media Disposed by Region
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: HardwareKey: [IN]
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: HardwareKey: [OUT]
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: MainForm - Prepare Layout: Created new region
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Region - SetNextMediaNode: No Valid media nodes to display
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: MainForm - DurationElapsedEvent: Region Elapsed
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: MainForm - DurationElapsedEvent: Region Expired - Next Region.
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: Info: <message>Only 1 layout showing, refreshing it</message><method>Schedule -

Interesting fragment is after:
Jan 18 22:57:20 10.168.65.238 XiboClient[496]: There are 2 files to get
Clients reporting two files to get, downloads only one and crash after switching to just downloaded xlf.
Client loops like there is no media in region, region on server was not empty in reported time, but is very possible that some media items were added just before, on in same time that client crashed (without cleaning timeline).
After that situation cachemanager.xml is empty so there is no way to restart client without xml deletion as we already know.

Question information

Language:
English Edit question
Status:
Solved
For:
Xibo Edit question
Assignee:
No assignee Edit question
Solved by:
Bartek
Solved:
Last query:
Last reply:
Revision history for this message
Bartek (czajka) said : 		#1

One more info:

Two clients that were playing that xlf crashed. Second ona five minutes later that first. Sync interval is 60 secs on those clients.

Revision history for this message
Alex Harrington (alexharrington) said : 		#2

I've been talking with Dan about this. Are you running the released 1.2.0 code (with your logos etc) on that client or is it the 1.2.1 pre-release code base?

Alex

Revision history for this message
Bartek (czajka) said : 		#3

Right now 1.2.0 clients only. Probably that's bug that was crashing my cachedmanager's on random clients earier so i've noticed that it is not possible to start client later without manual intervention.

Revision history for this message
Dan Garner (dangarner) said : 		#4

Hi Bartek... I wonder if you could change 2 things for me?

Firstly on the server, in "lib/service/xmdssoap.class.php" on line 203 - change $SQL .= " ORDER BY RecordType"; to $SQL .= " ORDER BY RecordType DESC";

Secondly on the client, in FileCollector.cs after line 237 add the following:

// Output a list of the files we need to get
string debugMessage = "";

foreach (FileList fileToGet in files)
        debugMessage += string.Format("File: {0}, Type: {1}, MD5: {2}. ", fileToGet.path, fileToGet.type, fileToGet.md5);

Debug.WriteLine(debugMessage);

I think the problem might be solved by the first change - which is that the layout file was being downloaded first - so there is a certainty that a layout will exist without all its media. This should be handled correctly, however clearly something about this situation is causing the media file to never be downloaded. The second change is to provide a little more information should the first change not have an effect.

@Alex - I am pretty sure it doesn't matter to the python client which order the layouts/media appear in RF?

Revision history for this message
Alex Harrington (alexharrington) said : 		#5

Nope. It doesn't care.

Revision history for this message
Bartek (czajka) said : 		#6

Hello,

I've just added DESC in server.
I'm afraid adding something into client is much more complex problem :) I'll add that line in next client update iteration, probably one of next two weekends.
If some client would crash since then i'll let you know.