Old 22nd June 2013, 07:39   #1
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
5.64 crash on large media library on start

update from 3.63 to 3.64 on strt diplays a window updating.... an then crash i have a very large media library > 250000 mp3 on 3.63 is no problem.
unixgeri is offline   Reply With Quote
Old 22nd June 2013, 09:56   #2
DrO
 
Join Date: Sep 2003
Posts: 27,880
do you mean 5.63 and 5.64 ? if so I would suggest installing the 5.7 beta and allow it to generate a crash report and attach that to this thread so we can try to work out what the cause of the issue is.
DrO is offline   Reply With Quote
Old 22nd June 2013, 11:16   #3
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
sorry i mean 5.64, im testing now the 5.7 beta
unixgeri is offline   Reply With Quote
Old 22nd June 2013, 11:35   #4
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
Quote:
Originally Posted by DrO View Post
do you mean 5.63 and 5.64 ? if so I would suggest installing the 5.7 beta (which is currently the same as 5.64) and allow it to generate a crash report and attach that to this thread so we can try to work out what the cause of the issue is.
the 5.7 beta starting without problem, now testing a full scan i hope it is runing ( in the old version i must split the scans in over 20 parts else the scan is crash winamp,

if I buy the funktionier (as the charge of the error is gone but I do not need) pro version

The text comes from google translate :-)
unixgeri is offline   Reply With Quote
Old 22nd June 2013, 12:04   #5
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
the rescan does not work is crash without any message. i see on task manager winamp starts with 590.450kb

it is sufficient to put it in the gui settings or you have to activate it via the commandline, please share it with me as I activated a crash.log (i found no report.zip or _crash.dmp or _crash.log on the given location)

all my mp3 are mp3val validatet and without errors, no video or other files are in the path only .mp3 and folder.jpg an many mp3 files with included albumcovers.
unixgeri is offline   Reply With Quote
Old 22nd June 2013, 12:21   #6
DrO
 
Join Date: Sep 2003
Posts: 27,880
Did the Winamp crash reporter show any sign of running? i.e. would have been a small window with Winamp branding and a moving progress bar.


As it seems that it has not, then we'll need to go with an alternative way to try to get a crash report. So if you can follow the following procedure then that would be much appreciated.


First thing is to get ProcDump (http://technet.microsoft.com/en-us/s...rnals/dd996900) and extract procdump.exe from the archive.

Would suggest making a C:\dumps folder first and then putting procdump.exe in there.

Then do Windows Key + R and enter cmd.exe which should open a command-line window.

Enter cd c:\dumps and press return.

Then enter (or copy+paste should work) procdump.exe -e 1 -f "" -x c:\dumps "C:\Program Files (x86)\Winamp\winamp.exe" and press return.


That should start procdump and have it start Winamp and hopefully will generate a dmp file in C:\dumps.

If it does, zip up the file and either upload to a file sharing site or if it's only a few 100 KB when compressed, you should be able to attach it a post in the thread. Then hopefully from that i might be able to work out what's going on and fix the issue.
DrO is offline   Reply With Quote
Old 22nd June 2013, 13:02   #7
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
dump file

dump is to large for upload, from this location you can download http://www.pero.com/winamp_130622_144210.7z
unixgeri is offline   Reply With Quote
Old 22nd June 2013, 13:15   #8
DrO
 
Join Date: Sep 2003
Posts: 27,880
can you try again, this time using the english language pack and also using the following command:

procdump.exe -e 1 -f "" -x c:\dumps "C:\Program Files (x86)\Winamp\winamp.exe" /safe=1

as there seems to be a few 3rd party plug-ins present. as from a quick look, the crash dump wasn't able to indicate much on where the issue is happening other than i what i have to suspect is some form of memory corruption.
DrO is offline   Reply With Quote
Old 22nd June 2013, 19:31   #9
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
dump

ok now with the englisch language pack and

procdump.exe -e 1 -f "" -x c:\dumps "C:\Program Files (x86)\Winamp\winamp.exe" /safe=1

many thanks for your efforts
Attached Files
File Type: 7z winamp_130622_212743.7z (294.8 KB, 195 views)
unixgeri is offline   Reply With Quote
Old 22nd June 2013, 21:37   #10
DrO
 
Join Date: Sep 2003
Posts: 27,880
that at least gives me a point in the code where it's seemingly crashing which is better than before. will have to see if i can use that information to replicate things locally over the next few days and get back to you with some form of test build to try out.
DrO is offline   Reply With Quote
Old 22nd June 2013, 21:59   #11
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,190
Send a message via AIM to MrSinatra
unixgeri,

can you run the 4.2 beta of the infotool and post the results here?

also, can you please clarify: are you saying your files have BOTH folder art AND embedded art on all or most of the files?

exactly how many files do you have?

do you use "watch folders" to scan them in, or some other way? please describe how?

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 22nd June 2013, 22:10   #12
DrO
 
Join Date: Sep 2003
Posts: 27,880
none of that information is needed or is already provided in the earlier posts.
DrO is offline   Reply With Quote
Old 22nd June 2013, 22:15   #13
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,190
Send a message via AIM to MrSinatra
Quote:
Originally Posted by DrO View Post
none of that information is needed.
I would nevertheless appreciate it for my own interest anyway.

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 22nd June 2013, 22:26   #14
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
ok, many thanks
unixgeri is offline   Reply With Quote
Old 1st July 2013, 05:32   #15
kirkenbirken
Junior Member
 
Join Date: Jul 2013
Posts: 1
Hey guys, just downloaded the software for the first time. I'm having the same problem, although I don't have anywhere close to that number of files.. was there a solution/cause?
kirkenbirken is offline   Reply With Quote
Old 2nd July 2013, 13:15   #16
Tumpin
Junior Member
 
Join Date: Jul 2013
Posts: 3
Hello, also having the same problem on Win 8 x64. I have about 10,000 files, a mixture of itunes and Wav / Ogg.
I remove ml_local.dll and Winamp opens but of course then I have no library.
Tumpin is offline   Reply With Quote
Old 2nd July 2013, 13:22   #17
Tumpin
Junior Member
 
Join Date: Jul 2013
Posts: 3
I found a temp fix, I used the version of ml_local.dll that came with Winamp 5.58 and it works fine. Copy the old file into the Winamp plugins directory.
I installed 5.58 onto an old computer and got the file that way.
Tumpin is offline   Reply With Quote
Old 2nd July 2013, 13:53   #18
Tumpin
Junior Member
 
Join Date: Jul 2013
Posts: 3
After all that I just found out there is no ASIO or WASAPI support on Winamp. I found some old plugin but it doesnt work. So many features but no direct output lol. Winamp cant be considered a serious audio player without those. Im actually pretty shocked it doesn't have native support after all these years.
Tumpin is offline   Reply With Quote
Old 2nd July 2013, 15:28   #19
DrO
 
Join Date: Sep 2003
Posts: 27,880
there is no need for us to write extra output plug-ins when in the case of Wasapi, there's already a good one available (under the 'maiko' name). this is the point of plug-ins so others can make things and expand functionality. maybe there should be at least a native Wasapi output plug-in, but considering the time it takes to make them mature, if someone has already done that then in the scheme of things, it's better to point people at the plug-in than us use up resources which are already spread thin on the ground.

as for the crash issue, following the procdump steps from earlier in the thread and providing a copy of the crash dump would be more helpful so i've more data on what the issue (assuming you're even seeing the same code issue as was found with this thread).
DrO is offline   Reply With Quote
Old 3rd July 2013, 22:11   #20
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
A friend of mine has for the first time winamp instaled windows 7 64 it has only about 1000 mp3 and media at the first scan winamp (5.64) crash, I then looked at whether the mp3 is strange what I have found is 2 with embedded jpg than 100 kb were great. I then removed the embedded jpgs and the scan has run without problems. In my collection, the embedded images are checked all have a maximum of 60kb and a size 300 300 72dpi. I noticed that the memory requirements when embedet jpgs are available very quickly rises (task manager), and at a limit of about 800 000 kb scan breaking without message from.
(mine is xp 32)
If I can help let me know what they are.

Excuse the bad English, it comes from the google translator.
unixgeri is offline   Reply With Quote
Old 3rd July 2013, 22:44   #21
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Chicago, IL
Posts: 4,566
Hi unixgeri,

In your case, you will need to do the scan in stages. Start the scan and watch the memory rise. Stop the scan and shutdown Winamp when the memory gets to 700,000 kb. Restart Winamp and restart the scan. It will pick up from where it was stopped. You may need to use several stages to complete the scan of your whole collection, depending on how large your collection is.

Winamp Pro 5.666.3516 fully-patched - Komodo X Touchscreen by Victhor skin
Windows 10 Home 64-bit desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 3rd July 2013, 23:00   #22
DJ Egg
Techorator
Winamp & SHOUTcast Team
 
Join Date: Jun 2000
Posts: 35,762
Hi unixgeri,

Did you make a backup of those mp3's first? Can you send them to us?
Was there also an external jpg file (folder.jpg, cover.jpg, etc) in the same folder? If yes, please include those in the zip file.
If the zip is too large to attach here, you can upload to zippyshare.com and post the link here or via PM to me & DrO.

