The message is: Warning: mysql_connect() [function.mysql-connect]: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (11) in /home/www/..../..../system/database/mysql.php on line 6
Thanks for reading.
Occasionally I get this error message. I keep refreshing my screen and it dissappears. It keeps happening and I am getting quite impatient now. Anyone come across this message and able to provide an answer please?
The message is: Warning: mysql_connect() [function.mysql-connect]: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (11) in /home/www/..../..../system/database/mysql.php on line 6
Thanks for reading.
The message is: Warning: mysql_connect() [function.mysql-connect]: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (11) in /home/www/..../..../system/database/mysql.php on line 6
Thanks for reading.
The issue seems to be with your hosting provider, may be you need to shift to dedicated hosting
Thanks mate. My host provider told me is the script problem and they don't support if the lies with the scripts. I keep logging me out as well. Is that the same problem?lynnchris9 wrote:The issue seems to be with your hosting provider, may be you need to shift to dedicated hosting
Most servers' inner sanctum folks will eschew knowing, thinking, or doing anything having to do with scripts. As most of us learn along the way, those folks are possibly in the right part of the time, and definitely in the wrong part of the time.
The present problem (computer-related problems are not "issues") arises from database settings (for caches and other delicacies) that are generally not in the OpenCart tables, but instead lie somewhere outside the "www" or "public_html" or similarly denominated portion of assigned userspace, and accordingly lie where one can reach with actual configuration files and configuration commands, unless, alas, one has shared hosting rather than any semblance of a dedicated server or altogether rather accommodating and helpful server staff. If those settings are not optimal, the cannot connect error will be triggered.
Some of us, owing primarily to eventual experience, automatically refresh a screen when a nonsensical error appears. Most customers will never think of what to do to make that particular error screen go away and be replaced in a twinkling by what is supposed to be there. That particular error message does not spring from the server's own configurations. That particular error message springs from one of the mysql files inside OpenCart itself. Trying to make it not even show (such as by making the error report not happen) is fundamentally more complicated for so few lines than is taking on the server personnel. The reason why it triggers relates to the server settings, where the fix must be made. The irritation in the error screen is that it shows too much of the inner sanctum's layout; if the error screen is nullified, customers will see a probably white and code-blank screen rather than a glimpse of that layout.
Lo, if you can see in your tree via ftp (as with FileZIlla Client) below and outside your public area (www, public_html, or the like), then you can navigate your Unix or Linux or Yuks (broken windows) tree to where the control files for mysql reside, and using a suitable entree (such as WinSCP and putty.exe or similar combinations or standalones as suit your fancy) you can issue actual commands and watch the server actually obey (or balk as the case may be, march).
However, if you cannot see anything other than your public area (below or outside its bottom www, public_html, or the like), then you can still ask the staff (such as by help ticket) to make requisite changes in settings for caches, etc.. It will be helpful first to delve through your control panel's own phpMyAdmin's (or similar's) mysql (or similar) panels for status and statistics. There you will see a long list of parameters, values, and comments (together, on successive lines). Where the values are "red" or similarly conspicuous, the comments should pretty well spell out what needs to be reset.
It will generally be in servers' best interests to have those parameters reset for all users' instances of OpenCart sharing the servers. The parameters speak to resettings that save cpu cycles, improve performance as viewed from the perspectives of processors and of customers, and minimize glitches such as cannot connect unless refreshed errors.
The fun begins if you are able to issue the commands yourself. There are tutorials on-line for resetting servers' mysql configurations (caches, etc.).
Your Apache, php, and similar settings are not the problem, although seemingly minor differences between php.ini for 5.2 and for 5.3 are not faint but pregnant in making 1.5.x work or resume working. It is well worth checking from time to time in your control panel whether server maintenance routines reset your php choice from what it worked. It is definitely worth using your control panel (or ftp if you can get there) to save a complete copy of each php.ini file that you use. The php.ini file does have settings that relate to particular database systems; but not that relate to the present problem.
The present problem (computer-related problems are not "issues") arises from database settings (for caches and other delicacies) that are generally not in the OpenCart tables, but instead lie somewhere outside the "www" or "public_html" or similarly denominated portion of assigned userspace, and accordingly lie where one can reach with actual configuration files and configuration commands, unless, alas, one has shared hosting rather than any semblance of a dedicated server or altogether rather accommodating and helpful server staff. If those settings are not optimal, the cannot connect error will be triggered.
Some of us, owing primarily to eventual experience, automatically refresh a screen when a nonsensical error appears. Most customers will never think of what to do to make that particular error screen go away and be replaced in a twinkling by what is supposed to be there. That particular error message does not spring from the server's own configurations. That particular error message springs from one of the mysql files inside OpenCart itself. Trying to make it not even show (such as by making the error report not happen) is fundamentally more complicated for so few lines than is taking on the server personnel. The reason why it triggers relates to the server settings, where the fix must be made. The irritation in the error screen is that it shows too much of the inner sanctum's layout; if the error screen is nullified, customers will see a probably white and code-blank screen rather than a glimpse of that layout.
Lo, if you can see in your tree via ftp (as with FileZIlla Client) below and outside your public area (www, public_html, or the like), then you can navigate your Unix or Linux or Yuks (broken windows) tree to where the control files for mysql reside, and using a suitable entree (such as WinSCP and putty.exe or similar combinations or standalones as suit your fancy) you can issue actual commands and watch the server actually obey (or balk as the case may be, march).
However, if you cannot see anything other than your public area (below or outside its bottom www, public_html, or the like), then you can still ask the staff (such as by help ticket) to make requisite changes in settings for caches, etc.. It will be helpful first to delve through your control panel's own phpMyAdmin's (or similar's) mysql (or similar) panels for status and statistics. There you will see a long list of parameters, values, and comments (together, on successive lines). Where the values are "red" or similarly conspicuous, the comments should pretty well spell out what needs to be reset.
It will generally be in servers' best interests to have those parameters reset for all users' instances of OpenCart sharing the servers. The parameters speak to resettings that save cpu cycles, improve performance as viewed from the perspectives of processors and of customers, and minimize glitches such as cannot connect unless refreshed errors.
The fun begins if you are able to issue the commands yourself. There are tutorials on-line for resetting servers' mysql configurations (caches, etc.).
Your Apache, php, and similar settings are not the problem, although seemingly minor differences between php.ini for 5.2 and for 5.3 are not faint but pregnant in making 1.5.x work or resume working. It is well worth checking from time to time in your control panel whether server maintenance routines reset your php choice from what it worked. It is definitely worth using your control panel (or ftp if you can get there) to save a complete copy of each php.ini file that you use. The php.ini file does have settings that relate to particular database systems; but not that relate to the present problem.
i am getting this error message.
Notice: Undefined index: custom_title in /home/itactica/public_html/store/vqmod/vqcache/vq2-admin_model_catalog_category.php on line 14Notice: Error: Unknown column 'custom_title' in 'field list'
Error No: 1054
INSERT INTO category_description SET category_id = '1', language_id = '0', name = 'Category 2', meta_keyword = '', custom_title = '', meta_description = '', description = '' in /home/itactica/public_html/store/system/database/mysql.php on line 50
help!
Notice: Undefined index: custom_title in /home/itactica/public_html/store/vqmod/vqcache/vq2-admin_model_catalog_category.php on line 14Notice: Error: Unknown column 'custom_title' in 'field list'
Error No: 1054
INSERT INTO category_description SET category_id = '1', language_id = '0', name = 'Category 2', meta_keyword = '', custom_title = '', meta_description = '', description = '' in /home/itactica/public_html/store/system/database/mysql.php on line 50
help!
[This was my first post today but I see now that it somehow didn't "take" so here it is--so that I can point to it from another thread on another subject.]
[. . . and a further day later, the missing original is now in place 2nd above here, as its own
http://forum.opencart.com/viewtopic.php ... 37#p391324
so the present replacement is now editorially truncated rather than deleted, as both are now crossreferenced FROM
http://forum.opencart.com/viewtopic.php ... 64#p391364
with regard to server settings in bogging down the processor. The following 8 paragraphs now found above are deleted.]
[. . . and a further day later, the missing original is now in place 2nd above here, as its own
http://forum.opencart.com/viewtopic.php ... 37#p391324
so the present replacement is now editorially truncated rather than deleted, as both are now crossreferenced FROM
http://forum.opencart.com/viewtopic.php ... 64#p391364
with regard to server settings in bogging down the processor. The following 8 paragraphs now found above are deleted.]
Last edited by butte on Thu Mar 21, 2013 7:57 am, edited 1 time in total.
somethingnew, your error message is of a different kind than the initial one in this thread. xbyte's error message owed (probably) just to overtaxing the processor momentarily before refreshing the page before connecting to the database. Yours owes to a (re)scripting (apparently by vqmod) which can't find something in the database.
You can actually do this with (1), (5), and (6) without panic.
(1) Go into the admin panel and bring up Catalog / Categories. Make sure that each and every Category has ALL of its settings SET. If you know which recently added custom category preceded the failure to work (it seems to be "'Category 2" but that could also just be the database's own name, a la 0-1-2-3, for an otherwise named Category that you would see as 3rd, a la ordinary 1-2-3), then hit Edit. Reset it to Disabled. Check that these settings are compatible with the other Categories' own settings: Parent Category (None or whatever),Top (checked or not), Columns (1 or more), Sort Order (left to right across top, top to bottom on left). If you find a glitch among those, fix it, then reset it back to Enabled. Otherwise, leave it Disabled. Hit Save. (If vqmod itself blew it, removing that one Category may overcome the error message; maybe not.) See what happens. If the error still occurs, go back in and delete all Categories and establish all new ones, ensuring that each and every Category has ALL of its settings SET.
(2) Since the error is pointing to your store/vqmod/vqcache/vq2-admin_model_catalog_category.php on line 14, and since it is balking at an Unknown column 'custom_title' in 'field list', it appears that there is a vqmod booboo traceable via Error No: 1054. Check that one out at vqmod's website. Since vqmod is supposed to change files without changing the originals, there may well be a stepwise booboo of minor size (maybe a missing ";" ending a line or phrase of code) but with big consequence (error). Check whether a predecessor version of that file works (assuming vqmod kept it). If you have a vqmod mod for OC, maybe it doesn't quite work right, and needs just a little bit more work (as Brits would say without intending a compliment).
(3) Its view of the fix speaks to the database tables: INSERT INTO category_description SET category_id = '1', language_id = '0', name = 'Category 2', meta_keyword = '', custom_title = '', meta_description = '', description = '' in /home/itactica/public_html/store/system/database/mysql.php on line 50. Go into your admin panels to Settings / Backup [/] Restore and make a fresh backup. Your home client local machine will receive a .sql file, it's a simple text file. You can peruse it for consistencies in its own layout concerning Categories (e.g., a row of stuff will have column separators such as " or ' and ; or ,).
(4) Make safety copies of those three files (.sql, .php, .php), grab a decent pure text editor (Crimson Editor or similar), and open the files. The .sql file can be searched for "Category 2", etc., and the line numbering will help you to compare successive rows for inconsistencies. If they're obvious, make changes and save 'em, just keep 'em (one option is just deleting every row that mentions "Category2"). In the other two files just fix' their respective lines 14 and 50 and save 'em.
Yes, you may feel queasy, but you'll be ahead by looking inside the files and learning to take a deep breath and type changes, even if you don't put changes on the server.
(5) IF vqmod itself is (or may be) at the bottom of the problem, keep (do not restore or upload back into place) the three files. Instead use pre-vqmod versions of the two .php files (the install package will have them, and presumably vqmod doesn't change original files anyway). There is presumably a vqmod command, to vqmod itself, for, "Stuff it, revert!" Also instead, check whether your server has a recent backup of your database made before the error showed up; if yes, reinstate it.
(6) After the present problem is cured, be aware that this is all in a production box (publically accessible cpu), and error messages display often sensitive facts about your overall file layout (merely knowing that you're using OC does not open the same Pandora's Box, just another one). Inside the admin panel under Systen / Settings pick Store and hit Edit and under Server set Display Errors to No, and set Log Errors to Yes. Inside your hosting account's control panel, be sure (whether you do it or must have staff do it) to turn off error reporting. You can turn error reporting and error displays on and off; most of the time you won't want general public viewing them; and some of the time you'll need them for testing.
You can actually do this with (1), (5), and (6) without panic.
(1) Go into the admin panel and bring up Catalog / Categories. Make sure that each and every Category has ALL of its settings SET. If you know which recently added custom category preceded the failure to work (it seems to be "'Category 2" but that could also just be the database's own name, a la 0-1-2-3, for an otherwise named Category that you would see as 3rd, a la ordinary 1-2-3), then hit Edit. Reset it to Disabled. Check that these settings are compatible with the other Categories' own settings: Parent Category (None or whatever),Top (checked or not), Columns (1 or more), Sort Order (left to right across top, top to bottom on left). If you find a glitch among those, fix it, then reset it back to Enabled. Otherwise, leave it Disabled. Hit Save. (If vqmod itself blew it, removing that one Category may overcome the error message; maybe not.) See what happens. If the error still occurs, go back in and delete all Categories and establish all new ones, ensuring that each and every Category has ALL of its settings SET.
(2) Since the error is pointing to your store/vqmod/vqcache/vq2-admin_model_catalog_category.php on line 14, and since it is balking at an Unknown column 'custom_title' in 'field list', it appears that there is a vqmod booboo traceable via Error No: 1054. Check that one out at vqmod's website. Since vqmod is supposed to change files without changing the originals, there may well be a stepwise booboo of minor size (maybe a missing ";" ending a line or phrase of code) but with big consequence (error). Check whether a predecessor version of that file works (assuming vqmod kept it). If you have a vqmod mod for OC, maybe it doesn't quite work right, and needs just a little bit more work (as Brits would say without intending a compliment).
(3) Its view of the fix speaks to the database tables: INSERT INTO category_description SET category_id = '1', language_id = '0', name = 'Category 2', meta_keyword = '', custom_title = '', meta_description = '', description = '' in /home/itactica/public_html/store/system/database/mysql.php on line 50. Go into your admin panels to Settings / Backup [/] Restore and make a fresh backup. Your home client local machine will receive a .sql file, it's a simple text file. You can peruse it for consistencies in its own layout concerning Categories (e.g., a row of stuff will have column separators such as " or ' and ; or ,).
(4) Make safety copies of those three files (.sql, .php, .php), grab a decent pure text editor (Crimson Editor or similar), and open the files. The .sql file can be searched for "Category 2", etc., and the line numbering will help you to compare successive rows for inconsistencies. If they're obvious, make changes and save 'em, just keep 'em (one option is just deleting every row that mentions "Category2"). In the other two files just fix' their respective lines 14 and 50 and save 'em.
Yes, you may feel queasy, but you'll be ahead by looking inside the files and learning to take a deep breath and type changes, even if you don't put changes on the server.
(5) IF vqmod itself is (or may be) at the bottom of the problem, keep (do not restore or upload back into place) the three files. Instead use pre-vqmod versions of the two .php files (the install package will have them, and presumably vqmod doesn't change original files anyway). There is presumably a vqmod command, to vqmod itself, for, "Stuff it, revert!" Also instead, check whether your server has a recent backup of your database made before the error showed up; if yes, reinstate it.
(6) After the present problem is cured, be aware that this is all in a production box (publically accessible cpu), and error messages display often sensitive facts about your overall file layout (merely knowing that you're using OC does not open the same Pandora's Box, just another one). Inside the admin panel under Systen / Settings pick Store and hit Edit and under Server set Display Errors to No, and set Log Errors to Yes. Inside your hosting account's control panel, be sure (whether you do it or must have staff do it) to turn off error reporting. You can turn error reporting and error displays on and off; most of the time you won't want general public viewing them; and some of the time you'll need them for testing.
I'm putting together a store (for a client) - I uploaded items about a few weeks ago, and everything was wonderful on different computers, until I checked it out today ready to sort out the postage to find text on the page (hidden has been used to replace file names):
Warning: mysql_connect() [function.mysql-connect]: Access denied for user 'hidden'@'localhost' (using password: YES) in /home/hidden/public_html/bookshop/system/database/mysql.php on line 6
Notice: Error: Could not make a database link using hidden_ocar275@localhost in /home/hidden/public_html/bookshop/system/database/mysql.php on line 7
Warning: mysql_select_db() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 10
Notice: Error: Could not connect to database hidden_ocar275 in /home/hidden/public_html/bookshop/system/database/mysql.php on line 11
Warning: mysql_query() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 14
Warning: mysql_query() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 15
Warning: mysql_query() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 16
Warning: mysql_query() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 17
Notice: Trying to get property of non-object in /home/hidden/public_html/bookshop/index.php on line 52
Notice: Trying to get property of non-object in /home/hidden/public_html/bookshop/index.php on line 61
Warning: Invalid argument supplied for foreach() in /home/hidden/public_html/bookshop/index.php on line 61
Notice: Trying to get property of non-object in /home/hidden/public_html/bookshop/index.php on line 69
Can you please tell me what I need to do?
With thanks
Warning: mysql_connect() [function.mysql-connect]: Access denied for user 'hidden'@'localhost' (using password: YES) in /home/hidden/public_html/bookshop/system/database/mysql.php on line 6
Notice: Error: Could not make a database link using hidden_ocar275@localhost in /home/hidden/public_html/bookshop/system/database/mysql.php on line 7
Warning: mysql_select_db() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 10
Notice: Error: Could not connect to database hidden_ocar275 in /home/hidden/public_html/bookshop/system/database/mysql.php on line 11
Warning: mysql_query() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 14
Warning: mysql_query() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 15
Warning: mysql_query() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 16
Warning: mysql_query() expects parameter 2 to be resource, boolean given in /home/hidden/public_html/bookshop/system/database/mysql.php on line 17
Notice: Trying to get property of non-object in /home/hidden/public_html/bookshop/index.php on line 52
Notice: Trying to get property of non-object in /home/hidden/public_html/bookshop/index.php on line 61
Warning: Invalid argument supplied for foreach() in /home/hidden/public_html/bookshop/index.php on line 61
Notice: Trying to get property of non-object in /home/hidden/public_html/bookshop/index.php on line 69
Can you please tell me what I need to do?
With thanks
Last edited by GreenDoor on Mon Sep 09, 2013 4:15 am, edited 1 time in total.
GreenDoor, your essentially identical other post (here you deleted "for a client"), http://forum.opencart.com/viewtopic.php?f=19&t=109636 four hours prior to this one just above, was answered two hours later by a Moderator who gave you http://forum.opencart.com/viewtopic.php?t=20806 -- and then was for some reason locked.
Why did you repost that opener verbatim (save for deleting "for a client") here?
Why did you repost that opener verbatim (save for deleting "for a client") here?
No reason for the deletion of 'for a client' other than I thought it made me look like I knew all html speak as I don't usually do web design, just basic web editing, I and a qualified designer for publishing as a rule. Thanks for acknowledging my message but I need help with the issue rather than pointing out I deleted 'for a client'. The reason the message was locked was because I was directed to a bunch of other posts. I PM'd the moderator who said to post in one of these active posts, so that's what I've done. So my problem still remains.butte wrote:GreenDoor, your essentially identical other post (here you deleted "for a client"), http://forum.opencart.com/viewtopic.php?f=19&t=109636 four hours prior to this one just above, was answered two hours later by a Moderator who gave you http://forum.opencart.com/viewtopic.php?t=20806 -- and then was for some reason locked.
Why did you repost that opener verbatim (save for deleting "for a client") here?
EDIT*have added it back in via edit if it makes you happier - I just add here that I need clear concise guidance as to what the issue is and how to fix it
Okay. (The "for a client" itself didn't matter, but seeing a locked version was unusual.)
The "denied for user 'hidden'@'localhost' (using password: YES)" means that username hidden[...] gave a password and the combination failed.
The "Could not make a database link using hidden_ocar275@localhost" follows from that failure.
Initially, check both config.php files in the //DATABASE section, both of those sections should say the same thing: databasename, databaseusername, and databasepassword, in both of them. The server should normally be "localhost" (except on GoDaddy and some other servers).
In your host control panel under mysql databases you'll be able to get at the databasename, databasepassword, and (to reset it) databasepassword. The Statistics or the mysql section (depending upon server) should give you the mysql host (either a quad-decimal nnn.nnn.nnn.nnn or localhost). When you do that, run through the control panel and two config.php files again, same way as before with the new entries, so that it will connect.
Try that and see if it least connects to database. When it connects you'll want to change the databaseusername at your leisure -- you've made it public, removing one thing hackers would try to guess.
The "denied for user 'hidden'@'localhost' (using password: YES)" means that username hidden[...] gave a password and the combination failed.
The "Could not make a database link using hidden_ocar275@localhost" follows from that failure.
Initially, check both config.php files in the //DATABASE section, both of those sections should say the same thing: databasename, databaseusername, and databasepassword, in both of them. The server should normally be "localhost" (except on GoDaddy and some other servers).
In your host control panel under mysql databases you'll be able to get at the databasename, databasepassword, and (to reset it) databasepassword. The Statistics or the mysql section (depending upon server) should give you the mysql host (either a quad-decimal nnn.nnn.nnn.nnn or localhost). When you do that, run through the control panel and two config.php files again, same way as before with the new entries, so that it will connect.
Try that and see if it least connects to database. When it connects you'll want to change the databaseusername at your leisure -- you've made it public, removing one thing hackers would try to guess.
Thanks for thisbutte wrote:Okay. (The "for a client" itself didn't matter, but seeing a locked version was unusual.)
The "denied for user 'hidden'@'localhost' (using password: YES)" means that username hidden[...] gave a password and the combination failed.
The "Could not make a database link using hidden_ocar275@localhost" follows from that failure.
Initially, check both config.php files in the //DATABASE section, both of those sections should say the same thing: databasename, databaseusername, and databasepassword, in both of them. The server should normally be "localhost" (except on GoDaddy and some other servers).
In your host control panel under mysql databases you'll be able to get at the databasename, databasepassword, and (to reset it) databasepassword. The Statistics or the mysql section (depending upon server) should give you the mysql host (either a quad-decimal nnn.nnn.nnn.nnn or localhost). When you do that, run through the control panel and two config.php files again, same way as before with the new entries, so that it will connect.
Try that and see if it least connects to database. When it connects you'll want to change the databaseusername at your leisure -- you've made it public, removing one thing hackers would try to guess.
The config files share the same Username & Password
Just to annoy me clearly, there doesn't seem to be a way of editing database usernames or passwords in the mysql databases section - only add and delete :-/
EDIT - I may have solved the issue but still need to know how to edit the username and password anyways
You're doing okay, they work that way, delete and replace database, not change databasename. The only editable items are create/delete database, create/assign/delete databaseusername, and create/change databaseusernames' passwords.
That means, as you've just discovered, that each time you want to change the database name you will think twice and probably change just databaseusername and databaseusernamepassword, so as not to have to populate a blank database if that can be avoided.
For the moment, we have two config.php files which agree with each other, and which may not agree completely with the server (what you see in control panel), so we are still setting up to test whether password is the culprit. Be sure capslock is off when you reset password. You can initially just reset password to match the config.php files, in order to connect to database; and if need be also databaseusername.
Then the errors after the first two might well all go poof. If it cannot connect, the first couple of errors are thrown, then it will normally mumble about what it couldn't do after it couldn't connect but had tried and here is the list mumble.
That means, as you've just discovered, that each time you want to change the database name you will think twice and probably change just databaseusername and databaseusernamepassword, so as not to have to populate a blank database if that can be avoided.
For the moment, we have two config.php files which agree with each other, and which may not agree completely with the server (what you see in control panel), so we are still setting up to test whether password is the culprit. Be sure capslock is off when you reset password. You can initially just reset password to match the config.php files, in order to connect to database; and if need be also databaseusername.
Then the errors after the first two might well all go poof. If it cannot connect, the first couple of errors are thrown, then it will normally mumble about what it couldn't do after it couldn't connect but had tried and here is the list mumble.
Who is online
Users browsing this forum: No registered users and 18 guests
