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

Tsorovan

  • Posts: 1247
Re: 3.5 reports, queries and bugs
« Reply #50 on: 13 Mar '10 - 12:33 »
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.
Digital certificates for signing code aren't free though.

Xander

  • Posts: 32
Re: 3.5 reports, queries and bugs
« Reply #51 on: 13 Mar '10 - 13:07 »
Xander, thanks for the effot to replicate. I tried the stuff version. No fix. Reinstalled Comodo. Problem persists. Now what?

I was able to replicate your scenario generating the error message in another VM.

The only way I found so far was to disable Defense+ altogether. You'll lose the Defense+ system but you'll be able to run XMPlay (I don't even use an antivirus system).

To do that go to Defense+ -> Advanced -> Defense+ Settings -> "Deactivate the Defense+ permanently". I also set it to "Disabled" in the slider, but deactivating it should be enough.

winner

  • Posts: 260
Re: 3.5 reports, queries and bugs
« Reply #52 on: 13 Mar '10 - 15:18 »
Xander, thanks for the effot to replicate. I tried the stuff version. No fix. Reinstalled Comodo. Problem persists. Now what?

I was able to replicate your scenario generating the error message in another VM.

The only way I found so far was to disable Defense+ altogether. You'll lose the Defense+ system but you'll be able to run XMPlay (I don't even use an antivirus system).

To do that go to Defense+ -> Advanced -> Defense+ Settings -> "Deactivate the Defense+ permanently". I also set it to "Disabled" in the slider, but deactivating it should be enough.
Xander, yes the problem is fixed for me when I disable Defense+. The person helping me on the Comodo forum has also provided the following information:
Quote
Maybe a staff member maybe intreasted in this

Based on virustotal.com  There's 3 other anti-virus venders that detects this.

Maybe the crew can upload petite.zip and xmp-cd.dll (in a .rar or .zip file)
and the following in quote (below)  <----this should have everything (plus the files to upload to the anti-virus company) it needs to remove the false-positives

Quote
Petite is a compresser that came out in year 2005

petgui.exe   unclassifiedMalware[at]8310843
http://camas.comodo.com/cgi-bin/submit?file=90a0e7b3de34fdcc65fb39ab3357c5d7959a5d2c399c0f1e7d609319c48c9cee
It shows as clean

petite.exe   UnclassifiedMalware[at]6359055
http://camas.comodo.com/cgi-bin/submit?file=e7f74dfb376ccf5133efb606a4bc8e032078f1b288a6814dd10caf519eab1be7
it shows that its clean

xmp-cd.dll is being flagged as "Heur.Packed.Unknown[at]-1
witch is packed from petite
CIMA doesn't scan .dll files so I uploaded it to virustotal.com
http://www.virustotal.com/analisis/bdb6fe9b7f25ae9503fe8b4e8acd8ea1fc2cd0db68e4ebade781f327a2c96631-1267749384

Just an idea to help xmplay website :)

jay2007tech

  • Posts: 1
Re: 3.5 reports, queries and bugs
« Reply #53 on: 13 Mar '10 - 21:01 »
Just want to let the people and staff here know that the problem is now fixed with the newest comodo anti-virus updates  :)

xmp-cd.dll is now fixed and no longer detected by comodo

petite.exe is now fixed and no longer detected by comodo

But petgui.exe is still detected <--- but that one shouldn't really matter.  It's the other 2 that count the most


Quote
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.
As far as I know, Comodo doesn't rely on md5 checksums because these can be faked.   They use SHA style checksums, but that's  not the reason why it got flagged. 

P.S.  This will be my 1 and only post here,  I'm only creating this post to let the users, staff, and developers know the problems have been fixed on comodo's side. :)

Keep it easy




winner

  • Posts: 260
Re: 3.5 reports, queries and bugs
« Reply #54 on: 13 Mar '10 - 23:35 »
Just want to let the people and staff here know that the problem is now fixed with the newest comodo anti-virus updates  :)

xmp-cd.dll is now fixed and no longer detected by comodo

petite.exe is now fixed and no longer detected by comodo

But petgui.exe is still detected <--- but that one shouldn't really matter.  It's the other 2 that count the most


