SoundPlay - application executable file get their "modified date" attribute updated after opening the program

Help
1

Well, this issue is a really weird one… : I had been using SoundPlay (the old BeOS app) since years… never had any issue, but recently I am facing the following problem:

Any time that I open SoundPlay from the Tracker (by double-click in the application file), I notice that the ‘Modified’ attribute in the Tracker get changed… (like the executable file were modified by just doing a doble click on it). In addition, the application stopped working (try to play the file, but only noise came out). I recorder a short video, to show this behaviour:

https://0x0.st/XOXS.mpg

Any idea where I can start to search? The Tracker behaviour is really weird, and I am pretty sure that SoundPlay stopped working suddently, is not coincidence. Could be related to the file attributes?

Thank you!!

2

Hello. I continued looking for some clues. Looks like the checksum of the file is also “modified” by just running the application (notice how the MD5 checksum changes after each execution):

I tried with a fresh copy of SoundPlay downloaded from BeShare, and I have the same issue. However, apparently is the only application that suffer this issue (tried with other old BeOS application, but cannot reproduce it). Also, tried rebooting and using a previous Haiku hrev, but the issue persists. Wathever is causing this issue, is not related to Tracker or some other system package (otherwise, it would be fixed when booting with a previous system state).

Maybe is some settings corruption? Some configuration related to the app signature?

3

Maybe try using some sort of binary diff on it to see how much of a change is happening, and where?
Something like:

xxd SoundPlay > SoundPlay.old.hd
SoundPlay
xxd SoundPlay > SoundPlay.new.hd
diff -y SoundPlay.*.hd
1 Like
4

If I remember well soundplay wasn’t freeware, perhaps it modifies some other attribute with some stats? Did it have a limit of its free usage and did you reach that limit? Have you tried to delete its settings file/folder from ~/config/settings?

1 Like
5

Hello zuMi. Long time ago the developer released a free key, to be able to continue using the application. I had been using it for years, so I don’t think that could be the issue. However, I would try deleting the config/settings file. Thanks for the suggestion :slight_smile:

Coincidentally, the application also stopped working: the application starts but cannot reproduce sound files.

6

I have two hypotheses:

  1. It may use some other file placed somewhere that got corrupted. Did you try it on a clean install?
  2. Did you try to bring the system date back?
7

Hello. Thank you for your answers and suggestions. I tried on a different laptop (an old Haiku installation from around April 2024), and SoundPlay works perfectly fine, but also the executable file changes their timestamp every time that the application runs.

I tried the command mention by @coolcoder613 , and there is the only “change” is in the line 0009f620:

/boot/apps/SoundPlay> diff SoundPlay.old.hd SoundPlay.new.hd
40803c40803
< 0009f620: 0800 0000 0800 0000 0000 0000 0000 0000  ................
---
> 0009f620: 0600 0000 0800 0000 0000 0000 0000 0000  ................
/boot/apps/SoundPlay>

After running several times, and repeating the process, the only difference is on line 0009f620 I found some pattern: looks like every time that the application is executed, it loops between some of the following values:

/boot/apps/SoundPlay> grep 0009f620 *.hd
SoundPlay.new.hd:0009f620: 0600 0000 0800 0000 0000 0000 0000 0000  ................
SoundPlay.new2.hd:0009f620: 0200 0000 0800 0000 0000 0000 0000 0000  ................
SoundPlay.new3.hd:0009f620: 0800 0000 0800 0000 0000 0000 0000 0000  ................
SoundPlay.old.hd:0009f620: 0800 0000 0800 0000 0000 0000 0000 0000  ................

Therefore, looks like is something inherent to SoundPlay. I need to test more deeply in this second laptop, to see if there is something different.

About the main issue (why SoundPlay stopped working), I also found something: apparently SoundPlay stopped working with MP3 and WAV files, but is still able to reproduce .M4A files.

8

This may be due to the timer bug that was exposed in recent nightlies. Please test again after hrev57916 and see if the problem is solved.

1 Like
9

Hi @waddlesplash , thanks for your help. I tried again using hrev57921, but the issue persists.

However, I found a debug tool inside the SoundPlay folder (SoundPlayState), that maybe could bring more information. Allow me a couple of days to do some more testing.

10

There are some other users reporting the problems haven’t gone away either. Please let me know if hrev57936 improves things.

11

Hi @waddlesplash ! I tested again in hrev57936. Unfortunatelly, I am facing the same issue.

In addition, I am noticing that after starting and closing SoundPlay a couple of times, I end with the SoundPlay application (the window closes) but the process is still running. I try to kill it usingProcess Controller but even if I select the process and kill it, it continues running, preventing the application to be restarted.

Below this line, there is the output of SoundPlayState tool:

> Soundplay - process started, but without main window - cannot kill process, even from Process Controller)
> =========================================================================================================
> 
> /boot/apps/SoundPlay/Extras/SoundPlayState> ./SoundPlayState 
>   3772  SoundPlay, waiting for semaphore -1 (), currently held by thread 1908925188
>   3775* visualizer, sleeping 
>   3776* visualizer, sleeping 
>   3777* visualizer, sleeping 
>   3778* visualizer, sleeping 
> 
> If you ran this command because SoundPlay is locked up, please leave SoundPlay in its locked state if possible. You may be asked to run some additional tests.
> /boot/apps/SoundPlay/Extras/SoundPlayState>
12

