Topic: 3.8 reports, queries and bugs

[raina]

I think a 64-bit Windows 7 is a fairly common setup currently and I, for one, can't say I'm having these problems.

[Ian @ un4seen]

I don't seem to be able to reproduce those 2 problems here either. Are they happening with particular paths/filenames? Do they not happen with XMPlay 3.7? In the case of the drag'n'dropping problem, do you see the crossed circle icon when dragging the files over XMPlay's window?

[piovrauz]

I don't see the crossed circle while dropping on XMPlay window.
It's like XMPlay didn't react the first time I drop the files (from C:\).
I'll see if it can be me doing it too fast.
I don't think 3.7 had this "issue", but lets see if some reboot and days of use make it go away.

[Nukkels]

I updated XMPlay to 3.8, then I started getting the error about Delix, so I updated that plugin. When I next opened XMPlay, it just kept crashing immediately. I narrowed down the cause to 2 plugins:

* xmp-gz.dll - XMPlay crashes after about 2 seconds with the standard Windows error. A 'clean' crash.
* xmp-ra.dll - XMPlay never opens. Causes the process to remain in Task Manager and needs to be killed off manually. Very 'unclean' crash.

Both of these were updated late last year and even updating to the latest version did not fix the problem. Removing these 2 plugins (and leaving my other 20 odd plugins) XMPlay is working great now, and I guess I'll just have to wait for further updates to these plugins.

I realise this may not be a problem with XMPlay directly, but may I suggest contacting the major plugin developers to help with beta testing their plugins before the next version of XMPlay is released. It'll help avoid a lot of these sorts of issues (which usually just ends in a hundred people all coming to the forums to complain about the same thing).

[Dotpitch]

... I narrowed down the cause to 2 plugins:
* xmp-gz.dll - XMPlay crashes after about 2 seconds with the standard Windows error. A 'clean' crash.
* xmp-ra.dll - XMPlay never opens. Causes the process to remain in Task Manager and needs to be killed off manually. Very 'unclean' crash.

Do they also make a clean XMPlay crash, i.e. one without your current settings and without any files in the playlist? I've got both of those plugins, and I'm not seeing any problems at all.

I realise this may not be a problem with XMPlay directly, but may I suggest contacting the major plugin developers to help with beta testing their plugins before the next version of XMPlay is released. It'll help avoid a lot of these sorts of issues (which usually just ends in a hundred people all coming to the forums to complain about the same thing).

The author (Fraggie) was contacted by Ian before 3.8 was released.

[rst]

the ability to use the mouse middle wheel to move through the vis plugins. I have over 1xx vis plugins and it is tedious to move through them without the wheel.

[Dotpitch]

the ability to use the mouse middle wheel to move through the vis plugins.

It works exactly like that over here: when the pointer is on the vis, each tick of the wheel will change the active visualization. Is that not happening in your case?

[piovrauz]

Eh, I'd like something like that for milkdrop, it has a ton of presets...
But if Barna doesn't reappear, I guess I'll just keep dreaming.

[Fraggie]

I updated XMPlay to 3.8, then I started getting the error about Delix, so I updated that plugin. When I next opened XMPlay, it just kept crashing immediately. I narrowed down the cause to 2 plugins:

* xmp-gz.dll - XMPlay crashes after about 2 seconds with the standard Windows error. A 'clean' crash.

Does it also happen if you don't have any files in your playlist? If not then it's apparently tripping over some file, so please try to narrow down that file.

* xmp-ra.dll - XMPlay never opens. Causes the process to remain in Task Manager and needs to be killed off manually. Very 'unclean' crash.

I don't know what might be happening there. Did you change something in your Real Alternative installation? The plugin should not be affected by XMPlay version change.

[Tsorovan]

Nice to see the split-cue-to-individual-virtual-tracks feature.
However, I can't get the subsong titles to show; it just says


Filename (1)
Filename (2)


This is my current title formatting string:

%?0{%0|%?2{%5 · }%1}

Am I missing something?


Edit: actually, I'm kind of daft. I got halfway there by using this string:


%?0{%?1{%0 · %1|%0}|%?2{%5 · }%1}


However, it's not perfect.


Filename · Title_from_cue (1)
Filename · Title_from_cue (2)


So far so good, but normal tracks are displayed thus:


Filename_that_already_includes_the_title · Title_from_tag


Kind of difficult to explain...
My original format string was designed to primarily use the filename (since I avoid metadata/tags), but in case of a .cue-split album, use the info from the .cue. It seems this is not possible anymore.

[saga]

It seems like the 2D spectrum visualisation is somewhat broken - old frames no longer fade out so you get a pretty static picture after a while.

[Ian @ un4seen]

Nice to see the split-cue-to-individual-virtual-tracks feature.
However, I can't get the subsong titles to show...

An overhaul of the title formatting options is on the list for 3.9, but for now here's an update that adds a "%9" option for the subsong number...

   www.un4seen.com/stuff/xmplay.exe

To get "Filename · Title_from_cue (1)", you might set the title format to something like this: %0%?9{ · %?1{%1 }(%9)}

It seems like the 2D spectrum visualisation is somewhat broken - old frames no longer fade out so you get a pretty static picture after a while.

Oops. I was experimenting with some compiler options in the 3.8.0.6 build, and that seems to have broken the inline assembly code for fading-out the vis. The update above should get it working again

[Andreasvb]

Something broke in the latest stuff (3.8.0.7) with WAModern.
The main view is static and no buttons are working, and the panels goes over it.

http://www.un4seen.com/download.php?skin/WAModern

Works with bare minimum: xmplay.exe + WAModern NightVision.xmpskin
Will try remove some files in my main folder.

Happens if XMPlay is set to On top Normal.

[Muxson]

3.8.0.7 works fine for me under W7, with NightVision and any other skin, including all the WA.

[Tsorovan]

Nice to see the split-cue-to-individual-virtual-tracks feature.
However, I can't get the subsong titles to show...

An overhaul of the title formatting options is on the list for 3.9, but for now here's an update that adds a "%9" option for the subsong number...

   www.un4seen.com/stuff/xmplay.exe

To get "Filename · Title_from_cue (1)", you might set the title format to something like this: %0%?9{ · %?1{%1 }(%9)}

Splendid! Thanks a bunch. That simplified my old (and rather horrible) format string a lot. I simplified it further by using %0%?9{ · %?1{%1}} since it already adds the " (<tracknum>)" bit at the end automatically.

I did encounter another issue of sorts with the .cue support, and it's... well, I guess I get why it does this, and I totally buy the reason, but it is a cause for annoyance nonetheless.

So, it's common to keep an original .cue around from EAC (or your other ripper software of choice) for archival/completeness reasons, even though the album might be cut up into separate (encoded) files. If you try to add a folder containing both individually split tracks and this original .cue (which points to .wav files, naturally), it'll ignore the .mp3s (or FLACs, or what-have-you), and try to load the .wav files that the .cue is pointing to. Of course. Could there possibly be an option added that, if the .cue links fail to load when you add the folder to the playlist, you instead attempt to load the tracks in that folder?  I get why this happens and it does make sense, so maybe it's best to make it an option...

[saga]

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.


There seems to be something wrong with the message display; take e.g. this file and play it with xmp-openmpt. You will notice that the first line of the ANSI art in the message window is misplaced, but using the "copy to clipboard" feature and pasting the message into e.g. Notepad shows that everything should be alright. Looks like a rendering bug to me.

[rst]

3.8.0.5

i have in titles: %cut{%3|25|...} - %4 | %5 - %cut{%1|30|...}

but the playlist windows doesnt format the entries. They are flacs.

[piovrauz]

Maybe not a real bug, but while checking for updates ith XMPlay 3.8.0.7 I get noticed that theres a new zip archive plugin (rev.10a), but it's not in the plugin download, and the XMPlay zip is still @ 3.8.0.5... I know the zip plugin is part of the XMPlay download. What's happening?

[Ian @ un4seen]

So, it's common to keep an original .cue around from EAC (or your other ripper software of choice) for archival/completeness reasons, even though the album might be cut up into separate (encoded) files. If you try to add a folder containing both individually split tracks and this original .cue (which points to .wav files, naturally), it'll ignore the .mp3s (or FLACs, or what-have-you), and try to load the .wav files that the .cue is pointing to. Of course. Could there possibly be an option added that, if the .cue links fail to load when you add the folder to the playlist, you instead attempt to load the tracks in that folder?  I get why this happens and it does make sense, so maybe it's best to make it an option...

That's strange. Everything in the folder should get added to the playlist in that scenario (the CUE only if "Ignore playlists & shortcuts" is disabled), ie. the CUE file's presence shouldn't prevent the other files in the folder being added to the playlist. Are you sure the MP3/FLAC files don't follow the WAV files in the list?

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.

