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

saga · « **Reply #150 on:** 2 Apr '14 - 18:33 »

Quote from: Ian @ un4seen on 27 Jan '14 - 17:20

Quote from: saga on 23 Jan '14 - 22:37
I've noticed this error to happen for quite a while now, although it only happens rather rarely. When double-clicking the vis to make it go fullscreen, sometimes the window is indeed extended to the full screen size, but the vis (mostly or maybe only managed to reproduce it with the built-in pattern vis) kept rendering at the previous windows resolution in the top-left corner of the window.

Does it happen during playback, or while paused/stopped? If during playback, does it correct itself eventually, eg. at the next pattern? Please also check whether channel muting via the mouse middle-clicking works then.

I just had this one again, I didn't remember to check the middle-clicking, but it definitely didn't fix itself by just waiting for the next pattern to come by. I've attached a screen of the situation... In the middle you can see a frozen pattern vis covered by some context menus that won't go away (no redraws happening), and only the small pattern vis in the upper left is actually scrolling.

saga · « **Reply #151 on:** 4 Apr '14 - 19:07 »

It seems like module comments with URLs in them aren't copied to the clipboard correctly. Try copying the module comment of the attached test module to the clipboard and you should notice that anything following the URL in the comment text won't be copied.

saga · « **Reply #152 on:** 6 Apr '14 - 01:01 »

Another update on the fullscreen vis bug: Channel muting using middle-clicking works. The clicks are registered at the area where the full-screen vis would be expected to be drawn, even if that part is being cut off. This time, I didn't get any vis updating at all, i.e. I just saw the frozen vis in the middle of the screen, nothing else.

Ian @ un4seen · « **Reply #153 on:** 7 Apr '14 - 18:07 »

Quote from: saga on 2 Apr '14 - 18:33

Quote from: Ian @ un4seen on 27 Jan '14 - 17:20
Quote from: saga on 23 Jan '14 - 22:37
I've noticed this error to happen for quite a while now, although it only happens rather rarely. When double-clicking the vis to make it go fullscreen, sometimes the window is indeed extended to the full screen size, but the vis (mostly or maybe only managed to reproduce it with the built-in pattern vis) kept rendering at the previous windows resolution in the top-left corner of the window.

Does it happen during playback, or while paused/stopped? If during playback, does it correct itself eventually, eg. at the next pattern? Please also check whether channel muting via the mouse middle-clicking works then.

I just had this one again, I didn't remember to check the middle-clicking, but it definitely didn't fix itself by just waiting for the next pattern to come by. I've attached a screen of the situation... In the middle you can see a frozen pattern vis covered by some context menus that won't go away (no redraws happening), and only the small pattern vis in the upper left is actually scrolling.

I'm still not certain what's causing the problem, but I'll send you a little update to try.

Quote from: saga on 4 Apr '14 - 19:07

It seems like module comments with URLs in them aren't copied to the clipboard correctly. Try copying the module comment of the attached test module to the clipboard and you should notice that anything following the URL in the comment text won't be copied.

Oops! I think that would've been introduced in the eliminating duplicate URLs update. I'll sort it for the next update.

saga · « **Reply #154 on:** 7 Apr '14 - 20:00 »

Thanks, I'll see if the update helps. Since the problem was occuring randomly (just toggling between fullscreen and windowed mode a few times in a row wouldn't be enough to reproduce the problem most of the time), I guess it will take a while until I can be sure whether it's fixed or not.

EDIT: Well, that was quick. I can still reproduce the pattern vis bug. This time, I could even reproduce it four times while playing the same song by just double-clicking the vis often enough (I swear, I only did it for science!

). The internal vis rendering size seems to stay at the size of the windowed vis, and anything around that small area isn't updated anymore. Switching to another vis eliminates the problem.
I've attached another screenshot to demonstrate the situation.

Ian @ un4seen · « **Reply #155 on:** 8 Apr '14 - 14:31 »

Hmm. I'll try to think of something else to try, and then send it for you to try.

saga · « **Reply #156 on:** 22 Apr '14 - 15:30 »

I was able to reproduce this bug on the compo machine at Revision too, btw, so it's definitely not just me (and luckily it didn't happen during the tracked music compo, too).