Quote
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.
As far as I know, Comodo doesn't rely on md5 checksums because these can be faked.   They use SHA style checksums, but that's  not the reason why it got flagged. 

P.S.  This will be my 1 and only post here,  I'm only creating this post to let the users, staff, and developers know the problems have been fixed on comodo's side. :)

Keep it easy
Hmmm. Problem remains for me. I suppose the fix will come in the next version update or virus db update from Comodo.

saga

  • Posts: 2181
Re: 3.5 reports, queries and bugs
« Reply #55 on: 14 Mar '10 - 11:39 »
As far as I know, Comodo doesn't rely on md5 checksums because these can be faked.   They use SHA style checksums, but that's  not the reason why it got flagged. 
SHA can be tricked just like MD5, but the chance of colliding hashes is smaller. So that explains nothing.

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #56 on: 16 Mar '10 - 22:00 »
Hmmm. Problem remains for me. I suppose the fix will come in the next version update or virus db update from Comodo.
Any luck with the new db? Or did you have to permanently disable Defense+?

winner

  • Posts: 260
Re: 3.5 reports, queries and bugs
« Reply #57 on: 16 Mar '10 - 23:04 »
Hmmm. Problem remains for me. I suppose the fix will come in the next version update or virus db update from Comodo.
Any luck with the new db? Or did you have to permanently disable Defense+?
Comodo has not issued a db update yet since version 4 was introduced. I've had to disable Defense+ permanently to get XMPlay to work.

saga

  • Posts: 2181
Re: 3.5 reports, queries and bugs
« Reply #58 on: 25 Mar '10 - 23:10 »
I have my XMPlay window at the bottom of the screen, the XMPlay settings window is also placed there. Every now and then, I move files around so I'm working with the "dead files" settings and also use the "scan for new locations" button. However, the folder selection dialog is always popping up in a very strange relative position (not even centered in the dialog), so I can't see half of the window, as it can be seen on the screenshot. I always have to move it up. Is there any chance that this can be fixed? It's has been quite an annoyance for a while now.

winner

  • Posts: 260
Re: 3.5 reports, queries and bugs
« Reply #59 on: 26 Mar '10 - 00:37 »
Hmmm. Problem remains for me. I suppose the fix will come in the next version update or virus db update from Comodo.
Any luck with the new db? Or did you have to permanently disable Defense+?
Comodo has not issued a db update yet since version 4 was introduced. I've had to disable Defense+ permanently to get XMPlay to work.
After an upgrade to Comodo version 4.0.138377.779, XMPlay is now running on my system with Defense+ active and in safe mode. Yay!

Ian @ un4seen

  • Administrator
  • Posts: 20427
Re: 3.5 reports, queries and bugs
« Reply #60 on: 26 Mar '10 - 14:45 »
However, the folder selection dialog is always popping up in a very strange relative position (not even centered in the dialog), so I can't see half of the window, as it can be seen on the screenshot. I always have to move it up. Is there any chance that this can be fixed?

Here's an update that should improve things...

   www.un4seen.com/stuff/xmplay.exe

After an upgrade to Comodo version 4.0.138377.779, XMPlay is now running on my system with Defense+ active and in safe mode. Yay!

Jolly good :)

saga

  • Posts: 2181
Re: 3.5 reports, queries and bugs
« Reply #61 on: 26 Mar '10 - 21:39 »
thanks! that's a lot better indeed!

Edit: Woo, 777 posts 8)

Diggie

  • Posts: 1
Re: 3.5 reports, queries and bugs
« Reply #62 on: 29 Mar '10 - 03:30 »
I'm having problems here with the new ASIO rev 6 output on an EMU 1820M. The settings in XMPlay are all correct but I get no sound unless I tweak a setting and hit the "Apply" button. It doesn't really seem to matter what I change or if I change anything at all, the ASIO just isn't kicking when XMPlay starts, and fails again when the next song starts.

If I put the old DLL back (which sadly has no version number) everything works.
« Last Edit: 29 Mar '10 - 03:52 by Diggie »

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #63 on: 29 Mar '10 - 08:26 »
I'm having problems here with the new ASIO rev 6 output on an EMU 1820M.
Could you try this one?

saga

  • Posts: 2181
