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

Funzi

  • Guest
Re: 3.8 reports, queries and bugs
« Reply #300 on: 11 May '15 - 14:21 »
I dont have time now to run full 24 hod testing(i can run it later if you wish). But after just after few runs i reproduced this bug: http://pastebin.com/iUXDx3Pf .
When i was trying to reproduce bug posted before, it dit not appear with particular file. I tried to debug with file which fuzzer mark as crash but i could not reproduce bug in every run.
I reproduced it in WinDbg after 10 or so runs but it appear to happen quite random.
This is mentioned file(still from version 3.7): http://s000.tinyupload.com/?file_id=81671150716416272404

raina

  • Posts: 1163
Re: 3.8 reports, queries and bugs
« Reply #301 on: 19 May '15 - 13:49 »
3.8.1.12: Song title scroll speed increases when moving the mouse over playlist or library entries. Tested on the default skin and a custom uncompiled one, happens with the playlist panel, the extended playlist and the library.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #302 on: 19 May '15 - 14:33 »
Oops, that's due to some refresh rate reduction tweaks (to reduce CPU usage) in the last update. The refresh rate needs to be kept high while scrolling the title. I'll sort that for the next update.

Philippe

  • Posts: 43
Re: 3.8 reports, queries and bugs
« Reply #303 on: 21 May '15 - 13:52 »


   www.un4seen.com/stuff/xmplay.exe

MMhhh... I tried to download the latest "stuff" version today, and for the first time ever I got a "404 Not Found - nginx" page instead...

Thought I should let you know.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #304 on: 21 May '15 - 15:11 »
Yep, a "stuff" version isn't available currently as the release version (3.8.1.12) on the XMPlay webpage is the latest.

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #305 on: 25 May '15 - 20:33 »
I dropped a mysterious crash dump on the FTP, xmplay-freeze-saga.7z. This happened again using DSound, while suspending to RAM and detaching / re-attaching headphones.

piovrauz

  • Posts: 967
Re: 3.8 reports, queries and bugs
« Reply #306 on: 26 May '15 - 10:16 »
Well, not really a bug, but there's still something that needs fixing...
In the info window the frequency unit is written as "hz", while it should be written as "Hz" (SI docet).
Heinrich Rudolf Hertz expects a due correction... XD

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #307 on: 26 May '15 - 17:00 »
I dropped a mysterious crash dump on the FTP, xmplay-freeze-saga.7z. This happened again using DSound, while suspending to RAM and detaching / re-attaching headphones.

It appears to be stuck in a GetCurrentPosition call on the DirectSound buffer, and XMPlay is waiting for that to return so that it can release the buffer before the system is suspended. I'm not really sure what can be done about it. Did you suspend the system while it was in the process of switching to/from headphone output? Also, does the problem only happen if XMPlay is using the affected output, ie. not if a different soundcard is used?

Well, not really a bug, but there's still something that needs fixing...
In the info window the frequency unit is written as "hz", while it should be written as "Hz" (SI docet).
Heinrich Rudolf Hertz expects a due correction... XD

Yeah, strictly speaking it should be "Hz". It's just that I think "hz" fits better with the other lowercase units there, eg. "bytes", "bit", "kbps" :)

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #308 on: 26 May '15 - 19:19 »
I think that I have pulled out the headphone plug before suspending, but I cannot be entirely sure. It definitely happened after pausing playback in XMPlay, though. If you don't see any immediate solution to it, I guess we can just label it as a typical DSound problem and forget about it.

markun2

  • Posts: 2
Re: 3.8 reports, queries and bugs
« Reply #309 on: 30 May '15 - 19:20 »
Nice to meet you, too

XM Play 3.8.1.12
Reproducibility is strange.

neverend-silkdreams
http://lite.modarchive.org/index.php?query=neverend-silkdreams&request=search&search_type=songtitle

markun2

  • Posts: 2
Re: 3.8 reports, queries and bugs
« Reply #310 on: 1 Jun '15 - 07:29 »
Nice to meet you, too

XM Play 3.8.1.12
Reproducibility is strange.

"Jason's Rhapsody"
http://lite.modarchive.org/index.php?query=Jason%27s+Rhapsody&request=search&search_type=songtitle

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #311 on: 1 Jun '15 - 17:04 »
I think that I have pulled out the headphone plug before suspending, but I cannot be entirely sure. It definitely happened after pausing playback in XMPlay, though.

Yep, XMPlay will only release the output device when suspending if playback is paused at the time. That was introduced (in 3.8.1) because Windows will automatically resume paused playback when the system is resumed.

XM Play 3.8.1.12
Reproducibility is strange.

neverend-silkdreams
http://lite.modarchive.org/index.php?query=neverend-silkdreams&request=search&search_type=songtitle
...
"Jason's Rhapsody"
http://lite.modarchive.org/index.php?query=Jason%27s+Rhapsody&request=search&search_type=songtitle

