Replacing media in a layout or interrupted downloads cause media to be played before downloads are completed

Someone else reported something similar to this but hasn't come back with any information on it and Dan and I have been unable to reproduce it - their report concerned a video.

What's happening is for some reason the client thinks it has that file downloaded already - otherwise it wouldn't attempt to load that layout at all.

Are you certain this client has never downloaded that file before and then you deleted it from the local library? The client keeps a cache of which files it's downloaded and their checksums to speed up startup and prevent continual checksumming of things like large video files. If the client sees that it's downloaded that presentation successfully once, then it will always expect it to be there. If you then delete that file from under the client, the next time it sees a layout with that media item in, it will consult it's cache and see that it has downloaded the file and so it should already be in the library.

Is that possible in your case?

Alex

Also in general when it's not clear that this is a bug from the outset, we prefer people post in Launchpad Answers where we can work through and isolate the problem. When it's clear it is a bug, we can very easily pull the whole thread through here to bugs and target as appropriate.

Cheers

Alex

What I have been doing is making a slight change in the powerpoint file and then loading it into the layout. But I would assuem the checksum has changes.

I have never deleted any files from the client.

Uploading a new version of a file is essentially the same as uploading a whole new file. The new version gets a new ID and assuming it's different a new checksum.

I'll try and set aside some time to look at trying to replicating this again.

Cheers

Alex

My first test on trying to figure this out is as follows:

New 1.0.7 client against 1.2.0-rc1 server. I uploaded Big Buck Bunny 720p video (312MB) and created a layout with two regions. The first region has the video, duration 0. The second region has some text in it duration 20 seconds.

When I start the client, the client correctly holds at the splash screen while the file downloads. Once the file is downloaded the layout began playing correctly.

So it looks like Bartek's test is more accurate - are we actually seeing a bug where downloads are dropped part way through causing problems? I'll try Barktek's test next, but I can't make the client try and play a layout without the media assuming the download goes OK - which was the original complaint in this bug report.

Alex

Another quick test. Again on a fresh client, I started the same layout downloading, then after 10MB or so quit the client. I then started the client up again and the client correctly detected the video was not complete, deleted it and started downloading again. All the time the client correctly holds on the splash screen.

If I then take the same setup, remove the video from the region and put some text in, then run the client and allow it to begin running that video, then remove the text and add in the video, the video does begin playing before the file has completed download.

Theory:
Schedule.cs line 322 needs a check before it to ensure all media for that layout is downloaded correctly.

Or actually maybe even better in MainForm.cs line 153.

That seems quite odd... before each media item is played a check against the
cache manager is done to ensure that media is downloaded and complete.

So the question for me is how does a partially downloaded file get in the
Cachemanager?

Maybe excepion catch caused to skip cachemanager check im my example?

I've made similar test two times, first file damage without exception was detected correcty, in second pass, when exception was raised check was skipped and playback started immedialety.

So when an exception occurs in the GetFile methods we aren't correctly
removing the media from the CacheManager. That would certainly explain it.

I have this problem too. What I do when it occurs is to acess the client and delete the file so that new upload is done, or else I remotely access client, I save the original file in the media folder, and rename putting the same name that gave Xibo it (1.wmw, for example).

Fix for this is now in lp:xibo for those who want to have a test before 1.2.0-rc2 is released.

Note that we've incremented the webservice schema number with this client, so it won't run against existing Xibo servers. If you're rolling your own client just for testing you can change the "Version" setting back to 1 and the client will connect OK.

Once you're in production with this then clearly we recommend 1.2.0-rc2 client and server and later paired so the versions available from us will be compatible at that point.