Recent changes to bugs

#232 Trying to run lives within a docker container

ovizii — Wed, 04 Aug 2021 06:50:07 -0000

thanks for pointing me in the right direction.

#232 Trying to run lives within a docker container

Salsaman — Wed, 04 Aug 2021 00:34:24 -0000

H, the current bugtracker can be found at https://github.com/salsaman/LiVES/issues
You are welcome to repost there.

#232 Trying to run lives within a docker container

ovizii — Tue, 03 Aug 2021 09:25:46 -0000

it looks like the screenshot disappeared. :-( The text was along the lines of "lives cannot write to and make sure you have write access to (null)

If anyone is interested to help I can share my Dockerfile as well as my docker-compose.yml

Trying to run lives within a docker container

ovizii — Tue, 03 Aug 2021 08:53:51 -0000

Hi there,

I am trying to get lives running inside a docker container and am getting a random error message. Does this look like its coming from lives or from my botched attempt at accessing it via VNC?

#228 Clean up Diskspace amok run in 2.10.2

Salsaman — Tue, 14 Jan 2020 12:13:02 -0000

Hi Guenter, I'm not sure if you are still monitoring this, but the current git version of LiVES has even more extensive safeguards to try to ensure nothing like this ever happens again.

If you recall, the root of the problem was that your config file was damaged, leading to the program unfortunately falling back to its default working directory, without prompting for it to be set.

Here is a summary of the safeguards in the upcoming release.
Firstly, on startup, the program will check for an existing config file. If this is not present, then it will attempt to recover from the backup config file, as I will explain shortly. Next, if the config file is there we try to read the version string from it. If this is not present the we assume the file is corrupt and it is renamed (for later forensics if needed). In this case we then retry the same procedure with the backup config file.

If we got a version string from the config or backup config, then the next step is to try to retrieve the working directory. If this succeeds then we assume all is OK and do a normal startup, althought the user is informed if recovery was made from the backup config file.

If a version string or a working directory string are not present then the flag is set for a fresh install. There is no longer a default for the working directory, nothing is written to it until the user selects it. The config files are still created by default in $HOME, however it is possible to override this by starting the program with the -configdir option, in which case it is possible to avoid entirely writing anything to $HOME. Additionally, one can use the commandline option -workdir to override any setting in the config dir.

Secondly, the process of updating the config file has been meticulously rewritten to ensure that it is almost impossible to end up with a corrupted config file. Before making any alterations, the file is backed up, and the size of the backup is compared with the original to make sure it is the same, otherwise we abort immediately. Alterations are then made in a third copy of the config file, and the size is checked after inserting every string to make sure it is as we expect. Only if the final size is OK, we then copy the new file over the original, again checking the size of the resulting file. If anything goes wrong with the copying process then we do the following: - if the config file still has its original size, do nothing, just abort. If the config file has a different size, try to delete it and then rename the new file to the config file (in case there was insufficient disk space for the copy operation), if anything goes wrong here, we also have the option of deleting the new config file, provided the original backup is still there. On the next startup, we'll check the config file, the new file, and the backup in that order.

In the normal case, after copying the new config file to the original file, the new config file would then replace the backup. This way we should always have at least 2 copies of the config file. You can even delete the config file and LiVES will happily continue with the backup file on the next restart.

Finally, the diskspace cleanup has been extensively rewritten in the new version. If you are running the program from a terminal window, then you get a running comentary describing the decisions taken. Each subdirectory of the working directory is examined. The directory will only be removed if it meets some strict conditions, With a couple of specific exceptions, the directory name must be composed of 5 or more digits only, with a numerical value > 65535, or else it must contain a file named "order", and not contain specific marker files.

Anyway, if you are still following this then please be reassured that the issue is still being taken very seriously and every action possible being taken to ensure such a tragedy does occur again.

LiVES 2.8.3 on Debian 9

Glenn Gagne — Wed, 13 Nov 2019 04:16:19 -0000

Hi,

I known that LiVES 2.8.3 is not the latest version of the moment (where 3.0.1 was released)... But its the official stable version available under Debian 9.

I installed it and I got a graphic bug using the interface. I use a lot of applications on the same computer and I didn't have any graphic problem.

Whe I run the application, many menus and boxes are in black or gray instead returning a basic text label...

I'm using Debian 9 with MATE GUI interface.

Let me known if this issue is already known and if a fix exist ?

Crashes on OpenBSD 6.4

Teppo Saari — Sat, 05 Oct 2019 11:48:02 -0000

operating system: OpenBSD 6.4
LiVES version: 1.0.10

I have built LiVES from the ports tree on OpenBSD 6.4. When importing a .flv video, the program crashes. There is no output except from telling me to report this to this URL.

On starting up, the program outputs:

(lives:77799): GLib-WARNING **: 14:35:33.602: gmem.c:489: custom memory allocation vtable not supported

After crash, when trying to run lives -recover, the program crashes again without even displaying the GUI.

When trying to run a clean start, LiVES starts up, then it says that you have some files there, do you want to recover them. I click yes, and the program crashes.

If there are any log files you want me to post here, then please tell me which ones.

#229 White text

Rich Howell — Tue, 20 Aug 2019 18:38:08 -0000

In software manager it shows Lives 3.1 but installs 2.8.7 . Get the same result with
sudo add-apt-repository ppa:ubuntuhandbook1/lives
sudo apt update
sudo apt install lives lives-plugins

So how do i install 3.0.1 ?

#229 White text

Salsaman — Mon, 19 Aug 2019 16:04:46 -0000

HI
this version is no longer supported, please update tothe latest version 3. 0. 1

White text

Rich Howell — Mon, 19 Aug 2019 08:12:13 -0000

Just downloaded Lives 2.8.7 on Mint 19.2 Cinnamon All the variable information boxes ( e.g video ply back speed, setting frame size, etc appear blank - but when I rolled over them I could see it was white text ( against a white bacjground) This makes it very difficult wto adjust to what you wnat ! and is obvioulsy hugely user unfrinedly. How do you adjust to make it readable ? As a result only had a limited exploration of Lives and fist impressions ae that it is not very intuitive !