To save some time, please give a position where each file isn't sounding right in XMPlay. Also, in the MOD file's case, you could try changing the "MOD playback mode" setting in the "MOD" options page and see if that helps.

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #312 on: 1 Jun '15 - 18:10 »
In case of the first mod, the issue is that in pattern 20 (at about 4:20), there is a portamento effect with a 00 parameter (100). Apparently XMPlay only ignores this in PT1 mode, which I find a bit weird since I've always thought that 1xx/2xx should never have effect memory in MOD files under any circumstances? Are there any trackers that actually have memory for these commands?
« Last Edit: 1 Jun '15 - 18:18 by saga »

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #313 on: 2 Jun '15 - 15:17 »
Oh yes, you're right, it should always be ignoring "100" effects (and "200") in MOD files. I'll correct that for the next update. I don't suppose you found the problem in the S3M file too? :)

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #314 on: 2 Jun '15 - 19:34 »
The S3M file sounded pretty normal to me, no idea what's supposed to be wrong there. :)
Edit: There is indeed something that is not being handled correctly: Recently you implemented ScreamTracker 3 style effect memory, which takes the last non-zero parameter as command memory. However, vibrato commands should still have their own memory, so H00 and U00 should always recall vibrato memory, not the last non-zero parameter.
« Last Edit: 2 Jun '15 - 23:49 by saga »

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #315 on: 3 Jun '15 - 23:48 »
A while ago, I fixed S9F behaviour in OpenMPT so that it actually does something sensible with looped samples. That is, when applying S9F next to a note of a looped sample, it will now start from the end of the sample (as before) and actually play the sample backwards (this part is new). Would be great if XMPlay/BASS follows the new implementation.
Ping :) Did you look into changing this behaviour yet? See the linked post for an example file, which should play a backwards looping bass drum.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #316 on: 4 Jun '15 - 16:38 »
There is indeed something that is not being handled correctly: Recently you implemented ScreamTracker 3 style effect memory, which takes the last non-zero parameter as command memory. However, vibrato commands should still have their own memory, so H00 and U00 should always recall vibrato memory, not the last non-zero parameter.

Oh right, it was indeed using the wrong shared memory for H00. Here's an update to sort that and the previous MOD issue:

   www.un4seen.com/stuff/xmplay.exe

A while ago, I fixed S9F behaviour in OpenMPT so that it actually does something sensible with looped samples. That is, when applying S9F next to a note of a looped sample, it will now start from the end of the sample (as before) and actually play the sample backwards (this part is new). Would be great if XMPlay/BASS follows the new implementation.
Ping :) Did you look into changing this behaviour yet? See the linked post for an example file, which should play a backwards looping bass drum.

The update above should also do this. It doesn't do any special tracker checking, but I think S9F is an MPT-only thing anyway?

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #317 on: 4 Jun '15 - 21:25 »
Yup, it should be OpenMPT-only. The old behaviour could of course still be used for old MPT versions or OpenMPT versions older than 1.22.

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #318 on: 25 Jun '15 - 14:42 »
I'm not sure if this was supposed to be fixed before, but resuming playback of a VBR MP3 file with cuesheets afte closing XMPlay doesn't quite work as intended.
Audio is resumed at the correct position, however the timer is not, it pointed to a position in the future, so according to the title display it was already playing the next song. Using cursor keys to adjust the playback position adjusts it relative to this reported position, not to the real playback position.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #319 on: 25 Jun '15 - 17:51 »
Are you sure the problem isn't the other way round, ie. the time display is correct (the same as it was) but the heard position isn't? To have accurate seeking in MP3 files (particularly VBR files), XMPlay needs to scan the file for seek points. To avoid delaying playback, XMPlay will do the scanning after starting playback, so any seeking (eg. to the resumption position) before that's finished may be inaccurate.

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #320 on: 25 Jun '15 - 20:13 »
Ah yes, I just re-checked the time display was indeed correct but the playback position wasn't. I do think it would be a good idea to do the scanning in advance when resuming from a position. You don't really gain anything from this feature if it leaves off from the completely wrong playback position, especially when listening to e.g. a mixtape with several songs in it. I'd rather wait for the VBR scanning to complete than resuming from the wrong position.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #321 on: 26 Jun '15 - 14:38 »
Yep, I'll make it wait for the scanning to finish before resuming playback in the next update.

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #322 on: 15 Jul '15 - 14:53 »
XMPlay's song length estimation seems to get confused when there are position jumps and row breaks inside a pattern loop. Here's a test case which detects the second pattern as a separate subtune, even though it should be played consecutively.
« Last Edit: 20 Jul '15 - 16:45 by saga »

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.8 reports, queries and bugs
« Reply #323 on: 20 Jul '15 - 13:00 »
I don't seem to be able to reproduce the problem here; I'm seeing a single song detected, with a length of 5.6 seconds. Perhaps the problem is triggered by some config setting, so please upload your XMPLAY.INI file to have a look at here:

   ftp.un4seen.com/incoming/

saga

  • Posts: 2179
Re: 3.8 reports, queries and bugs
« Reply #324 on: 20 Jul '15 - 16:45 »
Oops, I accidentally simplified the test case a bit too much so the behaviour was not triggered anymore. Seems like that it might require at least two pattern jumps in the loop to trigger the erroneous behaviour, so I have updated the file in the post above to reflect that.