View Issue Details

IDCategoryLast Update
0007188bugs2016-12-30 22:40
ReporterkjetilAssigned To 
Reproducibilityalways 
Status newResolutionopen 
PlatformWindowsOSWindowsOS Version10
Product Version5.5 
Fixed in Version 
Summary0007188: 10 seconds freeze when opening file dialogs
DescriptionOpening some of the dialogs takes around 10 seconds.
Steps To Reproduce1. Start Ardour
2. Select "Open" from the session menu.
3. After around 10 seconds, the import dialog is shown. In the mean time, Ardour freezes.

Same situation with the "Save" and "Import" dialogs. I guess it is disk related, and possibly not reproducable for everyone. Haven't noticed same behavior in other programs.

The "Import" dialog only freezes 10 seconds the first time. The second time I try to open the "Import" dialog, it opens immediately.
Additional InformationTried both Jack and Portaudio.

I set "severity"to "major" since this leaves a really bad first impression of the program. Waiting 10 seconds for the file dialogs to open is quite annoying.
TagsNo tags attached.

Activities

kjetil

2016-12-29 22:57

reporter   ~0019236

In "3. After around 10 seconds, the import dialog is shown. In the mean time, Ardour freezes.", I meant to write that it took 10 seocnds before the "Load" dialog is shown, not the "Import" dialog. (i.e. it's not the wrong dialog that opens)

kjetil

2016-12-29 22:59

reporter   ~0019237

And this happens every time when trying to open the "Load" or "Save" dialogs. It's only the "Import" dialog that only freezes the first time.

x42

2016-12-29 23:06

administrator   ~0019238

Do other gtk apps behave the same?

The gtk file dialog does spawn a couple of threads to index files and generate previews and AFAIK there's no way to turn that off or limit it.

Are you using jack1? If so, try with jack2 or Ardour's ALSA backend.

(jack1 memlocks everything and only has a blacklist for some libs. Those threads can memlocked and the maschine starts swapping or OOMing. I'm not sure if that's the issue at hand, but I've seen that before)

x42

2016-12-29 23:07

administrator   ~0019239

Oops, I missed that this is windows.

kjetil

2016-12-29 23:13

reporter   ~0019240

I'm using jack2. I also tried to select portaudio during startup (i.e. not using jack I presume), and it made no difference.

kjetil

2016-12-29 23:18

reporter   ~0019241

Yes, it seems to be gtk related. It takes around 10 seconds to open file dialogs in Gimp 2.8 as well.

kjetil

2016-12-29 23:38

reporter   ~0019242

Googled the problem and found a workaround.[1] It's caused by the floppy disk controller. I disabled it in the device manager (there is no floppy disk on this computer), and now there is no freeze. I guess you probably should investigate if there is anything you can do to fix this in Ardour though since it only seems to happen in gtk programs and there are not many gtk programs on windows.

[1] https://www.reddit.com/r/GIMP/comments/3itrti/gimp_2814_slow_on_win_10/?st=ixb07rqn&sh=c737d6d2

mhartzel

2016-12-30 12:13

reporter   ~0019243

I'm a Ardour user, not developer. I had this same kind of behavior in Linux when I had created a shortcut in the gtk open files dialog that pointed to a path that no longer existed. The delay is probably caused by the dialog checking the existence of paths and waits for a while and then time outs.

My guess is that there is not much one can do here, because the problem does not reside in Ardour code.

kjetil

2016-12-30 16:34

reporter   ~0019244

Well, the gtk libraries are included with the program, so if I were a developer of Ardour, I would at least take a quick look at the gtk code. In addition, it's not unlikely that someone has fixed the bug already, but that it hasn't been included in the version of gtk included with Ardour.

mhartzel

2016-12-30 17:52

reporter   ~0019245

Yes I understand, but it is quite possible that this is no bug. The dialog might check a path that leads to a slow device (floppy, network mount, dvdrom) and that's why it needs to give the device some amount of time to react for the read command. When there is no answer the dialog gives up after a set time.

For example there might be no way for the application to know if a previously mounted network drive is still available other than try to access it. Then it just needs to wait for a reply and timeout after a period of time (for example 10 seconds) if there is no answer.

I wonder why windows does not know there is no floppy drive connected, it probably didn't bother to check. In my opinion it should have done it while booting and mark the device as offline.

kjetil

2016-12-30 19:08

reporter   ~0019246

But it doesn't matter whether you define it as a bug or not since other file requesters (qt, etc.) doesn't use 10 seconds to show up, and then people will see it as a bug.

x42

2016-12-30 20:07

administrator   ~0019247

It also must be system specific as well. There are alot of Windows users for Mixbus (Ardour derivative) which didn't report the issue over the time span of the last 6 years. Also the win7 test-system here is not affected.

Does the file-dialog show drive "A:" in the left side bar?

Best guess this issue is in gtk/gtkfilesystem.c get_volumes_list()

---------
  else if (g_drive_is_media_removable (drive) && !g_drive_is_media_check_automatic (drive))
  {
    /* If the drive has no mountable volumes and we cannot detect media change.. we
     * display the drive in the sidebar so the user can manually poll the drive by
     * right clicking and selecting "Rescan..."
     *
     * This is mainly for drives like floppies where media detection doesn't
     * work.. but it's also for human beings who like to turn off media detection
     * in the OS to save battery juice.
     */
--------

kjetil

2016-12-30 22:40

reporter   ~0019248

No, there is no "A:". There is no floppy disk on the computer either. But isn't there an option to use native file requester when using gtk?

Issue History

Date Modified Username Field Change
2016-12-29 22:55 kjetil New Issue
2016-12-29 22:57 kjetil Note Added: 0019236
2016-12-29 22:59 kjetil Note Added: 0019237
2016-12-29 23:06 x42 Note Added: 0019238
2016-12-29 23:07 x42 Note Added: 0019239
2016-12-29 23:13 kjetil Note Added: 0019240
2016-12-29 23:18 kjetil Note Added: 0019241
2016-12-29 23:38 kjetil Note Added: 0019242
2016-12-30 12:13 mhartzel Note Added: 0019243
2016-12-30 16:34 kjetil Note Added: 0019244
2016-12-30 17:52 mhartzel Note Added: 0019245
2016-12-30 19:08 kjetil Note Added: 0019246
2016-12-30 20:07 x42 Note Added: 0019247
2016-12-30 22:40 kjetil Note Added: 0019248