Batchrender update diff
Generated by diff -u -w -B /home/guest/botva/src/cinelerra-git/cin-5/new-git/cinelerra/cinelerra-5.1/cinelerra/batchrender.C batchrender.C > /home/guest/botva/src/cinelerra-git/cin-5/batchrender_post_merge_raw_fix.diff (a lot of options because I wanted patch without empty lines added) and hand-editing header. probably should be applied from within cinelerra-5.1/cinelerra folder. should fix clonsole rendering and also fix -r file.xml overwriting in case it was not batchrender.xml AND should also NOT abort on GUI loading of same project file as batchrender job file .... (my previous patch introduced new crash because I used exit(1) even when GUI was running ..)
What is CONSOLE rendering? I have been trying to understand what that is. On Mon, Jan 18, 2021 at 6:07 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
Generated by
diff -u -w -B /home/guest/botva/src/cinelerra-git/cin-5/new-git/cinelerra/cinelerra-5.1/cinelerra/batchrender.C batchrender.C > /home/guest/botva/src/cinelerra-git/cin-5/batchrender_post_merge_raw_fix.diff
(a lot of options because I wanted patch without empty lines added) and hand-editing header.
probably should be applied from within cinelerra-5.1/cinelerra folder.
should fix clonsole rendering and also fix -r file.xml overwriting in case it was not batchrender.xml AND should also NOT abort on GUI loading of same project file as batchrender job file .... (my previous patch introduced new crash because I used exit(1) even when GUI was running ..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Tuesday 19 January 2021 04:56:10 Phyllis Smith via Cin написал(а):
What is CONSOLE rendering? I have been trying to understand what that is.
Just run cin -r batch.xml .....
On Mon, Jan 18, 2021 at 6:07 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
Generated by
diff -u -w -B /home/guest/botva/src/cinelerra-git/cin-5/new-git/cinelerra/cinelerra-5.1/cinelerra/batchrender.C batchrender.C > /home/guest/botva/src/cinelerra-git/cin-5/batchrender_post_merge_raw_fix.diff
(a lot of options because I wanted patch without empty lines added) and hand-editing header.
probably should be applied from within cinelerra-5.1/cinelerra folder.
should fix clonsole rendering and also fix -r file.xml overwriting in case it was not batchrender.xml AND should also NOT abort on GUI loading of same project file as batchrender job file .... (my previous patch introduced new crash because I used exit(1) even when GUI was running ..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Sorry Andrew, I'm getting confused! Which patches should I test for batch rendering and more?
В сообщении от Tuesday 19 January 2021 10:56:29 Andrea paz via Cin написал(а):
Sorry Andrew, I'm getting confused! Which patches should I test for batch rendering and more?
This specific patch should fix non-GUI crash if you run cin like 'cin -r batch.xml' AND silent xml file corruption if it was Project and not JobList For more you can test fix_menuattachtransition_3.diff - should fix non-working 'Attach transition' dialog, when it called from localized CinelerraGG. title_untranslate_popup.diff - should fix Titler's pop up menu in text area - where you can select some styles for titles (it works in English, but not in localized version) .... I think this is all for now ..... (autobackup stuff currently in 'big mess of unrelated changes in mwindow.C' state) but attached anyway
Thanks Andrew. cin -r listjob.xml doesn't crash, but neither does it start rendering. It says: "cin command not found".
From GUI everything is OK.
Backup: several backups with timecode and number are created (38 after a little testing). In .bcast5 there is a backup.prev; a backup.xml and the various backups with timecode. "Save backup" creates a new backup; "load backup" creates a new backup; I didn't really understand how it works. Titler: both with English (that I always put) and with sys (Italian) I don't see problems in the textbox popup, but maybe I didn't understand the problem. Transition: both setting English and sys (Italian), Attach Transition works without problems. In dialog I've Italian in sys and english in En. Default transition is in english.
There are a few parts where save_backup() is called: cinelerra/cwindowgui.C:2 cinelerra/swindow.C:1 cinelerra/keyframepopup.C:2 cinelerra/pluginpopup.C:1 cinelerra/mwindowedit.C:87 cinelerra/presetsgui.C.sav1:1 cinelerra/assetpopup.C:1 cinelerra/cwindowtool.C:1 cinelerra/render.C:1 cinelerra/setformat.C:1 cinelerra/mwindow.C:9 cinelerra/keyframegui.C:2 cinelerra/mwindowgui.C:1 cinelerra/mainmenu.C:1 cinelerra/loadfile.C:2 cinelerra/savefile.C:2 cinelerra/menueffects.C:1 cinelerra/main.C:1 cinelerra/presetsgui.C.sav:1 cinelerra/record.C:1 cinelerra/plugindialog.C:1 On 2021. 01. 19. 14:45, Andrea paz via Cin wrote: ...>
Backup: several backups with timecode and number are created (38 after a little testing). In .bcast5 there is a backup.prev; a backup.xml and the various backups with timecode. "Save backup" creates a new backup; "load backup" creates a new backup; I didn't really understand how it works.
...>
Andrew, 1- The thing about the transitions, if it is the same patch, I already tried it and now it works perfectly. The fact that the default transition is in English is not important, when it is configured it is in the local language, but when the window is reopened it appears in English, but I reiterate that this is not important and that it works perfectly. 2- I replaced the files mwindow.h and mwindow.C that you attach, when compiling this error appeared: mwindow.C:1032:9: warning: unused variable ‘result’ [-Wunused-variable] int result; ^~~~~~ But it compiled and installed fine. 2.1 But when opening a project in local mode, all the effects and transitions used in this project generated an error, the error said that these effects and transitions did not belong to Cinelerra. 2.2 It is true that now from the terminal the xml files are no longer overwritten or deleted, but the render still does not work. 3- The tags in the title effect works fine but the translations are lost in working in local mode. This point is my fault, maybe these tags shouldn't be translated. Sincerely Rafa. El mar, 19 ene 2021 a las 17:14, Reuss András via Cin (< cin@lists.cinelerra-gg.org>) escribió:
There are a few parts where save_backup() is called:
cinelerra/cwindowgui.C:2 cinelerra/swindow.C:1 cinelerra/keyframepopup.C:2 cinelerra/pluginpopup.C:1 cinelerra/mwindowedit.C:87 cinelerra/presetsgui.C.sav1:1 cinelerra/assetpopup.C:1 cinelerra/cwindowtool.C:1 cinelerra/render.C:1 cinelerra/setformat.C:1 cinelerra/mwindow.C:9 cinelerra/keyframegui.C:2 cinelerra/mwindowgui.C:1 cinelerra/mainmenu.C:1 cinelerra/loadfile.C:2 cinelerra/savefile.C:2 cinelerra/menueffects.C:1 cinelerra/main.C:1 cinelerra/presetsgui.C.sav:1 cinelerra/record.C:1 cinelerra/plugindialog.C:1
On 2021. 01. 19. 14:45, Andrea paz via Cin wrote: ...>
Backup: several backups with timecode and number are created (38 after a little testing). In .bcast5 there is a backup.prev; a backup.xml and the various backups with timecode. "Save backup" creates a new backup; "load backup" creates a new backup; I didn't really understand how it works.
...>
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Tuesday 19 January 2021 21:39:42 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Andrew, 1- The thing about the transitions, if it is the same patch, I already tried it and now it works perfectly. The fact that the default transition is in English is not important, when it is configured it is in the local language, but when the window is reopened it appears in English, but I reiterate that this is not important and that it works perfectly.
2- I replaced the files mwindow.h and mwindow.C that you attach, when compiling this error appeared: mwindow.C:1032:9: warning: unused variable ‘result’ [-Wunused-variable] int result; ^~~~~~ But it compiled and installed fine. 2.1 But when opening a project in local mode, all the effects and transitions used in this project generated an error, the error said that these effects and transitions did not belong to Cinelerra.
As I said - file currently a mess ....I tried to fix local old test projects (where effect names were translated into cp1251) and only messed it up more ... Just two lines calling if( new_edl->load_xml(&xml_file, LOAD_ALL) ) { eprintf(_("Error: unable to load:\n %s"), filename); @@ -2657,7 +2748,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( plugin->plugin_type != PLUGIN_STANDALONE ) continue; // ok we need to find it in plugindb PluginServer *server = - scan_plugindb(plugin->title, track->data_type); + scan_plugindb(_(plugin->title), track->data_type); + fix_plugin_title(_(plugin->title)); if( !server || server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n" @@ -2672,7 +2764,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( !edit->transition ) continue; // ok we need to find transition in plugindb PluginServer *server = - scan_plugindb(edit->transition->title, track->data_type); + scan_plugindb(_(edit->transition->title), track->data_type); + fix_plugin_title(_(edit->transition->title)); if( !server || !server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n" remove or comment out those two calls to fix_plugin_title()
2.2 It is true that now from the terminal the xml files are no longer overwritten or deleted, but the render still does not work.
Can I see how it complain ?
3- The tags in the title effect works fine but the translations are lost in working in local mode. This point is my fault, maybe these tags shouldn't be translated.
As far as I understand currently CinGG send exactly same text that you put into menu item structure, there is no generic support for holding both translated and untranslated string there ... may be I can come up with another hack :}
Sincerely Rafa.
El mar, 19 ene 2021 a las 17:14, Reuss András via Cin (< cin@lists.cinelerra-gg.org>) escribió:
There are a few parts where save_backup() is called:
cinelerra/cwindowgui.C:2 cinelerra/swindow.C:1 cinelerra/keyframepopup.C:2 cinelerra/pluginpopup.C:1 cinelerra/mwindowedit.C:87 cinelerra/presetsgui.C.sav1:1 cinelerra/assetpopup.C:1 cinelerra/cwindowtool.C:1 cinelerra/render.C:1 cinelerra/setformat.C:1 cinelerra/mwindow.C:9 cinelerra/keyframegui.C:2 cinelerra/mwindowgui.C:1 cinelerra/mainmenu.C:1 cinelerra/loadfile.C:2 cinelerra/savefile.C:2 cinelerra/menueffects.C:1 cinelerra/main.C:1 cinelerra/presetsgui.C.sav:1 cinelerra/record.C:1 cinelerra/plugindialog.C:1
On 2021. 01. 19. 14:45, Andrea paz via Cin wrote: ...>
Backup: several backups with timecode and number are created (38 after a little testing). In .bcast5 there is a backup.prev; a backup.xml and the various backups with timecode. "Save backup" creates a new backup; "load backup" creates a new backup; I didn't really understand how it works.
...>
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Can I see how it complain ?
A .dmp file is created, but has no content ... :-( may be I can come up with another hack :}
Sure you do, but don't waste a lot of time on it either, normally a user who uses Cinelerra in the local language will not use it in English. It's really my fault, when I did the Spanish translation, I translated everything I saw without translating without really knowing what it was. The funny thing is that these HTML-type tags work well translated, the only problem is if you open a project made in Spanish in another language, they stop working. Because the xml has these tags written with the local language. Perhaps we should ensure that in the xml file the instruction is always written in English, and the user sees the labels as they are in the .po or .mo language file Sorry if because of my lack of programming knowledge I say nonsense. I can really contribute ideas, some of them are surely stupid for the above, I have no programming knowledge. But like I told you, don't give too much importance to this issue. El mar, 19 ene 2021 a las 20:06, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 21:39:42 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Andrew, 1- The thing about the transitions, if it is the same patch, I already tried it and now it works perfectly. The fact that the default transition is in English is not important, when it is configured it is in the local language, but when the window is reopened it appears in English, but I reiterate that this is not important and that it works perfectly.
2- I replaced the files mwindow.h and mwindow.C that you attach, when compiling this error appeared: mwindow.C:1032:9: warning: unused variable ‘result’ [-Wunused-variable] int result; ^~~~~~ But it compiled and installed fine. 2.1 But when opening a project in local mode, all the effects and transitions used in this project generated an error, the error said that these effects and transitions did not belong to Cinelerra.
As I said - file currently a mess ....I tried to fix local old test projects (where effect names were translated into cp1251) and only messed it up more ...
Just two lines calling
if( new_edl->load_xml(&xml_file, LOAD_ALL) ) { eprintf(_("Error: unable to load:\n %s"), filename); @@ -2657,7 +2748,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( plugin->plugin_type != PLUGIN_STANDALONE ) continue; // ok we need to find it in plugindb PluginServer *server = - scan_plugindb(plugin->title, track->data_type); + scan_plugindb(_(plugin->title), track->data_type); + fix_plugin_title(_(plugin->title)); if( !server || server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n" @@ -2672,7 +2764,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( !edit->transition ) continue; // ok we need to find transition in plugindb PluginServer *server = - scan_plugindb(edit->transition->title, track->data_type); + scan_plugindb(_(edit->transition->title), track->data_type); + fix_plugin_title(_(edit->transition->title)); if( !server || !server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n"
remove or comment out those two calls to fix_plugin_title()
2.2 It is true that now from the terminal the xml files are no longer overwritten or deleted, but the render still does not work.
Can I see how it complain ?
3- The tags in the title effect works fine but the translations are lost
in
working in local mode. This point is my fault, maybe these tags shouldn't be translated.
As far as I understand currently CinGG send exactly same text that you put into menu item structure, there is no generic support for holding both translated and untranslated string there ...
may be I can come up with another hack :}
Sincerely Rafa.
El mar, 19 ene 2021 a las 17:14, Reuss András via Cin (< cin@lists.cinelerra-gg.org>) escribió:
There are a few parts where save_backup() is called:
cinelerra/cwindowgui.C:2 cinelerra/swindow.C:1 cinelerra/keyframepopup.C:2 cinelerra/pluginpopup.C:1 cinelerra/mwindowedit.C:87 cinelerra/presetsgui.C.sav1:1 cinelerra/assetpopup.C:1 cinelerra/cwindowtool.C:1 cinelerra/render.C:1 cinelerra/setformat.C:1 cinelerra/mwindow.C:9 cinelerra/keyframegui.C:2 cinelerra/mwindowgui.C:1 cinelerra/mainmenu.C:1 cinelerra/loadfile.C:2 cinelerra/savefile.C:2 cinelerra/menueffects.C:1 cinelerra/main.C:1 cinelerra/presetsgui.C.sav:1 cinelerra/record.C:1 cinelerra/plugindialog.C:1
On 2021. 01. 19. 14:45, Andrea paz via Cin wrote: ...>
Backup: several backups with timecode and number are created (38
after
a little testing). In .bcast5 there is a backup.prev; a backup.xml and the various backups with timecode. "Save backup" creates a new backup; "load backup" creates a new backup; I didn't really understand how it works.
...>
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Tuesday 19 January 2021 22:31:21 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Can I see how it complain ?
A .dmp file is created, but has no content ... :-(
I mean just output from X terminal as you run it ... You usually can copy/paste with mouse from there ...
may be I can come up with another hack :}
Sure you do, but don't waste a lot of time on it either, normally a user who uses Cinelerra in the local language will not use it in English. It's really my fault, when I did the Spanish translation, I translated everything I saw without translating without really knowing what it was. The funny thing is that these HTML-type tags work well translated, the only problem is if you open a project made in Spanish in another language, they stop working. Because the xml has these tags written with the local language. Perhaps we should ensure that in the xml file the instruction is always written in English, and the user sees the labels as they are in the .po or .mo language file Sorry if because of my lack of programming knowledge I say nonsense. I can really contribute ideas, some of them are surely stupid for the above, I have no programming knowledge. But like I told you, don't give too much importance to this issue.
El mar, 19 ene 2021 a las 20:06, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 21:39:42 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Andrew, 1- The thing about the transitions, if it is the same patch, I already tried it and now it works perfectly. The fact that the default transition is in English is not important, when it is configured it is in the local language, but when the window is reopened it appears in English, but I reiterate that this is not important and that it works perfectly.
2- I replaced the files mwindow.h and mwindow.C that you attach, when compiling this error appeared: mwindow.C:1032:9: warning: unused variable ‘result’ [-Wunused-variable] int result; ^~~~~~ But it compiled and installed fine. 2.1 But when opening a project in local mode, all the effects and transitions used in this project generated an error, the error said that these effects and transitions did not belong to Cinelerra.
As I said - file currently a mess ....I tried to fix local old test projects (where effect names were translated into cp1251) and only messed it up more ...
Just two lines calling
if( new_edl->load_xml(&xml_file, LOAD_ALL) ) { eprintf(_("Error: unable to load:\n %s"), filename); @@ -2657,7 +2748,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( plugin->plugin_type != PLUGIN_STANDALONE ) continue; // ok we need to find it in plugindb PluginServer *server = - scan_plugindb(plugin->title, track->data_type); + scan_plugindb(_(plugin->title), track->data_type); + fix_plugin_title(_(plugin->title)); if( !server || server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n" @@ -2672,7 +2764,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( !edit->transition ) continue; // ok we need to find transition in plugindb PluginServer *server = - scan_plugindb(edit->transition->title, track->data_type); + scan_plugindb(_(edit->transition->title), track->data_type); + fix_plugin_title(_(edit->transition->title)); if( !server || !server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n"
remove or comment out those two calls to fix_plugin_title()
2.2 It is true that now from the terminal the xml files are no longer overwritten or deleted, but the render still does not work.
Can I see how it complain ?
3- The tags in the title effect works fine but the translations are lost
in
working in local mode. This point is my fault, maybe these tags shouldn't be translated.
As far as I understand currently CinGG send exactly same text that you put into menu item structure, there is no generic support for holding both translated and untranslated string there ...
may be I can come up with another hack :}
Sincerely Rafa.
El mar, 19 ene 2021 a las 17:14, Reuss András via Cin (< cin@lists.cinelerra-gg.org>) escribió:
There are a few parts where save_backup() is called:
cinelerra/cwindowgui.C:2 cinelerra/swindow.C:1 cinelerra/keyframepopup.C:2 cinelerra/pluginpopup.C:1 cinelerra/mwindowedit.C:87 cinelerra/presetsgui.C.sav1:1 cinelerra/assetpopup.C:1 cinelerra/cwindowtool.C:1 cinelerra/render.C:1 cinelerra/setformat.C:1 cinelerra/mwindow.C:9 cinelerra/keyframegui.C:2 cinelerra/mwindowgui.C:1 cinelerra/mainmenu.C:1 cinelerra/loadfile.C:2 cinelerra/savefile.C:2 cinelerra/menueffects.C:1 cinelerra/main.C:1 cinelerra/presetsgui.C.sav:1 cinelerra/record.C:1 cinelerra/plugindialog.C:1
On 2021. 01. 19. 14:45, Andrea paz via Cin wrote: ...>
Backup: several backups with timecode and number are created (38
after
a little testing). In .bcast5 there is a backup.prev; a backup.xml and the various backups with timecode. "Save backup" creates a new backup; "load backup" creates a new backup; I didn't really understand how it works.
...>
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Of course I have recompiled, but I have again the problem of the errors of the effects and transitions in local. Terminal out: rafa@rafa-pc:/media/DATA/Tests_Cinelerra/BATCH-RENDER$ cin -r BatchTest.xml Cinelerra Infinity - built: Jan 18 2021 12:14:50 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. ** segv at 0x55de6e6354df in pid 18499, tid 18499 writing debug data to /tmp/cinelerra_batch18499.dmp lock_items: 0 lock_frees: 1 Segment violation (`core' generated) El mar, 19 ene 2021 a las 20:35, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 22:31:21 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Can I see how it complain ?
A .dmp file is created, but has no content ... :-(
I mean just output from X terminal as you run it ... You usually can copy/paste with mouse from there ...
may be I can come up with another hack :}
Sure you do, but don't waste a lot of time on it either, normally a user who uses Cinelerra in the local language will not use it in English. It's really my fault, when I did the Spanish translation, I translated everything I saw without translating without really knowing what it was. The funny thing is that these HTML-type tags work well translated, the
only
problem is if you open a project made in Spanish in another language, they stop working. Because the xml has these tags written with the local language. Perhaps we should ensure that in the xml file the instruction is always written in English, and the user sees the labels as they are in the .po or .mo language file Sorry if because of my lack of programming knowledge I say nonsense. I can really contribute ideas, some of them are surely stupid for the above, I have no programming knowledge. But like I told you, don't give too much importance to this issue.
El mar, 19 ene 2021 a las 20:06, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 21:39:42 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Andrew, 1- The thing about the transitions, if it is the same patch, I already tried it and now it works perfectly. The fact that the default transition is in English is not important, when it is configured it is in the local language, but when the window is reopened it appears in English, but I reiterate that this is not important and that it works perfectly.
2- I replaced the files mwindow.h and mwindow.C that you attach, when compiling this error appeared: mwindow.C:1032:9: warning: unused variable ‘result’ [-Wunused-variable] int result; ^~~~~~ But it compiled and installed fine. 2.1 But when opening a project in local mode, all the effects and transitions used in this project generated an error, the error said that these effects and transitions did not belong to Cinelerra.
As I said - file currently a mess ....I tried to fix local old test projects (where effect names were translated into cp1251) and only messed it up more ...
Just two lines calling
if( new_edl->load_xml(&xml_file, LOAD_ALL) ) { eprintf(_("Error: unable to load:\n %s"), filename); @@ -2657,7 +2748,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( plugin->plugin_type != PLUGIN_STANDALONE ) continue; // ok we need to find it in plugindb PluginServer *server = - scan_plugindb(plugin->title, track->data_type); + scan_plugindb(_(plugin->title), track->data_type); + fix_plugin_title(_(plugin->title)); if( !server || server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n" @@ -2672,7 +2764,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( !edit->transition ) continue; // ok we need to find transition in plugindb PluginServer *server = - scan_plugindb(edit->transition->title, track->data_type); + scan_plugindb(_(edit->transition->title), track->data_type); + fix_plugin_title(_(edit->transition->title)); if( !server || !server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n"
remove or comment out those two calls to fix_plugin_title()
2.2 It is true that now from the terminal the xml files are no longer overwritten or deleted, but the render still does not work.
Can I see how it complain ?
3- The tags in the title effect works fine but the translations are
lost in
working in local mode. This point is my fault, maybe these tags shouldn't be translated.
As far as I understand currently CinGG send exactly same text that you put into menu item structure, there is no generic support for holding both translated and untranslated string there ...
may be I can come up with another hack :}
Sincerely Rafa.
El mar, 19 ene 2021 a las 17:14, Reuss András via Cin (< cin@lists.cinelerra-gg.org>) escribió:
There are a few parts where save_backup() is called:
cinelerra/cwindowgui.C:2 cinelerra/swindow.C:1 cinelerra/keyframepopup.C:2 cinelerra/pluginpopup.C:1 cinelerra/mwindowedit.C:87 cinelerra/presetsgui.C.sav1:1 cinelerra/assetpopup.C:1 cinelerra/cwindowtool.C:1 cinelerra/render.C:1 cinelerra/setformat.C:1 cinelerra/mwindow.C:9 cinelerra/keyframegui.C:2 cinelerra/mwindowgui.C:1 cinelerra/mainmenu.C:1 cinelerra/loadfile.C:2 cinelerra/savefile.C:2 cinelerra/menueffects.C:1 cinelerra/main.C:1 cinelerra/presetsgui.C.sav:1 cinelerra/record.C:1 cinelerra/plugindialog.C:1
On 2021. 01. 19. 14:45, Andrea paz via Cin wrote: ...>
Backup: several backups with timecode and number are created (38
after
a little testing). In .bcast5 there is a backup.prev; a backup.xml and the various backups with timecode. "Save backup" creates a new backup; "load backup" creates a new backup; I didn't really understand how it works.
...>
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Tuesday 19 January 2021 22:54:28 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Of course I have recompiled, but I have again the problem of the errors of the effects and transitions in local.
Then you need to apply other two patches too .. If you compile from git tree you and run 'git diff' and see full list of changes ..... sorry, I mean even from my experienced experience I still mess with patching/recompile from time to time ...
Terminal out: rafa@rafa-pc:/media/DATA/Tests_Cinelerra/BATCH-RENDER$ cin -r BatchTest.xml Cinelerra Infinity - built: Jan 18 2021 12:14:50 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra.
** segv at 0x55de6e6354df in pid 18499, tid 18499 writing debug data to /tmp/cinelerra_batch18499.dmp lock_items: 0 lock_frees: 1 Segment violation (`core' generated)
:/
El mar, 19 ene 2021 a las 20:35, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 22:31:21 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Can I see how it complain ?
A .dmp file is created, but has no content ... :-(
I mean just output from X terminal as you run it ... You usually can copy/paste with mouse from there ...
may be I can come up with another hack :}
Sure you do, but don't waste a lot of time on it either, normally a user who uses Cinelerra in the local language will not use it in English. It's really my fault, when I did the Spanish translation, I translated everything I saw without translating without really knowing what it was. The funny thing is that these HTML-type tags work well translated, the
only
problem is if you open a project made in Spanish in another language, they stop working. Because the xml has these tags written with the local language. Perhaps we should ensure that in the xml file the instruction is always written in English, and the user sees the labels as they are in the .po or .mo language file Sorry if because of my lack of programming knowledge I say nonsense. I can really contribute ideas, some of them are surely stupid for the above, I have no programming knowledge. But like I told you, don't give too much importance to this issue.
El mar, 19 ene 2021 a las 20:06, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 21:39:42 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Andrew, 1- The thing about the transitions, if it is the same patch, I already tried it and now it works perfectly. The fact that the default transition is in English is not important, when it is configured it is in the local language, but when the window is reopened it appears in English, but I reiterate that this is not important and that it works perfectly.
2- I replaced the files mwindow.h and mwindow.C that you attach, when compiling this error appeared: mwindow.C:1032:9: warning: unused variable ‘result’ [-Wunused-variable] int result; ^~~~~~ But it compiled and installed fine. 2.1 But when opening a project in local mode, all the effects and transitions used in this project generated an error, the error said that these effects and transitions did not belong to Cinelerra.
As I said - file currently a mess ....I tried to fix local old test projects (where effect names were translated into cp1251) and only messed it up more ...
Just two lines calling
if( new_edl->load_xml(&xml_file, LOAD_ALL) ) { eprintf(_("Error: unable to load:\n %s"), filename); @@ -2657,7 +2748,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( plugin->plugin_type != PLUGIN_STANDALONE ) continue; // ok we need to find it in plugindb PluginServer *server = - scan_plugindb(plugin->title, track->data_type); + scan_plugindb(_(plugin->title), track->data_type); + fix_plugin_title(_(plugin->title)); if( !server || server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n" @@ -2672,7 +2764,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( !edit->transition ) continue; // ok we need to find transition in plugindb PluginServer *server = - scan_plugindb(edit->transition->title, track->data_type); + scan_plugindb(_(edit->transition->title), track->data_type); + fix_plugin_title(_(edit->transition->title)); if( !server || !server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n"
remove or comment out those two calls to fix_plugin_title()
2.2 It is true that now from the terminal the xml files are no longer overwritten or deleted, but the render still does not work.
Can I see how it complain ?
3- The tags in the title effect works fine but the translations are
lost in
working in local mode. This point is my fault, maybe these tags shouldn't be translated.
As far as I understand currently CinGG send exactly same text that you put into menu item structure, there is no generic support for holding both translated and untranslated string there ...
may be I can come up with another hack :}
Sincerely Rafa.
El mar, 19 ene 2021 a las 17:14, Reuss András via Cin (< cin@lists.cinelerra-gg.org>) escribió:
There are a few parts where save_backup() is called:
cinelerra/cwindowgui.C:2 cinelerra/swindow.C:1 cinelerra/keyframepopup.C:2 cinelerra/pluginpopup.C:1 cinelerra/mwindowedit.C:87 cinelerra/presetsgui.C.sav1:1 cinelerra/assetpopup.C:1 cinelerra/cwindowtool.C:1 cinelerra/render.C:1 cinelerra/setformat.C:1 cinelerra/mwindow.C:9 cinelerra/keyframegui.C:2 cinelerra/mwindowgui.C:1 cinelerra/mainmenu.C:1 cinelerra/loadfile.C:2 cinelerra/savefile.C:2 cinelerra/menueffects.C:1 cinelerra/main.C:1 cinelerra/presetsgui.C.sav:1 cinelerra/record.C:1 cinelerra/plugindialog.C:1
On 2021. 01. 19. 14:45, Andrea paz via Cin wrote: ...> > Backup: several backups with timecode and number are created (38
after
> a little testing). In .bcast5 there is a backup.prev; a backup.xml and > the various backups with timecode. "Save backup" creates a new backup; > "load backup" creates a new backup; I didn't really understand how it > works. > ...>
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Tuesday 19 January 2021 22:54:28 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Of course I have recompiled, but I have again the problem of the errors of the effects and transitions in local. Terminal out: rafa@rafa-pc:/media/DATA/Tests_Cinelerra/BATCH-RENDER$ cin -r BatchTest.xml
Oh, you need to run ./cin for local copy!!!
Cinelerra Infinity - built: Jan 18 2021 12:14:50 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra.
** segv at 0x55de6e6354df in pid 18499, tid 18499 writing debug data to /tmp/cinelerra_batch18499.dmp lock_items: 0 lock_frees: 1 Segment violation (`core' generated)
El mar, 19 ene 2021 a las 20:35, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 22:31:21 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Can I see how it complain ?
A .dmp file is created, but has no content ... :-(
I mean just output from X terminal as you run it ... You usually can copy/paste with mouse from there ...
may be I can come up with another hack :}
Sure you do, but don't waste a lot of time on it either, normally a user who uses Cinelerra in the local language will not use it in English. It's really my fault, when I did the Spanish translation, I translated everything I saw without translating without really knowing what it was. The funny thing is that these HTML-type tags work well translated, the
only
problem is if you open a project made in Spanish in another language, they stop working. Because the xml has these tags written with the local language. Perhaps we should ensure that in the xml file the instruction is always written in English, and the user sees the labels as they are in the .po or .mo language file Sorry if because of my lack of programming knowledge I say nonsense. I can really contribute ideas, some of them are surely stupid for the above, I have no programming knowledge. But like I told you, don't give too much importance to this issue.
El mar, 19 ene 2021 a las 20:06, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 21:39:42 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Andrew, 1- The thing about the transitions, if it is the same patch, I already tried it and now it works perfectly. The fact that the default transition is in English is not important, when it is configured it is in the local language, but when the window is reopened it appears in English, but I reiterate that this is not important and that it works perfectly.
2- I replaced the files mwindow.h and mwindow.C that you attach, when compiling this error appeared: mwindow.C:1032:9: warning: unused variable ‘result’ [-Wunused-variable] int result; ^~~~~~ But it compiled and installed fine. 2.1 But when opening a project in local mode, all the effects and transitions used in this project generated an error, the error said that these effects and transitions did not belong to Cinelerra.
As I said - file currently a mess ....I tried to fix local old test projects (where effect names were translated into cp1251) and only messed it up more ...
Just two lines calling
if( new_edl->load_xml(&xml_file, LOAD_ALL) ) { eprintf(_("Error: unable to load:\n %s"), filename); @@ -2657,7 +2748,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( plugin->plugin_type != PLUGIN_STANDALONE ) continue; // ok we need to find it in plugindb PluginServer *server = - scan_plugindb(plugin->title, track->data_type); + scan_plugindb(_(plugin->title), track->data_type); + fix_plugin_title(_(plugin->title)); if( !server || server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n" @@ -2672,7 +2764,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( !edit->transition ) continue; // ok we need to find transition in plugindb PluginServer *server = - scan_plugindb(edit->transition->title, track->data_type); + scan_plugindb(_(edit->transition->title), track->data_type); + fix_plugin_title(_(edit->transition->title)); if( !server || !server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n"
remove or comment out those two calls to fix_plugin_title()
2.2 It is true that now from the terminal the xml files are no longer overwritten or deleted, but the render still does not work.
Can I see how it complain ?
3- The tags in the title effect works fine but the translations are
lost in
working in local mode. This point is my fault, maybe these tags shouldn't be translated.
As far as I understand currently CinGG send exactly same text that you put into menu item structure, there is no generic support for holding both translated and untranslated string there ...
may be I can come up with another hack :}
Sincerely Rafa.
El mar, 19 ene 2021 a las 17:14, Reuss András via Cin (< cin@lists.cinelerra-gg.org>) escribió:
There are a few parts where save_backup() is called:
cinelerra/cwindowgui.C:2 cinelerra/swindow.C:1 cinelerra/keyframepopup.C:2 cinelerra/pluginpopup.C:1 cinelerra/mwindowedit.C:87 cinelerra/presetsgui.C.sav1:1 cinelerra/assetpopup.C:1 cinelerra/cwindowtool.C:1 cinelerra/render.C:1 cinelerra/setformat.C:1 cinelerra/mwindow.C:9 cinelerra/keyframegui.C:2 cinelerra/mwindowgui.C:1 cinelerra/mainmenu.C:1 cinelerra/loadfile.C:2 cinelerra/savefile.C:2 cinelerra/menueffects.C:1 cinelerra/main.C:1 cinelerra/presetsgui.C.sav:1 cinelerra/record.C:1 cinelerra/plugindialog.C:1
On 2021. 01. 19. 14:45, Andrea paz via Cin wrote: ...> > Backup: several backups with timecode and number are created (38
after
> a little testing). In .bcast5 there is a backup.prev; a backup.xml and > the various backups with timecode. "Save backup" creates a new backup; > "load backup" creates a new backup; I didn't really understand how it > works. > ...>
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
I did not do a local installation, it is installed on the system, otherwise I would get an error that cin is not found. El mar, 19 ene 2021 a las 21:13, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 22:54:28 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Of course I have recompiled, but I have again the problem of the errors of the effects and transitions in local. Terminal out: rafa@rafa-pc:/media/DATA/Tests_Cinelerra/BATCH-RENDER$ cin -r BatchTest.xml
Oh, you need to run ./cin for local copy!!!
Cinelerra Infinity - built: Jan 18 2021 12:14:50 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra.
** segv at 0x55de6e6354df in pid 18499, tid 18499 writing debug data to /tmp/cinelerra_batch18499.dmp lock_items: 0 lock_frees: 1 Segment violation (`core' generated)
El mar, 19 ene 2021 a las 20:35, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 22:31:21 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Can I see how it complain ?
A .dmp file is created, but has no content ... :-(
I mean just output from X terminal as you run it ... You usually can copy/paste with mouse from there ...
may be I can come up with another hack :}
Sure you do, but don't waste a lot of time on it either, normally a
user
who uses Cinelerra in the local language will not use it in English. It's really my fault, when I did the Spanish translation, I translated everything I saw without translating without really knowing what it was. The funny thing is that these HTML-type tags work well translated, the only problem is if you open a project made in Spanish in another language, they stop working. Because the xml has these tags written with the local language. Perhaps we should ensure that in the xml file the instruction is always written in English, and the user sees the labels as they are in the .po or .mo language file Sorry if because of my lack of programming knowledge I say nonsense. I can really contribute ideas, some of them are surely stupid for the above, I have no programming knowledge. But like I told you, don't give too much importance to this issue.
El mar, 19 ene 2021 a las 20:06, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Tuesday 19 January 2021 21:39:42 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
Andrew, 1- The thing about the transitions, if it is the same patch, I already tried it and now it works perfectly. The fact that the default transition is in English is not important, when it is configured it is in the local language, but when the window is reopened it appears in English, but I reiterate that this is not important and that it works perfectly.
2- I replaced the files mwindow.h and mwindow.C that you attach, when compiling this error appeared: mwindow.C:1032:9: warning: unused variable ‘result’ [-Wunused-variable] int result; ^~~~~~ But it compiled and installed fine. 2.1 But when opening a project in local mode, all the effects and transitions used in this project generated an error, the error said that these effects and transitions did not belong to Cinelerra.
As I said - file currently a mess ....I tried to fix local old test projects (where effect names were translated into cp1251) and only messed it up more ...
Just two lines calling
if( new_edl->load_xml(&xml_file, LOAD_ALL) ) { eprintf(_("Error: unable to load:\n %s"), filename); @@ -2657,7 +2748,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( plugin->plugin_type != PLUGIN_STANDALONE ) continue; // ok we need to find it in plugindb PluginServer *server = - scan_plugindb(plugin->title, track->data_type); + scan_plugindb(_(plugin->title), track->data_type); + fix_plugin_title(_(plugin->title)); if( !server || server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n" @@ -2672,7 +2764,8 @@ void MWindow::test_plugins(EDL *new_edl, const char *path) if( !edit->transition ) continue; // ok we need to find transition in plugindb PluginServer *server = - scan_plugindb(edit->transition->title, track->data_type); + scan_plugindb(_(edit->transition->title), track->data_type); + fix_plugin_title(_(edit->transition->title)); if( !server || !server->transition ) { sprintf(string, _("The %s '%s' in file '%s' is not part of your installation of Cinelerra.\n"
remove or comment out those two calls to fix_plugin_title()
2.2 It is true that now from the terminal the xml files are no longer overwritten or deleted, but the render still does not work.
Can I see how it complain ?
3- The tags in the title effect works fine but the translations
are lost in
working in local mode. This point is my fault, maybe these tags shouldn't be translated.
As far as I understand currently CinGG send exactly same text that you put into menu item structure, there is no generic support for holding both translated and untranslated string there ...
may be I can come up with another hack :}
Sincerely Rafa.
El mar, 19 ene 2021 a las 17:14, Reuss András via Cin (< cin@lists.cinelerra-gg.org>) escribió:
> There are a few parts where save_backup() is called: > > cinelerra/cwindowgui.C:2 > cinelerra/swindow.C:1 > cinelerra/keyframepopup.C:2 > cinelerra/pluginpopup.C:1 > cinelerra/mwindowedit.C:87 > cinelerra/presetsgui.C.sav1:1 > cinelerra/assetpopup.C:1 > cinelerra/cwindowtool.C:1 > cinelerra/render.C:1 > cinelerra/setformat.C:1 > cinelerra/mwindow.C:9 > cinelerra/keyframegui.C:2 > cinelerra/mwindowgui.C:1 > cinelerra/mainmenu.C:1 > cinelerra/loadfile.C:2 > cinelerra/savefile.C:2 > cinelerra/menueffects.C:1 > cinelerra/main.C:1 > cinelerra/presetsgui.C.sav:1 > cinelerra/record.C:1 > cinelerra/plugindialog.C:1 > > > On 2021. 01. 19. 14:45, Andrea paz via Cin wrote: > ...> > > Backup: several backups with timecode and number are created
(38 after
> > a little testing). In .bcast5 there is a backup.prev; a backup.xml and > > the various backups with timecode. "Save backup" creates a new backup; > > "load backup" creates a new backup; I didn't really understand how it > > works. > > > ...> > > -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin >
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Tuesday 19 January 2021 16:45:27 Andrea paz via Cin написал(а):
Thanks Andrew. cin -r listjob.xml doesn't crash, but neither does it start rendering. It says: "cin command not found". From GUI everything is OK.
strange! Can you paste full output?
Backup: several backups with timecode and number are created (38 after a little testing). In .bcast5 there is a backup.prev; a backup.xml and the various backups with timecode. "Save backup" creates a new backup; "load backup" creates a new backup; I didn't really understand how it works.
I think it saves backups at every important operation (but not fade automation change, for example!) so, because 'load backup' is also operation altering timeline - it backups in this case too .. or so I think ....
Titler: both with English (that I always put) and with sys (Italian) I don't see problems in the textbox popup, but maybe I didn't understand the problem.
Hm, try to put stylized text via this menu, for example with 'blink' attrib?
Transition: both setting English and sys (Italian), Attach Transition works without problems. In dialog I've Italian in sys and english in En. Default transition is in english.
But may be those problems only specific to some locale settings ....
The patch attached to this original email for batchrender.C has been checked into GIT just now (minus the warning for XML). This fixes the console runs problem due to GUI versus command line. Thank you, Andrew! On Mon, Jan 18, 2021 at 6:07 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
Generated by
diff -u -w -B /home/guest/botva/src/cinelerra-git/cin-5/new-git/cinelerra/cinelerra-5.1/cinelerra/batchrender.C batchrender.C > /home/guest/botva/src/cinelerra-git/cin-5/batchrender_post_merge_raw_fix.diff
(a lot of options because I wanted patch without empty lines added) and hand-editing header.
probably should be applied from within cinelerra-5.1/cinelerra folder.
should fix clonsole rendering and also fix -r file.xml overwriting in case it was not batchrender.xml AND should also NOT abort on GUI loading of same project file as batchrender job file .... (my previous patch introduced new crash because I used exit(1) even when GUI was running ..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
I just tried this new version: Observations. - The render works fine again if launched from the terminal. - I notice that the solution that Andrew proposed for the Insert transitions wizard in local mode has not been included yet. https://www.cinelerra-gg.org/bugtracker/view.php?id=545 Days ago I tried it and it worked satisfactorily. Recommendations. - The known problem that if using cin -r we point to an EDL project file .xml, it is deleted and a blank xml remains. I think Andrew is working on it. It would be a shame if someone could lose their job due to this issue, since in other applications it is very common that when a render is launched from the terminal it points to the project file. I take this opportunity to report an error that I have been observing from the beginning with the batch render window. This error only occurs on the first use of this wizard and has to do with assigning the extension when choosing FFMPEG. To play it you need to delete or rename, the .bcast5 folder, to simulate that it is the first time we use Cinelerra. And create a new list of EDL's to render, since if we load a list already created, this problem is not reproduced. Let's see if I can explain it so that it is understood. - When we open the Render window for the first time in "File format" it comes as "Unknown". - If I create a new render line, assigning an EDL and an output path, if I choose the FFMPEG option, this option automatically gives me the mp4 extension, and this is precisely the one I want to use and I don't touch anything else. - But when I press the Start button I get an error message with two windows, one says like this: "Couldn't open <file path> file.mp4" And a log message that says like this: "int FFMPEG :: init_encoder (const char *): bat file format: <file path> file.mp4 " [image: b.render.error.png] [image: imagen.png] How is it solved? Apparently it is not enough that in File format put FFMPEG, I must also click on choose extension, even if I want to use the same one that is shown, which is mp4 by default. If I display the extensions menu and click on another, or even on mp4, this problem no longer occurs. Conclusions. - If the person who performs a batch render for the first time and wants to export with mp4 will encounter this problem. It will not be the case if, for example, this person chooses another format. Possible solutions. - The sloppy proposal by a person who does not know programming, that is me. Set by default an extension that no one wants to use today, such as .avi, which is also the first on the list. - The elegant one, fix this or failing that, when FFMPEG is chosen, the extension is left blank and forces the user to choose one. With this simplicity, this error no longer occurs. Even with the experience I have, I got a little confused with this, because I wanted to use mp4 and this was the extension that I saw and I did not realize that I should display this menu and click on it, and this problem repeats itself every time I do tests, because I always rename the .bcast5 folder first to simulate a first use of Cinelerra that is not contaminated with my settings, which I recover again after testing. I apologize for being such a perfectionist about these things, "fussy" I would say. El mié, 20 ene 2021 a las 0:51, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:
The patch attached to this original email for batchrender.C has been checked into GIT just now (minus the warning for XML). This fixes the console runs problem due to GUI versus command line. Thank you, Andrew!
On Mon, Jan 18, 2021 at 6:07 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
Generated by
diff -u -w -B /home/guest/botva/src/cinelerra-git/cin-5/new-git/cinelerra/cinelerra-5.1/cinelerra/batchrender.C batchrender.C > /home/guest/botva/src/cinelerra-git/cin-5/batchrender_post_merge_raw_fix.diff
(a lot of options because I wanted patch without empty lines added) and hand-editing header.
probably should be applied from within cinelerra-5.1/cinelerra folder.
should fix clonsole rendering and also fix -r file.xml overwriting in case it was not batchrender.xml AND should also NOT abort on GUI loading of same project file as batchrender job file .... (my previous patch introduced new crash because I used exit(1) even when GUI was running ..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Wednesday 20 January 2021 08:59:51 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
I just tried this new version: Observations. - The render works fine again if launched from the terminal.
Cool :}
- I notice that the solution that Andrew proposed for the Insert transitions wizard in local mode has not been included yet. https://www.cinelerra-gg.org/bugtracker/view.php?id=545 Days ago I tried it and it worked satisfactorily.
Recommendations. - The known problem that if using cin -r we point to an EDL project file .xml, it is deleted and a blank xml remains. I think Andrew is working on it. It would be a shame if someone could lose their job due to this issue, since in other applications it is very common that when a render is launched from the terminal it points to the project file.
yes, I'm working on it .... But may be I should extract those two checks ('Is this file XML?' and 'Is this file actually XML Project from compatible Cinelerra?') into function(s) first ...
I take this opportunity to report an error that I have been observing from the beginning with the batch render window. This error only occurs on the first use of this wizard and has to do with assigning the extension when choosing FFMPEG. To play it you need to delete or rename, the .bcast5 folder, to simulate that it is the first time we use Cinelerra. And create a new list of EDL's to render, since if we load a list already created, this problem is not reproduced. Let's see if I can explain it so that it is understood. - When we open the Render window for the first time in "File format" it comes as "Unknown". - If I create a new render line, assigning an EDL and an output path, if I choose the FFMPEG option, this option automatically gives me the mp4 extension, and this is precisely the one I want to use and I don't touch anything else. - But when I press the Start button I get an error message with two windows, one says like this: "Couldn't open <file path> file.mp4" And a log message that says like this: "int FFMPEG :: init_encoder (const char *): bat file format: <file path> file.mp4 " [image: b.render.error.png]
[image: imagen.png]
How is it solved? Apparently it is not enough that in File format put FFMPEG, I must also click on choose extension, even if I want to use the same one that is shown, which is mp4 by default. If I display the extensions menu and click on another, or even on mp4, this problem no longer occurs. Conclusions. - If the person who performs a batch render for the first time and wants to export with mp4 will encounter this problem. It will not be the case if, for example, this person chooses another format. Possible solutions. - The sloppy proposal by a person who does not know programming, that is me. Set by default an extension that no one wants to use today, such as .avi, which is also the first on the list. - The elegant one, fix this or failing that, when FFMPEG is chosen, the extension is left blank and forces the user to choose one. With this simplicity, this error no longer occurs.
Yes, i noticed it too .... Will try to fix .... as far as I learn enough :}
Even with the experience I have, I got a little confused with this, because I wanted to use mp4 and this was the extension that I saw and I did not realize that I should display this menu and click on it, and this problem repeats itself every time I do tests, because I always rename the .bcast5 folder first to simulate a first use of Cinelerra that is not contaminated with my settings, which I recover again after testing.
I apologize for being such a perfectionist about these things, "fussy" I would say.
El mié, 20 ene 2021 a las 0:51, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:
The patch attached to this original email for batchrender.C has been checked into GIT just now (minus the warning for XML). This fixes the console runs problem due to GUI versus command line. Thank you, Andrew!
On Mon, Jan 18, 2021 at 6:07 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
Generated by
diff -u -w -B /home/guest/botva/src/cinelerra-git/cin-5/new-git/cinelerra/cinelerra-5.1/cinelerra/batchrender.C batchrender.C > /home/guest/botva/src/cinelerra-git/cin-5/batchrender_post_merge_raw_fix.diff
(a lot of options because I wanted patch without empty lines added) and hand-editing header.
probably should be applied from within cinelerra-5.1/cinelerra folder.
should fix clonsole rendering and also fix -r file.xml overwriting in case it was not batchrender.xml AND should also NOT abort on GUI loading of same project file as batchrender job file .... (my previous patch introduced new crash because I used exit(1) even when GUI was running ..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
A Cinelerra project always starts with: <?xml version="1.0"?> <EDL VERSION=Infinity PATH=""> Perhaps you can indicate in the code that if the file you find has in the header "EDL VERSION = Infinity" or simply "EDL" ignore this file, do nothing with it and get an error that says "This file is not a batch render" I see that the batch list headers are different: <?xml version="1.0"?> <JOBS> And they do not contain the EDL attribute. Maybe I'm saying other nonsense because I don't know how to program. You are really good, I know, because a person who understands told me that the Cinelerra code requires a person with a lot of knowledge and experience. And you are demonstrating both characteristics and solving everything. I feel bad for being so perfectionist with these things and always very critical of functions that can damage our work. The render window is now much better than a few days ago. Above all, safer and easier to use. I keep the option to see dangerous buttons disabled, I don't need them because of the way I wo El mié, 20 ene 2021 a las 7:42, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Wednesday 20 January 2021 08:59:51 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
I just tried this new version: Observations. - The render works fine again if launched from the terminal.
Cool :}
- I notice that the solution that Andrew proposed for the Insert transitions wizard in local mode has not been included yet. https://www.cinelerra-gg.org/bugtracker/view.php?id=545 Days ago I tried it and it worked satisfactorily.
Recommendations. - The known problem that if using cin -r we point to an EDL project file .xml, it is deleted and a blank xml remains. I think Andrew is working on it. It would be a shame if someone could lose their job due to this issue, since in other applications it is very common that when a render is launched from the terminal it points to the project file.
yes, I'm working on it .... But may be I should extract those two checks ('Is this file XML?' and 'Is this file actually XML Project from compatible Cinelerra?') into function(s) first ...
I take this opportunity to report an error that I have been observing
from
the beginning with the batch render window. This error only occurs on the first use of this wizard and has to do with assigning the extension when choosing FFMPEG. To play it you need to delete or rename, the .bcast5 folder, to simulate that it is the first time we use Cinelerra. And create a new list of EDL's to render, since if we load a list already created, this problem is not reproduced. Let's see if I can explain it so that it is understood. - When we open the Render window for the first time in "File format" it comes as "Unknown". - If I create a new render line, assigning an EDL and an output path, if I choose the FFMPEG option, this option automatically gives me the mp4 extension, and this is precisely the one I want to use and I don't touch anything else. - But when I press the Start button I get an error message with two windows, one says like this: "Couldn't open <file path> file.mp4" And a log message that says like this: "int FFMPEG :: init_encoder (const char *): bat file format: <file path> file.mp4 " [image: b.render.error.png]
[image: imagen.png]
How is it solved? Apparently it is not enough that in File format put FFMPEG, I must also click on choose extension, even if I want to use the same one that is shown, which is mp4 by default. If I display the extensions menu and click on another, or even on mp4, this problem no longer occurs. Conclusions. - If the person who performs a batch render for the first time and wants to export with mp4 will encounter this problem. It will not be the case if, for example, this person chooses another format. Possible solutions. - The sloppy proposal by a person who does not know programming, that is me. Set by default an extension that no one wants to use today, such as .avi, which is also the first on the list. - The elegant one, fix this or failing that, when FFMPEG is chosen, the extension is left blank and forces the user to choose one. With this simplicity, this error no longer occurs.
Yes, i noticed it too .... Will try to fix .... as far as I learn enough :}
Even with the experience I have, I got a little confused with this,
because
I wanted to use mp4 and this was the extension that I saw and I did not realize that I should display this menu and click on it, and this problem repeats itself every time I do tests, because I always rename the .bcast5 folder first to simulate a first use of Cinelerra that is not contaminated with my settings, which I recover again after testing.
I apologize for being such a perfectionist about these things, "fussy" I would say.
El mié, 20 ene 2021 a las 0:51, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:
The patch attached to this original email for batchrender.C has been checked into GIT just now (minus the warning for XML). This fixes the console runs problem due to GUI versus command line. Thank you, Andrew!
On Mon, Jan 18, 2021 at 6:07 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
Generated by
diff -u -w -B
/home/guest/botva/src/cinelerra-git/cin-5/new-git/cinelerra/cinelerra-5.1/cinelerra/batchrender.C
batchrender.C >
/home/guest/botva/src/cinelerra-git/cin-5/batchrender_post_merge_raw_fix.diff
(a lot of options because I wanted patch without empty lines added) and hand-editing header.
probably should be applied from within cinelerra-5.1/cinelerra folder.
should fix clonsole rendering and also fix -r file.xml overwriting in case it was not
batchrender.xml
AND should also NOT abort on GUI loading of same project file as batchrender job file .... (my previous patch introduced new crash because I used exit(1) even when GUI was running ..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Last evening I no longer got the "cin command not found" message, but the crash returned with the empty dump file. Same exact message as Rafa; both from root or not and with "./cin -r" instead of "cin -r". Today I compiled the new release without patches. In the "autogen.sh" step I get a very long series of messages on the terminal; I report a small part of them: "... ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:840: PKG_STATIC is expanded from... configure.ac:868: PKG_PROVIDE is expanded from... configure.ac:928: the top level configure.ac:929: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:929: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:840: PKG_STATIC is expanded from... configure.ac:850: PKG_FORCED is expanded from... configure.ac:868: PKG_PROVIDE is expanded from... configure.ac:929: the top level configure.ac:929: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:929: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:827: PKG_DISABLED is expanded from... configure.ac:868: PKG_PROVIDE is expanded from... configure.ac:929: the top level configure.ac:929: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:929: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:840: PKG_STATIC is expanded from... configure.ac:868: PKG_PROVIDE is expanded from... configure.ac:929: the top level configure.ac:940: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:940: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:940: the top level configure.ac:944: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:944: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:944: the top level configure.ac:6: installing './compile' configure.ac:4: installing './install-sh' configure.ac:4: installing './missing' " (same as yestarday!) Run autoupdate works fine! Started CinGG, the batch render works, as always. Started the terminal render, it works!: " [paz@arch-paz bin]$ cin -r /home/paz/video_editing/prova/listjob.rc bash: cin: command not found [paz@arch-paz bin]$ ./cin -r /home/paz/video_editing/prova/listjob.rc Cinelerra Infinity - built: Jan 20 2021 09:35:41 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. Render::run: /home/paz/video_editing/prova/1080/align_edit.xml 33% ETA: 0:00:05 FFMPEG::open_decoder: some stream have bad times: /home/paz/video_editing/prova/1080/0004.png 50% ETA: 0:00:03 FFMPEG::open_decoder: some stream have bad times: /home/paz/video_editing/prova/1080/0003.png 99% ETA: 0:00:00 Render::render_single: Session finished. Render::run: done in 0:00:07 Render::run: /home/paz/video_editing/prova/1080/edit-test.xml 80% ETA: 0:00:00 Render::render_single: Session finished. Render::run: done in 0:00:03 Render::run: /home/paz/video_editing/prova/1080/demo2.xml 83% ETA: 0:00:00 FFMPEG::open_decoder: some stream have bad times: /home/paz/video_editing/prova/1080/ocra.png 90% ETA: 0:00:00 Render::render_single: Session finished. Render::run: done in 0:00:06 ** rendered 93 frames in 17.859 secs, 5.207 fps Session time: 0:00:18 Cpu time: user: 0:02:15.657 sys: 0:00:28.561 " So for me "./cin -r" works and "cin -r" doesn't. Thank you Andrew; you are doing so much and great work!
On Wed, 20 Jan 2021, Andrea paz via Cin wrote:
the crash returned with the empty dump file. Same exact message as
To get nonempty dump, try in the terminal where you are going to start cin, the following command: ulimit -S -c unlimited and then start cin from the same terminal where ulimit was specified. To check the current core dump limit, execute: ulimit -H -c ulimit -S -c -H is for hard limit, -S for soft limit, if it is 0 then dumping core is disallowed. Perhaps only root can set hard limit with ulimit -H -c unlimited. _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email sge@nmr.nioch.nsc.ru _______________________________________________________________________________
В сообщении от Wednesday 20 January 2021 12:04:04 Andrea paz via Cin написал(а):
Last evening I no longer got the "cin command not found" message, but the crash returned with the empty dump file. Same exact message as Rafa; both from root or not and with "./cin -r" instead of "cin -r".
Today I compiled the new release without patches. In the "autogen.sh" step I get a very long series of messages on the terminal; I report a small part of them:
"... ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:840: PKG_STATIC is expanded from... configure.ac:868: PKG_PROVIDE is expanded from... configure.ac:928: the top level configure.ac:929: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:929: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:840: PKG_STATIC is expanded from... configure.ac:850: PKG_FORCED is expanded from... configure.ac:868: PKG_PROVIDE is expanded from... configure.ac:929: the top level configure.ac:929: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:929: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:827: PKG_DISABLED is expanded from... configure.ac:868: PKG_PROVIDE is expanded from... configure.ac:929: the top level configure.ac:929: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:929: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:840: PKG_STATIC is expanded from... configure.ac:868: PKG_PROVIDE is expanded from... configure.ac:929: the top level configure.ac:940: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:940: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:940: the top level configure.ac:944: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:944: You should run autoupdate. ./lib/autoconf/general.m4:203: AC_HELP_STRING is expanded from... configure.ac:944: the top level configure.ac:6: installing './compile' configure.ac:4: installing './install-sh' configure.ac:4: installing './missing' "
(same as yestarday!) Run autoupdate works fine!
Started CinGG, the batch render works, as always. Started the terminal render, it works!:
" [paz@arch-paz bin]$ cin -r /home/paz/video_editing/prova/listjob.rc bash: cin: command not found
may be because you try to run 'cin' while you currently reside in '/usr/bin' (or /usr/local/bin) ? I think this is basically bash (shell) or environment feature ... try to step outside: cd ../ (on level up) and see where you are: ls if you are at / (with /bin, /etc /home and other dirs) then you probably can go to home: cd ~ and usually stay there I have few console 'tabs' running in terminal emulator (Konsole), one or two of them dedicated to root tasks. This terminal window (application) put in KDE autostart (it was part of my old KDE session, when I simply exited KDE with this app running), so I usually have my terminals right after DE start ...
[paz@arch-paz bin]$ ./cin -r /home/paz/video_editing/prova/listjob.rc Cinelerra Infinity - built: Jan 20 2021 09:35:41 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra.
Render::run: /home/paz/video_editing/prova/1080/align_edit.xml 33% ETA: 0:00:05 FFMPEG::open_decoder: some stream have bad times: /home/paz/video_editing/prova/1080/0004.png 50% ETA: 0:00:03 FFMPEG::open_decoder: some stream have bad times: /home/paz/video_editing/prova/1080/0003.png 99% ETA: 0:00:00 Render::render_single: Session finished. Render::run: done in 0:00:07 Render::run: /home/paz/video_editing/prova/1080/edit-test.xml 80% ETA: 0:00:00 Render::render_single: Session finished. Render::run: done in 0:00:03 Render::run: /home/paz/video_editing/prova/1080/demo2.xml 83% ETA: 0:00:00 FFMPEG::open_decoder: some stream have bad times: /home/paz/video_editing/prova/1080/ocra.png 90% ETA: 0:00:00 Render::render_single: Session finished. Render::run: done in 0:00:06 ** rendered 93 frames in 17.859 secs, 5.207 fps Session time: 0:00:18 Cpu time: user: 0:02:15.657 sys: 0:00:28.561 "
So for me "./cin -r" works and "cin -r" doesn't.
Thank you Andrew; you are doing so much and great work!
Update on:
"
So for me "./cin -r" works and "cin -r" doesn't.
https://superuser.com/questions/156582/why-is-not-in-the-path-by-default == Q: Why is . not in the path by default? A: More than a security risk, having '.' in the PATH make almost impossible to make it sure that the execution of any command acts as intended. Think about running a command like 'zip' in a huge directory containing thousand of files with random names. The possibility that one of them is actually named 'zip' is not negligible and would lead to an error which is very difficult to understand (actually the file should be executable, which, however, might happen). In particular this is true when writing scripts that keep the PATH variable of the user. A good written script should deal with all corner cases (like filenames with spaces in them or starting with '-'). But it is impractical to prevent a file in the current directory being executed instead of a system command... ====quote end==== In our case I often run ../bin/cin from inside 'cinelerra' folder in CinGG source tree or you can call it from root of this tree: root@slax:/dev/shm/tmp/cinelerra-goodguy-20210119/cinelerra-5.1/cinelerra# cd ../ root@slax:/dev/shm/tmp/cinelerra-goodguy-20210119/cinelerra-5.1# bin/cin Cinelerra Infinity - built: Jan 20 2021 08:22:21 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. RenderFarmClient::main_loop: client started Session time: 0:00:08 Cpu time: user: 0:00:02.682 sys: 0:00:00.289 or from anywhere by just autocompleting long path (like with tons of TAB autocompletion :) ) guest@slax:~/.wine/drive_c/TournamentDemo/System$ /dev/shm/tmp/cinelerra-goodguy-20210119/cinelerra-5.1/bin/cin Cinelerra Infinity - built: Jan 20 2021 08:22:21 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. RenderFarmClient::main_loop: client started Session time: 0:00:08 Cpu time: user: 0:00:02.572 sys: 0:00:00.306 have fun and thanks for all your testing!
Thank you Andrew; you are doing so much and great work!
В сообщении от Wednesday 20 January 2021 11:37:19 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
A Cinelerra project always starts with: <?xml version="1.0"?> <EDL VERSION=Infinity PATH=""> Perhaps you can indicate in the code that if the file you find has in the header "EDL VERSION = Infinity" or simply "EDL" ignore this file, do nothing with it and get an error that says "This file is not a batch render"
I see that the batch list headers are different: <?xml version="1.0"?> <JOBS> And they do not contain the EDL attribute. Maybe I'm saying other nonsense because I don't know how to program.
I created this little function: int BatchRenderThread::probe(const char *path) { FILE *fp = fopen(path, "rb"); if( !fp ) return FILE_NOT_FOUND; char data[16]; memset(data,0,sizeof(data)); int ret = fread(data, 1, 16, fp); fclose(fp); if( !ret ) return FILE_NOT_FOUND; if ( !strncmp(&data[0],"<",1) && ( !strncmp(&data[1],"EDL>",4) || !strncmp(&data[1],"HTAL>",5) || !strncmp(&data[1],"?xml",4) )) return FILE_IS_XML; return FILE_UNRECOGNIZED_CODEC; } by literally copy/pasting code around from file.C seems to work, while I still don't have 'this is EDL from Cin5+' *function* . If you feel brave you can try to apply batchrender_current_work_labels-2.diff from my prev. email and see how many things I broke! (but it *hopefully* has this fileprotection part working - try on easy-to-recreate files!) it also should support manually setting IOPOINTED=1 in batchrender's JOB line (and obviously you can hack such file by hand, err by your favourite editor, unlike more compressed and binary config files .... or by script ....)
You are really good, I know, because a person who understands told me that the Cinelerra code requires a person with a lot of knowledge and experience. And you are demonstrating both characteristics and solving everything.
I feel bad for being so perfectionist with these things and always very critical of functions that can damage our work.
The render window is now much better than a few days ago. Above all, safer and easier to use. I keep the option to see dangerous buttons disabled, I don't need them because of the way I wo
El mié, 20 ene 2021 a las 7:42, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:
В сообщении от Wednesday 20 January 2021 08:59:51 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
I just tried this new version: Observations. - The render works fine again if launched from the terminal.
Cool :}
- I notice that the solution that Andrew proposed for the Insert transitions wizard in local mode has not been included yet. https://www.cinelerra-gg.org/bugtracker/view.php?id=545 Days ago I tried it and it worked satisfactorily.
Recommendations. - The known problem that if using cin -r we point to an EDL project file .xml, it is deleted and a blank xml remains. I think Andrew is working on it. It would be a shame if someone could lose their job due to this issue, since in other applications it is very common that when a render is launched from the terminal it points to the project file.
yes, I'm working on it .... But may be I should extract those two checks ('Is this file XML?' and 'Is this file actually XML Project from compatible Cinelerra?') into function(s) first ...
I take this opportunity to report an error that I have been observing
from
the beginning with the batch render window. This error only occurs on the first use of this wizard and has to do with assigning the extension when choosing FFMPEG. To play it you need to delete or rename, the .bcast5 folder, to simulate that it is the first time we use Cinelerra. And create a new list of EDL's to render, since if we load a list already created, this problem is not reproduced. Let's see if I can explain it so that it is understood. - When we open the Render window for the first time in "File format" it comes as "Unknown". - If I create a new render line, assigning an EDL and an output path, if I choose the FFMPEG option, this option automatically gives me the mp4 extension, and this is precisely the one I want to use and I don't touch anything else. - But when I press the Start button I get an error message with two windows, one says like this: "Couldn't open <file path> file.mp4" And a log message that says like this: "int FFMPEG :: init_encoder (const char *): bat file format: <file path> file.mp4 " [image: b.render.error.png]
[image: imagen.png]
How is it solved? Apparently it is not enough that in File format put FFMPEG, I must also click on choose extension, even if I want to use the same one that is shown, which is mp4 by default. If I display the extensions menu and click on another, or even on mp4, this problem no longer occurs. Conclusions. - If the person who performs a batch render for the first time and wants to export with mp4 will encounter this problem. It will not be the case if, for example, this person chooses another format. Possible solutions. - The sloppy proposal by a person who does not know programming, that is me. Set by default an extension that no one wants to use today, such as .avi, which is also the first on the list. - The elegant one, fix this or failing that, when FFMPEG is chosen, the extension is left blank and forces the user to choose one. With this simplicity, this error no longer occurs.
Yes, i noticed it too .... Will try to fix .... as far as I learn enough :}
Even with the experience I have, I got a little confused with this,
because
I wanted to use mp4 and this was the extension that I saw and I did not realize that I should display this menu and click on it, and this problem repeats itself every time I do tests, because I always rename the .bcast5 folder first to simulate a first use of Cinelerra that is not contaminated with my settings, which I recover again after testing.
I apologize for being such a perfectionist about these things, "fussy" I would say.
El mié, 20 ene 2021 a las 0:51, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:
The patch attached to this original email for batchrender.C has been checked into GIT just now (minus the warning for XML). This fixes the console runs problem due to GUI versus command line. Thank you, Andrew!
On Mon, Jan 18, 2021 at 6:07 PM Andrew Randrianasulu via Cin < cin@lists.cinelerra-gg.org> wrote:
Generated by
diff -u -w -B
/home/guest/botva/src/cinelerra-git/cin-5/new-git/cinelerra/cinelerra-5.1/cinelerra/batchrender.C
batchrender.C >
/home/guest/botva/src/cinelerra-git/cin-5/batchrender_post_merge_raw_fix.diff
(a lot of options because I wanted patch without empty lines added) and hand-editing header.
probably should be applied from within cinelerra-5.1/cinelerra folder.
should fix clonsole rendering and also fix -r file.xml overwriting in case it was not
batchrender.xml
AND should also NOT abort on GUI loading of same project file as batchrender job file .... (my previous patch introduced new crash because I used exit(1) even when GUI was running ..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (6)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
Phyllis Smith -
Rafa Mar Multimedia en Gnu\Linux -
Reuss András