Where is the best place to raise an AMPlayer bug

Hi,

Is the Bugs part of the ROOL site for bugs in RISC OS itself or for related applications?

I’ve had a bug reported to me that I’ve traced to AMPlayer 1.42.

Steps to reproduce:
1) Start the AMPlayer front end
2) Play an MP3
3) Close the front end
4) On the command line type *amstop
5) Start up the Tasks window
6) Re-size the AMPlayer antishock

Results in : “Internal error on Data Transfer at &202182c4” (address varies).

Not sure which hardware my reporter was using. But I reproduced on an ARMX6.

It would appear likely that when the MP3 is stopped, possibly there is a reference to a stale memory address i.e. the anti-shock is still available to be modified when no MP3 itself is playing.

Tony.

Is the Bugs part of the ROOL site for bugs in RISC OS itself or for related applications?

I believe that it’s only for the ROM and software that’s included in the base HD4 image. Bugs in third-party software should be reported to the relevant developer (hopefully the documentation states who that is!)

That reminded me of that AMPlayer has an issue with some Select versions of RISC OS. When you modify the replay position, RISC OS won’t stop complaining that it detects a stack imbalance.

I managed to stop the fury of error boxes which allowed me to check with *showregs and get an idea of what happens. To summarize, OS 6 stores some info at the bottom of the system stack area (you know on the 1MB boundary (R13 << 20) >> 20) before the calling callbacks, including a putting a copy of R13 (at offset 0xC) which it retrieves afterwards to check against current value of R13.

What I have seen is that the new R13 is within the system stack area limits but the value in R6, loaded from offset 0xC of the stack area, is an address pointing to offset 0×2FC in the AMPlayer workspace. In other words there is no stack imbalance but AMPlayer overwrites offset 0xC of the system stack area.