Player Version
xibo-dotnetclient-4R403
Issue
I have a playlist with two videos of each 2 minutes long. So the playlist length is 4 minutes total. The playlist is looping itself.
Whenever the playlist ends or every 2 minutes, there is a black screen for a second or two.
Does anyone know how to prevent this black screen? It really breaks up the watching ‘experience’, and it looks like a glitch for customers. Perhaps I am doing something wrong.
I looked around and I could not find anyone with a similair setup and problem.
I just want 1 video to be looping forever without a black screen between the looping.
Do you experience a 1-2 second black screen with every layout change? Are your transitions disabled? In my experience, this happens when the player is too weak for the respective video material. It could be due to a slow processor, a slow hard drive, or the video being large with a high bitrate. Short black screens are normal though… If you pay attention, you notice them
No its really only with a video file. With smaller sized video’s its a shorter black screen. Its strange because with a videoplayer like VLC it just starts again with no black screen whatsoever.
As a quick hardware-level workaround, you could try splitting the two videos into smaller segments (if possible, though it might not be). Alternatively, reducing the bitrate (and possibly the FPS) could help lower the overhead of loading and encoding the video every two minutes.
For that, I recommend using HandBrake. I’d optimize every media file for Xibo using this tool.
On the software side, there may be others who can suggest a fix. Instead of looping the entire layout, use just one layout and add the videos in sub-playlists, or use Xibo’s overlay module to add the new video on top?
I tried a windows player instance on my PC which has 32gb ram a ryzen 9 5900x 12 core(12x 3.70 ghz). And a 3080 video card.
So what I tried was; the playlist with the 200 mb video; it gave similar black screen time
I also made a layout containing 4 video widgets with a quater of the video, so lets say 50 mb each; it gave the same black screen time.
Isn’t there a loop function in the player so that it stores the video in ram in case the video needs to be played again; thus preventing that the entire video file has to be loaded again resulting in this ugly black screen time?
By all means Xibo is amazing, but having a 2 second black screen on a menuboard inside a fastfood joint is far from ideal. Imagine you deciding on what to get and the screen goes black for 2 seconds. How annoying.
Oh, my bad for the unclear explanation. There’s a CacheManager for MediaElements, Layouts and similar components. Your video won’t reload from storage to RAM every 2 minutes if, for example, you’ve marked it as loopable – it will just repeat.
However, I’m not entirely sure how this works with two videos in a single layout. My guess is that after 4 minutes, once both videos have played and the layout is scheduled to repeat, all MediaElements/Videos might be cleared from the cache. I’d need to check the repo to give you a definite answer, but I’m currently tied up with other tasks.
Maybe Dan can chime in with a more detailed response 
(By the way, you could check this yourself by monitoring the Task Manager or Resource Monitor in Windows and watching for any disk I/O activity after the layout finishes.)
OT
I actually have the same use-case – MenuBoards for well-known fast food chains / stores (the one with the M or D), running on clients with comparatively low computing power (Quad-core @1.45GHz, 4GB RAM, 2GB VRAM). It runs without noticeable black screens, but I’m on WSE7 with a custom Windows Forms Xibo Client (v2 R202) specifically modified for that blackscreen and memory leak issue.
Have you thought about revisiting a few sections of the manual? It might just lead you to a setup that eliminates that blackscreens. For instance, you can check out your Transitions—try adjusting the default duration to 0 in the CMS Settings. Additionally, consider the difference between scheduling Playlists and Layouts for your displays.
Thank you for your detailed answer. The help is really appreciated.
If what you say is correct, about the cachemanager, then this is either a very silly bug or design flaw. I can’t imagine any professional use of this current setup with those two black seconds when a 2 min video loops.
I looked in taskmanager what the xibo client process uses on disk, and when its playing the video it shows a usage around 1-2 MB/s. When it loops the video it goes to 3 MB/s and after that back to around 1-2 MB/s
- Even with one video in a playlist, the black screen comes up when it needs to loop.
- I changed the default transition time; unfortunately that didn’t make a difference
- I already had tried a playlist with two and one video, and a layout; both still gave me the black two seconds when it loops.
Is it that I am the only person who uses Xibo to loop a video? Or am I the only person experiencing this black screen issue?
So I just tried it on my Android player running R312. 3min@1080p, VBR ~10Mbps, x264, 222MB. I was actually expecting to see the same thing as you described, as I’ve noticed complete reloads of content with other widgets, such as the Website widget, but after the video ended it went right back to the beginning with no pause at all.
Maybe this is a Windows only bug and not relevant for Android players?
Hey, thanks for your testing! Well thats interesting, and yeah with your results it makes me think that it is some kind of bug.
I don’t wanna ring the bell for nothing and be bothersome, but @dan could I ask for your expertise on the issue I’m having? Do you perhaps know where its going wrong for me?
On Windows the media player closes after the end of the video. The starting point of blackscreen is opening mediaplayer.
On android, it is using the buildin player which is likely always active.
If this is the case then the Windows player is not that useful for professional use. Do you know a workaround for this flaw in the Windows player?
I have this same problem too running a Xibo 4.1.0 system and Windows 11 clients running xibo-client-v4-R403.1. It happens on any machine type I’ve been using, powerful or not. None of my displays are mission critical, so I’ve just ignored it and thought maybe it was normal.
What I can’t work through, however, is the stuttering/freezing video playback with whatever video rendering engine Xibo is using to play MP4s. I cannot get it to play a video correctly. The solution? Upload my 4K video to YouTube and play it back from there. Flawless and perfect then.
I’ll experiment with different settings and configurations to see if I can get rid of the black screen in between videos or at the end of my looping playlists and will report back.
I am not experiencing stuttering/freezing with video playback, do you use big video files?
Thanks, I am curious what you’ll come across! I tried several setups but none got rid of the black screen.
For stutter and freezing problem you could try the k-lite codec pack. WMP will pick up the codecs and use it for playback. It could go alot smoother for decoding on GPU or use more CPU but not recommended. Using Handbrake (explained in the xibo manual) will give you the best practice in how to re-encode the MP4 for best playback.
For the player delayed start, there is no simple solution which involves changes or behavior of wmp. You could use the transition part with a fade so the player starts earlier with opening wmp and load your MP4.
I would recommend to use the Xibo Android DSCS9X. We have a few customer still running on Windows, they were testing it for us and kept the device. We were also using clips but after a few weeks we changed it to a Youtube playlist. The same clips they want to play in the showroom also appears on Youtube. Another customer is using the interactive functionality because we integrated an alarm system with a panicbutton. It is easier to tell xibo on windows to trigger a layer without internet. Our solutions keeps working even if there is no connection to the CMS/XMR.
As a test, I setup a new Xibo 4.1 server and v4-R403.1 Windows client. My 4K files are about 200 to 500MBs in size, play for 1 to 3 minutes, and are encoded with a total bitrate of 2.5MBs/second. What I see happening is the video seems to pause on the last frame of the video for about a half second, shows a black screen for about 1 second, and then begins playing the next video. I’m going to check my older Xibo 2.3 system and v2-R201 Windows client to compare and see if there is any difference.
Also, I’ll experiment with using HLS and making m3u8 playlists to see if there would be any change in the transition between videos. I’ll let you know what I find!
Thanks Vishal. I saw a post you made on a similar topic awhile back and gave the k-lite codec pack a try, but didn’t see any improvement. I may give it a try again and hack around a bit more. I’ll also “go back to the drawing board” and redo my exports out of Adobe Premiere, as that is the source of my footage. Maybe I could improve something there or messed something up.
I’ll also take a peek at the Android DSCS9X. Wonder if I could imitate the functionality using a laptop and load a Linux distro? I’m intrigued by the idea of an Android player.
@Steven2919 - I don’t mean to hijack your post! I’ll do what I can to help you out. Thanks for confirming you haven’t seen stuttering issues with your videos.
Whoops, I meant Android distro, like LineageOS.
Using the same Windows client PC and switching to Xibo 2.3 server, I was able to get rid of the half-second pause that occurred on the last frame of each video. The black screen between videos went down to about a half-second as well.
Using HLS on Xibo 2.3 server gave the same results with the same video playlist. No pause on the last frame and a half-second black screen between videos.
I can’t get the HLS widget to play anything on Xibo 4.1 server, to compare. I’m using the same stream server (basic Python web server) and same m3u8 playlists used on Xibo 2.3. In the Python logs I see the Xibo client kicking off the m3u8 file, but doesn’t load the TS files afterwards, which the playlist points to.