-
Notifications
You must be signed in to change notification settings - Fork 364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autosave with multiple instance #353
Comments
Hi! Yes I also thought about that problem once but did not address it further because I rarely have two YUView instances open at the same time and when I do I am comparing two videos and don't care much about the playlist being lost. The idea with the date and time in the name is great! But what if a new instance is launched. How can it tell if the saved playlist is from a crashed YUView or from one that is still running fine? I can think of 2 options:
|
Alternatively we can save a UUID for each new instance, along with its process id. New instances can query if there are processes recorded which are no longer running. There is a QUuid class. The process part will be a bit more difficult, probably have to distinguish there between different OSes. |
working on it in #355 |
Ok but is it possible to get all running process IDs of all currently running instances of YUView on all platforms? What about dockerized environment like Snap? Is this even possible from a security point of view? |
Good point. I think this should work for Linux (tested) and Mac (can't test it), the code for windows will have to be adapted. I'll get it working first, then test with appimage/flatpak (i don't think we have snaps?). From what I found it will probably not work. Changing the backend storage from qsettings to something else shouldn't be difficult though. |
Hmm but we should not merge some sort of Hack using QSettings. I still think the better option is to setup some inter process communication. E.g. using Sockets or the Networking library which we are using in YUView already anyways to check for updates. |
One more thing to consider is how long the memory from the other options will persist. Had a quick look at shared memory, it should be persistent until the last instance is closed. However if there was only a single instance I would expect it to be cleaned up after a crash. To get around that we need to create another independent process which keeps the shared memory alive it the main/only instance crashes. |
Yep I am now also unsure about the shared memory. Maybe thats not the optimal way. But the Sockets/Network stuff looks more promising. Maybe there we could also use signals/slots and all of that for threading. |
Doesn't that have the same problem if there was/is only one instance? |
One idea I had:
Ok this also sounds a bit complicated. |
QSetting based multiples instance work now. Still have to look into other backends |
I often have more than one YUView running. What I noticed is that if there is already an instance running opening a new one will show the crash recovery dialog. That's because crash is detected by the presences of "Autosaveplaylist" in QSettings, put there by the first instance. Looking a the code I think there is also another issue. Every instance will save the playlist every ten seconds. Didn't test this but I would expect with more than one instance it would be chance which playlist you will recover when one crashes. If more than ten seconds pass before you open another one the playlist will be lost.
How about adding the time that YUView was launched to the setting, i.e. something like "Autosaveplaylist-2020.04.16-9:39". Then we'll have more than one saved playlist. Since this is only for crash recovery, playlist older than say a day can be ignored and removed when found. Playlist of the same day can be used to provide a list to choose from.
The text was updated successfully, but these errors were encountered: