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

piovrauz · « **Reply #50 on:** 31 Dec '13 - 13:12 »

1) Check the cover plugin, xmp-coverart: (remove it and see if XMPlay crashes).
2) On the options tab regarding the filetype exclusion add .jpg and .jpeg.

Ian @ un4seen · « **Reply #51 on:** 31 Dec '13 - 16:08 »

Quote from: Nicolas @ b&f on 30 Dec '13 - 19:56

OK, I have one of the most annoying bugs in XMPlay... the worst thing is, I don't know if it's a problem in XMPlay or it's another craziness of my Portable Hard Disk Drive motherboard. Each time I drag the "Music" folder from my Portable HDD to XMPlay, it crashes exactly 3 minutes after that operation with a MSVC Runtime Code R6016.

To hopefully get some clues on what's going wrong, please use Task Manager's "Create Dump File" option when the error occurs and then upload the file to have a look at here...

ftp.un4seen.com/incoming/

Quote from: piovrauz on 31 Dec '13 - 09:49

xmp-midi crashes XMPlay upon loading a midi file (stream I mean, not local file). T_T

I don't seen to be able to reproduce that here. Is it happening with a particular MIDI file? If so, please upload that to have a look at.

piovrauz · « **Reply #52 on:** 31 Dec '13 - 16:24 »

