This is interesting - 1.7.8 has stalled out after just 2 1/2 hours, but there are no pop-ups on the screen. It just isn’t running. Watchdog has not stepped in and restarted the player because it is, technically, still running, though the media is not updating. I played with it a little, locking the screen (Win + L) and unlocking it, but that simply made the screen all black, no media at all, and it still didn’t restart.
Edit: I was dragged away before I could mess with the stalled player, so it sat for about an hour, and nothing changed. I then clicked a random place on the screen (can’t see the mouse, didn’t enable that for this layout), and the following pop-up showed up:
It seems that it is not completely disabled, but rather is suppressed. I’m not sure if that is correct, or helpful, but I thought I would let you know.
< / edit >
The simple layout is still running well at this point. I will not add anything to it until Monday, after which we should know for sure if memory will be a problem with it. Would you like me to upload this layout after each change so you can monitor what I’m doing with it?
So its showing something, but not responsive and not moving through its layouts… and yet it has not crashed either… very odd. It is difficult to imagine what is causing that, although I think we can safely assume its an artefact of the PC not having any free memory.
That is annoying - I am quite sure we are doing all the correct things to disable that error reporting… although it may well be this particular error is something that cannot be disabled.
That is good - so it looks like something related to IE with your more advanced content. It would be useful to see exports of the layout during each change in complexity.
I will continue to monitor this one for at least a day, and will report back once I have determined how it runs. If you have any preferred testing, please don’t hesitate to let me know, and I will certainly add it in.
I am imagining that you are slowly rebuilding your original layout, until you reach a point where the problem item is identified. Once we have that, we can create a layout with only that item on it and see if memory still leaks.
My apologies for the delay; I have been swamped with several other projects lately.
The third iteration of the simple layout has been running for several days with no problems, so I have added another set of switching images to it, and the link to that exported layout is here:
As before, I will continue to monitor. Should this run well, I will set up a layout that has nothing but the external content on it, and test that, as the next step.
So I think the theory that an item of your external content is causing the memory issues is a fairly strong bet. Of course, finding which one is the difficult bit
Ok, the fourth iteration is running fine after nearly 24 hours. I believe that I agree that the finger needs to point at the web content I was trying to display. Now to get just that content running with nothing else and see what happens. As before, here is the new layout:
I have switched over to this layout, and will monitor over the day, possibly over the weekend, depending on how it runs.
Edit before posting:
I noted that, with the above layout containing a much larger area from the initial webpage, there was a pop-up almost immediately. I have pop-ups disabled in Internet Options for IE 11, but it doesn’t seem to affect the player.
Thoughts/questions:
Is it possible that this is the cause of the memory leaks?
If so, is it possible to get Xibo to also block pop-ups?
I am going to install AdBlocker+ and a third party pop-up blocker (if I can find one) on this computer in an effort to control some of this, but I suspect that these will only affect IE, not the IE engine used by Xibo. Is this correct, or will they possibly help?
I also think I need to narrow the scope of the display to what I was using in my initial layout. I will play with all of this for a bit and report back once again after I see how things appear to be reacting.
Adblocker is not helping within the player. I think I’m not surprised by this. So, the last posted layout is running, and I’ll monitor it for a while to see what happens.
OOM happened in less than 30 minutes with the latest layout, as well. I need to come up with a better option to display the weather on an hourly basis.
I have indeed attempted to utilize the forcast.io widget, but it only displays daily weather, and we need to find a way to display hourly weather, as this is for a company that delivers propane locally, and this will help them as they come and go throughout the day.
Is there a better way to accomplish this than what I have been trying?
Edit: I tried to use weather.com once before, but was still new enough at using Xibo that I was not successful in getting the hourly weather out of it. I am now more familiar with setting up the layout, and appear to have been able to get the hourly data I require. I have the following layout running now, and I am not seeing the immediate guzzling of memory that the previous one was having:
There was a very slight rise in memory usage when I first started the player with that layout, but it leveled off almost immediately and appears to be staying fairly steady.
As always, I will monitor this and keep everyone updated with my findings.
Ok, memory usage is continuing to climb with this layout, as well, albeit a bit slower. It is now up to 1.2 GB and continuing to climb. I suspect this will OOM, as well.
Looking for other possibilities for hourly weather…
Some good detective work there - i’m pleased it has turned out to be something external to Xibo. It would be nice if that were something we could control, but unfortunately I already know we cannot.
I suppose we could develop an addition to the watchdog application to check for extreme memory usage, which results in cycling the player (killing and re-opening). That might be an interesting feature to have for the future.
The forecast data we use does return hourly information, its just that we haven’t developed an interface to it as yet. One option might be to look at enhancing the forecast module to include hourly data. I appreciate that is a longer term thing.
The only other suggestion i have is to look for an alternative source of weather
It took a little over 24 hours on that one, but it still crashed.
I am going to need to explore other options for the weather output I need until such time as you have the hourly data integrated into the Forecast IO module.
I attempted that via Windows Task Scheduler, but the problem is that the web content causes the player to crash within a couple of hours at the longest, so a nightly reboot didn’t help. I tried to get an hourly restart of the player to help, but couldn’t make that work, probably due to lack of knowledge, but Windows doesn’t play nice with cron like my beloved Linux does.
As a side note, I talked to my brother, who is an active programmer (currently working as an Open Stack engineer). His assessment of the most likely cause for the crash on web content seems to agree with your own - he is convinced that the memory leak exists within the javascript being used by the weather display portions of the websites I have been using. I don’t have experience with javascript like he does, but my limited knowledge of java leads me to agree. However, that doesn’t resolve my problem of needing hourly weather content displayed.
To be honest, I finally found and implemented Xibo version 1.5.2 server and player yesterday afternoon (I also have a complete collection of all versions). I set up the web content only, and it has been running for > 15 hours with no rise in memory usage. It has been steady on 1GB of memory the entire time. That makes me wonder at the difference between the versions, but I won’t complain.
If anyone else needs to display web content that causes the new player to crash, 1.5.2 appears to handle it nicely. Perhaps this new revelation will help to understand why the new version crashes so consistently.
I will continue to test via 1.5.2, but have to leave the office (possibly for the entire day), so this new test will sit and run for a while longer, still.
After more than 36 hours of successful running with no rise in memory usage, I am going to alter this and start using the preferred web content, which comes from the following URL:
I’m not sure if it’s still relevant or not, but I will continue to report on my findings.
