next »

[Alexsource]

Yeah, you're right, the header looks kinda different, there's no PK at the beggining for starters...
Strange... wonder why/how winamp could open then up (after renaming then to .mdz) them...
Winrar seems to cope fine with then. I don't use winzip anymore
[edit]Winrar reports then as GZIP files , still, i don't understand why they opened fine in winamp.....  [/edit]

[Torkell]

Resolved bug

XMPlay appears to cache file tags even after the file has been removed from the playlist. Not a bug

I added a bunch of MP3s to an instance of XMPlay, but removed them straight away when I saw that the tags were all over the place. I unmangled them in mp3tag for a bit, then added the files back to XMPlay (by dragon dropping them from mp3tag). The tags had been changed, but the filenames hadn't. XMPlay 'remembered' the old tags and didn't look to see if they had changed.

To reproduce: add a file to the playlist in XMPlay, then remove it. Change the tags using an external tag editor, then add the same file again. Do not rename the file. XMPlay will show the old tags.

Workarounds: restart XMPlay before re-adding the files, use the internal tag editors (the winamp plugin), or rename the files when editing the tags. Using the "refresh all tags & titles" button doesn't appear to work (possibly a seperate bug).


Edit: just after writing that, XMPlay bombed with "instruction at 0x77fcd6ad could not read memory at 0x06ccf88d". Call stack is (top first) NTDLL! 77fcd6ad(), NTDLL! 77fcb80c(), MSVCRT! 78001e00(), XMPLAY.3.2.0.7B! 0040169b(), XMPLAY.3.2.0.7B! 0042c97a(), XMPLAY.3.2.0.7B! 0043b4cd(), KERNEL32! 7c57b388(). Registers are EAX = 00000820, EBX = 00950000, ECX = 7FFD7000, EDX = 00950608, ESI = 06CD00A8, EDI = 06CCF888, EIP = 77FCD6AD, ESP = 02DBBB6C, EBP = 02DBBB78, EFL = 00000283. (sorry for posting them this way, but MSVC caught the crash instead of Dr. Watson).

I had another try (at trying to get XMPlay to update track titles from the "refresh" button), and this time I could exit XMPlay. However, when exiting it told me that it was still updating track titles, even though it had yet to update the first one. Methinks the title formatting is broken in some way.

Tried again, and XMPlay bombed about 2 seconds after i changed a number in my title format string. Same place but different registers (different ones are ECX = 7FFDA000, EDX = 00950608, ESI = 05E900A8, EDI = 05E8F888, ESP = 020CBB6C, EBP = 020CBB78, EFL = 00200283). A different instance of XMPlay (with my master 2500-song list) didn't crash, but instead exited instantly when I tried the same and clicked "refresh".

Ideas? I can probably pull more information out of MSVC if needed.


To clarify, the first (caching titles) is not a bug, although it could be better. The second (crashing when refreshing tags) *is* a bug, and has been fixed in the current 3.2.0.7 beta.

[Bistzack]

Here is how to crash XMPlay: download some song and keep "save window" opened until the next song is playing. And then hit "save" button.

I uploaded Dr Watson log (savewin.zip).

[Ian @ un4seen]

XMPlay appears to cache file tags even after the file has been removed from the playlist.

Yep, XMPlay does cache (in memory) the details of all tracks that are added to the list in a session.

Besides the "Refresh all tags & titles" button, you can refresh individual files in the library via the "Refresh info from file" right-click option. I guess that option could be available to the playlist too... it is in the update below

I had another try (at trying to get XMPlay to update track titles from the "refresh" button), and this time I could exit XMPlay. However, when exiting it told me that it was still updating track titles, even though it had yet to update the first one. Methinks the title formatting is broken in some way.

The first file in the playlist isn't necessarily the first to be refreshed - the files in the library will generally be first. Do you have a large library?

Ideas? I can probably pull more information out of MSVC if needed.

Please copy'n'paste the disassembly, register and call-stack windows to have a look at. If it's too big to post, you can bung it in an email.

If you've not already done so, you could also try removing all plugins, to eliminate the possibility of it being a plugin problem.

Here is how to crash XMPlay: download some song and keep "save window" opened until the next song is playing. And then hit "save" button.

Here's an update that'll wait for the user to close the file selector before advancing...

   www.un4seen.com/stuff/xmplay.exe

[Torkell]

E-mail sent, subject "Crashing XMPlay" from domain @sussex.ac.uk. Good luck fixing the bug!

[Dotpitch]

just got my new laptop running (WinXP Pro SP2, a NEC model) and the first program to be installed was xmplay

just noticed two weird things:
if i've got files in the library or playlist and change the title formatting, xmplay silently quits. it does work when i've got nothing in the playlist or library, but i think it's too much work to delete and reload everything .
when adding files from the library to an empty playlist (RMB, add to playlist), sometimes some (non-selected) files appear in playlist and they're queued.

i've never seen those things happen on my other pc (WinXP Home SP2), it kind of confuses me but at least i've got xmplay running, so i can enjoy the music

[Torkell]

The crashing on tag refresh bug's been fixed! Thanks Ian!

[Ian @ un4seen]

if i've got files in the library or playlist and change the title formatting, xmplay silently quits. it does work when i've got nothing in the playlist or library, but i think it's too much work to delete and reload everything .

Do you have any UMX files in the library or playlist? If so, it's probably the same problem Boggy encountered. Try the update...

   www.un4seen.com/stuff/xmplay.exe