Another thing we noticed is that disabling bubbles alltogether doesn't seem to work. We wanted no song title bubbles to show up on the fullscreen pattern animation at all, but having the info bubbles set to [_] Enable [_] ... including fullscreen still shows them when changing tracks on a fullscreen vis.

Ian @ un4seen · « **Reply #157 on:** 22 Apr '14 - 16:55 »

That MOD pattern vis issue still has me stumped. I think I'll have to send you a debug version to (hopefully) get some clues.

Regarding the title bubbles, there are separate options for that in the "Titles" options page

saga · « **Reply #158 on:** 4 May '14 - 20:17 »

I got a crash when trying to play a module file, I uploaded the dump as xmplay-crash-saga.7z. The second time I tried to play it, XMPlay froze while jumping around in the module, but I forgot to create a memory dump of that. After that, it played as intended, so I'm not sure if the dump is going to be helpful anyway...

Ian @ un4seen · « **Reply #159 on:** 5 May '14 - 16:46 »

I think I see what caused the crash. Here's an update for you to try...

www.un4seen.com/stuff/xmplay.exe

Let me know if you still get the crashing.

Krstfr · « **Reply #160 on:** 6 May '14 - 23:52 »

Is it just me, or is the playlist too big? I tried adding the ModArchive torrents, 2008-2013 to XMPlay, and once it recognised all the files were there, (not the length and stuff) you know, stopped showing "adding", it stops showing info (I have it to where it shows time next to title) for added files, after less than a minute, XMPlay crashes, would there be a way to allow that many files?

I saw the thread about 4tb hard drives, corrupt files, yada yada. But the file made XMPlay crash, worked in OpenMPT, zipped or unzipped.
It wasn't a song I like, so it doesn't matter.

raina · « **Reply #161 on:** 7 May '14 - 09:56 »

Quote from: Krstfr on 6 May '14 - 23:52

It wasn't a song I like, so it doesn't matter.

That is practically the equivalent of "nvm, fixed it" in terms of helpfulness. There just might be another person trying to play the TMA torrents in XMPlay, some time, somewhere. Obviously something isn't right and if you've tracked the problem down to file level, why not go all the way and upload the file to ftp://ftp.un4seen.com/incoming/ for inspection. If the problem can be fixed in XMPlay, not only does it help other people trying to play that particular file but potentially fixes the handling for a lot of files with similar properties.

winner · « **Reply #162 on:** 10 May '14 - 20:33 »

XMPlay 3.8.0.14 is crashing when I use the Winamp Vis Wrapper plugin and Winamp AVS v2.81d visualizer.

This used to work fine on my system, so I checked functionality with older versions of XMPlay (which exist in the same XMPlay folder as version 3.0.8.14).

With version 3.7.0.51 it works. With versions 3.8.0.9 and 3.8.0.10 it works. So it seems that something has changed within 3.0.8.14 to cause the trouble.

Here are the error details from Windows' Event Viewer:

Faulting application name: xmplay.exe, version: 3.8.0.14, time stamp: 0x53679707
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x059865ac
Faulting process id: 0x13f0
Faulting application start time: 0x01cf6c825e123ca1
Faulting application path: Q:\PROGRAMS\XMPlay\xmplay.exe
Faulting module path: unknown
Report Id: aa9e173b-d875-11e3-a8f7-00241d1c49e4

