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

saga · « **Reply #700 on:** 25 Feb '20 - 22:02 »

The info is updated, but the file duration remains cached until the file is played again. That seems to be the only odd part. Apart from that, the info is carried over correctly. XMPlay has been running for a while so there shouldn't be any background scanning going on.

Ian @ un4seen · « **Reply #701 on:** 26 Feb '20 - 16:34 »

Oh right, I see why that is. To save time, XMPlay won't get a track's duration (until it is next played) if it already has one. Here's an update that removes the renamed track's duration so that it does get refreshed:

www.un4seen.com/stuff/xmplay.exe

Krstfr · « **Reply #702 on:** 25 Apr '20 - 02:12 »

https://modarchive.org/module.php?166897 Doesn't work anymore, the last version i could get it to work on was the 3.8.2 version from the support website's archive.
I currently have version 3.8.4.7

Ian @ un4seen · « **Reply #703 on:** 27 Apr '20 - 17:26 »

The issue with that file it that its final pattern has 2048 rows, which XMPlay isn't expecting to see and treats as corruption (I didn't think any tracker went that high?). But it looks like it genuinely does have 2048 rows, so I will remove that check in the next XMPlay update.

saga · « **Reply #704 on:** 27 Apr '20 - 17:36 »

To give some insights on that, the file was manually hex-edited (the instrument text suggests so), so there are some things in there you'd normally not see in a regular XM track. I'm not aware of any tracker that will actually load and play the file as intended (due to high tempo, speed and row counts), it was pretty much meant to be played with XMPlay.

brycco · « **Reply #705 on:** 6 May '20 - 05:05 »

Posting a bug report here. I'm using xmplay 3.8.3.4 and this .MOD file is not playing properly:

http://modland.com/pub/modules/Protracker/Muttley/zo%20zad.mod

It plays fine in pt2clone and openmpt

And just want to mention this one:
http://modland.com/pub/modules/Protracker/Groo/the%20ultimate%20beeper.mod

Apparently it makes sound in pt2clone despite not having samples...

saga · « **Reply #706 on:** 6 May '20 - 08:33 »

Quote from: brycco on 6 May '20 - 05:05

And just want to mention this one:
http://modland.com/pub/modules/Protracker/Groo/the%20ultimate%20beeper.mod

Apparently it makes sound in pt2clone despite not having samples...

