Hi guys! I think that we should try to catch the reason of this problem on Jens's computer as before.
Jens, what do you think? Can you run teamviewer again today in the evening (I will be ready at 17:00 your time). -- Regards, Andrew 09.10.2015 09:31, Jens Radloff wrote: > Hi Robert, hi Andrew, > >> Quick question, you are still running a patched version Jens, is that >> right? > Yes. I have compiled my current clone version on 29 September 2015, and > I strongly guess that the source code of that clone version is from the > same day, i.e. updated by the command "git pull". What I reported > yesterday in this email thread, refers to the clone version. > > By the way, I have tested if the behaviour occurs in the official MusE > 2.2.1 version: It does not occur. I tested this five times, i.e. I > started five times the official MusE version, then first loaded > "song_1_distorted_bass.med", then "song_2.med" five times. MusE does not > crash. > > By the way, the behaviour does not always occur in my clone version of > MusE, as I just discovered: My first test today with the clone version > resulted in that the file "song_2.med" was loaded successfully. My second > test today with the clone version resulted in that the file "song_2.med" > was not successfully loaded; MusE crashed. In both cases I first loaded > the other file "song_1_distorted_bass.med". > >> More over, is there something special with these songs > The file "song_2.med" contains a third party VST synth (OXE) and two fluid > synth instances and three MIDI tracks. And a guitarix effect on one of > the fluid synth instances. > The file "song_1_disorted_bass.med" contains two fluid synth instances and > three MIDI tracks. And a guitarix effect on one of the fluid synth > instances. > >> or does it hang if >> you go from other songs also? > The behaviour occurs also if I do the following: > > 1. I start MusE (the clone version) > > 2. I load the file "song_1_distorted_bass.med" > > 3. I load the file "song_1.med", so another file => while the file is > loading, MusE crashes > > The difference between these two files: "song_1.med" contains one fluid > synth instance and three MIDI tracks, and no guitarix effect on one the > fluidsynth instances. "song_1_distorted_bass.med" contains two fluid synth > instances, three MIDI tracks, and the guitarix effect on one of the fluid > synth instances. > > So I think this behaviour is not related to a third party VST synth > (here: OXE), which is part of "song_2.med". > >> If they are special do send them to me and/or Andrew, hopefully that >> will help. > I would like to avoid sending my files to Robert or Andrew. > > Regards, > > Jens > > > Am Donnerstag, 8. Oktober 2015 schrieb Robert Jonsson: >> Hello Jens, Andrew, >> >> Quick question, you are still running a patched version Jens, is that >> right? What is in this patched version? Is there a way to get these >> fixes back to the main line? it's not so good as a long term >> solution. >> >> More over, is there something special with these songs or does it >> hang if you go from other songs also? >> If they are special do send them to me and/or Andrew, hopefully that >> will help. >> >> Regards, >> Robert >> >> 2015-10-08 16:56 GMT+02:00 Jens Radloff <[email protected]>: >>> Hi Andrew, hi @all, >>> >>> I have loaded the file "song_2_distorted_bass.med" in MusE. When I >>> open, while this file is loaded in MusE, another med file, i.e. >>> "song_2.med", then MusE hangs while loading song_2.med. I have to >>> kill MusE with the command "killall muse2" to get out of this >>> situation. >>> >>> To demonstrate at which point MusE hangs, please see the attached >>> screenshot. >>> >>> I can successfully load and play both files in MusE if I start MusE >>> and then either load the file "song_2_distorted_bass.med" or >>> "song_2.med". >>> >>> I have tried to record a debug text with gdb, but when I try to >>> reproduce the behaviour described above with gdb, then it is >>> curious that the behaviour does not appear, i.e. I can >>> successfully first load file "song_2_distorted_bass.med", and then >>> file "song_2.med". I tried to record a debug text with gdb twice, >>> but in both cases I successfully could load both files one after >>> another. >>> >>> Everytime I repeat these steps without the use of gdb, as specified >>> in the first paragraph of this email, then MusE chrashes. >>> >>> So I only could record a debug file with the command "muse2 -DD" in >>> my debug installation. Please see the attached dump file. But it >>> is curious that the behaviour does not appear if I start MusE with >>> the command "./muse2 -DD > dump.txt". But the behaviour appears if >>> I start MusE with the command "./muse2 -DD" (without piping the >>> dump information into a text file). >>> >>> So the attached dump file has been created by the command "./muse2 >>> -DD", and I have copied what was left in the console when MusE >>> crashed. >>> >>> Regards, >>> >>> Jens >>> >>> >>> ------------------------------------------------------------------- >>> ----------- >>> >>> _______________________________________________ >>> Lmuse-developer mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/lmuse-developer ------------------------------------------------------------------------------ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