DrO might also ask for crash logs...

Thanks.
DJ Egg is offline   Reply With Quote
Old 3rd July 2013, 23:04   #23
DrO
 
Join Date: Sep 2003
Posts: 27,880
like i'd done in the earlier posts you mean ?

but an example of some of the files causing the issue would be helpful as i've so far not been able to get anywhere close to replicating the issue. which is a memory related issue in the db itself but if something else is going awry then that could be a false trail for me to go down.

as Winamp really shouldn't be consuming that much memory when scanning things, as it will show an increase depending on which task manager metric is looked at but it just increasing is not correct. and if it's consistent for a few types of files / artwork combination then that may finally be the reproducible trigger for the issue for us to be able to fix it.
DrO is offline   Reply With Quote
Old 4th July 2013, 05:10   #24
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Chicago, IL
Posts: 4,566
Hi unixgeri,

There is a recent Windows update to fix issues displaying certain JPEG images that was caused by another update. See support article (link below) for update KB2836502. Check your installed updates.

http://support.microsoft.com/kb/2836502

Winamp Pro 5.666.3516 fully-patched - Komodo X Touchscreen by Victhor skin
Windows 10 Home 64-bit desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 4th July 2013, 22:35   #25
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
my friend in there is a problem with a few files already visited me unfortunately only july 14 with its hard drive. I will then report.
unixgeri is offline   Reply With Quote
Old 7th July 2013, 20:56   #26
Kateylynn4
Junior Member
 
Join Date: Jul 2013
Posts: 1
Quote:
Originally Posted by Aminifu View Post
Hi unixgeri,

In your case, you will need to do the scan in stages. Start the scan and watch the memory rise. Stop the scan and shutdown Winamp when the memory gets to 700,000 kb. Restart Winamp and restart the scan. It will pick up from where it was stopped. You may need to use several stages to complete the scan of your whole collection, depending on how large your collection is.
I am having the same issue. I tried watching the memory increase, but now Winamp crashes immediately after I open it. I don't get a chance to do anything before the windows message that Winamp has stopped working appears. Everytime I open the app, the # of files is still at 1224. Any ideas?
Kateylynn4 is offline   Reply With Quote
Old 8th July 2013, 14:04   #27
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Chicago, IL
Posts: 4,566
Hi Kateylynn4,

Install version 5.64.3418 (link below), if you are using an older Winamp version. If the crash continues, then follow DrO's instructions in post #6 above or use the ProcDump command line in post #8 if you are using 3rd party plug-ins.

The crash report will hopefully help the devs identify the problem.

http://forums.winamp.com/showthread.php?t=364291

Winamp Pro 5.666.3516 fully-patched - Komodo X Touchscreen by Victhor skin
Windows 10 Home 64-bit desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 8th July 2013, 14:16   #28
DrO
 
Join Date: Sep 2003
Posts: 27,880
after a few days work on this, i'll be sending out test builds later today to some of the people who have been experiencing the issue to see if a) it resolves it or b) if it still persists (which if it does then would need to have a new proc dump crash from people).
DrO is offline   Reply With Quote
Old 9th July 2013, 16:31   #29
Spanky69
Junior Member
 
