|
Pike84
Posts: 1398
|
 |
« Reply #40 on: 7 Mar '10 - 11:41 » |
 Quote
|
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 »
|
Logged
|
|
|
|
|
Ian @ un4seen
Administrator
Posts: 15366
|
|
« Reply #41 on: 8 Mar '10 - 16:28 » |
Quote
|
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. |
|
|
|
|
Logged
|
|
|
|
|
Pike84
Posts: 1398
|
|
« Reply #42 on: 8 Mar '10 - 16:48 » |
Quote
|
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  . I'll keep a watch on that though, and report if I find something consistent. |
|
|
|
|
Logged
|
|
|
|
|
winner
Posts: 193
|
|
« Reply #43 on: 13 Mar '10 - 00:03 » |
Quote
|
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: Here's the problem Before I got started, I ran it through virustotal.com http://www.virustotal.com/analisis/bdb6fe9b7f25ae9503fe8b4e8acd8ea1fc2cd0db68e4ebade781f327a2c96631-1267749384It 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! |
|
|
|
|
Logged
|
|
|
|
|
Pike84
Posts: 1398
|
|
« Reply #44 on: 13 Mar '10 - 01:12 » |
Quote
|
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?
|
|
|
|
|
Logged
|
|
|
|
|
Xander
Posts: 32
|
|
« 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: 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. |
|
|
|
|
Logged
|
|
|
|
|
winner
Posts: 193
|
|
« 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: 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. |
|
|
|
|
Logged
|
|
|
|
|
Xander
Posts: 32
|
|
« Reply #47 on: 13 Mar '10 - 03:00 » |
Quote
|
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. |
|
|
|
|
Logged
|
|
|
|
|
winner
Posts: 193
|
|
« Reply #48 on: 13 Mar '10 - 05:41 » |
Quote
|
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? |
|
|
|
|
Logged
|
|
|
|
|
Dotpitch
Posts: 2503
|
|
« Reply #49 on: 13 Mar '10 - 09:22 » |
Quote
|
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 »
|
Logged
|
|
|
|
|
Tsorovan
Posts: 1244
|
|
« Reply #50 on: 13 Mar '10 - 12:33 » |
Quote
|
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. |
|
|
|
|
Logged
|
|
|
|
|
Xander
Posts: 32
|
|
« Reply #51 on: 13 Mar '10 - 13:07 » |
Quote
|
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. |
|
|
|
|
Logged
|
|
|
|
|
winner
Posts: 193
|
|
« Reply #52 on: 13 Mar '10 - 15:18 » |
Quote
|
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: |
|
|
|
|
Logged
|
|
|
|
|
jay2007tech
Posts: 1
|
|
« Reply #53 on: 13 Mar '10 - 21:01 » |
Quote
|
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 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 |
|
|
|
|
Logged
|
|
|
|
|
winner
Posts: 193
|
|
« Reply #54 on: 13 Mar '10 - 23:35 » |
Quote
|
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 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. |
|
|
|
|
Logged
|
|
|
|
|
saga
Posts: 1393
|
|
« Reply #55 on: 14 Mar '10 - 11:39 » |
Quote
|
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. |
|
|
|
|
Logged
|
|
|
|
|
Dotpitch
Posts: 2503
|
|
« Reply #56 on: 16 Mar '10 - 22:00 » |
Quote
|
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+? |
|
|
|
|
Logged
|
|
|
|
|
winner
Posts: 193
|
|
« Reply #57 on: 16 Mar '10 - 23:04 » |
Quote
|
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. |
|
|
|
|
Logged
|
|
|
|
|
saga
Posts: 1393
|
|
« Reply #58 on: 25 Mar '10 - 23:10 » |
Quote
|
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.
|
|
|
|
Logged
|
|
|
|
|
winner
Posts: 193
|
|
« Reply #59 on: 26 Mar '10 - 00:37 » |
Quote
|
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! |
|
|
|
|
Logged
|
|
|
|
|
