Author Topic: 3.5 reports, queries and bugs  (Read 106325 times)

Nicramek

  • Guest
Re: 3.5 reports, queries and bugs
« Reply #300 on: 5 Dec '10 - 21:58 »
Thank for so fast reply, but Your link do not work. It says 404 error.
You may download sample mp3 from here: www.marcinwilk.eu/music.zip

Thanks :)

Pike84

  • Posts: 1398
Re: 3.5 reports, queries and bugs
« Reply #301 on: 5 Dec '10 - 22:10 »
Sorry, I accidentally pasted the address as a http link :P. I fixed it now.

Nicram

  • Posts: 5
Re: 3.5 reports, queries and bugs
« Reply #302 on: 5 Dec '10 - 22:19 »
Oh, ok, i uploaded few songs. I hope it will help. thank you for so fast response, i didn;t expect that :)

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.5 reports, queries and bugs
« Reply #303 on: 6 Dec '10 - 15:04 »
http://modarchive.org/module.php?165754
Although this track has a restart position, XMPlay doesn't detect it as looping (possible because there's digital silence at the end)

Yep, the restart position isn't actually used in the loop detection; it's based on whether there are notes playing at the end, and at what level (eg. not faded-out). In this file's case there is a note playing, but at a level lower than the threshold. Here's an update to try, with the threshold reduced so that the file is detected as looped...

   www.un4seen.com/stuff/xmplay.exe

Let me know if you find that other files have suddenly erroneously become looped :)

Oh, ok, i uploaded few songs.

The problem is that the file's ID3v2 tags have been created using the ISO-8859-1 character set rather than Unicode, which unfortunately makes it impossible for them to correctly contain things like Thai characters.

Zarggg

  • Posts: 1242
Re: 3.5 reports, queries and bugs
« Reply #304 on: 6 Dec '10 - 15:31 »
Yep, the restart position isn't actually used in the loop detection; it's based on whether there are notes playing at the end, and at what level (eg. not faded-out). In this file's case there is a note playing, but at a level lower than the threshold.
Is it not possible to actually detect the restart position and override any other internal "guessing"? I don't know much about programming a mod player, but to me that would seem the most logical method.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.5 reports, queries and bugs
« Reply #305 on: 7 Dec '10 - 14:06 »
Yes, it would be possible to treat any non-0 restart position as a looping file, but checking for sound at the end is more general purpose, eg. the IT/S3M/MTM formats don't support a restart position, and a single restart position also doesn't work with sub-songs. A position jump effect will usually be used to loop instead.

If you have any files that aren't being detected correctly, then please let me know so that things can be tweaked.

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #306 on: 10 Dec '10 - 18:05 »
Changelog for XMPlay 3.5:

The changelog for 3.6 can be found in the 3.6 reports, queries and bugs-thread.
« Last Edit: 22 Dec '10 - 20:26 by Dotpitch »

Chinese Sausage

  • Posts: 424
Re: 3.5 reports, queries and bugs
« Reply #307 on: 11 Dec '10 - 12:30 »
Thanks again Dotpitch! :)

Zorba

  • Guest
Re: 3.5 reports, queries and bugs
« Reply #308 on: 13 Dec '10 - 08:31 »
Hello, on some songs the ratings disapear when I close and restart the player, is it incompatible with some types of audio files ?

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #309 on: 13 Dec '10 - 09:55 »
Hello, on some songs the ratings disapear when I close and restart the player, is it incompatible with some types of audio files?
Ratings are not stored in the files itself, but in the library. If a file is not in the library, its ratings will be lost when you close XMPlay.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.5 reports, queries and bugs
« Reply #310 on: 13 Dec '10 - 13:38 »
Info for the tracks currently in the playlist is also stored in the library file (XMPLAY.LIBRARY), so ratings in the playlist should be retained across sessions too, but to retain the info long-term (ie. even after removal from the playlist), the tracks would need to be added to the library.

Jace

  • Posts: 825
Re: 3.5 reports, queries and bugs
« Reply #311 on: 17 Dec '10 - 11:27 »
Not certain if I'm doing something wrong here but I'm having some problems with the Find tracks dialog. Trying to get tracks from two bands to match. As in all tracks by "Blah" and "Floof".

Quote from: xmplay.txt
'+' and '-' prefixes can be used to require that a word is present or absent, respectively. Of any other words, at least one must be present. For example, a search string of "+a -b c d" would mean that "a" must be present, "b" must be absent, and either "c" or "d" must be present.