Join Date: Apr 2008
Posts: 2
I was having this issue with winamp564_pro_en-us (563 wouldn't even launch after installing (Win 8 x64))

I tried the fixes mentioned here, (remove dodgy audio files, changing detection from All to Any) but no joy... http://forums.winamp.com/showthread.php?t=316788

5.7 Beta 10, build 3417 seems to have resolved the issue.

Thanks
Spanky69 is offline   Reply With Quote
Old 9th July 2013, 16:44   #30
DrO
 
Join Date: Sep 2003
Posts: 27,880
we know that the 5.7 beta build (which is actually older than the 5.64 release) does not have the main issue which is affecting some users on importing (mainly due to badly tagged files). which is why we've sent out test builds to some people who reported it with a newer build to confirm that the fix and a few other things help to resolve the crash on import issue.

however this thread is more about trying to track down and resolve the issue with importing large libraries which has been an on-going issue for the last few years.

also that's good to know the changes to get Winamp running on Windows 8 is working for you.
DrO is offline   Reply With Quote
Old 9th July 2013, 22:51   #31
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
First Dump Is rescan existing library taskmanager display > 800
Attached Files
File Type: 7z winamp_130710_004401.7z (327.4 KB, 176 views)
unixgeri is offline   Reply With Quote
Old 9th July 2013, 23:25   #32
DrO
 
Join Date: Sep 2003
Posts: 27,880
thanks for that. i've just had a quick look and at least it's consistent with the earlier dump you'd provided so that seems to indicate i've not made anything worse compared to how it was before the newer test build. will be good to see what comes from the full add, though i'll likely have something else for you to try out tomorrow.
DrO is offline   Reply With Quote
Old 10th July 2013, 00:57   #33
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
Winamp started, media library clear, winamp terminate und then start with procdump,
the largest size in taskmanger 1.214.700 winamp not terminate automaticly and i see the last filename "Q:\Musik\gerimusik\Party\Fetenhits\Fetenhits - New Rock Party Disk 2\Matchbox 20 - Push.mp3" this file has no embaded jpg and mp3val say its ok. On the subfolder "Q:\Musik\gerimusik\Party\" see the memory in taskmanger is up exponential. from 300 000 to 1.214.700 i recheked with mp3val all containing mp3 are ok, and no large embaded jpgs ar included and no large folder.jpg containing the folders.
Attached Files
File Type: 7z winamp_130710_023505.7z (345.9 KB, 138 views)
unixgeri is offline   Reply With Quote
Old 10th July 2013, 01:16   #34
DrO
 
Join Date: Sep 2003
Posts: 27,880
hmm, for some reason it's saying the dmp file is invalid. though i suspect it'd be the same issue.

i don't think the file is the cause specifically in your case, it's purely down to something is causing memory not to be freed up (as you're seeing a 300MB -> 1214MB increase). as a large library is going to use more memory just due to how it goes, but it really shouldn't be having such issues even with a 250k library size.


as from my testing, with an existing library which was correct imported (irrespective of the size), re-reading all of the file metadata shouldn't at the end of the process have caused any noticeable change in the memory usage. which sadly isn't the case though the new build and what i'm looking at currently are better than how they did things previously (is only increasing by ~6Mb compared to ~20Mb on my 12k files).

but that doesn't help the issue with importing to begin with (which is the main issue you're having). i'll just keep trawling through more of the code to make sure we're not doing anything wrong on failures which could be causing memory leaks.

we'll get there somehow with a solution
DrO is offline   Reply With Quote
Old 10th July 2013, 03:54   #35
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
I think I found the problem, its APE tags in files, First, I Have Searched in which folder of the memory requirements are increasing, then one folder copied to a new directory with it 36 folders with 843 files. 270K scan results in the task manager, then no error mp3val about it. Then I noticed that many VBR files are checked with vbrfix and repaired, renewed scan no change, then set the settings vbrfix Remove APE tags and again repaired and renewed scan memory requirements in the task manager, 74K. so I assume that it is related to the APE tags.
(on every step i cleared the media library and restart winamp)
unixgeri is offline   Reply With Quote
Old 10th July 2013, 09:48   #36
DrO
 
Join Date: Sep 2003
Posts: 27,880
so just to confirm, using the test build provided, after you removed the ape tags you were then able to import all of the files in one go ?
DrO is offline   Reply With Quote
Old 10th July 2013, 10:08   #37
unixgeri
Junior Member
 
Join Date: Jun 2013
Posts: 27
total scan I have not try, I'll afternoon recopy all times and remove the ape day, I will write about.
unixgeri is offline   Reply With Quote
Old 10th July 2013, 19:05   #38
DrO
 
Join Date: Sep 2003
Posts: 27,880
i've sent you a newer build to try out based on a few things i found from the first crash dump.

though from better analysing things, with 250k of songs and expecting an average of 4kb of metadata data for a file, we'd expect to see around 1GB of memory usage.

so even with the fixes i'm making it could be that your setup is currently on the limits of what the Winamp library can cope with efficiently compared to limits imposed on us by the OS. as once we've done the scan we do a re-build of the library to ensure everything is correctly organised in the saved instance of the database.

and if that potentially needs 1Gb of memory, then that's ~2Gb of memory for the operation which is more than a 32-bit program like Winamp can effectively use. but will have to see how it goes with the newer build with small memory leaks i was able to find.
DrO is offline   Reply With Quote
Old 10th July 2013, 19:46   #39
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Chicago, IL
Posts: 4,566
Why does Winamp need to keep everything in active memory, especially the artwork cache? Why not let Winamp work with the OS and use virtual memory or flush and start rebuilding the active artwork cache after it reaches 400 MB or less. Saving artwork decoding time should not be more important than preventing runaway memory use, imo.

As for 'bad' tags, if the plug-in is able to tell it is having trouble reading or creating (with the guessing options) a file's tags during a scan, can it skip the file? A list of skipped files would then need to be provided, so that the user would know which files tags need fixing. I think this would work better than Winamp trying to deal with partially corrupt tags or a multitude of standard tagging revisions, i.e. ID3v2.2 (seems to be a problem reading this version's artwork tag) and ID3v2.3, APEv1 and APEv2, and so on.