[EDIT: I've found also that visualizers Tripex3 (v3.12) and Milkdrop (v2.24) DO work, while Geiss 2 (v1.0) DOES NOT work with XMPlay 3.0.8.14, where these all used to work on older versions of XMPlay.]

[EDIT: I noticed that .ini files were associating with my older versions, i.e., XMPlay_3_8_0_10.ini, while of course my main .ini file is XMPlay.ini. The older .ini files were much simpler than my customized one. So as a test to eliminate my .ini file as a cause, I renamed XMPlay.ini and let XMPlay 3.8.0.14 generate a new one. The problem persisted, so apparently not an issue with my .ini file either.]

Krstfr · « **Reply #163 on:** 13 May '14 - 02:27 »

Quote from: raina on 7 May '14 - 09:56

Quote from: Krstfr on 6 May '14 - 23:52
It wasn't a song I like, so it doesn't matter.
why not go all the way and upload the file to ftp://ftp.un4seen.com/incoming/ for inspection.

The file is jitters_.it: http://modarchive.org/module.php?169893 I tried to find it on my comp, but I guessed I deleted it.
Freshly downloaded from TMA, still crashes XMPlay. Also, sorry for taking a while to respond, un4seen is blocked at school.

piovrauz · « **Reply #164 on:** 13 May '14 - 10:07 »

I can confirm that file crashes "my" XMPlay 3.8.0.14 here too.
More than crashes it, it just XMPlay window just closes as soon the fil is dragged on the playlist.
Windows' Event Viewer doesn't report anything for XMPlay, but it does report the error I got with an ext4 driver.
Win7 64bit if it matters.

winner · « **Reply #165 on:** 14 May '14 - 03:56 »

Quote from: Krstfr on 13 May '14 - 02:27

Quote from: raina on 7 May '14 - 09:56
Quote from: Krstfr on 6 May '14 - 23:52
It wasn't a song I like, so it doesn't matter.
why not go all the way and upload the file to ftp://ftp.un4seen.com/incoming/ for inspection.
The file is jitters_.it: http://modarchive.org/module.php?169893 I tried to find it on my comp, but I guessed I deleted it.
Freshly downloaded from TMA, still crashes XMPlay. Also, sorry for taking a while to respond, un4seen is blocked at school.

Also crashes XMPlay on my system, Windows 7 x64. The file plays in VLC player.

piovrauz · « **Reply #166 on:** 14 May '14 - 08:59 »

I noticed it plays in Modplug tracker too. If I save as a new it file it will still crash XMPlay, so I don't think it's amalformed file.

Ian @ un4seen · « **Reply #167 on:** 14 May '14 - 16:34 »

Quote from: Krstfr on 13 May '14 - 02:27

The file is jitters_.it: http://modarchive.org/module.php?169893 I tried to find it on my comp, but I guessed I deleted it.

Oops. Here's an update that should get it working...

www.un4seen.com/stuff/xmplay.exe

Quote from: winner on 10 May '14 - 20:33

XMPlay 3.8.0.14 is crashing when I use the Winamp Vis Wrapper plugin and Winamp AVS v2.81d visualizer.

To help narrow down where the problem lies, please try removing all other plugins (leaving just XMPLAY.EXE and Winamp vis plugins), and see if the crash still happens then (with the latest EXE above). If it does persist, to get some more info on it, please upload a dump file for it. You can get Windows to generate a dump file by applying this "localdumps-full" registry entry...

www.un4seen.com/stuff/localdumps.zip

Windows will then generate a dump file (in "C:\Users\<yourname>\AppData\Local\CrashDumps") whenever a crash occurs. Once you have got a dump file for the XMPlay crash, you can compress and upload it here...

ftp.un4seen.com/incoming/

You can use the "localdumps-off" registry file to disable the dump file generation afterwards.

winner · « **Reply #168 on:** 15 May '14 - 02:37 »

Quote from: Ian @ un4seen on 14 May '14 - 16:34

Quote from: winner on 10 May '14 - 20:33
XMPlay 3.8.0.14 is crashing when I use the Winamp Vis Wrapper plugin and Winamp AVS v2.81d visualizer.

To help narrow down where the problem lies, please try removing all other plugins (leaving just XMPLAY.EXE and Winamp vis plugins), and see if the crash still happens then (with the latest EXE above). If it does persist, to get some more info on it, please upload a dump file for it. You can get Windows to generate a dump file by applying this "localdumps-full" registry entry...

www.un4seen.com/stuff/localdumps.zip

Windows will then generate a dump file (in "C:\Users\<yourname>\AppData\Local\CrashDumps") whenever a crash occurs. Once you have got a dump file for the XMPlay crash, you can compress and upload it here...

ftp.un4seen.com/incoming/

You can use the "localdumps-off" registry file to disable the dump file generation afterwards.

Ian, I did this test. I downloaded the current XMPlay 3.8.0.5 install package and unzipped to a new folder. I copied over the Winamp Vis Wrapper (xmp-wavis.dll v1.0.5.0) and the Winamp AVS visualization files from my main installation folder, to same subfolders, Plugins and Vis. I replaced XMPlay version 3.8.0.5 with 3.8.0.15.

With XMPlay version 3.8.0.15, I loaded up some MP3 files and started AVS via the Winamp Vis Wrapper. This time AVS does not crash. However, the display does not move to the music and sometimes causes XMPlay to hang (window frozen, but no crash). When I tap my space bar, which normally causes the visualizer to progress to a new visualization setting/display, the AVS window shows "Loading... (wait)" and hangs.

I then replaced XMPlay with version 3.8.0.5. With this version, the AVS visualizer works perfectly.

[EDIT: Since the crash occurred only with my normal XMPlay folder and setup, I've tried to FTP a zipped crashdump file originating from there. I think the transfer worked, but I tried a new method and I'm not sure.]

Krstfr · « **Reply #169 on:** 15 May '14 - 23:05 »

What exactly was the reason for that file crashing XMPlay?
I guess it doesn't matter much now that it is fixed, but I have a curiosity about it.

Ian @ un4seen · « **Reply #170 on:** 16 May '14 - 17:56 »

Quote from: winner on 15 May '14 - 02:37

Ian, I did this test. I downloaded the current XMPlay 3.8.0.5 install package and unzipped to a new folder. I copied over the Winamp Vis Wrapper (xmp-wavis.dll v1.0.5.0) and the Winamp AVS visualization files from my main installation folder, to same subfolders, Plugins and Vis. I replaced XMPlay version 3.8.0.5 with 3.8.0.15.

With XMPlay version 3.8.0.15, I loaded up some MP3 files and started AVS via the Winamp Vis Wrapper. This time AVS does not crash. However, the display does not move to the music and sometimes causes XMPlay to hang (window frozen, but no crash). When I tap my space bar, which normally causes the visualizer to progress to a new visualization setting/display, the AVS window shows "Loading... (wait)" and hangs.

I then replaced XMPlay with version 3.8.0.5. With this version, the AVS visualizer works perfectly.

[EDIT: Since the crash occurred only with my normal XMPlay folder and setup, I've tried to FTP a zipped crashdump file originating from there. I think the transfer worked, but I tried a new method and I'm not sure.]

It looks like it may be that the VIS_AVS.DLL plugin isn't compatible with Data Execution Prevention, resulting in a crash when it tries to call an address without the correct permissions. Recent XMPlay builds have been marked as being compatible with Data Execution Prevention (NXCOMPAT). You could try adding XMPLAY.EXE to the DEP exception list (System Properties -> Advanced -> Performance Settings -> Data Execution Prevention).

Quote from: Krstfr on 15 May '14 - 23:05

What exactly was the reason for that file crashing XMPlay?
I guess it doesn't matter much now that it is fixed, but I have a curiosity about it.

The problem was related to support for funky IT files that have a non-standard number of rows (over 256), which was added in XMPlay 3.8. The modified code wasn't allocating enough memory to read the pattern data in this file's case, specifically for channel 1 in pattern 13; the Lxx effects get separated into G00 + Dxx effects by XMPlay so require a bit more memory.

winner · « **Reply #171 on:** 17 May '14 - 00:17 »

Quote from: Ian @ un4seen on 16 May '14 - 17:56

Quote from: winner on 15 May '14 - 02:37
Ian, I did this test. I downloaded the current XMPlay 3.8.0.5 install package and unzipped to a new folder. I copied over the Winamp Vis Wrapper (xmp-wavis.dll v1.0.5.0) and the Winamp AVS visualization files from my main installation folder, to same subfolders, Plugins and Vis. I replaced XMPlay version 3.8.0.5 with 3.8.0.15.

With XMPlay version 3.8.0.15, I loaded up some MP3 files and started AVS via the Winamp Vis Wrapper. This time AVS does not crash. However, the display does not move to the music and sometimes causes XMPlay to hang (window frozen, but no crash). When I tap my space bar, which normally causes the visualizer to progress to a new visualization setting/display, the AVS window shows "Loading... (wait)" and hangs.

I then replaced XMPlay with version 3.8.0.5. With this version, the AVS visualizer works perfectly.

[EDIT: Since the crash occurred only with my normal XMPlay folder and setup, I've tried to FTP a zipped crashdump file originating from there. I think the transfer worked, but I tried a new method and I'm not sure.]

It looks like it may be that the VIS_AVS.DLL plugin isn't compatible with Data Execution Prevention, resulting in a crash when it tries to call an address without the correct permissions. Recent XMPlay builds have been marked as being compatible with Data Execution Prevention (NXCOMPAT). You could try adding XMPLAY.EXE to the DEP exception list (System Properties -> Advanced -> Performance Settings -> Data Execution Prevention).

Ian, this didn't help. Performance options were set for "Turn on DEP for essential Windows programs and services only." So I switched to "Turn on DEP for all programs and services except those I select" and rebooted my computer as required. When I tried to add XMPlay version 3.8.0.15, Windows responded with "This program must run with data execution prevention (DEP) enabled. You cannot turn off DEP for this program." This is a bit troubling since I do enjoy being able to use AVS with XMPlay.

saga · « **Reply #172 on:** 17 May '14 - 14:49 »

I'm not sure if I brought this one up before, but it's a strange issue nevertheless. I'm using the DSound driver on a laptop, and headphone / laptop speakers are seen as two devices. I occasionally plug the headphones in and out - For example, I might pause playback, remove the headphones plug, go into standby, wake up, plug the headphones back in. Now XMPlay continues to play music (it shouldn't!), you can see the time display being updated but the pause button still flashes. Hitting the play button will also make the rest of the GUI realize that some music is playing again.