According to this it should just be "Blah Floof", right? Though that only brings up tracks which contain both "Blah" and "Floof". Tried with adding a phrase with a + or - in case that triggered it to go OR instead of AND with no luck. In addition, the - prefix works fine (excludes tracks with following word), but + doesn't seem to. Even if I search just "+a", it doesn't find a single match.

Tried with a clear xmplay.ini, behaved just the same. Either I'm just mightily confused or this is a case of knobbed whoopsies.

Pike84

  • Posts: 1398
Re: 3.5 reports, queries and bugs
« Reply #312 on: 17 Dec '10 - 11:39 »
I haven't used the search much, so I hadn't noticed, but I can confirm this on my part; I can't find anything if I enter two strings of two tracks, that don't appear in both cases. None of the options seem to affect this.

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #313 on: 17 Dec '10 - 17:01 »
Yep, there was a change in 3.5.0.1:
Quote from: xmplay.txt
When multiple words are specified, they must all be present for a track to be considered a match. Words can be prefixed with '-' to require them to be absent rather than present. It is also possible to group words so that only one of the group has to be present, by joining them with '/'. For example, a search string of "a -b c/d" would mean that "a" must be present, "b" must be absent, and at least one of "c" or "d" must be present.
So you'd have to use "Blah/Floof".

Jace

  • Posts: 825
Re: 3.5 reports, queries and bugs
« Reply #314 on: 17 Dec '10 - 20:44 »
Ah, thanks. Thought there might've been something along those lines. But "find" and "dialog" aren't particularly good keywords for the search. :P

saga

  • Posts: 2179
Re: 3.5 reports, queries and bugs
« Reply #315 on: 21 Dec '10 - 17:00 »
it seems like a change has happened some time ago; I have my extended playlist window above the player window. When double-clicking the player, it goes into the mini mode. Previously, the playlist window was moved down so the distance between the player and the playlist didn't change; now it doesn't move with the main window anymore. "move info window with main" is enabled, though.
Furthermore, when the player is set to mini mode, the window title (song title) is first moved up two pixels or so, and shortly after that it is moved down a few pixels. That doesn't look intentional... Using the Neutron(medium) skin.

Chinese Sausage

  • Posts: 424
Re: 3.5 reports, queries and bugs
« Reply #316 on: 21 Dec '10 - 17:41 »
The problem you mention seems to be fixed with the recent stuff version. Also reassure that the Auto-resize option is not enabled.

saga

  • Posts: 2179
Re: 3.5 reports, queries and bugs
« Reply #317 on: 22 Dec '10 - 07:57 »
I just downloaded the .55 version before reporting, so no, the current version doesn't fix this.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: 3.5 reports, queries and bugs
« Reply #318 on: 22 Dec '10 - 16:04 »
it seems like a change has happened some time ago; I have my extended playlist window above the player window. When double-clicking the player, it goes into the mini mode. Previously, the playlist window was moved down so the distance between the player and the playlist didn't change; now it doesn't move with the main window anymore. "move info window with main" is enabled, though.
Furthermore, when the player is set to mini mode, the window title (song title) is first moved up two pixels or so, and shortly after that it is moved down a few pixels. That doesn't look intentional... Using the Neutron(medium) skin.

The playlist window doesn't move when toggling mini-mode with any version that I try (I tried 3.5.1/3.5/3.4.2), so I'm not sure I understand the problem. Perhaps you could post some screenies to illustrate it? Also, do you (or did you) happen to be using a laptop with something like Synaptics touchpad software installed? I seem to recall that resulting in some strange things in the past.

Anyway, if there is still a problem, let the "3.6 reports, queries and bugs" thread commence :)

saga

  • Posts: 2179
Re: 3.5 reports, queries and bugs
« Reply #319 on: 22 Dec '10 - 17:58 »

Probably this was an unintentional feature; I notice that it only happens if the main window is docked to the task bar. In that case, the player shrinks in the direction of the toolbar (downwards), and otherwise it shrinks towards the title bar of the player (upwards).
Also, do you (or did you) happen to be using a laptop with something like Synaptics touchpad software installed?
Always. ;D

oddiophile

  • Posts: 149
Re: 3.5 reports, queries and bugs
« Reply #320 on: 22 Dec '10 - 19:09 »
For reporting bugs and problems, use this free open-source screen capture tool:

http://www.cockos.com/licecap/

and post an animated .GIF image :)
« Last Edit: 22 Dec '10 - 19:25 by oddiophile »

Chinese Sausage

  • Posts: 424
Re: 3.5 reports, queries and bugs
« Reply #321 on: 22 Dec '10 - 20:17 »
Thank you for this tools, I've needed this :)