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

OSH

  • Posts: 39
Re: 3.5 reports, queries and bugs
« Reply #25 on: 16 Feb '10 - 12:57 »
No, we are talking about Nullsoft Module Decoder 2.2.10 beta 29 from WinAmp. Is this the same plugin?
Under XMPlay 3.4.2 works, under 3.5.x doesn't work...

wrkq

  • Posts: 82
Re: 3.5 reports, queries and bugs
« Reply #26 on: 16 Feb '10 - 14:09 »
You know, I just found the "Auto-sort by filename" function, which seems to be available since quite a while.

Now, even tho it is in the "Integration" tab, it applies also to both of "Add to playlist" and "Open file(s)" functions. As I like to add and open whole album folders using the right-click feature (which usually adds the files in the on-disk order, which's rarely the sorted case), the autosort was an awesome discovery... followed by a "Since 3.3?!" facepalm.

Anyway, to the point... if you use the "Open file(s)" function with it, the playlist gets cleared, files added in the unsorted order... then the first entry starts playing, finally list gets sorted. So, final effect is a sorted playlist with an arbitrary "was-first" track playing, which can be now #3 or any other.

That's 3.5.1.1 stuff, by the way. If it matters, (shouldn't; changing them doesn't do anything for me, at least) Default action: add to queue; Play listed tracks: if not playing.

And no matter how cliche it sounds... thanks for all the great work, Ian!

wrkq

  • Posts: 82
Re: 3.5 reports, queries and bugs
« Reply #27 on: 22 Feb '10 - 19:54 »
Urm, forgive me if you can and wish so... but... *bump*?

piovrauz

  • Posts: 967
Re: 3.5 reports, queries and bugs
« Reply #28 on: 1 Mar '10 - 08:08 »
I'll sadly post about an issue I have with last ASIO output plugin: the last revision, when I hit play, just hangs XMPlay, and after that I can't even kill the process in the taskmanager. The windows closes but it's still there, and I have to reboot to "fix" that. Can someone help please?

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #29 on: 1 Mar '10 - 08:50 »
I'll sadly post about an issue I have with last ASIO output plugin: the last revision, when I hit play, just hangs XMPlay, and after that I can't even kill the process in the taskmanager.
With what revision of xmp-asio was it still working properly? What soundcard do you have? What happens when you untick 'Set hardware sample rate when possible'?

piovrauz

  • Posts: 967
Re: 3.5 reports, queries and bugs
« Reply #30 on: 1 Mar '10 - 09:14 »
right... a bit of info:

creative audigy2
xmplay 3.5.1
asio plugin rev 6 (dunno if it's the last, just got it and used it to get xmplay to work :P)

'Set hardware sample rate when possible': never ever used it, but why should it matter? It worked before (and now) so I think the culprit is not a setting.

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #31 on: 1 Mar '10 - 10:35 »
asio plugin rev 6 (dunno if it's the last, just got it and used it to get xmplay to work :P) 'Set hardware sample rate when possible': never ever used it, but why should it matter? It worked before (and now) so I think the culprit is not a setting.
Oh right, I thought the problems appeared when you upgraded the plugin. Can other programs still work with ASIO? What does XMPlays time display show when it hangs? Is the GUI still responsive, or is it completely locked? If it still responds, can you change the output device to resume playback?

piovrauz

  • Posts: 967
Re: 3.5 reports, queries and bugs
« Reply #32 on: 1 Mar '10 - 10:51 »
the GUI dies, it's still visible but doesn't "react" to action.
dunno if other asio enabled proggy works, didn't tried (not on my main box right now, I'll see tonight).

piovrauz

  • Posts: 967
Re: 3.5 reports, queries and bugs
« Reply #33 on: 2 Mar '10 - 14:40 »
I tried other asio enabled progs: nope, xmplay does seem to lock the asio generally.
When it hangs, even if I kille the interface using taskman, asio won't be free. T_T
only rebooting helps. any Idea?

Ian @ un4seen

  • Administrator
  • Posts: 20396
Re: 3.5 reports, queries and bugs
« Reply #34 on: 2 Mar '10 - 16:57 »
You know, I just found the "Auto-sort by filename" function, which seems to be available since quite a while.

Now, even tho it is in the "Integration" tab, it applies also to both of "Add to playlist" and "Open file(s)" functions. As I like to add and open whole album folders using the right-click feature (which usually adds the files in the on-disk order, which's rarely the sorted case), the autosort was an awesome discovery... followed by a "Since 3.3?!" facepalm.

Anyway, to the point... if you use the "Open file(s)" function with it, the playlist gets cleared, files added in the unsorted order... then the first entry starts playing, finally list gets sorted. So, final effect is a sorted playlist with an arbitrary "was-first" track playing, which can be now #3 or any other.

Yep, I'll try to do something about that.

I'll sadly post about an issue I have with last ASIO output plugin: the last revision, when I hit play, just hangs XMPlay, and after that I can't even kill the process in the taskmanager. The windows closes but it's still there, and I have to reboot to "fix" that. Can someone help please?

I'll send you a debug version to get some info on what's happening there.

piovrauz

  • Posts: 967
Re: 3.5 reports, queries and bugs
« Reply #35 on: 3 Mar '10 - 10:33 »
got it, I'll check tonight, send you the log tomorrow.

mmm, I loaded it but it doesn't hang with this debug version. could you link me the non debug stuff one so I can check it wasn't a corrupt dl? Thanks.
« Last Edit: 4 Mar '10 - 10:22 by piovrauz »

Pike84

  • Posts: 1398
Re: 3.5 reports, queries and bugs
« Reply #36 on: 7 Mar '10 - 01:07 »
This isn't really a bug report, as it's rather about a peculiarity than a bug, I think...

Anyway, is there any reason for track change to occur in the GUI (title) a tiny moment before the actual track change? It's not like it's causing trouble or anything, but it seems a little weird ::).

My memory fails me, but I have a feeling that there's been a mention about this before (it's not a new issue at least). The search didn't turn up anything useful, though.

raina

  • Posts: 1163
Re: 3.5 reports, queries and bugs
« Reply #37 on: 7 Mar '10 - 02:37 »
Crossfading?

I can also remember a discussion about asynchronous track and title change but that was with internet streams and their title updates.

Pike84

  • Posts: 1398
Re: 3.5 reports, queries and bugs
« Reply #38 on: 7 Mar '10 - 03:00 »
Nice guess, but I'm pretty sure this one predates crossfading. I thought it might be related to the introduction of gapless playback, but that was added in 2004, so I'm not so sure ::)

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #39 on: 7 Mar '10 - 10:55 »
Anyway, is there any reason for track change to occur in the GUI (title) a tiny moment before the actual track change?
I thought it might be related to the introduction of gapless playback, but that was added in 2004, so I'm not so sure ::)
I don't seem to be able to get that here. How much is a tiny moment? :) Possibly related to the buffer in the output device? For Shout/IceCast streams the metadata is often a bit off, but for files the title change seems to coincide with the actual track change. The indicator on the playlist does advance about a second earlier, though.

Pike84

  • Posts: 1398
Re: 3.5 reports, queries and bugs
« Reply #40 on: 7 Mar '10 - 11:41 »
I meant playing files on my HD, but I guess it could apply to streams as well. A "tiny" moment means, that I'm able to pause a track so, that the time display shows something like 00:00:*, but the title has already changed to the one of the next track.

It seems I'm now having trouble fully reproducing the bug myself - the title change doesn't always occur beforehand, but the marker in the playlist does move to the next track early. I was playing VBR mp3 files just now, and fiddled with the buffer length in between, but I remember seeing this a long time ago... not sure how long, though.

[edit]There seems to be something funky about track changing even if the title doesn't change beforehand; it seems like the time may be stuck at 00:00:0 for nearly a second in between the tracks that I'm testing with... but I don't have time to test it thoroughly right now. Perhaps something like a slight miscalculation of time with (some) VBR files?
« Last Edit: 7 Mar '10 - 12:03 by Pike84 »

Ian @ un4seen

  • Administrator
  • Posts: 20396
Re: 3.5 reports, queries and bugs
« Reply #41 on: 8 Mar '10 - 16:28 »
mmm, I loaded it but it doesn't hang with this debug version. could you link me the non debug stuff one so I can check it wasn't a corrupt dl? Thanks.

The latest "stuff" is available here...

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

