View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007188 | ardour | bugs | public | 2016-12-29 22:55 | 2016-12-30 22:40 |
| Reporter | kjetil | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Windows | OS | Windows | OS Version | 10 |
| Product Version | 5.5 | ||||
| Summary | 0007188: 10 seconds freeze when opening file dialogs | ||||
| Description | Opening some of the dialogs takes around 10 seconds. | ||||
| Steps To Reproduce | 1. 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 Information | Tried 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. | ||||
| Tags | No tags attached. | ||||
|
|
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) |
|
|
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. |
|
|
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) |
|
|
Oops, I missed that this is windows. |
|
|
I'm using jack2. I also tried to select portaudio during startup (i.e. not using jack I presume), and it made no difference. |
|
|
Yes, it seems to be gtk related. It takes around 10 seconds to open file dialogs in Gimp 2.8 as well. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. */ -------- |
|
|
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? |
| 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 |
