close
Comments you submit will be routed for moderation. If you have an account, please log in first.
Modify

Opened 4 years ago

Closed 4 years ago

#214 closed bug (fixed)

YAM can't quit after filter action with sound.

Reported by: opiopi Owned by:
Priority: undecided Milestone: YAM 2.7
Component: mail filtering Version: nightly build
Severity: major Keywords:
Cc: OS Platform:
Blocked By: Blocking:
Release Notes:

Description

If i configure YAM to play a sound in the filter action then YAM can't quit.

Step by step to reproduce:

  1. Start YAM. (here Version: YAM 2.7-dev [OS3/m68k] (18.09.2010))
  2. Be sure you have some mails into a folder for testing.
  3. Go to config -> Filters.
  4. Select the 'Action' tab.
  5. Change (or create a new) filter which match the mails in the folder mentioned in 2.
  6. Select 'Play sound' and select a valid soundfile.
  7. Click 'Save' or 'Use'.
  8. Go to the folder mentioned in 2. (here it was incomig)
  9. Select some mails which match the filter mentioned in 5. (here i select 10 mails)
  10. Click 'Filter' in the main window.
  11. The filter is working and the sound is playing. (here it moves the mails and play the sound)
  12. Quit YAM.

YAM show now the thread 'YAM warning':
While trying to cleanup YAM still running sub threads
have been found. ...

Click on 'Retry' in this requester several times doesn't help.
I can't quit YAM.

In the next test i run Scout. It show me that 10 threads are
still running it the requester appear the first time.
After click 'Retry' 6 of them was removed.
The remaining 4 threads seems to run forever even if i click 'Retry'.

Doing the same with the debug version YAM show this requester
too but after click on 'Retry' i can quit YAM.
So maybe it's timing problem?!

I attach the last lines from a '@all all' log from this test
as SoundFilterTest.txt.

Attachments (1)

SoundFilterTest.txt (12.3 KB) - added by opiopi 4 years ago.
last lines of a '@all all' log

Download all attachments as: .zip

Change History (7)

Changed 4 years ago by opiopi

last lines of a '@all all' log

comment:1 Changed 4 years ago by tboeckel

I just tested this on OS4 with about 20 mails to be filtered. After lots of noise due to one sample being played 20 times YAM was able shut down without a single warning.

This really seems to be an issue with the sound.datatype being used. As I said before already, there are several versions out there which don't implement asynchronous playback on a per object basis correctly. The v41sound.datatype I use on my WinUAE setup perfectly plays several samples, but only the last of YAM's playback threads will be notified of the finished playback. All other threads are left in the rain. This indicates that the notification information is stored globally instead in the object's instance data and any additional playback will erase the notification information of the first object.

The former synchronous implementation just aborted playback of any still playing sample whenever a new sample had to be played. From my point of view this is not what one would expect. Constantly aborting the playback until the last filter's playback action finally plays the sample completely is no really good idea.

There are several options to solve this:

  1. switch back to synchronous playback as in YAM 2.6, at least for OS3
  2. remove sound playback from the possible filter actions, because one cannot know how many mails will be filtered and having one sample being played a hundred times because the filter was used that often will be quite noisy.
  3. find a sound.datatype for OS3 which correctly implements simultaneous asynchronous playback of several samples and advice the people to use this.

Personally I would go for either 2 or 3 first.

The sample playback for new mails happens only once for each download attempt, but not for every single mail, which is a far better approach than the per filter and per mail playback.

comment:2 Changed 4 years ago by tboeckel

I investigated a bit and for AmigaOS3 the situation is really bad.

I have two versions of sound.datatype on my WinUAE setup:
v41sound.datatype 41.11 (11.08.2000) © 1998-2000 by Stephan Rupprecht
sound.datatype 44.25 (18.10.2001)

Both can play more than one sample, but with different results. I used a simple 8bit mono sample.

v41sound.datatype can play only one sample and signal the end of the playback. Starting a second playback action while the first is still running will play both, but the end of the first playback will never be signaled, only the end of the second playback.

sound.datatype 44.25 can play up to 4 samples and the end of each playback action is correctly signaled. But from the 5th playback action on while the first 4 are still running I get the same result as with v41sound.datatype. This seems to be due to the mono sample. For a stereo sample I assume the limit would have been 2.

To make a long story short: playing lots of samples with any sound.datatype on AmigaOS3 is a real PITA and will definitely fail sooner or later. Because of this, and the fact that playing a sample for each and every mail being filtered by one filter is absolute non-sense, I really opt to remove the sound playback option from the filters.

Opinions please!

comment:3 Changed 4 years ago by damato

Back from vacation I have now read through the discussion and I have to say that I vote against removing the playback option from the filter action as many people might already use that. Instead I have the feeling that we should probably bring back the old behaviour in that particular case. I understand that putting the playback into a separate thread might be favourable, but if we can't garantuee that this really works because of dependencies against sound.datatype, I think we should synchronize the playback threads somehow so that only one thread can playback at a time. This could be either be done with a separate public sempahore or with reverting to the old mechanism of playing the sample in the main thread because the playback is anyway performed asynchronously (as it alwas has been before we introduced the threads) and thus will not block anything and we also don't really need to know if the playback was successfull or not (we don't need to give the user a feedback for that really).

So for me the option to remove the possibility to play a sound on a filter action is really the worst option and we should think about other possibilities (like I outlined).

comment:4 Changed 4 years ago by opiopi

I use that feature in my filters so i vote of course for not removing
that feature. I use it not for every filter but for some important
filters. Most i hear the sound if i get a mail which inform me that
i got a bill. :-(

I don't have a solution for the problem and i can't believe that
the sound.datatype is so corrupt and nobody complained...

comment:5 Changed 4 years ago by tboeckel

Ok, I will revert the sound playback to the old approach then.
But believe me. Certain parts of AmigaOS3 are really buggy, if you like it or not. And the fact that nobody complained so far is just because nobody has used simultaneous playback of many samples excessively by now. Otherwise this design fault would have be obvious instantly, as it now happend with YAM.

comment:6 Changed 4 years ago by tboeckel

  • Resolution set to fixed
  • Status changed from new to closed

(In [5263]) * YAM_UT.c, Threads.c: removed the sound playback in a separate thread again

and reverted to the old approach. AmigaOS3's sound.datatype is simply too
buggy to be able to play more than 4 samples in different threads without
causing major problems. This closes #214.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber

  • Frank Weber(Reporter, Participant)