Xibo Windows Client 1.4.1 closes unexpectedly

[RLaurette]

Steps to reproduce:
(1) create a new design containing two regions.
(2) set the background to a jpg image.
(3) edit the timeline of each region, setting it to play back two Local Videos each, with the duration of each video set to 0. Note: It may not be necessary to have two regions with two videos each, but that's the configuration I was using when I found this problem.
(4) schedule a client to display this design.

At the set time, the client shows this new design. The background image appears. If the local videos are on the client PC, they playback properly. However, if the local videos are unreachable (e.g. path not found, or file not found), after about 2 minutes 30 seconds, the client software closes unexpectedly, leaving the unit at the Windows desktop.

[Alex Harrington (alexharrington)]

It's your responsibility to ensure the local files are there BEFORE you schedule the layout.

If you don't want to do that, upload the video to the Xibo system and let us handle it.

Alex

[Dan Garner (dangarner)]

The windows client checks that the video is there just before it starts playing it - it would be a small task to move that check to before the video gets in the schedule (put in the call to IsValidLayout). Might be worth doing this just to prevent the force close.

[Bartek (czajka)]

Hi,

Concept of localvideo was that it would be quietly skipped each time when layout is displayed, if there is no file on hdd. It makes possible to remove externally localvideo from hdd after some hour etc, if we're displaying cams views only between 8-20 etc, without touching xibo itself. Layout should still be valid even if there is no localvideos and displayed correctly.
I'm not - if this fix would break this "feature"? :)

[Dan Garner (dangarner)]

Bartek, this would break that feature - thanks for reminding us that local video was different to all other media items. I have reverted the changes and will look for another solution.

[Dan Garner (dangarner)]

Would you accept a compromise?

If the local video is the ONLY item on the layout then it will remove the layout from the schedule if the local video does not exist?

If there are other items on the layout it will leave the layout in the schedule and the local video will be quietly skipped as it currently is?

[Bartek (czajka)]

I sounds like one possible logic solution, if there is no file, there is no sense to display such layout, right?

[Dan Garner (dangarner)]

I think this is the only sensible way to get both requirements... if there is no file then we can skip the layout - but if there is a missing local video and another file, then the layout should play as normal

[Alex Harrington (alexharrington)]

Layout with only two missing files? Or three?

[RLaurette (rlaurette)]

I've retested this using client 1.4.2 & server 1.4.2. Here's what I'm seeing now.

Scenario 1.

Create a layout with 3 regions. For easy reference I'll call them A, B, and C. The timeline in A is a text followed by a different text. The timeline in B is a local video, a text, a different local video, then a different text. The timeline in C is similar to B, but using different local videos.

If all local videos are present on an attached USB flash drive at the moment this layout is scheduled to begin, everything works properly. If someone happens to suddenly remove the USB flash drive, region A is unaffected, and region B or C may freeze, showing a black rectangle if that region was playing back a video at the time. However if region B or C was showing text at the moment the USB flash drive disappeared, the videos assigned to that region will be skipped, and only the text will appear (alternating between that region's two text messages properly.)

If none of the local videos are present at the moment this layout is scheduled to begin. Region A, B, and C show their text only, skipping over any local videos that may have been assigned to them.

Scenario 2.

Create a layout with 3 regions. Again, I'll call them A, B, and C. The timeline in A is a text followed by a different text. The timeline in B is a local video, then a different local video. The timeline in C is similar to B, but using different local videos. (This layout is similar to that in scenario 1, except regions B & C don't have any text.)

As in scenario 1, if all local videos are initially available, playback begins properly, then playing videos are replaced with black rectangles when the USB flash drive is suddenly removed.

However, as with the initial problem I reported, if none of the local videos are present at the moment the layout begins, only the background appears. Regions A, B, and C don't appear. Then, after a few minutes, the client suddenly closes, leaving the PC at the Windows desktop.

Summary.

If regions contain local video only, the client still crashes.

[Dan Garner (dangarner)]

So the only crash scenario that remains is if the local videos were present when the schedule was checked (USB attached) but were not present when the layout actually came into the scheduling window AND only if local video are the only items on the layout AND only if this is the only layout showing?