Re: 3.5 reports, queries and bugs
« Reply #64 on: 3 Apr '10 - 22:51 »
I'm not sure if this has been discussed before, but I find it somewhat illogical that first, the user directory is checked for an xmplay.ini and then the actual application folder. I normally use one instance of xmplay which stores its settings in the user dir, but I needed another copy with different settings, so I thought that changing that option there would actually work - but I also get the user dir data when starting that copy of xmplay.

winner

  • Posts: 260
Re: 3.5 reports, queries and bugs
« Reply #65 on: 3 Apr '10 - 23:23 »
I'm not sure if this has been discussed before, but I find it somewhat illogical that first, the user directory is checked for an xmplay.ini and then the actual application folder. I normally use one instance of xmplay which stores its settings in the user dir, but I needed another copy with different settings, so I thought that changing that option there would actually work - but I also get the user dir data when starting that copy of xmplay.
I'd been wondering about that myself for some time. The convention for most Windows apps would be to check the startup directory for an .ini file before checking the user directory. I agree this would be desired behavior.

tongub

  • Posts: 91
Re: 3.5 reports, queries and bugs
« Reply #66 on: 4 Apr '10 - 17:04 »
Hello,

having just moved from two well-known players to using Xmplay for mp3/lossless (not just tracker music as before), I feel a lack of a couple of handy playlist features as
- grouping: possibility to enable/disable grouping of items by containing folder name will be just enough;
- add to end of playlist: an option to make drag-n-dropped items automatically append to the list, no matter in what position of playlist they've been actually dropped.

It would be really nice to see those implemented sometime in further versions.
Thanks.

Dotpitch

  • Posts: 2871
Re: 3.5 reports, queries and bugs
« Reply #67 on: 4 Apr '10 - 17:09 »
add to end of playlist: an option to make drag-n-dropped items automatically append to the list, no matter in what position of playlist they've been actually dropped.
You can drop the files on the top bar of the Extended playlist, rather than on the list itself.

Ian @ un4seen

  • Administrator
  • Posts: 20427
Re: 3.5 reports, queries and bugs
« Reply #68 on: 5 Apr '10 - 18:04 »
I'm not sure if this has been discussed before, but I find it somewhat illogical that first, the user directory is checked for an xmplay.ini and then the actual application folder. I normally use one instance of xmplay which stores its settings in the user dir, but I needed another copy with different settings, so I thought that changing that option there would actually work - but I also get the user dir data when starting that copy of xmplay.

The main reason for the current system of the user config having precedence is simplicity, as XMPlay can just create/delete the user directory to enable/disable per-user config and it doesn't have to touch the XMPlay directory, eg. a global/default config can remain there without affecting things too much (Winamp/Sonique plugins don't use the per-user config). That does prevent the mixing of per-user and per-installation config, but the other way round has its problems too, ie. if one user of a shared installation disables per-user config, all users would be forced to use that config. On balance, I think the latter is probably a bit worse than the former, so it's probably best to just not enable per-user config in your situation, unless I'm overlooking something better? :)

winner

  • Posts: 260
Re: 3.5 reports, queries and bugs
« Reply #69 on: 6 Apr '10 - 02:10 »
I'm not sure if this has been discussed before, but I find it somewhat illogical that first, the user directory is checked for an xmplay.ini and then the actual application folder. I normally use one instance of xmplay which stores its settings in the user dir, but I needed another copy with different settings, so I thought that changing that option there would actually work - but I also get the user dir data when starting that copy of xmplay.

The main reason for the current system of the user config having precedence is simplicity, as XMPlay can just create/delete the user directory to enable/disable per-user config and it doesn't have to touch the XMPlay directory, eg. a global/default config can remain there without affecting things too much (Winamp/Sonique plugins don't use the per-user config). That does prevent the mixing of per-user and per-installation config, but the other way round has its problems too, ie. if one user of a shared installation disables per-user config, all users would be forced to use that config. On balance, I think the latter is probably a bit worse than the former, so it's probably best to just not enable per-user config in your situation, unless I'm overlooking something better? :)
OK, I can see that, Ian, but it causes a little problem with portability. Recently I did some demonstrations of XPlay's midi plugin. I copied the entire XMPlay directory to a USB flash drive to demonstrate on other computers, and put soundfonts and midi files in other folders on the flash drive. I configured the XMPlay instance on my flash drive as I wished, using the soundfonts on the flash drive, and assumed the .ini file there would make XMPlay perform on the other computers just as it had on my main computer. Of course, when I got to the other computers, and when moving the USB drive among them, the midi configuration was entirely lost and I had to re-establish soundfont assignments every time I moved between computers. The global configuration file I had tried to construct actually did not save to the USB drive as I wanted. I kind of expected then that XMPlay would default to the .ini file in the main directory for everything without trouble. I'm sure there's a proper way of preparing for using XMPlay such as this, but I didn't have the time to look into it. What would be the proper way to pre-configure XMPlay on a flash drive for this type of migrating use?

