If your having problems don’t increase the load to 1,000 try decreasing the load to 50 or 10, also increase the delay time to allow the disk to finish its I/O operations before executing another query.
Your PC memory has nothing to do with how much memory is being allocated to php.exe, to increase the allocated memory to the PHP process open up your php.ini file and increase ‘memory_limit’ to 256M.
Also open up Windows ‘Resource Monitor’ whilst you are running this to monitor the PHP process and Disk I/O, when I was doing early testing it was my HDD that was the bottleneck and causing the import to fail.
Thanks, I’ll try decreasing the rows, increasing delay time and observing my disk in the Resource Monitor. Already had memory_limit = 1000M.
I’m starting to suspect there is something fishy about this certain group of topics: Converting topics (500 – 599) – crashes every time. I had a delay of 5 seconds and could see in the monitor the disk use drop to zero for a good while.
Tried with 10 rows, 1 sec and 5 sec delay both result in a crash:
Converting topics (650 – 659)
Is there any way I can debug this?
bbPress 2.1.1 was released and the notes said “Fixed Invision, phpBB, and vBulletin importers”.
Didn’t help with my problem!
Also have a read of the following thread and try some of the suggestions by JJJ here and here.
Can you try with a clean WordPress install on a different webhost or setup a local environment?
Try the import using the remote SQL server address rather than ‘localhost’
Can you narrow down the if it is an exact post that the importer fails on? eg. Is there some weird strings in the database for topic #xyz that is causing the importer to stop.
It is a clean WP install on my local machine. Phpbb is 3.0.9.
I finally ran it 1 row at a time and this is the content of bbp_converter_query:
> SELECT convert(topics.topic_id USING “utf8”) AS
> topic_id,convert(topics.forum_id USING “utf8”) AS
> forum_id,convert(topics.topic_poster USING “utf8”) AS
> topic_poster,convert(posts.post_text USING “utf8”) AS
> post_text,convert(topics.topic_title USING “utf8”) AS
> topic_title,convert(topics.topic_time USING “utf8”) AS topic_time FROM
> phpbb_topics AS topics INNER JOIN phpbb_posts AS posts USING
> (topic_id) WHERE posts.post_id = topics.topic_first_post_id LIMIT 660,
> 1
How can I determine the correct id in phpmyadmin? Is it row 660? Like if I have Show 30 rows starting from 660, will it show the correct topic id as the first one? The topic in question doesn’t seem to have anything out of the ordinary in it.
Can you try going into the phpBB Admin and run the following:-
-
Resynchronise statistics
Recalculates the total number of posts, topics, users and files.
-
Resynchronise post counts
Only existing posts will be taken into consideration. Pruned posts will not be counted.
-
Resynchronise dotted topics
First unmarks all topics and then correctly marks topics that have seen any activity during the past six months.
Did those and it still gets stuck. Can you confirm that the topic is on the row 660?
- Open phpMyAdmin
- Open you phpBB database
- Click ‘browse’ on the ‘_topics’ table
- In the ‘topic_id’ field you will see the topic_id
- Navigate to page xyz where you will see a topic_id of 660
Have a good look at all the fields (horizontal list) of the data around that range and compare it to the previous 10 and next 10 topic_ids (i.e. topic_id 650-670)
Is there any major differences between the rows and fields of the posts besides topic title etc, is a particular topic_id row missing data that is in every other topic_id but not in that particular topic_id
660 does not imply the topic_id, but the row number. I finally managed to pinpoint the correct offending topic. Having to have to deal with row numbers, I was a bit confused about which topic I have to skip. There really should be some debugging feature that would display the exact topic_id or any first (=most important) field in a given table.
First I deleted a couple of topics (not the right ones) in phpBB. Then when it got stuck again, I realized which of them was the offender. Then I used the trick of bumping the value in bbp_converter_start by 1 and pressing Start to restart the conversion from where it left off.
The topic as I see it does not contain anything out of the ordinary: it’s by an admin, so his name is colored red. But otherwise the fields are fine.
Can you post a copy of that posts SQL data please so we can have a look at that data to improve the bbPress phpBB importer.
Can you contact me privately?
To add to my debugging wish, would be nice to have the specific info even when running with more than 1 row at a time.
Drop me an email the data and your contact info and I will look at it and get back to.
Sent you an email. The next stop was with replies, LIMIT 470. Managed to skip it. Left it running over night. When I came to check it, it had stalled at LIMIT 6874 and had outputted a huge line of dashes. I pressed stop and went to bump the bbp_converter_start. “Starting conversion” it said and started to output more dashes without actually doing anything.
If you can give me confirmation that 470 and 6874 mean row numbers in phpbb_posts, I will send those rows to you. But then I will wait for an update to bbPress with better debugging, because I can’t go doing conversions 1 row at a time for weeks on end hoping it won’t crash.
Ok restarting my web server did the trick and now it continues with the replies.
I’ve looked at the data you sent me and each value for each field is a valid field value/type!
I can import that data into a phpBB install, I can then import that data to bbPress!
I got nothing at the moment as to what is causing the import to stop, Ill try and gather some more sample data/databases to debug the issue.
For now if you get stuck try ‘bbp_converter_start by 1’
Thanks for checking into this. Will be nice to get this figured out.
Yes, I’m trying to locate some blocking replies to send to netweb for testing.
JJJ: does this logic mean it skips the first post in topic: LEFT JOIN phpbb_topics AS topics USING (topic_id) WHERE posts.post_id != topics.topic_first_post_id LIMIT 470, 1
I think if this is true, I can’t just look at my phpbb_post row 470 in phpmyadmin, but would have to run a modified query to display the exact offending post.
Damn, I just realized phpmyadmin’s browsing interface was confusing me and I was giving netweb the wrong topic! Now I have sent him the correct one + the first post.
I feel like a caveman in a spaceship with this SQL stuff.. ignore my worries about the logic, I have now sent netweb the replies row dumps. Realizing I can do “export, Dump some row(s), Number of rows: 1, Row to begin at: 470, View output as text” helped A LOT! Farewell to uncertainty.
So…. I created a new clean phpBB install, imported the data into phppBB, installed WordPress & bbPress and imported from phpBB.
Everything looks fine to me…. I wish I could find something, we know there is something wrong!
I’ll have another look in the morning with a fresh par of eyes.
Thanks for persisting and trying to help us find the problem.
Cheers,
Stephen
Did anyone ever get to the bottom of this? I have the same problem. I think it may have to do with WAMP.
It’s definitely WAMP, most likely the ‘W’ part. (I tried this on Windows 7) XAMPP has even more trouble. Apache is being disrupted and crashed at times, probably because of Windows User Account Control (UAC) security settings and/or IIS. You should get a warning about this when you install XAMPP on Windows. I haven’t test to see if that’s the cause, but it seems likely.
See: http://answers.microsoft.com/en-us/windows/forum/windows_xp-windows_programs/i-am-trying-to-install-xampp-win32-177-i-get-a/0b44bd10-2fff-49ac-bb48-30dfc4ae9c44?msgId=0c558024-e8e2-47b2-a9f7-ee102b62aec9
What does work is LAMP, so just do the migration on your webserver or localhost. I’ve had no problem doing it all on Nexcess.net’s WordPress hosting with over 61,000 posts and 1100 users converted with the default settings of 100 rows at a time with a 1s delay.