I think we might have to accept this as a limitation for the time being - exactly the same scenario would occur if your local library was located on the same USB stick and Xibo tried to show a layout with normal stored videos on it. Basically we pre-check that content is available when the schedule changes, and assume that it will remain available during that time.

One possibility for improvement would be to reintroduce the concept of a "black list". This is a list of media and or layouts that the client has determined are not suitable for playback. Once they are blacklisted they will not be played again by the client until the blacklist flag is cleared by the Xibo CMS. This is quite a bit architecture change and would be better tackled as a feature improvement rather than a bug fix.

I hope that all makes sense - please do correct me if my understanding is incorrect.

Thanks,
Dan

[RLaurette (rlaurette)]

The understanding in your first paragraph is not completely correct.

Correct: the local videos were present when the schedule was checked.

Correct: the local videos were not present when the layout came into the scheduling window.

Incorrect: the local videos are not the only items in the layout.
This layout contains three regions.
Two regions contain missing local videos.
One region contains text.

Incorrect: this is not the only layout.
This display has a default layout assigned to it. The default layout does not contain any regions with local videos.
The layout containing the missing local videos is a scheduled layout.

[Dan Garner (dangarner)]

OK - i'm trying to get my head around the various logical tests the client currently performs. The last statement, while true, will have no bearing as the default layout would not be contained in the schedule at that time (unless the interleave default setting was switched on).

The thing that has me confused is that the local videos are not the only items in the layout - this is quite strange.

I wonder if you could try the test again, but with a short text media item (it could even be blank) included in with each of the local video media items? I suspect that this will fix the problem.

I also wonder what would happen if there was more than one scheduled layout at this time, one with local videos missing and one with a simple text item on it.

The reason the client crashes it is ends up in an endless loop trying to find something valid to play - it thinks there should be something valid, because it was valid when it last checked the schedule, but it can't find anything. Putting the valid items in place should give it the "break" it needs and prevent the endless loop.

I hope that made sense - although this is only really confirming 100% what the problem is - rather than a solution. I still think the only solution is to mark the media as invalid the first time it fails (therefore also preventing the endless loop). More thought is required from our end.

[Dan Garner (dangarner)]

I've also moved this around so it is back on the stack for 1.5.0

[RLaurette (rlaurette)]

+-------------------+
| jpg text |
| slide |
| show local |
| area video |
| |
| text text text |
+-------------------+

I've tried to approximate our layout in the above ASCII art. The display is 1920 x 1080. The local video doesn't have large dimensions (maybe 640 x 480 pixels), but it has a long running time (about 22 minutes). It's a promo video supplied by our head office.

Yes, if the regions that contain local video also contain a brief text, the problem doesn't occur. However, we can't be sure that the person who creates the layout in head office will always remember to do this. And, once the problem occurs, it keeps occurring each time the client is manually relaunched, unless we delete the contents of the client's library folder. (Because as soon as it's launched, the client tries to resume the previous layout before it connects back to the server to see if there's a new one.) We want to use this layout on a display in each of our regional offices, some of which are located 1000+ KM away from head office.

If I copy the local videos to only a few clients, but schedule the layout for many clients, some of which doesn't contain the local videos, that won't be a problem? Each client validates that the local videos are present before attempting to display the layout?

[RLaurette (rlaurette)]

(Sorry multiple spaces were reduced to singles. Maybe this is better.)

+------------------+
| @@ jpg @@@ text. |
| @@ slide @ -_-_- |
| @@ show @@ local |
| @@ area @@ video |
| _-_-_-_-_-__-_-_ |
| text..text.text. |
+------------------+

[Dan Garner (dangarner)]

If the local video is never on the client, Xibo won't ever try to show it,
providing it is the only item on the layout. This is why the restart
doesn't work in your case, there are other items on the layout that make it
valid (for Barteks requirements)

I think we have arrived back at the root of the problem, which is that if
xibo tries to show a layout which it thinks is ok, but that layout fails,
we should temporarily quarantine that layout on that display and remove it
from the schedule. Next time there is a schedule update we can decide again
whether it should be in the queue of layouts to play.

This represents quite a bit of work, but i cant see any other quick fix
(aside from using Video instead of Local Video)