That file exploits some very specific ProTracker bugs (as you can probably imagine from the fact that it doesn't have any samples). While those bugs are emulted in bubsy's ProTracker clone, it's difficult to emulate them outside of that realm - not impossible but not worthy the effort most of the time. It's a conscious decision that I currently don't emulate that bug in OpenMPT for example, and I imagine it's similar for XMPlay.

saga · « **Reply #707 on:** 17 Jun '20 - 21:08 »

Playing this IT file crashes XMPlay at 5:43 (order position 73), without even showing a crash prompt: https://modarchive.org/module.php?187238
It is not necessary to listen through the whole module, just starting playback from that pattern triggers the bug, too. Jumping over that pattern to continue playback at a later stage works fine.

Ian @ un4seen · « **Reply #708 on:** 18 Jun '20 - 15:25 »

Oops. It's the invalid instrument 88 in row 26 combined with DMO effects being enabled that XMPlay is tripping over. Here's an update to fix that:

www.un4seen.com/stuff/xmplay.exe

saga · « **Reply #709 on:** 18 Jun '20 - 19:02 »

Yup, that works better. Thanks for the quick fix!

Rah'Dick · « **Reply #710 on:** 19 Jun '20 - 11:43 »

Hey there!

I saw that there was a discussion a while ago about XMPlay resuming playback when Windows changes the output device, e.g. BT headphones - this is something I'm experiencing regularly now, since I've started using BT speakers and headphones. Problem with these is, they turn themselves off after a while and as a consequence, Windows changes the output device and then XMPlay suddenly starts to play music.

I'm on Windows 10 and there is no "default" or "DirectSound" option, only "Microsoft Soundmapper" (and the playback devices that have been detected + the writers/encoders of course).

Do you happen to have ideas I could try?

Ian @ un4seen · « **Reply #711 on:** 19 Jun '20 - 17:05 »

Here's an update that will hopefully help (by stopping buffering output while paused):

www.un4seen.com/stuff/xmplay.exe

Let me know if the problem still happens.

Rah'Dick · « **Reply #712 on:** 20 Jun '20 - 17:27 »

Seems to be working! Thank you very much!

Juest · « **Reply #713 on:** 25 Jun '20 - 06:19 »

Hey, somehow IT and MO3 playback is broken since i installed 3.8.4, i tried .0 and .12
a thread just hangs and the file never gets played, due to this, switching to another file gets very difficult.

windows 7 sp1 x64 user here

Juest · « **Reply #714 on:** 25 Jun '20 - 06:21 »

sorry for double post, but it appears that most IT files don't play but some IT files do, size might play a role?

Ian @ un4seen · « **Reply #715 on:** 25 Jun '20 - 17:00 »

Please upload an affected file to have a look at here:

ftp.un4seen.com/incoming/

Juest · « **Reply #716 on:** 26 Jun '20 - 20:08 »

Sent a few that don't work, mostly IT and MO3 files are getting stuck, thanks for the reply, Ian.

Juest · « **Reply #717 on:** 26 Jun '20 - 21:32 »

Oh, found out that if I wait long enough it eventually starts playing but very choppy.

Ian @ un4seen · « **Reply #718 on:** 29 Jun '20 - 17:37 »

Your uploaded files are all loading fine here, so that's strange. To see if it's something config related, please try renaming your XMPLAY.INI file (without XMPlay running) for a fresh start and see if the problem still happens then. If that fixes the problem, please upload your old XMPLAY.INI file to have a look at (and hopefully find the cause of the problem).

Juest · « **Reply #719 on:** 1 Jul '20 - 15:55 »

Indeed it's the ini. no clue about some of the differences :/
you'll find it on incoming

Ian @ un4seen · « **Reply #720 on:** 6 Jul '20 - 16:50 »

The problem was caused by the "Virtual channels" setting in the MOD options page, which was making the MOD playback pre-scanning take a long time (one of the things it does is calculate an optimal mix level). 999999 is a bit excessive! The default setting of 256 should be plenty.

Juest · « **Reply #721 on:** 8 Jul '20 - 02:09 »

Quote from: Ian @ un4seen on 6 Jul '20 - 16:50

The problem was caused by the "Virtual channels" setting in the MOD options page, which was making the MOD playback pre-scanning take a long time (one of the things it does is calculate an optimal mix level). 999999 is a bit excessive! The default setting of 256 should be plenty.

Why it was not a issue before then? the point is to allow it go as much it needs just in case.

Ian @ un4seen · « **Reply #722 on:** 8 Jul '20 - 13:58 »

XMPlay's virtual channel code hasn't changed in many years, so I wouldn't expect this issue to be a new thing. Are you sure you didn't change that setting to 999999 around the same time as upgrading to XMPlay 3.8.4? If so, what was the previous version that you were using, and is there no problem if you switch back to that and set virtual channels to 999999 again?

Anyway, I will tweak the virtual channel stuff for the next release to prevent high virtual channel limits affecting CPU usage, but high limits will still be using more memory, so I wouldn't recommend it. When there are no virtual channels free, it will be the quietest one that is killed/replaced, so you're very unlikely to hear any difference over even 100 voices.

carrot007 · « **Reply #723 on:** 12 Jul '20 - 18:47 »

Hey has something change in 384?

I have a mod that will not play in it. (fresh unzipped copy). Where as 383 works fine.

mod.monday, amiga, pretty "chippy" so usese lots of things I guess?

(tried to post after joining last night so sory if it shows elsewhere, I had a but of wine! It really is odd though! Most others played fine (oh long time user, nice software!))

winner · « **Reply #724 on:** 12 Jul '20 - 20:08 »

Carrot007, upload the affected file to ftp.un4seen.com/incoming/ so the developer can look at it.

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

Juest

Juest

Juest

Juest

Juest

Juest