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.

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.

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.

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.

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.

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.

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.

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.