3.8 reports, queries and bugs

Started by Dotpitch,

winner

Quote from: Ian @ un4seen
Quote from: winnerIan, 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
YAY!! AVS and Geiss visualizers work again now! THANKS!

saga

I'm not entirely sure what's happening here, but no matter what kind of interpolation is chosen, the filtered sample in the second pattern always sounds like no interpolation is applied (i.e. it sounds much fresher than in the first pattern). I don't think this is intended?

mingle

Just another minor issue with 3.8 under Windows 8.1:

When xmplay starts via file-association (ie: I click on an .mp3 file), the program appears in the Windows task-bar and the task-bar 'icon' blinks yellow, as expected, as the program runs. However, when I click on the xmplay in the task-bar, the program window doesn't appear. I have to click two more times to get the xmplay window to appear.

It doesn't seem to matter how many other applications I have running, it behaves the same way. I'm running Classic Shell on my machine, but don't think that's the issue.

Is this repeatable for any other Win 8.1 users?

Cheers,

Mike.

Ian @ un4seen

Quote from: sagaI'm not entirely sure what's happening here, but no matter what kind of interpolation is chosen, the filtered sample in the second pattern always sounds like no interpolation is applied (i.e. it sounds much fresher than in the first pattern). I don't think this is intended?

It was actually always using linear interpolation on filtered channels. Here's an update that should also support sinc interpolation then...

   www.un4seen.com/stuff/xmplay.exe


winner

Quote from: Ian @ un4seenGood to hear that URL pasting is working again. To answer your question, the URL box's drop-down list does indeed only contain URLs that have previously been entered into the URL box, and not any URLs that have been opened in other ways.
Ahhhh... crud! The Open URL and paste operation is not working again for me in XMPlay 3.8.0.17 (see above posts in this topic). Does anyone else see this trouble?

Alt

Quote from: winnerThe Open URL and paste operation is not working again for me in XMPlay 3.8.0.17 (see above posts in this topic). Does anyone else see this trouble?
Works fine for me.

winner

Quote from: Alt
Quote from: winnerThe Open URL and paste operation is not working again for me in XMPlay 3.8.0.17 (see above posts in this topic). Does anyone else see this trouble?
Works fine for me.
Alt, thanks for doing a check! Well... an update. I have tried substituting various versions of XMPlay in my XMPlay folder. All tests would be using the same xmplay.ini file. I found that XMPlay version 3.8.0.5 does not show this problem, but all previous and subsequent versions I tested did not allow me to paste an URL in the Open dialog box.


winner

Quote from: Jimmy NeutronHave you tried with a fresh ini file?
Yes, I've tried that. No help.

winner

Quote from: winner
Quote from: Jimmy NeutronHave you tried with a fresh ini file?
Yes, I've tried that. No help.
Aha! Looks to be something having to do with my Webroot SecureAnywhere antivirus program, since it works when that is disabled. I'm investigating... I'll post my finding.

winner

Quote from: winner
Quote from: winner
Quote from: Jimmy NeutronHave you tried with a fresh ini file?
Yes, I've tried that. No help.
Aha! Looks to be something having to do with my Webroot SecureAnywhere antivirus program, since it works when that is disabled. I'm investigating... I'll post my finding.
I tried adding XMPlay.exe to the Allow list in SecureAnywhere but SA has an issue; I'm opening a support ticket. But, Windows reports that the publisher of XMPlay.exe is unknown. I think this has always been the case and shouldn't have any bearing here, but if anyone knows how to add a proper certificate to avoid this warning please let me know.

piovrauz

well, as far as I know XMPlay.exe shouldn't trigger AVs because of its publisher being unknown, at least it never did here.
It probably is a false positive or a bug, or just the AV being paranoid. You may scan it with virus total, just in case.

winner

Quote from: winner
Quote from: winner
Quote from: winner
Quote from: Jimmy NeutronHave you tried with a fresh ini file?
Yes, I've tried that. No help.
Aha! Looks to be something having to do with my Webroot SecureAnywhere antivirus program, since it works when that is disabled. I'm investigating... I'll post my finding.
I tried adding XMPlay.exe to the Allow list in SecureAnywhere but SA has an issue; I'm opening a support ticket. But, Windows reports that the publisher of XMPlay.exe is unknown. I think this has always been the case and shouldn't have any bearing here, but if anyone knows how to add a proper certificate to avoid this warning please let me know.
Resolved: Today I was able to get a Webroot technician to look at the issue. Turns out it was an identity protection feature of the AV software that prevented pasting into the URL field - I guess because this would be a track-able data item. Oddly though, SecureAnywhere thinks the executable is located elsewhere.

