HydrogenAudio

foobar2000 version: 1.1.7

foobar2000's default user interface implements Microsoft Active Accessibility (MSAA) for its playlist control in order to make it accessible to screen readers and other assistive technologies.

Whenever playback is started or stopped, an EVENT_OBJECT_NAMECHANGE win event is fired on every playlist item from the currently playing item to the end of the playlist. For example, in a playlist containing 2 items, if the first item is playing, EVENT_OBJECT_NAMECHANGE is fired on both items whenever playback is started, paused, resumed or stopped. This becomes a very serious problem in large playlists, as foobar2000 floods the system with unnecessary events, causing some MSAA clients to freeze indefinitely in the worst case. EVENT_OBJECT_NAMECHANGE should only be fired if the name of the item actually changes.

Steps to reproduce:
1. Load or create a playlist containing more than 1 item.
2. Set up an MSAA event inspection tool such as AccEvent or AccProbe to watch the foobar2000 application.
3. Play the first item.
Expected: EVENT_OBJECT_NAMECHANGE should not be fired on any playlist items, as their name has not changed.
Actual: EVENT_OBJECT_NAMECHANGE is fired on all playlist items.

I'd be glad to provide any further information requested or help with debugging.

Thanks,
Jamie

I can confirm this behaviour with the latest FB2k 1.1.9 and NVDA screen reader on Windows 7 32 and 64 bit. It becomes annoying when you have 2000+ items in the playlist. CPU usage for both Foobar and NVDA goes to about 30% each on both my systems.

Hello,
This has been brought to my attention by -MM- I have then consulted it with Jamie and finally tried to reproduce.
I can confirm it too.
This is most evident with Windows 7 and never because of a newer accessibility framework UIAutomation which is available since that version of Windows by default.
Can this be looked into please?

I am also having the same issue. Scrolling through a playlist with global hotkeys will cause problems due to this,
for example NVDA will have problems until all the events are processed).
My component info:

Core (2011-11-04 14:08:40 UTC)
    foobar2000 core 1.1.9
foo_albumlist.dll (2011-11-04 14:07:12 UTC)
    Album List 4.5
foo_cdda.dll (2011-11-04 14:07:04 UTC)
    CD Audio Decoder 3.0
foo_converter.dll (2011-11-04 14:06:48 UTC)
    Converter 1.5
foo_dsp_std.dll (2011-11-04 14:07:12 UTC)
    Standard DSP Array 1.0
foo_fileops.dll (2011-11-04 14:06:12 UTC)
    File Operations 2.1.3
foo_input_std.dll (2011-11-04 14:06:56 UTC)
    Standard Input Array 1.0
foo_rgscan.dll (2011-11-04 14:06:54 UTC)
    ReplayGain Scanner 2.1.2
foo_seek_box.dll (2011-07-25 00:54:46 UTC)
    Seek box 0.0.3
foo_texttools.dll (2011-07-16 13:27:48 UTC)
    Text Tools 1.0.5
foo_ui_std.dll (2011-11-04 14:07:18 UTC)
    Default User Interface 0.9.5

Does this problem still persist in 1.1.10 beta 2?

The problem with nameChange event flooding is fixed in 1.1.10beta2. Thanks very much!

Unfortunately, in the process of testing, I discovered another similar event flooding situation. If many items are selected or unselected at the same time (e.g. select all, clear selection, selecting a single item when many items are selected, etc.), this can result in a flood of EVENT_OBJECT_SELECTIONADD/EVENT_OBJECT_SELECTIONREMOVE events. One way to get around this is to instead fire a single EVENT_OBJECT_SELECTIONWITHIN on the list itself (child ID 0) when there is going to be a large change to the selection. However, this could be tricky to implement and i notice that even SysListView32 controls don't seem to do this. This issue is nowhere near as severe as the nameChange flood, though, as it only happens when working with selection, which is less common. I only noticed it because I was testing by sending all items from my Album List to the playlist, which initially selects all sent items.

Thanks for your continued support of accessibility.

OK, changed that part as well.

Thanks verry much for the fixes.
I will be testing them during the following days.
It's time to flattr fb2k again.

Greetings

Peter

Tested with latest beta on a playlist containing approx. 10k tracks, works perfectly. Thank you very much for the fix.