Author Topic: 3.4 reports, queries and bugs  (Read 303812 times)

mtas

  • Posts: 8
Re: 3.4 reports, queries and bugs
« Reply #650 on: 13 May '09 - 20:35 »
ok, thanks for the help to all, have connected another mouse and everything works fine. it must be the synaptics touchpad. tried different driversettings like buffersize, pagescroll and refreshrate - without success. would be nice if this could be solved in the future, guess there are many other synaptics users.

sys-specs are:
-synaptics touchpad, driver 8.2.xx and now 10.xx
-xp sp3
-hp pavilion dv8382ea
-centrino duo
-gforce go 7600
« Last Edit: 14 May '09 - 08:55 by mtas »

Cris

  • Posts: 231
Re: 3.4 reports, queries and bugs
« Reply #651 on: 14 May '09 - 11:51 »
I also have this problem with the Synaptics Touchpad (driver v8.2.4.6), on Dell Inspiron 1501.

saga

  • Posts: 1986
Re: 3.4 reports, queries and bugs
« Reply #652 on: 14 May '09 - 14:49 »
I think I have a problem similar to piovrauz's. The info window disappears always after shutting windows down. It's still there if I just restart XMPlay in one windows session.

piovrauz

  • Posts: 937
Re: 3.4 reports, queries and bugs
« Reply #653 on: 14 May '09 - 16:36 »
So let's name it: the infamous "vanishing shutting windows down" (maybe) bug. XD

Dotpitch

  • Posts: 2829
Re: 3.4 reports, queries and bugs
« Reply #654 on: 14 May '09 - 19:06 »
I think I have a problem similar to piovrauz's. The info window disappears always after shutting windows down. It's still there if I just restart XMPlay in one windows session.
So let's name it: the infamous "vanishing shutting windows down" (maybe) bug. XD
The position of the Info window is saved in xmplay.ini as well (InfoPos). saga and piovrauz, do you have 'Store per-user config/etc' checked? Could you check the values of InfoPos before and after restarting Windows?

saga

  • Posts: 1986
Re: 3.4 reports, queries and bugs
« Reply #655 on: 14 May '09 - 22:02 »
I have xmplay.ini in xmplay's folder, so the first one is negative. Just to remember for me when I restart my PC the next time, the current window pos is InfoPos=94030000290200000005000019030000 - however, I don't see how the window position could be relevant here, because after pressing F4 (for example) ,it will reappear at the old position.

Dotpitch

  • Posts: 2829
Re: 3.4 reports, queries and bugs
« Reply #656 on: 15 May '09 - 06:04 »
however, I don't see how the window position could be relevant here, because after pressing F4 (for example) ,it will reappear at the old position.
You're right, PanelPos is the one you should have.

piovrauz

  • Posts: 937
Re: 3.4 reports, queries and bugs
« Reply #657 on: 15 May '09 - 10:51 »
Store per-user config/etc' is not checked (btw, I'm the only user on bot machines, one with logon pwd).

saga

  • Posts: 1986
