Change of mind

Ok, so after exploring some new avenues on the SPP and trying to figure out where my discoveries really belong, I decided the wikidot wiki really wasn't the place for it. So I created a new wiki and I'm logging all of the information I'm discovering there.

http://screenplayprohd.wikia.com

I've added my 2 GB fix to it this morning. It was the luck of a draw, really. I was exploring the wikidot and noticed that on a German page (Peter's) where they discussed the FTP hack, they also had the samba hack. So I pulled that one down, extracted it (WinRar again) and found an smbd binary in it. Tried plugging it directly in place of the one on the drive (located at /usr/local/etc/dvdplayer/samba/bin) but that didn't fix the problem. In fact, it stopped the drive from recognizing any smb requests. I removed it from the inetd.conf file (in the /etc directory) and manually started it myself, specifying the location of the configuration file.

It worked. So I added it back into the inetd.conf file and added the samba configuration file as a parameter to the drive. Tried it again, and it worked. Cool thing is, it ended up transferring the file about twice as fast.

Some other things I've done:

1. With a second screenplay on the network, was able to confirm that they can see each other, that they both have different names (iomega-d7xxxxxx), and both have different divx codes.

2. Was able to format the media partition on the drive as ext3 (used the system rescue cd, fdisk to drop the partition and recreate it at an ext3 partition, then formatted it, which took a long time).

3. Trying to help out a friend -- his drive stops booting whenever he plugs the screenplay pro hd into Vista, even if he doesn't access the drive and just unplugs it. So I formatted mine as ext3, plugged it into his computer and it continued to work afterwards.

That means formatting it for fat32 would probably also take care of the problem, but then you've got a silly 4 gb limit. Reformatted it for NTFS, plugged it into his computer again and it stopped working.

At that point, I used the system rescue CD, disabled the mount (found in /etc/rcS1) and then booted it. Yes, it booted, but the drive was obviously inaccessible. Nonetheless, I was able to get into it via telnet and try to mount it manually. Got a segmentation fault, the drive had been "corrupted." The built in windows scandisk utilities did not fix it.

Vista has added some additional things into the drive which are supposed to be backwards compatible. Tried mounting it with system rescue cd and the ntfs-3g driver and it worked fine. So the problem is the screenplay pro hd ntfs driver. It is not compatible with the Vista changes.

4. Took apart the drive to see its innards. Nothing spectacular to look at, as most of the secrets are under the heat sink. The heat sink covers the main processor and I wasn't about to try to remove it. The shielding was really annoying to get off too.

5. Mapped out all of the remote codes. Tried sending it some of the unmapped remote codes, but didn't find any hidden menus / service menus. I logged all of that on the wiki. Did find that the requirement to point directly at the device comes from the lack of a good IR light on the remote itself. When I used my JP-1 remote, I could bounce the signal off of walls and picture frames and it would still pick it up. So the main unit has a good IR receiver. I think there may be a way to send a keycode to the player using the network. I'm going to explore that someday too.

6. I discovered that the uclibc libraries that ship with the device (0.9.28) are not binary compatible with those found on the toolchain I discovered earlier. So while it is still possible to run programs when you've done a chroot to do the compile, most of those won't work once you exit the chroot shell. So I will need to figure out a way to get a precompiled 0.9.28 toolchain. I think Peter may have the answer.

Response to comments:
Dominik -- haven't looked into the auto mount for the usb drives. It's easy enough to switch them to read/write, but I suspect you're asking how to get them to mount as r/w to begin with. The approach I'd take to figure it out would be to telnet in with the drive just barely powered up and the USB drive attached to it. If it is already mounted, then there may be a startup script on the drive somewhere that does it and it should easy to modify. If it isn't mounted until you select the USB option in the menu, then the main DvdPlayer is responsible for mounting it and it will be much more difficult to change without doing it through telnet every time. I'll take a look at it later and see.
-- followup: after I posted, I recalled that there was a "hotplug" binary that detects the new USB devices. Looking at the binary, I see the mount command being done as -o ro (read only) inside the binary. So you can wait for Iomega to publish their modifications to the hotplug program (yeah, right) or you can use a tool like WinHex to modify that binary so that the devices will be mounted read/write. Just look for the text "mount" in the hotplug file and, you'll find it. Make sure you don't insert new or delete extra characters, or you'll kill the binary. /sbin is where the hotplug file is found.