Topic: 3.8 reports, queries and bugs

[saga]

Thanks, I'll report any findings.

[Juest]

hello once again, so i've gotten another edge case related to audio device management.
for some reason it didn't update the device list when hdmi got replugged or i switched sessions and reconnected.
also i got a really strange playback reset and the output settings gui was glitched.
i should probably restart xmplay but its still a bug nonetheless

[Ian @ un4seen]

Was XMPlay playing something when you connected the HDMI device? XMPlay will only refresh its device list when nothing is playing - if you stop playback and go back to the device list then it should be refreshed. If that doesn't explain what happened then can you reproduce the problem every time you take certain steps or does it only happen sometimes?

[Juest]

Was XMPlay playing something when you connected the HDMI device? XMPlay will only refresh its device list when nothing is playing - if you stop playback and go back to the device list then it should be refreshed. If that doesn't explain what happened then can you reproduce the problem every time you take certain steps or does it only happen sometimes?

it's really sort of random. I tend to leave applications running for extremely long periods of time. I also utilize Virtual Audio Cable which is a virtual driver for loopback usage. it's possible that it may be a edge case due to windows behavior when (dis)connecting to user sessions.
device list didn't seem to have anything to be refreshed. just that the options dialog as a whole was responding erratically to interaction with said glitch.
thanks for the reply anyway, kind of posted and moved on honestly, just restarted xmp and off we go (and my applications later all collapsed due to me playing with some desktop manager extension lol, dont worry about that)
ps: in case you're wondering, i am the same guy, i just havent really bothered creating an account, hope that's okay

[Juest]

sorry, the device change coping mechanism while paused is still not good. it managed to play about a second in some rare cases....

[Juest]

sorry, the device change coping mechanism while paused is still not good. it managed to play about a second in some rare cases....

a workaround was done not a permanent fix since i just noticed the glitch where the visualizer animations stop working and so does the pattern scroll and time counter after changing audio devices prior to unpausing; only stopping and starting playback again resolved that.

[Ian @ un4seen]

Sounds like a few different issues there? To perhaps narrow them down, do they all only happen when using the default output system, or also when using the DirectSound or WASAPI output plugins? Can you also post a screenshot of the output settings glitch, or does it look fine but the controls don't respond?

[Juest]

Sounds like a few different issues there? To perhaps narrow them down, do they all only happen when using the default output system, or also when using the DirectSound or WASAPI output plugins? Can you also post a screenshot of the output settings glitch, or does it look fine but the controls don't respond?

yeah mostly happening with the default microsoft sound mapper or without any plugins.
my apologies, its complicated for a screenshot.

[Juest]

the issue was the whole options dialog not just the output part.

[saga]

I uploaded a memory dump (xmplay_hang_saga_20201105.7z) from an XMPlay hang; I think I might have reported a similar hang before with no clear outcome. XMPlay was done playing an IT file (using the internal encoder). When playback finished, XMPlay did not advance to the next song, but the GUI was still responsive. I then tried to pick a song from the playlist manually, at which point XMPlay finally decided to freeze completely. Trying to repeat the same thing again with the same IT file didn't result in a hang.

[Ian @ un4seen]

I'm not sure why it didn't auto-advance to the next song (I guess the output didn't reach the expected end position for some reason), but it looks like it got stuck in a deadlock applying saved settings when you tried to advance manually. I will look into this more and hopefully post an update for you to try next week.

[Ian @ un4seen]

Here's an update for you to try:

   www.un4seen.com/stuff/xmplay.exe

I think it's unlikely to help with the auto-advancing issue but will hopefully prevent the freeze/deadlock when you then try to manually advance (with "Auto-load settings" enabled). If the auto-advancing problem happens again, please get a dump file of that before trying to advance manually. If you still get the deadlock at that point, please also get another dump file of that.

[saga]

Alright, thanks for the update. I will let you know if the issue happens again.

[saga]

Okay, it happened again. XMPlay didn't auto-advance after some MOD was finished playing (it was set to fade out), however manually advancing didn't result in a hang this time.
I have uploaded the memory dump of XMPlay being stuck at the end of that MOD as xmplay_hang_20210109_saga.7z.

[Ian @ un4seen]

That dump confirms that XMPlay was waiting for the output device to finish playing the buffered data before loading the next track. XMPlay will usually start processing the next track in advance (for gapless playback) but not when the MOD pattern vis is active, so that the display gets all the way to the end.

So it seems like the output device's reported position sometimes isn't reaching the end of the data for some reason. Are you using the default output system or an output plugin, or have you seen the problem happen with both? Here's an update for you to try, which should prevent the problem by not waiting any longer if the output position stops short:

   www.un4seen.com/stuff/xmplay.exe

Let me know if you still see the problem happening.

[saga]

Thanks for the update. I'm only using the WASAPI plugin (using the default output device) these days, so I wouldn't be able to tell right now if it also happens with other output devices.

[Ian @ un4seen]

To perhaps narrow it down, are you using shared or exclusive mode WASAPI, or has it happened with both?

[saga]

I've only been using shared mode. As it happens rather rarely, testing it in exclusive mode is a bit difficult.

[Ian @ un4seen]

OK. Anyway, it will hopefully happen even more rarely now, ie. never

[saga]

It seems like some recent-ish change in XMPlay broke XM pan slides. They are turned into pitch slides instead.
See attached file for an example.

[Ian @ un4seen]

Yeah, I was rearranging parts of the code this week and there were a few little mishaps, including that one (a "break" was omitted so pan slides fell through to pitch slides ). An update (.11) to fix them was uploaded yesterday, so they should be OK now, but please let me know if you do spot any other problems.

[saga]

Yup, sounds much better now. Couldn't find any other issues so far.

[saga]

using the latest stuff version, I noticed that the attached MOD keeps playing indefinitely even if loop is set to "never". It also doesn't seem to help to change any of the MOD-specific auto-loop settings.

Edit: And here's another bug, Arpeggios in this module don't play at all: https://modarchive.org/module.php?41838

[Ian @ un4seen]

Oops, arpeggio was indeed also broken in the recent rearranging. Here's an update to get it working again:

   www.un4seen.com/stuff/xmplay.exe

I think this will also fix the indefinite playback issue, but let me know if it doesn't.

[saga]

Indeed both issues are fixed now. Thanks!