...the title change doesn't always occur beforehand, but the marker in the playlist does move to the next track early.

The playlist marker will move ahead of time (as the old track is closed and new track opened), but the title display shouldn't be updated until the new track is heard to start playing. The display may get refreshed by other means though, eg. if mini-mode is toggled or the mouse moved over the title area.

There seems to be something funky about track changing even if the title doesn't change beforehand; it seems like the time may be stuck at 00:00:0 for nearly a second in between the tracks that I'm testing with... but I don't have time to test it thoroughly right now. Perhaps something like a slight miscalculation of time with (some) VBR files?

Is that with or without seeking? VBR MP3 files have seek tables that are only approximate (100 seek points accurate to within 1/256th of the total file size), so seeking can be quite inaccurate (more so if the file is large). As a result, playback is quite likely to not end at exactly the usual time following seeking.

Pike84

  • Posts: 1398
Re: 3.5 reports, queries and bugs
« Reply #42 on: 8 Mar '10 - 16:48 »
Is that with or without seeking? VBR MP3 files have seek tables that are only approximate (100 seek points accurate to within 1/256th of the total file size), so seeking can be quite inaccurate (more so if the file is large). As a result, playback is quite likely to not end at exactly the usual time following seeking.
Yes, that was after having seeked to the end of the track.. I guess there's nothing that can be done about that then.

I did have the title change issue happen just yesterday, but as I haven't been able to reproduce it (haven't had much time to test either), there doesn't seem to be anything to fix there either :P. I'll keep a watch on that though, and report if I find something consistent.

winner

  • Posts: 260
When trying to run XMPlay 3.5.1.0 on Windows 7 having Comodo Internet Security 64-bit version 4.0.135239.742, I'm getting the error "This file has been tampered with and MAY BE INFECTED BY A VIRUS!" I've reported the problem on the Comodo support forum HERE. A person helping me on the Comodo forum provided the following analysis:
Quote
Here's the problem
Before I got started, I ran it through virustotal.com
http://www.virustotal.com/analisis/bdb6fe9b7f25ae9503fe8b4e8acd8ea1fc2cd0db68e4ebade781f327a2c96631-1267749384
It seems pretty safe until I saw the bottom of the results
sigcheck: publisher....: n/a
copyright....: n/a
product......: n/a
description..: n/a
original name: n/a
internal name: n/a
file version.: n/a
comments.....: n/a
signers......: -
signing date.: -
verified.....: Unsigned
In specific "verified......:Unsigned"
Which means the company that made XMplay didn't sign there own work.  Also comodo didn't even reconised the packer.  In fact, non of the anti-virus companys couldn't even name the packer either

Quote
PEiD  : -
means Packer ID
Generally companys that make software submit there packers to anti-virus companys so their own software doesn't get flagged or at the very least sign their own product

So the next thing I did was,
I ran it through "CIMA"  and it just keeps running through a continuous  loops (like a never ending circles).  99 out of a 100 times it should complete the test here

I believe comodo is NOT going to un-flag something because it can't be verified for obvious reasons.  (Just like a bank won't open up a checking account if they have ID Cards, but the idenity can't be verified)

I've been running XMPlay for years. This problem cropped up in relation to a previous version of Comodo Internet Security as well, but disappeared after a Comodo version upgrade.

Please help!

Pike84

  • Posts: 1398
Re: 3.5 reports, queries and bugs
« Reply #44 on: 13 Mar '10 - 01:12 »
Well... Even though it's an old problem of a false-positive, reading that post from the Comodo forum, it seems like there's at least something that could be done on XMPlay's end.

For the time being, you can just ignore the message - Comodo has some sort of an exception list, right?

Xander

  • Posts: 32
Re: 3.5 reports, queries and bugs
« Reply #45 on: 13 Mar '10 - 01:15 »
Quote
Which means the company that made XMplay didn't sign there own work.  Also comodo didn't even reconised the packer.  In fact, non of the anti-virus companys couldn't even name the packer either

If you take a look at the file he/she submitted to VirusTotal is the zip archive not the exe. The XMPlay executable has not been signed, but it has the version info block filled in:

