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

Leras

  • Guest
Re: 3.8 reports, queries and bugs
« Reply #475 on: 11 Jun '17 - 03:43 »
In a new version bug is fixed. Great support!

Ian, thank you so much for great player!

tails__

  • Posts: 8
Re: 3.8 reports, queries and bugs
« Reply #476 on: 7 Aug '17 - 09:48 »
Ugh, I beg my pardon for posting in a wrong thread a few days ago.
Here's the link: http://www.un4seen.com/forum/?topic=15431.msg124674#msg124674

TL;DR: XMPlay does not break lines as supposed when text width is set in setting for Chinese/Japanese text and in file path.

Aryetis

  • Posts: 2
Re: 3.8 reports, queries and bugs
« Reply #477 on: 7 Aug '17 - 09:53 »
Hello,

I recently (couple months ago) updated to windows 10 and doing so I also updated my old xmplay. But since then whenever I change its skin from default to "whatever" the change do occurs, but gets rested back to default whenever I close and reopen xmplay.

Any ideas of what could be causing that sort of behavior ? Am I the only one in this case ?

EDIT : it doesn't keep track of opened files in the playlist either ... Seems to me like xmplay cannot create some file where it keeps its setting, playlists and such, maybe due to writing permissions ... Thought I don't even remember where that file is supposed to be and can't find any logs :/
« Last Edit: 7 Aug '17 - 11:59 by Aryetis »

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #478 on: 7 Aug '17 - 17:35 »
Yes, that does sound like XMPlay is unable to write its config files. Where do you have XMPlay installed, and do you see an XMPLAY.INI file there after closing XMPlay? You could try enabling the "Store per-user config/etc" option in the "Miscellaneous" options page and see if that helps.

Aryetis

  • Posts: 2
Re: 3.8 reports, queries and bugs
« Reply #479 on: 7 Aug '17 - 19:49 »
Got my xmplay installed in C:\outils\xmplay3823\ (outils <=> tools), I even "took ownership" of the whole folder to make sure there would be no permission conflicts. But it looks like it wasn't enough because I can't see any XMPLAY.INI in this folder. The "Store per user config" trick worked out fine for me, thank you.
So yeah I'm pretty sure the issue is on my side and not xmplay related, but if you need any informations to confirm this, please ask for it and I shall provide

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #480 on: 16 Aug '17 - 17:14 »
Filenames in LZH archies are not displayed correctly in the song properties. For example, taking the LZH file from this post, the filenames for all playlist entries are "gold.lhz|", with the in-archive filename missing after the pipe character.

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #481 on: 17 Aug '17 - 16:38 »
The problem is caused by the archive entry having some funky characters and the LHA/LZH plugin isn't converting them to UTF-8 for XMPlay. Here's an update that should handle it:

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

sveakul

  • Posts: 16
Re: 3.8 reports, queries and bugs
« Reply #482 on: 17 Aug '17 - 20:38 »
As the BASS module for Opus decoding was released June 30th updating the core decoder to libopus 1.2.1, would it be possible to release an updated version of xmp-opus.dll reflecting the same update to 1.2.1?  Thanks for your attention

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #483 on: 18 Aug '17 - 16:47 »
As I recall, libopus 1.2(.1) didn't introduce any decoding improvements/fixes (only encoding). Still, a higher version number looks better, so I've put up an Opus plugin update now anyway :)

sveakul

  • Posts: 16
Re: 3.8 reports, queries and bugs
« Reply #484 on: 18 Aug '17 - 18:14 »
Thanks Ian, I appreciate both your fast response and the update!  Been ripping music to 1.2.1 heavily and nice to be sure I have the speed improvements on both the encoding and decoding end of things.  Excited about this codec in general.

BTW, what is the relationship of the "regular" BASS modules to the "xmp-" versions that xmplay uses?  Seeing as some players use the standard BASS dll's as-is (Musicbee, Aimp, etc) I've been curious as to why xmplay does not, as they seem to be from the same developer (you?).

Thanks again for great support.


saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #485 on: 21 Aug '17 - 18:38 »
BTW, what is the relationship of the "regular" BASS modules to the "xmp-" versions that xmplay uses?  Seeing as some players use the standard BASS dll's as-is (Musicbee, Aimp, etc) I've been curious as to why xmplay does not, as they seem to be from the same developer (you?).
XMPlay has its own plugin system, as it is not built on top of BASS - it just shares most of its code with BASS. Other players by different authors can of course not pull that off, so they need to use the BASS plugin system. They could add their own support for XMPlay plugins, but it's not really necessary since most XMPlay plugins are also available as BASS plugins.

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #486 on: 22 Aug '17 - 14:57 »
Yep, the core (eg. decoder) of an XMPlay plugin will be the same as the corresponding BASS add-on, but BASS and XMPlay have different interfaces for the plugin/add-on to use. The BASS interface is more bare-bones. For example, it doesn't have info window stuff. The BASS user would implement that extra stuff themselves, if wanted.

sveakul

  • Posts: 16
Re: 3.8 reports, queries and bugs
« Reply #487 on: 22 Aug '17 - 19:15 »
Thanks Ian and saga for the explanation!

sveakul

  • Posts: 16
Re: 3.8 reports, queries and bugs
« Reply #488 on: 30 Aug '17 - 03:44 »
Is there any way to make "Write separate tracks" the default choice (checked) when keying the Write to disk--Download/Extract option while listening to a radio stream?  Have looked through xmplay.ini without finding any obvious "secret setting".  TIA

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #489 on: 4 Sep '17 - 00:55 »
About 9 seconds in, XMPlay simply crashes when trying to play this module:
https://modarchive.org/module.php?152282

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #490 on: 4 Sep '17 - 17:22 »
I don't seem to be able to reproduce that here, using the latest "stuff" build. If you rename your XMPLAY.INI file for a fresh config, does it still happen then? If not, please upload your XMPLAY.INI file, to check what setting is triggering the crash:

   ftp.un4seen.com/incoming/

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #491 on: 4 Sep '17 - 18:54 »
I have uploaded the .ini and a memory dump as xmplay-crash-saga.7z.
Interestingly, there is another crash (also happening with the default INI) if you try to view the message tab of that file. XMPlay really doesn't seem to like this file!

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #492 on: 5 Sep '17 - 16:04 »
I can reproduce the Message info window crash; the file's message is too big (40KB) for the info window text buffer. Here's an update that will crop the message to 30KB to prevent the crash:

   www.un4seen.com/stuff/xmplay.exe

I'm still unable to reproduce the other crash. Unfortunately, the dump doesn't reveal the crash location (it's probably a stack buffer overflow somewhere). I notice you have the auto-load settings option enabled, so perhaps it's something in the saved settings that's triggering the problem. Does it still happen if you disable auto-load settings? Did the crash happen when you renamed XMPLAY.INI for a fresh config? To help narrow it down, does it still happen if the info window is closed?

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #493 on: 5 Sep '17 - 17:43 »
With the new version, I cannot reproduce the crash anymore. Maybe the overly long message text was responsible for both crashes and overwrote some other memory without me having to go to the info window's message tab? For what it's worth, the info window was always open.
Anyway, shouldn't the buffer for the message be allocated dynamically to allow for arbitrarily-sized song messages?

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #494 on: 5 Sep '17 - 18:07 »
That's strange. The modification only affects the Message info window, so I wouldn't expect it to make any difference to the other crash if that happened without the Message info window being open. Was the crash happening every time you played the file previously, or only sometimes? Anyway, let me know if you see it happen again.

Regarding buffer allocation, the message's buffer is allocated dynamically when it's read from file (the entire message is still read now), but the info window's text buffer (passed to a plugin's GetMessage function) is currently fixed at 40KB. The file's message is a bit larger than that (once the funky characters are converted to UTF-8). The plugin API doesn't currently have any way for a plugin to enlarge the buffer, so they need to stay within the limit, but perhaps the size could be increased by default.

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #495 on: 5 Sep '17 - 22:43 »
To clarify, it didn't happen with a fresh xmplay.ini, however the uploaded xmplay.ini's MOD settings should have been the ones I actually used (as there were no specific settings for that file that could be auto-loaded). But with the uploaded xmplay.ini, the crash was 100% reproducable.
Reverting to the old xmplay.exe, I can still reliably reproduce the crash (with the same strange memory dump), even with the info window being hidden. Looking at the MOD vis, the crash always happens on the second pattern at around the fifth row. Manually jumping to the second patterns does not provoke the crash, it only happens if I play the song from the beginning.