Dezeer · « **Reply #173 on:** 18 May '14 - 18:42 »

I had an album of music that kept crashing Xmplay, I uploaded one of the mp3s named sp_intro into the /incoming/.

Ian @ un4seen · « **Reply #174 on:** 19 May '14 - 17:58 »

Quote from: winner on 17 May '14 - 00:17

Ian, this didn't help. Performance options were set for "Turn on DEP for essential Windows programs and services only." So I switched to "Turn on DEP for all programs and services except those I select" and rebooted my computer as required. When I tried to add XMPlay version 3.8.0.15, Windows responded with "This program must run with data execution prevention (DEP) enabled. You cannot turn off DEP for this program." This is a bit troubling since I do enjoy being able to use AVS with XMPlay.

Yep, it does seem like there is no way to disable DEP if the EXE states that it's DEP compatible. Oh well, here's an update that goes back to not stating DEP compatibility...

www.un4seen.com/stuff/xmplay.exe

Quote from: saga on 17 May '14 - 14:49

I'm not sure if I brought this one up before, but it's a strange issue nevertheless. I'm using the DSound driver on a laptop, and headphone / laptop speakers are seen as two devices. I occasionally plug the headphones in and out - For example, I might pause playback, remove the headphones plug, go into standby, wake up, plug the headphones back in. Now XMPlay continues to play music (it shouldn't!), you can see the time display being updated but the pause button still flashes. Hitting the play button will also make the rest of the GUI realize that some music is playing again.

I do recall someone reporting that issue in the past. I'm not sure what's causing it, as XMPlay doesn't request the playback resumption. It seems like Windows just forgets that the output was paused. If the playback buffer isn't full, XMPlay will continue to generate data while playback is paused, ready for resumption, so that will be why Windows can resume playback without XMPlay asking, ie. XMPlay will refill the space that appears in the playback buffer. I guess one solution would be to close the output (rather than leaving it paused) when the system goes to sleep, and that's what the update above should do. Let me know if you still get the problem occurring.

Quote from: Dezeer on 18 May '14 - 18:42

I had an album of music that kept crashing Xmplay, I uploaded one of the mp3s named sp_intro into the /incoming/.

The problem is triggered by the file's ID3v2 genre tag, which contains "(-1)". XMPlay will translate a number to the corresponding ID3 genre text, but it wasn't expecting to see a negative number. The update above will check that.