Code: [Select]
sigcheck:
publisher....: Un4seen Developments
copyright....: Copyright (c) 1998-2010
product......: n/a
description..: XMPlay
original name: n/a
internal name: n/a
file version.: 3.5.1
comments.....: n/a
signers......: -
signing date.: -
verified.....: Unsigned

Also, the packer used is quite known, PEtite (2.3 likely).

That said, can't you just add XMPlay to the list of exceptions while it's not whitelisted?

The dialog you're getting probably kicks in when there are checksum mismatches in code and/or PE header parts of the exe, what I wonder is what is Comodo exactly doing to cause this.

winner

  • Posts: 260
Re: 3.5 reports, queries and bugs
« Reply #46 on: 13 Mar '10 - 01:31 »
Quote
Which means the company that made XMplay didn't sign there own work.  Also comodo didn't even reconised the packer.  In fact, non of the anti-virus companys couldn't even name the packer either

If you take a look at the file he/she submitted to VirusTotal is the zip archive not the exe. The XMPlay executable has not been signed, but it has the version info block filled in:

Code: [Select]
sigcheck:
publisher....: Un4seen Developments
copyright....: Copyright (c) 1998-2010
product......: n/a
description..: XMPlay
original name: n/a
internal name: n/a
file version.: 3.5.1
comments.....: n/a
signers......: -
signing date.: -
verified.....: Unsigned

Also, the packer used is quite known, PEtite (2.3 likely).

That said, can't you just add XMPlay to the list of exceptions while it's not whitelisted?

The dialog you're getting probably kicks in when there are checksum mismatches in code and/or PE header parts of the exe, what I wonder is what is Comodo exactly doing to cause this.
I've added xmplay.exe to the exclusion list for image execution. Problem persists. Also I can't add xmplay.exe to My Own Safe Files in Comodo, as Comodo tells me the file is already safe. Xmplay.exe, of course, passes all virus scans too.

Xander

  • Posts: 32
Re: 3.5 reports, queries and bugs
« Reply #47 on: 13 Mar '10 - 03:00 »
I've added xmplay.exe to the exclusion list for image execution. Problem persists. Also I can't add xmplay.exe to My Own Safe Files in Comodo, as Comodo tells me the file is already safe. Xmplay.exe, of course, passes all virus scans too.

I've just tested the same configuration as you have there (Win7 x64 + Comodo 4, I wondered what's the problem) in a virtualized environment and everything seems to be working fine. I didn't even had to add XMPlay to a safe list, not even with Defense+ in paranoid and Image Execution Control in aggressive modes.

XMPlay is being recognized as a safe really. I'm running the stuff version in there, give it a try and if it keeps telling you so... try reinstalling Comodo to try to make it re-detect the programs.

winner

  • Posts: 260
Re: 3.5 reports, queries and bugs
« Reply #48 on: 13 Mar '10 - 05:41 »
I've added xmplay.exe to the exclusion list for image execution. Problem persists. Also I can't add xmplay.exe to My Own Safe Files in Comodo, as Comodo tells me the file is already safe. Xmplay.exe, of course, passes all virus scans too.

I've just tested the same configuration as you have there (Win7 x64 + Comodo 4, I wondered what's the problem) in a virtualized environment and everything seems to be working fine. I didn't even had to add XMPlay to a safe list, not even with Defense+ in paranoid and Image Execution Control in aggressive modes.

XMPlay is being recognized as a safe really. I'm running the stuff version in there, give it a try and if it keeps telling you so... try reinstalling Comodo to try to make it re-detect the programs.
Xander, thanks for the effot to replicate. I tried the stuff version. No fix. Reinstalled Comodo. Problem persists. Now what?

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #49 on: 13 Mar '10 - 09:22 »
When trying to run XMPlay 3.5.1.0 on Windows 7 having Comodo Internet Security 64-bit version 4.0.135239.742, I'm getting the error "This file has been tampered with and MAY BE INFECTED BY A VIRUS!"
Did the error look like the one in this thread? That is not a message from Comodo, so it's not a false positive. The message comes from Ians own Petite packer, which senses something has modified or is modifying XMPlay.
Xander, thanks for the effot to replicate. I tried the stuff version. No fix. Reinstalled Comodo. Problem persists. Now what?
Have you tried disabling Comodo's Defense+?
« Last Edit: 13 Mar '10 - 10:17 by Dotpitch »