Edit: Two more observations:
1) Manually removing the song message completely fixes the crash. So it seems like it is definitely related to that, even though for some reason, xmplay.ini also contributes. Possibly some buffer overflow that corrupts different kind of data depending on how much data has been read from xmplay.ini?
2) I found yet another crash. ;D XMPlay does not seem to sanitize the length of the "text" chunk, so if you truncate the file so that half of the song message is missing (without adjusting for the length field after the "text" magic bytes), XMPlay will read past the end of the file and crash: 'The "Modules" plugin crashed while attempting to open the following file: ...'
« Last Edit: 5 Sep '17 - 23:00 by saga »

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #496 on: 6 Sep '17 - 17:58 »
To clarify, it didn't happen with a fresh xmplay.ini, however the uploaded xmplay.ini's MOD settings should have been the ones I actually used (as there were no specific settings for that file that could be auto-loaded). But with the uploaded xmplay.ini, the crash was 100% reproducable.
Reverting to the old xmplay.exe, I can still reliably reproduce the crash (with the same strange memory dump), even with the info window being hidden. Looking at the MOD vis, the crash always happens on the second pattern at around the fifth row. Manually jumping to the second patterns does not provoke the crash, it only happens if I play the song from the beginning.

Are you able to find out which option setting is triggering the crash? One of the MOD options seems most likely, so you could try changing those.

1) Manually removing the song message completely fixes the crash. So it seems like it is definitely related to that, even though for some reason, xmplay.ini also contributes. Possibly some buffer overflow that corrupts different kind of data depending on how much data has been read from xmplay.ini?

That's very strange. I can't see any other place (besides the Message info window case) that the message text could cause a buffer overflow, as it isn't copied anywhere else. When you removed the message, was the rest of the file exactly the same as before, eg. if you use "fc /b" to compare them?

2) I found yet another crash. ;D XMPlay does not seem to sanitize the length of the "text" chunk, so if you truncate the file so that half of the song message is missing (without adjusting for the length field after the "text" magic bytes), XMPlay will read past the end of the file and crash: 'The "Modules" plugin crashed while attempting to open the following file: ...'

Indeed, XMPlay wasn't checking that OpenMPT chunks are fully present in the file. Here's an update to fix that (it won't read incomplete chunks):

   www.un4seen.com/stuff/xmplay.exe

This update also increases the amount of the message text that is shown in the Message info window to 35KB.

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #497 on: 6 Sep '17 - 18:56 »
Okay, I just had an epiphany. ;D It's related to xmp-scrobbler fetching the song metadata, and I have set it to do so after ten seconds of playback. Disabling xmp-scrobbler also prevents the crash in the old version. Cleaning up xmplay.ini helped because that caused xmp-scrobbler not to be added to the DSP chain.
« Last Edit: 7 Sep '17 - 00:31 by saga »

Ian @ un4seen

  • Administrator
  • Posts: 20437
Re: 3.8 reports, queries and bugs
« Reply #498 on: 7 Sep '17 - 14:32 »
Ah, that would make sense. It probably fetches the Message info window text to extract metadata. Mystery solved then :)

saga

  • Posts: 2183
Re: 3.8 reports, queries and bugs
« Reply #499 on: 13 Sep '17 - 23:26 »
I uploaded a file (jco - false message.mp3) where the "copy to clipboard" functionality on the message tab does not quite work as intended. After the first ID3v2 tag, it seems to stop.