when adding files from the library to an empty playlist (RMB, add to playlist), sometimes some (non-selected) files appear in playlist and they're queued.

Strange. Are you sure you're not accidentally middle-clicking all over the place?

Is it reproducible/predictable, or is it random? If the former, please give instructions.

[Dotpitch]

if i've got files in the library or playlist and change the title formatting, xmplay silently quits. it does work when i've got nothing in the playlist or library, but i think it's too much work to delete and reload everything .

Do you have any UMX files in the library or playlist? If so, it's probably the same problem Boggy encountered. Try the update...

i'm sure i don't have any UMX-files in the list, cause i don't even have UMX-files they're all ogg vorbis, and i can't get dr watson to make a log of the crash, because it isn't registered as a crash .

when adding files from the library to an empty playlist (RMB, add to playlist), sometimes some (non-selected) files appear in playlist and they're queued.

Strange. Are you sure you're not accidentally middle-clicking all over the place?
Is it reproducible/predictable, or is it random? If the former, please give instructions.

it happened first time i added something from the library after loading xmplay, but it doesn't happen any more, so it was probably my fault . i'll post about it when it happens again.

[Ian @ un4seen]

i'm sure i don't have any UMX-files in the list, cause i don't even have UMX-files they're all ogg vorbis, and i can't get dr watson to make a log of the crash, because it isn't registered as a crash .

I'll send you a debug version to find out what's going on there.

[Bistzack]

I uploaded mp3 file (tox_c.mp3) that was saved with XMPlay from this URL: http://212.72.165.18:9134/listen.pls

XMPlay says it's 1 second long but it's not.

Another thing is that I cannot save this stream when "write separate tracks" option is enabled.

[Ian @ un4seen]

I uploaded mp3 file (tox_c.mp3) that was saved with XMPlay from this URL: http://212.72.165.18:9134/listen.pls

XMPlay says it's 1 second long but it's not.

For some reason, that stream has a short MP3 (with a LAME header) stuck on at the front. The header says it's only 23 frames long.

Having said that, here's an update that should be able to get the length of the saved file...

   www.un4seen.com/stuff/xmplay.exe

This update also sorts out Dotpitch's problem, for anyone else who's having that problem.

Another thing is that I cannot save this stream when "write separate tracks" option is enabled.

The server says it will send meta data (so the "write separate tracks" option is made available), but then it doesn't appear to send any.

[Bistzack]

For some reason, that stream has a short MP3 (with a LAME header) stuck on at the front. The header says it's only 23 frames long.

Having said that, here's an update that should be able to get the length of the saved file...

It works now. Thank you!

[fernsx]

i just found weird that when i just start playing a song, i right click on the current played one, to check in_mp3.dll id3 info, and i get a STEREO EXPANDED SOUND, there are not any dsp plugins activated. i just got deedsp, but it is not activated, just the included equalizer and reberb

[Dotpitch]

add a folder to the library that contains a folder with audio that wasn't in the library already, delete the new files from the library, rename the folder, right-click the add-folder button to do it again, and xmplay quits (at least, over here ).
another thing: if you add files to the library and delete them from the library, you can't rename the folder they're in until you close xmplay.

[Ian @ un4seen]

add a folder to the library that contains a folder with audio that wasn't in the library already, delete the new files from the library, rename the folder, right-click the add-folder button to do it again, and xmplay quits (at least, over here ).

Oops. Should be sorted now...

   www.un4seen.com/stuff/xmplay.exe

another thing: if you add files to the library and delete them from the library, you can't rename the folder they're in until you close xmplay.

Let me know if it still happens with the update.

[Rah'Dick]

I don't have an exact bug to post but my impression over the last few beta versions is, that XMP has become a bit unstable. Almost every time when I try to add some directories, XMP either crashes or loads the Windows XP "example music" from somewhere on my HD! I recently had a crash when I tried to activate "omit file extension" - checked the box, clicked ok - half a second later, XMP was gone. Tried that ten times in a row and got a crashlog, too. Managed to close XMP before it crashed once, so it saved the setting. After reopening, the crashing ended.
I'll try the latest beta and see whether it's still behaving strangely when adding folders.

[Dotpitch]

Let me know if it still happens with the update.

both bugs are solved now

I don't have an exact bug to post but my impression over the last few beta versions is, that XMP has become a bit unstable.

i'd have to agree... i've had more crashes than ever last week (also on "omit file extension"!), perhaps i'm using it too much . unfortunately, all those crashes were silent quits, was something changed in the code to avoid drwtsn to log the bug?

[Tsorovan]

I'm not a beta tester, but I'm still getting files added to the playlist that shouldn't be added now and then. I don't really know if there's a plugin causing it or not, because it can be fine for weeks, and then one day BAM! LET'S PLAY TEXT FILES AND IMAGES! so naturally it's difficult to troubleshoot.

These are my plugins:
in_mp3.dll
in_mt2.dll
in_shn.dll
in_wave.dll
xmp-aac.dll
xmp-ape.dll
xmp-cd.dll
xmp-flac.dll
xmp-mpc.dll
xmp-rar.dll
xmp-wma.dll
xmp-zip.dll

[fernsx]

anoher weird thing i found for the first time since 0.7, is that sometimes when i try to play any mp3 file i get a message box saying somethig like: mmsystem032 cant playback the file..... then retrying the playback and it plays