Jimmy Neutron

  • Posts: 473
Re: 3.5 reports, queries and bugs
« Reply #70 on: 6 Apr '10 - 04:42 »
I'm sure there's a proper way of preparing for using XMPlay such as this, but I didn't have the time to look into it. What would be the proper way to pre-configure XMPlay on a flash drive for this type of migrating use?

It sounds as if the changing drive letter assigned to your USB drive was hosing the absolute paths that are embedded in the config files.  If the config files wrote/used relative paths, you'd be fine.

Otherwise, have you tried to use the PortableApps.com version of XMPlay?  It is designed to enable changes in the drive letter assigned to the USB drive as you move from computer to computer.

Ian @ un4seen

  • Administrator
  • Posts: 20427
Re: 3.5 reports, queries and bugs
« Reply #71 on: 6 Apr '10 - 15:56 »
...so it's probably best to just not enable per-user config in your situation, unless I'm overlooking something better? :)

Something better came to mind...

   www.un4seen.com/stuff/xmplay.exe

This update adds a "NoUserConfig" XMPLAY.INI option to ignore per-user config. So you could use that in your per-installation config, eg. add a "NoUserConfig=1" line (under "[XMPlay]").

OK, I can see that, Ian, but it causes a little problem with portability. Recently I did some demonstrations of XPlay's midi plugin. I copied the entire XMPlay directory to a USB flash drive to demonstrate on other computers, and put soundfonts and midi files in other folders on the flash drive. I configured the XMPlay instance on my flash drive as I wished, using the soundfonts on the flash drive, and assumed the .ini file there would make XMPlay perform on the other computers just as it had on my main computer. Of course, when I got to the other computers, and when moving the USB drive among them, the midi configuration was entirely lost and I had to re-establish soundfont assignments every time I moved between computers. The global configuration file I had tried to construct actually did not save to the USB drive as I wanted. I kind of expected then that XMPlay would default to the .ini file in the main directory for everything without trouble. I'm sure there's a proper way of preparing for using XMPlay such as this, but I didn't have the time to look into it. What would be the proper way to pre-configure XMPlay on a flash drive for this type of migrating use?

That sounds like a different issue, not a matter of mixing per-user and per-installation config, unless XMPlay was already installed on the system and had per-user config enabled? If that is the case, adding a "NoUserConfig=1" line to your XMPLAY.INI with the update above should sort it. If that isn't it, is your entire config being lost, or only the soundfont settings? If the latter, where are the soundfonts in relation to the XMPLAY.EXE file? The MIDI plugin should use relative paths if they are in the same directory as (or a sub-directory of) XMPLAY.EXE, otherwise it will use full paths.

saga

  • Posts: 2181
Re: 3.5 reports, queries and bugs
« Reply #72 on: 6 Apr '10 - 19:29 »
Yeah, I guess that INI option is a good enough workaround. Thanks!

saga

  • Posts: 2181
Re: 3.5 reports, queries and bugs
« Reply #73 on: 9 Apr '10 - 14:29 »
ok, it's the MOD date estimation thing again... some modules have texts saying something like "originally made in 1999, touch-ups made in 2010 for the tracked music compo at breakpoint"... in that case, xmplay always chooses the lower number (1999) for the year tag. wouldn't it make more sense to choose the higher one (2010)?

Cosworth

  • Posts: 123
Re: 3.5 reports, queries and bugs
« Reply #74 on: 10 Apr '10 - 13:43 »
Last ver3.5.1.12. XMPlay.
 "Add to XMPlay-list" doesn't shows on right-click mouse :(