There seems to be something wrong with the message display; take e.g. this file and play it with xmp-openmpt. You will notice that the first line of the ANSI art in the message window is misplaced, but using the "copy to clipboard" feature and pasting the message into e.g. Notepad shows that everything should be alright. Looks like a rendering bug to me.

It's an issue with the info window's "Maximum text width" processing counting bytes rather than characters, resulting in text containing UTF-8 characters (like your example) being limited to less than requested. Here's an update to fix that...

   www.un4seen.com/stuff/xmplay.exe

i have in titles: %cut{%3|25|...} - %4 | %5 - %cut{%1|30|...}

but the playlist windows doesnt format the entries. They are flacs.

Do you just see filenames, and is that in both the main window playlist and the info window extended playlist? If you right click on a playlist entry and choose "Track info", are there tags shown?

Maybe not a real bug, but while checking for updates ith XMPlay 3.8.0.7 I get noticed that theres a new zip archive plugin (rev.10a), but it's not in the plugin download, and the XMPlay zip is still @ 3.8.0.5... I know the zip plugin is part of the XMPlay download. What's happening?

As the ZIP plugin is now part of the main XMPlay package, the update can be found there. It was updated to rev.10a (to fix some PNG loading issues) at the same time as XMPlay was updated to 3.8.0.5.

[piovrauz]

Oh, thanks. I must have forgot to update, so last stuff was after the last XMPlay full package, and so I didn't notice the .zip was updated too.

[saga]

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.

During playback, and it doesn't seem to correct itself, or maybe I just haven't tried for long enough. I'll see if muting works the next time the problem occurs.

[moriez]

There's a bit of an Output annoyance:

- I play music over Wasapi (speakers),
- Then switch on my external dac,
- Exit XMPlay,
- I play music again..

..but there's no sound. Output has changed to the external dac on it's own.
Setting the config to read-only for Wasapi (speakers) is not a solution.

Help? 

[rst]

Quote from: rst on 25 Jan '14 - 16:25
i have in titles: %cut{%3|25|...} - %4 | %5 - %cut{%1|30|...}
but the playlist windows doesnt format the entries. They are flacs.

Quote from: Ian @ un4seen.
Do you just see filenames, and is that in both the main window playlist and the info window extended playlist? If you right click on a playlist entry and choose "Track info", are there tags shown?

Ian @ un4seen
no, into the track info all the tags are empty !!! something goes wrong on the 3.8.0.5 related to flac tags. In the previous version of XMplay that doesnt happened.

[rst]

Attention Ian @ un4seen

there are also problems playing .ape files. In this case the tags format is correct but, for some strange reasson XMplay jump each 1 or 2 seconds from a song to the next automatically and without stop. At the moment i have seen that behaviour only with .ape files.

Fixed: the problem wasnt xmplay. Jut the FFMpeg plugin ! But this fact throw again the fact that XMplay need some way to allow to the user to set a priority list with the plugins, because, who determined that is FFmpeg the plugin to play flac or ape ? we need a priority list, same one that use for example BSplayer.

[Ian @ un4seen]

There's a bit of an Output annoyance:

- I play music over Wasapi (speakers),
- Then switch on my external dac,
- Exit XMPlay,
- I play music again..

..but there's no sound. Output has changed to the external dac on it's own.
Setting the config to read-only for Wasapi (speakers) is not a solution.

The output device selection is retained as the output system (built-in/DirectSound/WASAPI/etc) and an index into its available outputs, so if the device order changes (eg. when devices are added/removed), it won't affect which output system is used but it could unfortunately change which device is used.

no, into the track info all the tags are empty !!! something goes wrong on the 3.8.0.5 related to flac tags. In the previous version of XMplay that doesnt happened.

That's strange, I'm not seeing any problems with FLAC tags here. One possibility that comes to mind is that another plugin is handling the files, perhaps XMP-FFMPEG? That would get to look at FLAC files before XMP-FLAC does due to alphabetical order. If you are using XMP-FFMPEG, try adding "flac" to the FLAC plugin's "Priority filetypes" setting (in the Input plugins options page).

there are also problems playing .ape files. In this case the tags format is correct but, for some strange reasson XMplay jump each 1 or 2 seconds from a song to the next automatically and without stop. At the moment i have seen that behaviour only with .ape files.

I'm not seeing that here either. Please confirm what plugin is playing the APE files.