In addition, just for comparition purposes, there is the SoundPlayState output, for both MP3 and M4A play:

> Soundplay - playing an MP3 (no sound - vu meters not working):
> =====================================================
> /boot/apps/SoundPlay/Extras/SoundPlayState> ./SoundPlayState 
>   1112  SoundPlay, waiting for semaphore -1 (), currently held by thread 1909294468
>   1115* visualizer, waiting for semaphore 59264846 (visualization buffer), currently held by thread 1116
>   1116* visualizer, waiting for semaphore 59264846 (visualization buffer), currently held by thread 1116
>   1117* visualizer, sleeping 
>   1118* visualizer, waiting for semaphore 59264846 (visualization buffer), currently held by thread 1116
>   1120* SoundPlay window thread, waiting for semaphore -1 (visualization buffer), currently held by thread 1116
>   1121* helper, sleeping 
>   1123* w>Tip of the day, waiting for semaphore -1 (visualization buffer), currently held by thread 1116
>   1126  w>Spectrum Analyzer, waiting for semaphore -1 (visualization buffer), currently held by thread 1116
>   1127  _BMediaRoster_, waiting for semaphore -1 (visualization buffer), currently held by thread 1116
>   1128* SoundPlay control, waiting for semaphore -1 (visualization buffer), currently held by thread 1116
>   1130  w>VU, waiting for semaphore -1 (visualization buffer), currently held by thread 1116
>   1141  w>Analog VU, waiting for semaphore -1 (visualization buffer), currently held by thread 1116
>   1142* displayupdater, receiving 
>   1144* Magic Knight Rayearth - -loader, receiving 
>   1148* bubble, waiting for semaphore -1 (visualization buffer), currently held by thread 1116
> 
> If you ran this command because SoundPlay is locked up, please leave SoundPlay in its locked state if possible. You may be asked to run some additional tests.
> /boot/apps/SoundPlay/Extras/SoundPlayState>

.

Soundplay - playing an M4A (sound fine - working):
=================================================

/boot/apps/SoundPlay/Extras/SoundPlayState> ./SoundPlayState 
  1112  SoundPlay, waiting for semaphore -1 (), currently held by thread 1924072996
  1115* visualizer, waiting for semaphore 59264846 (visualization buffer), currently held by thread 1115
  1116* visualizer, waiting for semaphore 59264846 (visualization buffer), currently held by thread 1115
  1117* visualizer, sleeping 
  1118* visualizer, waiting for semaphore 59264846 (visualization buffer), currently held by thread 1115
  1120* SoundPlay window thread, waiting for semaphore -1 (visualization buffer), currently held by thread 1115
  1121* helper, sleeping 
  1123* w>Tip of the day, waiting for semaphore -1 (visualization buffer), currently held by thread 1115
  1126  w>Spectrum Analyzer, waiting for semaphore -1 (visualization buffer), currently held by thread 1115
  1127  _BMediaRoster_, waiting for semaphore -1 (visualization buffer), currently held by thread 1115
  1128* SoundPlay control, waiting for semaphore -1 (visualization buffer), currently held by thread 1115
  1130  w>VU, waiting for semaphore -1 (visualization buffer), currently held by thread 1115
  1141  w>Analog VU, waiting for semaphore -1 (visualization buffer), currently held by thread 1115
  1142* displayupdater, receiving 
  1148* bubble, waiting for semaphore -1 (visualization buffer), currently held by thread 1115
  1273* media extractor thread, waiting for semaphore 70452466 (media extractor thread sem), currently held by thread 1273
  1274* Magic Knight Rayearth - -loader, receiving 

If you ran this command because SoundPlay is locked up, please leave SoundPlay in its locked state if possible. You may be asked to run some additional tests.
/boot/apps/SoundPlay/Extras/SoundPlayState>
13

Can you try to pinpoint more closely when the problem started (i.e. what is the last working hrev)? Perhaps this isn’t related to the timers changes after all, since the most significant one of those was undone.

14

Yes, I managed to reproduce it now.

I didn’t manage to reproduce this, however…

15

Well, I did some basic testing and didn’t manage to determine the cause, or when the regression occurred; but I didn’t do a full bisect either. If you have time to try and determine when the problem started in a narrower range than simply “since April”, that would be very helpful.

16

Hi @waddlesplash . Sure, I tried booting into previous states, but the issues still persist, and this don’t make much sense to me, honestly (this is the reason because I originally believed that the issue could be related to some configuration file that is the same across different hrev.)

To avoid “false-positives”, I will try downloading again a previous nightly and install it from scratch. Maybe is the best way to trace this issue. This will take some time, but I do not have more ideas… :slight_smile:

17

How old were the previous states? (And did you make really sure that the bootloader worked correctly and indeed booted into the previous states?)

18

If your hardware and your network bandwidth are allowing it, it may be interesting to download a nightly iso and to install it in a VM. Have zip of your soundplay folder handy on an USB key, most VM frontends will allow USB redirection so you will be able to copy it easily. Note hrev number somewhere and check for your bug presence. Download another iso install the new VM, delete the previous. Rinse and repeat till you found the guilty hrev.