Winamp Pro 5.666.3516 fully-patched - Komodo X Touchscreen by Victhor skin
Windows 10 Home 64-bit desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 10th July 2013, 21:37   #40
DrO
 
Join Date: Sep 2003
Posts: 27,880
ok, let's clarify a few things regarding the different aspects of media import as this has zero to do with artwork and i don't know why it's been brought up.

------------------------------------------------------------------

so firstly, import has zero to do with the artwork cache. that is completely different and is not populated as part of the import process. that is fud that i should have put down sooner as incorrectly persisted but then i didn't know the full workings of things until working through this import issue now. the only thing that happens with artwork during the import is if it's in the tag, then it's in the tag data loaded for processing but is not decoded or have anything else done to it, it's just there in the temporarily stored memory block which we use for parsing the tags.

so media import is separate to artwork import as artwork import will only happen on viewing of artwork - don't view it, then there's not going to be an artwork cache generated.

the media import goes into the main.dat/main.idx files and are separate to the artwork cache (art*.dat/art*.idx). the db is loaded into memory when we get a request to make use of the db and is like that due to the performance effects it has over always reading from disk and it does make use of virtual memory as that's how everything goes through. and it's mapped into memory for the performance it offers over the alternative.

the issue with this is irrespective of what we do with the current implementation, as a 32-bit process we are fundamentally limited to what can be done within those confines due to limits on virtual memory and all that. so if we try doing things with large libraries and need to re-build things in memory (since it's a hell of a lot faster than doing in pieces and working on disk), when we do an import and then re-build things for saving out (as we do since it provides a better experience post import), if we've already pushed for memory availability then we are going to have issues and random failures as we cannot access the memory needed.

there are things which can be done relating to all of this but it is not a simple thing to do.

------------------------------------------------------------------

with the case of artwork, i've still to specifically look into what the cache and it's handling is or isn't doing relating to the proper memory handling. however, artwork uses memory, in fact a lot of memory. for example i had a 4Mb jpeg provided today for checking against a crash issue - when that is decoded to be displayed, it's using almost 80Mb of memory.

now if you take that and apply it to a full view, even with the cached smaller versions we employ, it's going to use a lot of memory if everything has artwork associated with the items in the library being displayed. now without fully checking, i believe we do free the memory but as we've handing off certain aspects to the OS, it could be the OS caching things / duplicating what we'd cached and it had then used to display things.

so there is a fair chance that what people are seeing is a leak or just the cache persisting beyond what would be liked. and until it's looked into, i don't know who is or isn't at fault and what the solution needs to be to improve the perceived memory usage (if it can be).

------------------------------------------------------------------

my comment about tag errors was an internal implementation detail and i'm now regretting even mentioning it. we allocate memory for buffers to use and in some cases those weren't being released, that was all that comment was about.

maybe we should have something in place to cope with displaying items that had to be guessed, but then how / where is it exposed without causing more confusion. and everyone is going to have different views on what should be skipped as you've already thrown a few aspects in which i'd probably say shouldn't cause it to go on such a list.

as such the library has always and always will have to deal with crap tagging and so yes we should probably do something to inform users, but if someone has a large library and it's all badly tagged, are they really going to bother taking notice, probably not if they've allowed it to be in that state to being with. in an ideal world everything would be nicely tagged and there wouldn't be issues like ID3v2.2 not having the same apic format as ID3v2.3/2.4 do (and in that case, if i had an example file i'd look to add support for it just to cover off things).

so unfortunately, expectations are that we have to deal with what we get given and that's not taking into account the lesser formats which do weird and wonderful things with regards to tagging.

------------------------------------------------------------------

so not meaning to jump down on you, i just hope this makes things a bit saner as to what is trying to be achieved with the large import issue at the moment and how it's a separate issue to artwork and it's memory usage (and that it is going to be looked into). it's just there's a lot of code assuming certain behaviour and functionality and along with the legacy aspect, it's not simple to just gut and start over again, but we are getting there and the whole 5.64/5.7 process has gotten Winamp to be stabler than before (excluding the guessing related memory issue) and will be improved, it's just a matter of time to do things with the small team as we are.

and now i need a typing break as looking up, it's all sadly too much like a MrS post *shrugs*

p.s. was there a thread recently about artwork and ID3v2.2? i thought i'd seen one but cannot find it on the search.
DrO is offline   Reply With Quote
Reply
Go Back   Winamp & SHOUTcast Forums > Winamp > Winamp Technical Support

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump