Author Topic: 3.8 reports, queries and bugs (Read 320419 times)

saga · « **Reply #675 on:** 20 Oct '19 - 18:48 »

ramon: I think the Delix issue should best be reported in the Delix plugin thread, as it's not a general issue of XMPlay.

Could it be that the recent change about disabled S3M channels broke other stuff? This module used to sound fine, but I have no idea when exactly it stopped working:
https://modarchive.org/module.php?48485
On channel 3 there are some speed commands but they seem to be ignored. Both ST3 and IT (which was used to save the file) play the speed commands as intended.

Ian @ un4seen · « **Reply #676 on:** 21 Oct '19 - 14:42 »

Oops! The S3M channel disabling "fix" in the last update was buggy. Here's another update that should sort it:

www.un4seen.com/stuff/xmplay.exe

This update will also retain the "Priority filetypes" settings of removed plugins in the "PluginTypes" XMPLAY.INI entry.

saga · « **Reply #677 on:** 21 Oct '19 - 20:00 »

Both fixes confirmed. Thanks a lot!

saga · « **Reply #678 on:** 30 Oct '19 - 19:45 »

Right now the amplification slider in the DSP tab has its step size set to 8dB; this is quite a drastic change, in particular if you intended to actually drag the slider but accidentally clicked next to it. Could the step size be lowered to 3dB or 6dB maybe?

Ian @ un4seen · « **Reply #679 on:** 1 Nov '19 - 13:43 »

Yup, I will change that for the next update. In the meantime, you can just click on the other side of the slider to get it back where it was

saga · « **Reply #680 on:** 1 Nov '19 - 23:07 »

After the jump-scare from the sudden increase involume, yes

saga · « **Reply #681 on:** 26 Dec '19 - 12:37 »

Merry Christmas

Here's a little bug in IT replay that cuts off a note prematurely; it's a bit of a hacky situation where a note-off event is fired to slowly fade out the instrument, but a gating effect is achieved by having subsequent instrument numbers recall the instrument's default volume. If those instrument numbers are replaced with volume effects, it plays as intended, but with the instrument numbers the file just stops playing immediately.

Edit: Whoops, forgot to attach the example file!

Ian @ un4seen · « **Reply #682 on:** 27 Dec '19 - 18:00 »

Thanks for the present

Here's an update that seems to get it playing properly:

www.un4seen.com/stuff/xmplay.exe

Let me know if you find that it's broken things for any other IT (or perhaps S3M) files.

saga · « **Reply #683 on:** 30 Dec '19 - 13:22 »

Thanks for the quick fix, now the file plays perfectly!

Rah'Dick · « **Reply #684 on:** 6 Jan '20 - 03:02 »

Hey there!

I'm currently working on a high-resolution "4K" version of my old "Plastic" skin and noticed something:
Normally, when you right-click a volume slider, it mutes XMPlay and the slider knob disappears to reflect the muted state. However, when you right-click a volume knob, the last knob image of the sequence (full volume) is shown. Am I missing something or should there be some kind of "knob_volume_muted" image in the skin?
Nevermind, I was just too stupid to realize that the knob image is being hidden and the panel_main image is shown instead. I had the full volume state there by default, thinking it's never visible.

The main window is already finished, just need to add the mini mode and info window. I hope you don't mind a preview - see attachment.

Many greets and a happy new year,
Thomas

Ian @ un4seen · « **Reply #685 on:** 6 Jan '20 - 16:21 »

That looks great

MachineGhost · « **Reply #686 on:** 11 Jan '20 - 17:14 »

Upgraded to latest Windows 10 build 1909. XMplay 3.8.4 is locking up and becoming non-responsive after a certain number of Internet streaming hours, definitely at least 24 hours. Display is stuck on "buffering".

MachineGhost · « **Reply #687 on:** 6 Feb '20 - 15:48 »

Allright, gonna have to swtich to something else. It keeps locking up on the buffering, regardless of the size. Shame.

winner · « **Reply #688 on:** 6 Feb '20 - 16:43 »

Quote from: MachineGhost on 11 Jan '20 - 17:14

Upgraded to latest Windows 10 build 1909. XMplay 3.8.4 is locking up and becoming non-responsive after a certain number of Internet streaming hours, definitely at least 24 hours. Display is stuck on "buffering".

Do you mean you were running XMplay for 24 or more hours *continously*?

Ian @ un4seen · « **Reply #689 on:** 6 Feb '20 - 16:56 »

Quote from: MachineGhost on 11 Jan '20 - 17:14

Upgraded to latest Windows 10 build 1909. XMplay 3.8.4 is locking up and becoming non-responsive after a certain number of Internet streaming hours, definitely at least 24 hours. Display is stuck on "buffering".

Oops, I only just noticed this post. Is it 24+ hours non-stop of the same stream, or 24 hours in total across multiple streams? Anyway, to hopefully find out what's going wrong, please generate a dump file when the problem is happening and upload that to have a look at here:

ftp.un4seen.com/incoming/

You can use Task Manager's "Create Dump File" option (right-click on the xmplay.exe process) to create the dump file. Please also use this latest XMPlay build when doing so:

www.un4seen.com/stuff/xmplay.exe

Targaff · « **Reply #690 on:** 9 Feb '20 - 06:09 »

Hi Ian,

I've used XMPlay for many a year and it never crossed my mind to register here and ask about this as I thought it was just a bug in the skin I was using, but I recently realized that whatever skin I'm using, if I persist in right-clicking on XMPlay it will eventually break visually and need to be restarted. Is this a known issue? If so, is there a solution? I did search the forum broadly for e.g. right click crash and didn't find a mention, so I decided to take the leap and check.

I've posted a video of it happening here: http://www.targoneva.com/files/xmplay_skin_crash_video.mp4

winner · « **Reply #691 on:** 9 Feb '20 - 17:51 »

Quote from: Targaff on 9 Feb '20 - 06:09

Hi Ian,

I've used XMPlay for many a year and it never crossed my mind to register here and ask about this as I thought it was just a bug in the skin I was using, but I recently realized that whatever skin I'm using, if I persist in right-clicking on XMPlay it will eventually break visually and need to be restarted. Is this a known issue? If so, is there a solution? I did search the forum broadly for e.g. right click crash and didn't find a mention, so I decided to take the leap and check.

I've posted a video of it happening here: http://www.targoneva.com/files/xmplay_skin_crash_video.mp4

I tried to replicate this with the default skin and I could not. I see you are using Classic Start Menu / Classic Explorer. I am too. Also, it looks from your video that XMPlay actually minimized itself at lower left. Try double-clicking the title bar on that window and see if it returns. But you might want to try disabling the Classic GUI and see if that makes a difference.

Targaff · « **Reply #692 on:** 10 Feb '20 - 00:37 »

Quote from: winner on 9 Feb '20 - 17:51

I tried to replicate this with the default skin and I could not. I see you are using Classic Start Menu / Classic Explorer. I am too. Also, it looks from your video that XMPlay actually minimized itself at lower left. Try double-clicking the title bar on that window and see if it returns. But you might want to try disabling the Classic GUI and see if that makes a difference.

Thanks, I perhaps should've been clearer about "needs to be restarted" - it does "restore" but the skinning is broken (see attached). I have to close it from the tray or task manager and restart it. I also turned ClassicShell off and tried again, with the same result.

This has happened intermittently for me ever since I started using XM. Out of curiosity I backed up and did a clean reinstall; the little "minimize" taskbar mentioned here is only visible if I have XMPlay set to Show in Tray only, so I assume that's related to that functionality, but then it does restore okay, so something else must be playing into that problem. I do usually have a number of plugins installed, though nothing out of the ordinary. I'll try adding them back in one at a time and see if I can find a culprit.

Ian @ un4seen · « **Reply #693 on:** 10 Feb '20 - 15:24 »

That's strange. I don't seem to be able to reproduce it here. Please confirm what Windows version you're using and that you're using the latest XMPlay version. Also, does the problem happen when right-clicking in a certain area or could it be anywhere in the XMPlay window? Regarding the "Show in Tray" comment, did you mean the problem only happens when the "Show in" option is set to "tray", or just that the minimized bar thing only appears then but XMPlay still disappears with other "Show in" option settings?

saga · « **Reply #694 on:** 18 Feb '20 - 20:48 »

There appears to be a little edge case bug with the duplicate check of library entries. Steps to reproduce:
1. Have two library entries pointing to different files.
2. Delete one of them.
3. Now edit the track info for the other entry, and make it point to the same file as the deleted library entry.

XMPlay refuses to apply the changes in step 3 until you restart the application, so I guess the deleted library entry somehow continues to live on in memory and is considered in duplicate changes.

Ian @ un4seen · « **Reply #695 on:** 19 Feb '20 - 15:24 »

Yep, XMPlay does currently retain all track info during a session, so that if a removed file is added again (eg. perhaps an undo) then the track info is ready. It does also prevent multiple entries pointing to the same file to avoid conflicts. That could perhaps be changed to allow the filename change if the existing entry has a 0 reference count. The question then is which track info to keep: the existing entry's info or the newly renamed entry's info?

saga · « **Reply #696 on:** 19 Feb '20 - 18:19 »

If the currently edited entry has any overriden tags set, I would expect those to be kept; otherwise, I would expect the cached tags from the old entry to be reused or the file to be scanned again.

Ian @ un4seen · « **Reply #697 on:** 21 Feb '20 - 17:32 »

Here's an update that will allow a track entry to have its filename changed to the same as in an old removed/unreferenced entry:

www.un4seen.com/stuff/xmplay.exe

It will always initially keep the renamed entry's existing info (the old info is lost) and then rescan the file. Not tested much yet, so please report any problems with it.

saga · « **Reply #698 on:** 23 Feb '20 - 11:40 »

Thanks for the update. It seems to work in general, but I think there is an inconsistency when transferring the library data: It seems like the metadata is taken from the previously deleted entry, but the length of the edited entry is kept. It seems to me like that should also be taken from the deleted entry. I was thinking that since you can only edit one library entry at the time, this is not an expensive operation, so maybe XMPlay should simply immediately re-scan the file after hitting the Apply button.

Ian @ un4seen · « **Reply #699 on:** 24 Feb '20 - 15:51 »

What should currently happen is that the edited entry's existing info is retained initially before new info is fetched from the new file. The same as when changing an entry's filename to one that hasn't previously been used. Is the info not getting updated at all from the new file there? You may have to wait a bit for that to happen if XMPlay also has other files to scan.