Drag and drop from here: [link]http://www.swissdom.cc/midis/midi-internacional-ingles/d/DATURA/[/link]
no minidump are created ("this program has stopped working" window, and that's all.

saga · « **Reply #53 on:** 31 Dec '13 - 16:51 »

Alright, I think there is definitely a bug in the loop stuff since that time limiting feature has been introduced.
I have some modules that I'd like to repeat once and then fade out, so my settings are Loop = always, limit = 0, 0 minutes, auto-loop any track, fadeout = 10s. These modules loop infinitely now.

Ian @ un4seen · « **Reply #54 on:** 31 Dec '13 - 17:41 »

Quote from: piovrauz on 31 Dec '13 - 16:24

Drag and drop from here: [link]http://www.swissdom.cc/midis/midi-internacional-ingles/d/DATURA/[/link]
no minidump are created ("this program has stopped working" window, and that's all.

It's still refusing to crash here

To find out what's going wrong, please upload a dump file from the crash. To get Windows to generate dump files (in your user "AppData\Local\CrashDumps" folder), you can apply this "localdumps-full" registry entry...

www.un4seen.com/stuff/localdumps.zip

After reproducing the crash and getting a dump file, upload it (after compressing) to have a look at here...

ftp.un4seen.com/incoming/

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

Quote from: saga on 31 Dec '13 - 16:51

Alright, I think there is definitely a bug in the loop stuff since that time limiting feature has been introduced.
I have some modules that I'd like to repeat once and then fade out, so my settings are Loop = always, limit = 0, 0 minutes, auto-loop any track, fadeout = 10s. These modules loop infinitely now.

Are both the "times" and "minutes" loop limits set to 0? If either is set to 0, then that criteria will not apply. If both are set to 0, then neither will apply and it will loop indefinitely. To loop once, "times" should be set to 1.

saga · « **Reply #55 on:** 31 Dec '13 - 17:51 »

Both are zero. That's how it was imported from my 3.7 config, where it still worked.

piovrauz · « **Reply #56 on:** 31 Dec '13 - 18:02 »

ehm, doesn't help, adding that to the registry doesn't enable the dumps.
Last one I see is the old one about my ex wi-fi stick (drivers were unstable, say a bad port to 64bit), but that knocked down the OS, while XMPlay just closes.

EDIT: a clean XMPlay with only the midi plugin is fine. Usual install is not. Time to cleanup my XMPlay install. If I experience it again I'll let you know.

Ian @ un4seen · « **Reply #57 on:** 31 Dec '13 - 18:17 »

Quote from: saga on 31 Dec '13 - 17:51

Both are zero. That's how it was imported from my 3.7 config, where it still worked.

That's strange. XMPlay 3.7 restricted the loop count to a minimum of 1, so I'm not sure how 0 got there

Quote from: piovrauz on 31 Dec '13 - 18:02

ehm, doesn't help, adding that to the registry doesn't enable the dumps.

What Windows version are you using? The registry setting should work with Windows 7 and above. Also make sure you're looking for the dump file in the right place, eg. "C:\Users\<yourname>\AppData\Local\CrashDumps". If the dump file won't appear, please copy'n'paste the problem details from the "stopped working" window instead.

piovrauz · « **Reply #58 on:** 31 Dec '13 - 18:32 »

Actully I was checking the wrong directory. /facepalm
xmplay.exe.3736.dmp.7z & xmplay.exe.552.dmp.7z in the FTP in 15 min or so, slow up. (they're up)

saga · « **Reply #59 on:** 31 Dec '13 - 19:46 »

Quote from: Ian @ un4seen on 31 Dec '13 - 18:17

That's strange. XMPlay 3.7 restricted the loop count to a minimum of 1, so I'm not sure how 0 got there

Well, me neither. All I can say is that I'm still using the same saved settings as before, and that's how they turn up here. And it's hundreds of them. :\

piovrauz · « **Reply #60 on:** 31 Dec '13 - 20:48 »

Ian, since I couldn't start the new year with the midi plugin misbehaving, I had to find the cause.
It should be the xmp-ffmpeg plugin. I don't know why, but it crashes XMPlay while loading a midi from the web.
Removing it, or putting midi file priority to midi plugin stops the crash (the file loads and play normally).
Strange since xmp-ffmpeg... should not support midi at all...

Ian @ un4seen · « **Reply #61 on:** 2 Jan '14 - 16:45 »

Quote from: saga on 31 Dec '13 - 19:46

Quote from: Ian @ un4seen on 31 Dec '13 - 18:17
That's strange. XMPlay 3.7 restricted the loop count to a minimum of 1, so I'm not sure how 0 got there
Well, me neither. All I can say is that I'm still using the same saved settings as before, and that's how they turn up here. And it's hundreds of them. :\

The loop limit "times" and "mins" settings aren't actually stored in the saved settings currently, so if you set the "times" limit to 1, it should apply to all files. The "loop" saved settings currently include all of the settings in the "Track looping/ending" section apart from the "times" and "mins" and "crossfade" settings.

saga · « **Reply #62 on:** 3 Jan '14 - 14:39 »

Here's a new broken portamento test case. Seems like Gxx after note-off in IT is broken. Left and right channel (recorded from IT) should sound identical...

Muxson · « **Reply #63 on:** 4 Jan '14 - 11:37 »

Bug in zip-based xmpskin:

3.8.0.0 supports uncompiled skins with bmp32 and png renamed as bmp
3.8.0.3 sppports uncompiled skins with bmp32 and png renamed as bmp and native png

but

Zip-compiled skins are only supported with bmp32!
None of them support zip-compiled skins with png (renamed or native).
And it doesn't give the "Can't load skin" error message, it just crashes...

My tests skins can be found here:
https://www.dropbox.com/s/3d38tl65pf77gx0/VR2_bmp32.xmpskin [ works for me ]
https://www.dropbox.com/s/ocu9p52r51i1sn8/VR2_pngbmp.xmpskin [ does not work for me ]
https://www.dropbox.com/s/iy5z7plrrapl03m/VR2_png.xmpskin [ does not work for me ]

By the way Ian, that would be an update to Vintage Radio 1!

Knurek · « **Reply #64 on:** 4 Jan '14 - 17:40 »

Ian, I think the "Auto-loop any track ending with sound" option isn't working properly.

I have Loop set to never, the option above disabled and XMPlay still fades out non-looping tracks that end with sound. Setting fade-out to 0.0s fixes that.

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

Quote from: saga on 3 Jan '14 - 14:39

Here's a new broken portamento test case. Seems like Gxx after note-off in IT is broken. Left and right channel (recorded from IT) should sound identical...

Here's an update that should fix it (hopefully without breaking other IT files

)...

www.un4seen.com/stuff/xmplay.exe

Quote from: Muxson on 4 Jan '14 - 11:37

Zip-compiled skins are only supported with bmp32!
None of them support zip-compiled skins with png (renamed or native).
And it doesn't give the "Can't load skin" error message, it just crashes...

There was indeed a problem with loading PNG files in compiled skins. The update above should fix that. I also noticed a problem in the PNG processing that could prevent some PNG files loading, so here's an updated ZIP plugin (which handles PNG processing) to fix that too...

www.un4seen.com/stuff/xmp-zip.dll

Quote from: Knurek on 4 Jan '14 - 17:40

Ian, I think the "Auto-loop any track ending with sound" option isn't working properly.

I have Loop set to never, the option above disabled and XMPlay still fades out non-looping tracks that end with sound. Setting fade-out to 0.0s fixes that.

The fade-out triggering was changed in 3.8.0.1, so that it does now solely use the ending sound level to determine whether to fade-out, ie. it won't bother to fadeout if it's already quiet. Is there a particular file/format that the change is causing problems for? If so, please upload an example to have a look at here...

ftp.un4seen.com/incoming/

saga · « **Reply #66 on:** 6 Jan '14 - 16:28 »

I was able to reproduce Knurek's problem as well, so I uploaded "01 - ECD - Direct Drive (The Ready Made All That Jazz Remix).mp3" to have a look at.
Settings: Loop: Never [ ] Limit: 1, 0 mins
[ ] auto-loop
When finished playing, this MP3 restarts and fades out, which didn't happen before.

Muxson · « **Reply #67 on:** 6 Jan '14 - 19:42 »

Yep, ' works...

Quote from: Muxson on 4 Jan '14 - 11:37

Zip-compiled skins are only supported with bmp32!
None of them support zip-compiled skins with png (renamed or native).
And it doesn't give the "Can't load skin" error message, it just crashes...

I could open zip-compiled skins containing png files with XMP 3.8.0.4 and zip.dll 1.10.0.1, no problem.

Thanks Ian!

Ian @ un4seen · « **Reply #68 on:** 7 Jan '14 - 16:14 »

Quote from: saga on 6 Jan '14 - 16:28

I was able to reproduce Knurek's problem as well, so I uploaded "01 - ECD - Direct Drive (The Ready Made All That Jazz Remix).mp3" to have a look at.
Settings: Loop: Never [ ] Limit: 1, 0 mins
[ ] auto-loop
When finished playing, this MP3 restarts and fades out, which didn't happen before.

Here's an update that pretty much puts the fadeout triggering back to how it was before (except that it will always require there to be sound at the end)...

www.un4seen.com/stuff/xmplay.exe

pepak · « **Reply #69 on:** 11 Jan '14 - 08:23 »

Incorrect display of track number

Version 3.8 stopped displaying tracknumber of the currently playing file. Instead of the expected "01. Main Title (John Williams - Accidental Tourist)", I only get ". Main Title (John Williams - Accidental Tourist)".

In "Options and stuff -> Titles -> Formatting string" I have: "%5. %?1{%1|%0} (%2 - %3)". I am playing FLAC files with "TRACKNUMBER=xx" among its Vorbuis tags. The FLAC plugin is v1.0.9 (23.12.2013).

Version 3.7 worked correctly.

piovrauz · « **Reply #70 on:** 11 Jan '14 - 08:28 »

Bah, I found a bug, but it was me.
I posted a "nevermind", but now a new issue happened.
I got a .it wit lot of silence at the end. I have trim ending silence active.
Song plays till the end of "trimmed" time, counter shows -0:00 (coundown mode), but the track doesn't stop.
Uploaded "Siatek - Fury GOA" to FTP.

Dotpitch · « **Reply #71 on:** 11 Jan '14 - 10:03 »

Quote from: pepak on 11 Jan '14 - 08:23

Version 3.8 stopped displaying tracknumber of the currently playing file. Instead of the expected "01. Main Title (John Williams - Accidental Tourist)", I only get ". Main Title (John Williams - Accidental Tourist)". ... I am playing FLAC files with "TRACKNUMBER=xx" among its Vorbuis tags. The FLAC plugin is v1.0.9 (23.12.2013).

This issue is fixed in the latest version. Please update your XMPlay.

Kenode · « **Reply #72 on:** 13 Jan '14 - 14:42 »

Hello! This is my first post, but I've been a long time user of XMPlay since version 2!
I basically registered to post a possible bug in 3.8.0.5 which I don't have in 3.8.0.2: when right clicking an item in the playlist and choosing "Explore folder", the folder doesn't open like in previous versions of XMPlay (Basically it does nothing). Also, when trying to drag and drop a file into the playlist, it doesn't seem to add it, it does nothing as well. (I was trying to add an IT file)

In case it's needed, I run on Windows 7, x64, latest service pack.

raina · « **Reply #73 on:** 13 Jan '14 - 15:38 »

@Kenode, That's odd. The only thing that comes to mind (and that only applies to problem #2) is maybe you're running XMPlay as an administrator. That would block drag and dropping from programs running as normal user but it seems unlikely as you can't really run apps as an administrator unintentionally.

piovrauz · « **Reply #74 on:** 13 Jan '14 - 16:58 »

I have something similar to what kenoke is experiencing: when trying to drag and drop files or folders into the main windows, it doesn't seem to add it, it does nothing. But If I re-do it they get added.
Since I am on w7 sp1 64bit it may be related to the 64bit? Possible or just a coincidence? I run XMPlay normally, nothing fancy like admin.