Bonus: The tech took note of the Program ID and it seemed he was going to try to make XMPlay a regularly tracked and whitelisted application for SecureAnywhere. At least that's what I think he was saying.

saga

When "old FX" aren't activated, an offset beyond the sustain loop end should replay the sample from the beginning. The current behaviour - play from sustain loop start - is only correct in old FX mode. In the attached examples, the voice should say "new" in SustainEnd.it and "old" in SustainEndOld.it.

moriez

I'm using latest WASAPI plug-in and have encountered a prob. Basically playback just stops within ~10 seconds when WASAPI is the output. Strange thing is A> it does not happen with a second audio device I'm using and B> it does not happen in players like AIMP and FOOBAR. What could be the cause?

rst

#191
is it possible to have the VIS window into an independant window ? just to be able to have VIS and what the Playlist at the same time. And / or to show ALL TIME current song information over the vis.

Also, is it possible to select songs on the playlist thx to a square selection ?

thx in advance

Ian @ un4seen

Quote from: sagaWhen "old FX" aren't activated, an offset beyond the sustain loop end should replay the sample from the beginning. The current behaviour - play from sustain loop start - is only correct in old FX mode. In the attached examples, the voice should say "new" in SustainEnd.it and "old" in SustainEndOld.it.

Here's an update that should sort that out...

   www.un4seen.com/stuff/xmplay.exe

Let me know if you spot any more dodginess.

Quote from: moriezI'm using latest WASAPI plug-in and have encountered a prob. Basically playback just stops within ~10 seconds when WASAPI is the output. Strange thing is A> it does not happen with a second audio device I'm using and B> it does not happen in players like AIMP and FOOBAR. What could be the cause?

That sounds strange. I have a few questions... Does playback stop or does only the sound stop, eg. is the play button still in the playing state and/or is the position display advancing? Does the the "Buffer" setting affect when the playback/sound stops or is it always at the same position? What is the device that the problem is happening with, and is it happening whether exclusive mode is enabled or disabled? Did it just begin with the latest version of the WASAPI plugin, or did it happen with previous versions too? If it didn't happen with old versions, please give the last version number that wasn't affected.

moriez

Hi Ian,

Playback stops, the play button is still in the playing state but the position display is no longer advancing. Tried some of your suggestions and it's completely solved when I disable Exclusive mode(!) The device is an Aune T1 DAC/AMP which I've just received last week. If you could upload and link me to Rev.3 I can try it out with that version. I no longer have it around.

Ian @ un4seen

#194
OK. I will send you a debug version to find out what's happening in exclusive mode. Please PM me your current email address, as your registered email address seems to no longer be valid.


saga

When using "close with position saved", it seems like the play count of that file is incremented another time after restarting XMPlay. I don't think this should be happening.

saga

I think the sustain loop bugfix might have broken the offset effect in IT files. In the attached example, the sample keeps being played from the start instead for the correct offset position.

bauxite69

Hi,

XMPlay 3.8.0.20 can't play and load MPEG 1 Layer 1
XMPlay 3.8.0.20 can load MPEG 1 Layer 2 but it won't play.

XMPlay 3.8.0.5 works great with MPEG 1 Layer 1
XMPlay 3.8.0.5 won't play and load MPEG 1 Layer 2.

I uploaded files to ftp.un4seen.com/incoming/ for testing.

Thank you.

Ian @ un4seen

Quote from: sagaI think the sustain loop bugfix might have broken the offset effect in IT files. In the attached example, the sample keeps being played from the start instead for the correct offset position.

Oops, you're right, that was broken when adding the sustain loop fix. Here's an update that should get it working properly again...

   www.un4seen.com/stuff/xmplay.exe

Quote from: bauxite69XMPlay 3.8.0.20 can't play and load MPEG 1 Layer 1
XMPlay 3.8.0.20 can load MPEG 1 Layer 2 but it won't play.

XMPlay 3.8.0.5 works great with MPEG 1 Layer 1
XMPlay 3.8.0.5 won't play and load MPEG 1 Layer 2.

I uploaded files to ftp.un4seen.com/incoming/ for testing.

Both of your uploaded files are actually layer 3 (MP3) files. There was a bug in the recent MPEG verification changes that was breaking the detection of the file that was working previously. The other file wasn't being detected because it has a too large gap between the ID3v2 tags and the MP3 data. The update above should fix the bug affecting the 1st file, and increases the amount of file data that XMPlay will look at so that the 2nd file should be detected now too. Let me know if you still have similar troubles with any other MPEG files.