beta11 upgrade issues

USB connection is really flaky now. Most of the time it just doesn't see the player or it
cannot open the database. Connecting via ethernet is even worse. I haven't been able to
get it to work anymore at all via ethernet. The only thing that I did was upgrade my MKII
to the latest beta (11) from the detault factory OS that came on my unit (latest public release)

I did follow all instructions to the teeth, latest version of emplode, blah... I am 100% sure
there are issues here that repro... I work at Microsoft as a tester, just thought that I would
extend the courtesy of a bug report back to the dev's that write this stuff...

USB Troubleshoot Log / Result Set:
----------------------------------------------------------------------------------------------

Tue 16 Apr 2002 15:22:49.699 Logfile opened
15:22:50.317 EmplodePlayerTemplate.cpp(101) : I [0b48] CEmplodePlayerTemplate::Detach
15:22:50.317 EmplodePlayerTemplate.cpp(63) : I [0b48] CEmplodePlayerTemplate::Attach
15:23:15.391 EmplodePlayerTemplate.cpp(101) : I [0b48] CEmplodePlayerTemplate::Detach
Tue 16 Apr 2002 15:23:23.229 Logfile opened
15:23:23.229 emplode.cpp(179) : I [0c08] Starting emplode version 2.0-beta11
15:23:23.350 EmplodePlayerTemplate.cpp(63) : I [0c08] CEmplodePlayerTemplate::Attach
15:23:37.791 EmplodePlayerTemplate.cpp(101) : I [0c08] CEmplodePlayerTemplate::Detach
15:23:37.801 EmplodePlayerTemplate.cpp(63) : I [0c08] CEmplodePlayerTemplate::Attach


UI User Scenerio: Flashlight endlessly at times, others it finds it, you click the icon then it
is just followed by posting a message box "There doesn't appear to be a player connected". WTF???





USB Troubleshoot Log / Result Set:
----------------------------------------------------------------------------------------------

- Reading through the log it just won't find the damn thing via ethernet broadcast. Timeout.

The usb problems and winxp is a known bug and is FITNR. Regarding ethernet, try setting a permanent ip via serial and emplode. Then tell emplode to look for that specific address.

Sean

I didn't notice any problems with connection via either USB or ethernet after upgrading to Beta 11. There are two possible known causes for this, let's rule those out first:

1) There is a known bug in the driver when running under Windows XP. If that is your operating system, then this is a likely scenario.

2) There is a FAQ entry here, titled "Why did ethernet and/or USB quit working after I upgraded the software?". It's not that one, is it?

Let us know if it's either of those. If not, we'll work on it some more.

I am running WinXP, so that might explain the USB issue. However- I would like to clarify that the issue did not come up prior to the upgrade to beta 11 for me. I will try to set a static IP and have emplode look for that. I will then report back; however DHCP should be just fine and this should work as is- so a bug must still exist...

I checked the about dialog and an IP was assigned. The IP was 169.254.9.22 so I thought that this might do it. I went into the options in emplode and entered the static IP and had it look for it. No luck. I got the flashlight treatment...


Ethernet Troubleshoot Log Using Static Connection:
-------------------------------------------------------------
Tue 16 Apr 2002 15:51:58.723 Logfile opened
15:51:58.723 emplode.cpp(179) : I [0950] Starting emplode version 2.0-beta11
15:51:58.813 EmplodePlayerTemplate.cpp(63) : I [0950] CEmplodePlayerTemplate::Attach
15:52:19.802 connection_win32.cpp(1058) : W [0294] connect() failed: 10060
15:52:45.813 connection_win32.cpp(1058) : W [0294] connect() failed: 10060

If the player is on 169.254.9.22, and your PC's address is not 169.254.9.something, then it will not work.

Your PC has to be on the same subnet as the player before they can talk to each other. The first three octets have to be the same. Ethernet troubleshooting tips are here.

I am running WinXP and connecting via ethernet. Using either DHCP or entering a static address has worked fine for me......

169.254.*.* is an automatically assigned IP address when a DHCP server (which allocates IP addresses to devices that ask for them) is not found on the network. It's basically to say, I couldn't get an IP address, so I had to make one up, here it is.

This means that either you don't have a DHCP server on your network (and so will have to configure a fixed IP address on the player), the DHCP server is broken or ignoring connections from the empeg, or the empeg network port is broken in either hardware or software.

Unless you can get it to give you a real IP (most internal IPs are either 192.168.*.* or 10.0.*.*, but that's not an all-inclusive list), you'll have little luck connecting via Ethernet.

Hope this helps,

A.

That's not entirely true. Your statement is only completely accurate if your netmask is 255.255.255.0 (or /24), which is quite common, but certainly not the only possibility. For example, the netmask on my home network is 255.255.255.128 (or /25), which means that 192.168.2.1 and 192.168.2.129 are not on the same subnet. Conversely, if my netmask were 255.255.0.0 (or /16), then 192.168.2.1 and 192.168.199.20 (for example) would be on the same subnet. Given that he's using the link-local addresses, I believe that his netmask would actually be 255.255.0.0, so he's good to go on that point, as long as all of the nodes understand this properly.

Switching network hubs fixed my problem. Thank you again for all the quick responses.

The usb problems and winxp is a known bug and is FITNR.

No, it's not.

We can (now) reproduce the problem. That doesn't mean that we've had time to look at it.

We hope to get it fixed in time for the next release, but since it's not fixed on the internal builds yet, we can't promise anything.

This is true, but whatever his netmask has been set to (unless he's changed it or something), as long as the first three groups of numbers are the same, it'll be able to connect. It just removes one level of possible error. But I agree completely with what you say - I use 255.255.0.0 here also.

A.

Darn, I thought once you could reproduce it, it wouldnt be long before you fixed it. At least there is a work around by using ethernet.

I believe that his netmask would actually be 255.255.0.0, so he's good to go on that point, as long as all of the nodes understand this properly.

If I recall correctly, there was a problem once upon a time where even a 255.255.0.0 netmask wouldn't work, and the player still had to be the same first three octets as the computer.

It might have simply been a bug in an early emplode that's long since fixed, but that's what my memory tells me.

In any case, his problem has been solved by using a different hub, so it's all moot now.