PDA

View Full Version : LiveText Crashing - Memory Hog



dmchugh23
05-04-2015, 10:50 AM
I am curious if anyone is experiencing more crashing from LiveText recently, especially after the upgrade to 2.75. I have experienced it crashing on all computers I use. It seems it is hogging a lot more RAM than it used to - or at least it seemed to use. Or it is hogging a ton of memory when it isn't performing properly. One computer has 16GB RAM with a high-performance processor and it will crash often. You can imagine what it's doing on lower end computers.

On one computer I uninstalled 2.75 and reinstalled 2.73 and it still crashed.

The most common moments it's crashing are either when loading/opening a file or when putting one of the items "live."

Now, we do use a lot of logos and graphics in our scoreboards and look... but this is the first time we have been suffering from so many crashes... to the point it has become unreliable during games. On one of the computers it is crashing the most (i7 chip with 2.5+ GHZ and 4.0 GB RAM), I have cleared it temporary files, reduced how many programs are starting up, etc.

Anyone with any advice would be appreciated as we have some major events coming up and we need reliability.

Thank you.

kanep
05-04-2015, 11:14 AM
How many titles you do have loaded into LiveText? Do they each contain graphics? Multiple graphics per title?

Everytime a graphic is used, you can't look at how big the file is on your hard drive, but what it expands to when it is decompressed into RAM. This usually around 6MB of RAM per HD image (what Photoshop says the memory usage is when loaded).

If you end up with lots of titles, each with images on it, then you can quickly see how memory gets used up. This happens for each page, so the same graphic on 10 pages will use up 10 times the RAM.

Also, LiveText is a 32-bit application, no matter how much memory your computer has, 32-bit applications can only access 2GB of RAM.

One thing that can help, is to make sure only the 'active' parts of images are saved. For example, if you are creating a lower third graphics, don't save the entire 1920x1080 frame, even though 85% of the image is alpha channel, it still uses up tons of memory, if you only save the lower third graphics itself (the 15% that you see), it will use a lot less memory.

Perhaps this is your issue, perhaps it isn't. I've had other people run into similar issues and it is usually the above that is using up RAM.

dmchugh23
05-05-2015, 09:29 AM
We have a number of titles... the project coming up has at least 66. We do a full TV-style production for college sports using Daktronics All-Sport CG to pull in all kinds of great information from the scoreboard. We also use text files for additional information. We have a pre-game, halftime, and post-game shows that need graphics both in a lower-third format (in-game live scoreboard) and fullscreen (stats, player profiles, etc.).

I can see how memory can build up, but there are two challenges:
- upgrading to 2.75 was the first time we started experiencing consistent and across the board crashes of LiveText. We may get a couple here and there in the past, but not consistently like this.
- how can I do anything but save how LiveText is saving the project. How do you mean "active" parts of the image.

I suspect this is easier than I think it is ... but it isn't making any sense, either.

kanep
05-05-2015, 08:02 PM
What I mean by the 'active' part is shown in the attach picture.

If you look at the red border (at the edge of the screen), this represents a graphic that is an entire HD frame, even though all you need is the lower third title at the bottom. Most of this image is empty space, but there is still a Red/Green/Blue and Alpha values for each and every pixel, so it using a lot of RAM.

If you look at the green border, you can see it is just around the lower third title at the bottom of the screen. If you where to crop the graphic to just that, then you remove all of the transparent area from the source graphics. The result is a smaller graphic using less memory.

128152