Re: 3.4 reports, queries and bugs
« Reply #658 on: 21 May '09 - 20:11 »
Due to some recent update in the stuff version (can't recall exactly what it was about), playlist entries that already exist seem to be moved to the bottom of the playlist if they're added to the playlist again. Not exactly what I want...

Ian @ un4seen

  • Administrator
  • Posts: 18982
Re: 3.4 reports, queries and bugs
« Reply #659 on: 25 May '09 - 16:19 »
Bejeweled Twist uses BASS!  (Gotta love Skaven.) 

I can't figure out which settings to use in XMPlay to make the MO3s play like they should.  Subsong 2/14 has some percussion that sounds out of sync (compared to when played in-game.)  Generally the songs sound smoother in XMPlay (with different combinations of Surround sound, Interpolation, etc.) than in-game, and I can't figure out why it would be different.
 
FTP:
bejewel twist 06.10.mo3

The drum-loop in channel 1 does sound a bit out of place. I haven't heard the tune in-game, but perhaps that channel is muted? You can do that in XMPlay via the "MOD Pattern Display" vis (middle-click on the channel).

Regarding things sounding "smoother", do you mean that percussive sounds aren't so percussive? If so, check that the Ramping setting isn't on "normal" (try "sensitive" instead).

well, about the menu with the options when closing xmplay... in the last build sometime changed: it doesn't remember the position (even if I tell it to) upon a computer restart.

I think I have a problem similar to piovrauz's. The info window disappears always after shutting windows down. It's still there if I just restart XMPlay in one windows session.

I guess these are down to Windows shutting-down without closing XMPlay (which is when those settings would be saved), but I'm sure something had already been done about that :)

Trying it just now, the playback and info window position were saved when restarting Windows. That was with the current "stuff" version on XP and Vista. What XMPlay and Windows versions are you using?

Due to some recent update in the stuff version (can't recall exactly what it was about), playlist entries that already exist seem to be moved to the bottom of the playlist if they're added to the playlist again. Not exactly what I want...

Here's an update to try, in which that is optional ("move existing" option)...

   www.un4seen.com/stuff/xmplay.exe

saga

  • Posts: 1986
Re: 3.4 reports, queries and bugs
« Reply #660 on: 25 May '09 - 19:21 »
thanks for the update! about the mysterious info window problem, it doesn't seem to happen all the time. I'll try to track this problem down...

SmartOne

  • Posts: 217
Re: 3.4 reports, queries and bugs
« Reply #661 on: 5 Jun '09 - 07:29 »
The drum-loop in channel 1 does sound a bit out of place. I haven't heard the tune in-game, but perhaps that channel is muted? You can do that in XMPlay via the "MOD Pattern Display" vis (middle-click on the channel).

Regarding things sounding "smoother", do you mean that percussive sounds aren't so percussive? If so, check that the Ramping setting isn't on "normal" (try "sensitive" instead).

Thank you.  It was the channel muting and possibly a different surround or volume ramping setting.  Didn't know you could mute channels.  Learn something new about XMPlay every day!   :)

saga

  • Posts: 1986
Re: 3.4 reports, queries and bugs
« Reply #662 on: 5 Jun '09 - 13:16 »
Ok, I think I know what's going wrong with the info window now: When I use "close at end of track" and have the player minimized to the tray, the info window won't show up the next time I launch xmplay. :)

weeeee, 600 posts! ;D
« Last Edit: 5 Jun '09 - 14:08 by saga »

Cosworth

  • Posts: 121
Re: 3.4 reports, queries and bugs
« Reply #663 on: 5 Jun '09 - 14:21 »
Strange bug I have today, when I press on "Position slider", xmplay is open "Open file" window :-\
« Last Edit: 5 Jun '09 - 14:25 by Cosworth »

Dotpitch

  • Posts: 2829
Re: 3.4 reports, queries and bugs
« Reply #664 on: 5 Jun '09 - 15:05 »
Strange bug I have today, when I press on "Position slider", xmplay is open "Open file" window :-\
Does that happen with the default skin as well? Perhaps this black version is just misconfigured.

Cosworth

  • Posts: 121
Re: 3.4 reports, queries and bugs
« Reply #665 on: 5 Jun '09 - 17:06 »
Strange bug I have today, when I press on "Position slider", xmplay is open "Open file" window :-\
Does that happen with the default skin as well? Perhaps this black version is just misconfigured.

It's happens with all skins. Strange bug... :-X

Ian @ un4seen

  • Administrator
  • Posts: 18982
Re: 3.4 reports, queries and bugs
« Reply #666 on: 5 Jun '09 - 17:19 »
Ok, I think I know what's going wrong with the info window now: When I use "close at end of track" and have the player minimized to the tray, the info window won't show up the next time I launch xmplay. :)

Ah yes. Here's an update that should correct that...

   www.un4seen.com/stuff/xmplay.exe

Strange bug I have today, when I press on "Position slider", xmplay is open "Open file" window :-\


Strange indeed. When you move the mouse over the position slider, does the slider or the "Open file(s)" button get highlighted?

Cosworth

  • Posts: 121
Re: 3.4 reports, queries and bugs
« Reply #667 on: 5 Jun '09 - 18:04 »
Quote
Quote
Strange bug I have today, when I press on "Position slider", xmplay is open "Open file" window :-\


Strange indeed. When you move the mouse over the position slider, does the slider or the "Open file(s)" button get highlighted?



Hm, I think, I had found why, it's after "Babylon" translater :o
« Last Edit: 5 Jun '09 - 18:06 by Cosworth »

Dotpitch

  • Posts: 2829
Re: 3.4 reports, queries and bugs
« Reply #668 on: 5 Jun '09 - 19:38 »
Hm, I think, I had found why, it's after "Babylon" translater
So Babylon Translator tries to hook into XMPlay, but it actually breaks the interface. Do more funny things occur, or do the rest of XMPlays buttons work properly? I hope Babylon has some sort of blacklist which you can add XMPlay to.

Cosworth

  • Posts: 121
Re: 3.4 reports, queries and bugs
« Reply #669 on: 5 Jun '09 - 20:39 »
Hm, I think, I had found why, it's after "Babylon" translater
So Babylon Translator tries to hook into XMPlay, but it actually breaks the interface. Do more funny things occur, or do the rest of XMPlays buttons work properly? I hope Babylon has some sort of blacklist which you can add XMPlay to.

Yep, I had add :)

saga

  • Posts: 1986
Re: 3.4 reports, queries and bugs
« Reply #670 on: 6 Jun '09 - 10:48 »
I think it would be a good idea if xmplay saved the queue independently from the rest of xmplay.ini at regular intervals, just like the playlist. I had a rather long queue and decided to unload the oddcast plugin which crashed xmplay then... so my queue was gone..

