Looks like its going, but I'm getting this:

Code: [Select]

head: cannot open 'DBFILENAME' for reading: No such file or directory
Exporting account bxxxxn1 ...
head: cannot open 'DBFILENAME' for reading: No such file or directory
Exporting account bxxxxn2 ...
head: cannot open 'DBFILENAME' for reading: No such file or directory
Exporting account bxxxxn3 ...

etc


Bloody hell -- sorry, that was a typo.  I've put up a new build; if there are any more substantial issues in this one, I'll probably just set up vanilla Debian virtual machine, install v2 and v3 on it, and tinker with it until it succeeds... hate making you the guinea pig for this.

FYI while we did do some same-server testing, most of our testing of the utility was remote-server testing (eg: installing v3 on a separate machine from v2) which uses a different mechanism for copying.  That's why you're running into so many seemingly-obvious bugs.

Hey no problem. How do I specify a custom install of Icecast2 (KH build specifically). This is a pretty plain CentOS box.

If you've installed your own IceCast, you can enable it in CCv3 with:

Code: [Select]

/usr/local/centovacast/sbin/enable_package ICECAST /path/to/icecast
Replace /path/to/icecast with the actual path to IceCast, of course.

Does the importer map their existing IPs?

It is NOT importing their existing Port Numbers. It is assigning them new ones based on the range specified in the setup of CCv3.

Is this possible to get working?

Does the importer map their existing IPs?

It uses the default IP address configured for the v3 server.

It is NOT importing their existing Port Numbers. It is assigning them new ones based on the range specified in the setup of CCv3.

Is this possible to get working?

Hmmm, that's actually a very good point.  What we'll have to do is set it up so that it uses the originally-configured port IF it's available, and auto-allocates a new one if not.  The reason for this is because it's possible to import multiple v2 installation into a single v3 installation (or to import v2 accounts into a v3 installation that already contains accounts), so there may be port conflicts... I hadn't even noticed/considered that it reallocated them though, and clearly we do want at least a best effort.

Working on that now, back in a bit...

GET ON IT! Haha! Awaiting a new update

OK, I think we're good to go -- a new build is on the download server.  Just make sure that your port range in v3 (Settings -> Defaults -> Port range for new servers) includes all of the ports that your streams use, and it should maintain the port numbers during import.

Didnt work for me. It still assigned the port numbers starting at the lowest value (8000)

For me the custom Config is not auto-configuring the IP's and stays with the "defaults" from the skeleton - 192.168.x and port 8050

Just seeing if this got caught Steve.

Thanks!

Didnt work for me. It still assigned the port numbers starting at the lowest value (8000)

I tried a few different upgrades of a few different servers today and I can't seem to reproduce this... it faithfully reproduces the v2 port configuration on v3 whenever I try it.

The only thing I know of that would cause this to happen is if you had your port range set to 8000-9000 in v3, and your streams in v2 were using ports outside of that range.  The upgrader will enforce the port range set in v3, and will renumber the accounts if they're outside that range.

I also uploaded a new update to the download server -- you may want to try again with that one and see if it works any better.

We'll try it again. I even gave a range of 2000 to 90000 just to test