Oh, and I'd also request better support for synaptics touchpads, because I can neither use the trackpoint nor the touchpad to scroll the playlist on my thinkpad :(
« Last Edit: 6 Jun '09 - 11:08 by saga »

Tsorovan

  • Posts: 1247
Re: 3.4 reports, queries and bugs
« Reply #671 on: 6 Jun '09 - 15:48 »
The playlist should really be saved whenever there is an actual change (whenever a file is added or removed, or the list is reordered in any way). I'm surprised that wasn't fixed earlier.
Put in a 5-second activity check/delay or something like that so it won't cause disk thrashing (when adding lots of files) and/or saving a file entry to a corrupt file that crashes XMPlay upon adding to the playlist.
« Last Edit: 6 Jun '09 - 15:50 by Tsorovan »

Cris

  • Posts: 231
Re: 3.4 reports, queries and bugs
« Reply #672 on: 9 Jun '09 - 12:19 »
I just realized a few moments ago that my XMPlay's playlist only contained less than half of the songs I used to have in playlist (about 900 items, from a total of about 2600), and that the library and everything it contained related to play history and overwritten tags are...gone! :'( :'(

I simply cannot imagine what could have gone wrong.

The only thing that comes to my mind is related to a system crash I had yesterday. Looking at what was left of the original playlist file, I noticed that the last entry had no title or length...it just had the path, which tells me that this corruption occurred while XMPlay was saving the file (I set it to auto-save the playlist at 10 minutes).

Now...if the process of auto-saving the playlist is like this:
- delete current xmplay.pls and xmplay.library files
- write xmplay.pls
- write xmplay.library
- overwriting directly the files (without deleting them first) is exactly the same thing, as the system automatically truncates the file's content to 0 when opening a file for writing.
then I have to say: this is the wrong way to do it. Because it might lead to corruption in case of xmplay/system failure during the auto-save process, and the loss of over 2 years of library management (which I was kinda proud of  :'( ).

The correct way to do it is:
- save the xmplay.pls and xmplay.library files with temporary names
- copy both files, replacing the original ones
- after the copy process is done, remove the temporary files
It's not complicated at all, it doesn't consume resources (the only difference is copying the files and deleting them, which takes a very short time, considering it's 2 files of a few hundred KB). And if anything goes wrong at any of the steps, then at least one set of files will be left intact, and the user can recover them, so this method minimizes a lot the risk of data corruption or data loss during playlist/library saving.

So please, Ian, can you make these changes in XMPlay? There's no way to recover what I lost at this point, so I have to deal with it. But just to be sure that nor me, nor other users, get in the same situation, please make these changes in XMPlay (you can also apply them for normal playlist/library saving, since the same problems can occur then). Thanks.  :)
« Last Edit: 9 Jun '09 - 12:22 by Cris »

Knurek

  • Posts: 519
Re: 3.4 reports, queries and bugs
« Reply #673 on: 9 Jun '09 - 21:27 »
Better yet, have the player keep an optional backup if anyone fancies it. :)

Ian @ un4seen

  • Administrator
  • Posts: 18982
Re: 3.4 reports, queries and bugs
« Reply #674 on: 10 Jun '09 - 15:26 »
I think it would be a good idea if xmplay saved the queue independently from the rest of xmplay.ini at regular intervals, just like the playlist. I had a rather long queue and decided to unload the oddcast plugin which crashed xmplay then... so my queue was gone..

Yep, the queue was only saved when closing. Here's an update that should auto-save it along with the playlist...

   www.un4seen.com/stuff/xmplay.exe

Oh, and I'd also request better support for synaptics touchpads, because I can neither use the trackpoint nor the touchpad to scroll the playlist on my thinkpad :(

I'm not familiar with that stuff. If you can provide some info on it (eg. is there a message to handle?), I'll see what can be done.

I just realized a few moments ago that my XMPlay's playlist only contained less than half of the songs I used to have in playlist (about 900 items, from a total of about 2600), and that the library and everything it contained related to play history and overwritten tags are...gone! :'( :'(

Ouch! :(

The update above will backup the existing xmplay.library (to xmplay.library~) before updating it. A "NoBackup" XMPLAY.INI option has also been added to disable that.

It is strange that both your library and playlist were corrupted though. They aren't written simultaneously, so they can't both be interrupted by a crash. Did they both lose info at the same time, or could there have been separate incidents?

Did the library totally disappear or only the overridden tags? One important thing to note is that you should not switch to an older version of XMPlay (eg. from 3.4 to 3.3) whilst keeping a newer library, as it may not support the library's format, in which case it can't read the library contents and will end up replacing it. Is it possible that is what happened in your case? To avoid the possibility in future, XMPlay will from now on refuse to run with a library version that it doesn't recognise/support.