Super has been waiting for some help from me regarding VSFTP and BFTPD. I thought those were already in IomTools, but apparently the functions were not yet there. So I've helped with what I can and hopefully we'll see the new version soon.
Along the process, I discovered that VSFTP could not use the anonymous upload for the root directory. You have to create a directory on the media partition to do anonymous uploads. I had discovered this when I originally documented it on the wiki, but had forgotten and had to "rediscover" it. So I put it on the wiki this time.
Sunday, November 1, 2009
Monday, October 26, 2009
Start of compiling
Really late right now so I'll do a quick synopsis: The source for 1.00.011 APP is missing some pieces. I'm downloading the 2.00.004 sources now to see if the missing pieces are there instead. But then I started playing around with the Ellion sources.
I compiled up most of the libraries, and then compiled the WatchDogApp (also known as RootApp). Tried to run it on my iomega and got a segmentation fault. After a little debugging and searching, I found that in the Include/OSAL/PLI.h file there is a #define that defines the DEF_MEM_SIZE to be 256. Well, the Iomega only has 64. So I switched it over to 64, recompiled the libraries and the RootApp and...
it was able to run.
I stuck in some additional debug statements to tell me, once and for all, what the player thinks it's Realtek chip # is. And without a doubt, I can now safely change my assumption from 1262 to WRONG.
It isn't a 1262. It's a 1282.
Code to find it: I placed this in the resetav function:
reg = (unsigned int *)pli_getIOAddress(0xb801a200);
printf("Chip id is %x\n", *reg);
And 1282 was returned.
I compiled up most of the libraries, and then compiled the WatchDogApp (also known as RootApp). Tried to run it on my iomega and got a segmentation fault. After a little debugging and searching, I found that in the Include/OSAL/PLI.h file there is a #define that defines the DEF_MEM_SIZE to be 256. Well, the Iomega only has 64. So I switched it over to 64, recompiled the libraries and the RootApp and...
it was able to run.
I stuck in some additional debug statements to tell me, once and for all, what the player thinks it's Realtek chip # is. And without a doubt, I can now safely change my assumption from 1262 to WRONG.
It isn't a 1262. It's a 1282.
Code to find it: I placed this in the resetav function:
reg = (unsigned int *)pli_getIOAddress(0xb801a200);
printf("Chip id is %x\n", *reg);
And 1282 was returned.
Saturday, October 24, 2009
Organization, and yet another toolchain (conceptronic / media giant)
Organization. I have two external 1 TB drives with ISOs and I've moved all of my stuff off of the screenplay so I can experiment with it. In the process, I decided to switch back to EXT3 for the screenplay. The screenplayprohd.wikia.com wiki details how to do that in filesystem. Anyway, after reformatting the drive, I then organized all of the videos on the other two drives under one directory called Alphabetical, and then subdirectories from there ABC, DEF, GHI, JKL, and so on with VWXYZ all in the same. So both external drives had that. Underneath each of those directories, I put another directory for each movie / group of movies. For instance, all of the Star Wars ISOs are under Alphabetical/STU/Star Wars.
On the Screenplay, I setup a small, hidden script in the root directory that removes the contents of the Alphabetical directory and recreates the same directory structure as on the USB drives. So it's a mirror image, but empty. Then I use symbolic links to link the contents of each of the USB drives. I do it this way because if you do a symbolic link of an ISO file, the screenplay can't mount and play it.
So here's the script:
I know that's ugly and I could have used a for statement on it. But this follows a script I am making that I'm not ready to divulge yet.
The result of that is that all of my movies appear on the main drive and I don't have to guess as to which USB drive has the movie. I just navigate to the screenplay (now automatically done during bootup, as explained in my last post). It has vastly simplied finding any of the more than 250 movies in my collection. Next, I'm going to try to add some dvd covers in some way so that the kids can browse all of the covers when just looking for a movie to view. I'll probably just put all of them in a single directory, maybe 8 to a JPG and add some background music to the folder...
Media Giant Now that I've finally gotten some time on my hands, I pulled down Fedora 11 virtual machine (from vmware appliances, I used the LinHost one
Then I pulled down the conceptronic GPL sources. 2.00.004 linux one is corrupt, so I used the 1.00.011 sources. Copied them onto the virtual machine (I put them in a windows shared directory and just accessed it from the VM).
Although the instructions are there in the readme for the doing the kernel and the app, the instructions did not work exactly as indicated. First, you need GCC. But not just any GCC. If you do a yum gcc command you'll end up with the latest stable gcc, and that won't compile the OS. Instead, I've found you have to pull down gcc 3.4.6. Do yum install compat-gcc34. Of course, you have to do this under su mode. sudo should work, but I just did su and I'm doing everything under that mode (I know, I know, bad idea).
Now at that point, you're going to have a gcc34 in the /usr/bin, but still no gcc, so you'll still get an error about compiling. I created a symlink to gcc ln -s /usr/bin/gcc34 /usr/bin/gcc and then followed the rest of the directions. When I was finished, I had a full image of everything, app included.
I haven't tried flashing the image in. Instead, I searched for DvdPlayer and then copied that onto my ScreenPlay, along with the Resources and the symlinks of the two font files in the Resources directory. I executed a kill -9 95 (my root app proces from ps was 95) and then stopall. Switched over to the /tmp/hddmedia/mediagiant directory where I had put the other DvdPlayer and executed it.
It came up.
Unfortunately, it is in PAL mode, so I can't see the screen very clearly right now and it is not responding to keystrokes, remote codes,or anything else to allow me to switch it to NTSC. When I get a chance, I'm going to hook it to my HD TV and see if I can see it better. Although, without any way to control it, it's basically worthless to me. But I can see the "Grab 'n Go" interface, so I'm pretty happy that I've gotten this far with it. I ended up having do terminate the process, which left info on the screen even though the process was no longer running. When I ran a stopall, then the info cleared from the screen and I was able to restart the Iomega DvdPlayer version.
The ellion open source code posted at MHDWorld has the source necessary to rebuild and change the DvdPlayer app, so next step will be to get that one compiled with this environment and see if it comes up. If it does, this will probably be the start of a new interface.
On the Screenplay, I setup a small, hidden script in the root directory that removes the contents of the Alphabetical directory and recreates the same directory structure as on the USB drives. So it's a mirror image, but empty. Then I use symbolic links to link the contents of each of the USB drives. I do it this way because if you do a symbolic link of an ISO file, the screenplay can't mount and play it.
So here's the script:
cd Alphabetical
rm -r *
mkdir ABC
mkdir DEF
mkdir GHI
mkdir JKL
mkdir MNO
mkdir PQR
mkdir STU
mkdir VWXYZ
ln -s /tmp/usbmounts/sda1/Alphabetical/ABC/* ABC &
ln -s /tmp/usbmounts/sda1/Alphabetical/DEF/* DEF &
ln -s /tmp/usbmounts/sda1/Alphabetical/GHI/* GHI &
ln -s /tmp/usbmounts/sda1/Alphabetical/JKL/* JKL &
ln -s /tmp/usbmounts/sda1/Alphabetical/MNO/* MNO &
ln -s /tmp/usbmounts/sda1/Alphabetical/PQR/* PQR &
ln -s /tmp/usbmounts/sda1/Alphabetical/STU/* STU &
ln -s /tmp/usbmounts/sda1/Alphabetical/VWXYZ/* VWXYZ &
ln -s /tmp/usbmounts/sdb1/Alphabetical/ABC/* ABC &
ln -s /tmp/usbmounts/sdb1/Alphabetical/DEF/* DEF &
ln -s /tmp/usbmounts/sdb1/Alphabetical/GHI/* GHI &
ln -s /tmp/usbmounts/sdb1/Alphabetical/JKL/* JKL &
ln -s /tmp/usbmounts/sdb1/Alphabetical/MNO/* MNO &
ln -s /tmp/usbmounts/sdb1/Alphabetical/PQR/* PQR &
ln -s /tmp/usbmounts/sdb1/Alphabetical/STU/* STU &
ln -s /tmp/usbmounts/sdb1/Alphabetical/VWXYZ/* VWXYZ &
I know that's ugly and I could have used a for statement on it. But this follows a script I am making that I'm not ready to divulge yet.
The result of that is that all of my movies appear on the main drive and I don't have to guess as to which USB drive has the movie. I just navigate to the screenplay (now automatically done during bootup, as explained in my last post). It has vastly simplied finding any of the more than 250 movies in my collection. Next, I'm going to try to add some dvd covers in some way so that the kids can browse all of the covers when just looking for a movie to view. I'll probably just put all of them in a single directory, maybe 8 to a JPG and add some background music to the folder...
Media Giant Now that I've finally gotten some time on my hands, I pulled down Fedora 11 virtual machine (from vmware appliances, I used the LinHost one
Then I pulled down the conceptronic GPL sources. 2.00.004 linux one is corrupt, so I used the 1.00.011 sources. Copied them onto the virtual machine (I put them in a windows shared directory and just accessed it from the VM).
Although the instructions are there in the readme for the doing the kernel and the app, the instructions did not work exactly as indicated. First, you need GCC. But not just any GCC. If you do a yum gcc command you'll end up with the latest stable gcc, and that won't compile the OS. Instead, I've found you have to pull down gcc 3.4.6. Do yum install compat-gcc34. Of course, you have to do this under su mode. sudo should work, but I just did su and I'm doing everything under that mode (I know, I know, bad idea).
Now at that point, you're going to have a gcc34 in the /usr/bin, but still no gcc, so you'll still get an error about compiling. I created a symlink to gcc ln -s /usr/bin/gcc34 /usr/bin/gcc and then followed the rest of the directions. When I was finished, I had a full image of everything, app included.
I haven't tried flashing the image in. Instead, I searched for DvdPlayer and then copied that onto my ScreenPlay, along with the Resources and the symlinks of the two font files in the Resources directory. I executed a kill -9 95 (my root app proces from ps was 95) and then stopall. Switched over to the /tmp/hddmedia/mediagiant directory where I had put the other DvdPlayer and executed it.
It came up.
Unfortunately, it is in PAL mode, so I can't see the screen very clearly right now and it is not responding to keystrokes, remote codes,or anything else to allow me to switch it to NTSC. When I get a chance, I'm going to hook it to my HD TV and see if I can see it better. Although, without any way to control it, it's basically worthless to me. But I can see the "Grab 'n Go" interface, so I'm pretty happy that I've gotten this far with it. I ended up having do terminate the process, which left info on the screen even though the process was no longer running. When I ran a stopall, then the info cleared from the screen and I was able to restart the Iomega DvdPlayer version.
The ellion open source code posted at MHDWorld has the source necessary to rebuild and change the DvdPlayer app, so next step will be to get that one compiled with this environment and see if it comes up. If it does, this will probably be the start of a new interface.
Wednesday, October 21, 2009
Controlling the dvdplayer from an external program
Well, I figured out a couple of things today, my day off...
First, the RootApp. I figured out that it is required in order for the Power Off button to work. Otherwise, the unit does not shut down properly. This becomes critical with the second discovery...
In a prior post, Fun with the Player I detailed that you have telnet control over the screenplay if you launch the DvdPlayer program after executing a stopall. You can then send keypresses to remote control the screenplay. This trick was stopped in R1.8 firmware, although it still works if you kill -9 the RootApp process. The real trick is to get it to allow you to connect to some kind of key queue that you can fill up after the screenplay is booted.
For the ScreenPlay Pro, the /usr/local/etc has an rcS file that launches the DvdPlayer portion in conjunction with the RootApp. So, using a suggestion from jamoba posted to the emtec group back in february, I modified my rcS as follows:
if [ -f $DEFAULT_AP_DIR/DvdPlayer ] && [ -x $DEFAULT_AP_DIR/DvdPlayer ]; then
cd $DEFAULT_AP_DIR
if [ -f $DEFAULT_AP_DIR/RootApp ] && [ -x $DEFAULT_AP_DIR/RootApp ]; then
echo Running dvdplayer with RootApp
touch /tmp/command_sender.txt
tail -f /tmp/command_sender.txt | RootApp DvdPlayer -l on -o /var/log/dvdplayer/user_input&
else
echo Running dvdplayer
./DvdPlayer -l on -o /var/log/dvdplayer/user_input&
fi
else
/usr/local/etc/dvdplayer/script/run_tail
fi
sleep 10
cat /tmp_orig/startscript >> /tmp/command_sender.txt
So basically, I have a series of keypresses in the startscript file that it sends 10 seconds after launching the program, which is just about right. I can have the startscript read something like:
XX
(There's a single space before XX and a single space after)
To have it automatically go into the ScreenPlay drive and press down twice and select the folder or media at that location.
Now, if I wanted to send more keystrokes outside of the startscript, I can simply add to the /tmp/command_sender.txt by commands like "echo O >> command_sender.txt" to have it automatically shut down the screenplay. I can do this in a telnet prompt AFTER the screenplay has booted. Theoretically, I could write an http webpage that displays all of my movies, say in thumbnail mode, and if I select one, it could send the necessary prompts to the screenplay to automatically select and play the movie. It could even send the necessary prompts to launch the movie from a DVD menu. Or shut off the screenplay from a remote location.
There is a condition in which it won't run the script. This script will run each time the screenplay is powered on, but does not work if the screenplay is brought back from standby mode. If you shut off the screenplay with the remote, then any scheduled recordings you have will automatically boot up the screenplay. The screenplay is in Standby mode.
If you shut it down by holding down the power button on the front of the console, then it shuts off the power and you will miss any scheduled recordings. It is not in standby mode.
When you power up from standby mode, the "Iomega" logo does not appear during the boot process. That is one way you can identify that you are in standby mode. It also isn't going to run the rcS script, and thus won't run the startscript text file either.
Something else I discovered: If you telnet in, go into standby mode, then turn the screenplay back on, your telnet session will still be running. This is a symptom of it coming out of standby mode. All processes are still running. Thought it was interesting.
First, the RootApp. I figured out that it is required in order for the Power Off button to work. Otherwise, the unit does not shut down properly. This becomes critical with the second discovery...
In a prior post, Fun with the Player I detailed that you have telnet control over the screenplay if you launch the DvdPlayer program after executing a stopall. You can then send keypresses to remote control the screenplay. This trick was stopped in R1.8 firmware, although it still works if you kill -9 the RootApp process. The real trick is to get it to allow you to connect to some kind of key queue that you can fill up after the screenplay is booted.
For the ScreenPlay Pro, the /usr/local/etc has an rcS file that launches the DvdPlayer portion in conjunction with the RootApp. So, using a suggestion from jamoba posted to the emtec group back in february, I modified my rcS as follows:
if [ -f $DEFAULT_AP_DIR/DvdPlayer ] && [ -x $DEFAULT_AP_DIR/DvdPlayer ]; then
cd $DEFAULT_AP_DIR
if [ -f $DEFAULT_AP_DIR/RootApp ] && [ -x $DEFAULT_AP_DIR/RootApp ]; then
echo Running dvdplayer with RootApp
touch /tmp/command_sender.txt
tail -f /tmp/command_sender.txt | RootApp DvdPlayer -l on -o /var/log/dvdplayer/user_input&
else
echo Running dvdplayer
./DvdPlayer -l on -o /var/log/dvdplayer/user_input&
fi
else
/usr/local/etc/dvdplayer/script/run_tail
fi
sleep 10
cat /tmp_orig/startscript >> /tmp/command_sender.txt
So basically, I have a series of keypresses in the startscript file that it sends 10 seconds after launching the program, which is just about right. I can have the startscript read something like:
XX
(There's a single space before XX and a single space after)
To have it automatically go into the ScreenPlay drive and press down twice and select the folder or media at that location.
Now, if I wanted to send more keystrokes outside of the startscript, I can simply add to the /tmp/command_sender.txt by commands like "echo O >> command_sender.txt" to have it automatically shut down the screenplay. I can do this in a telnet prompt AFTER the screenplay has booted. Theoretically, I could write an http webpage that displays all of my movies, say in thumbnail mode, and if I select one, it could send the necessary prompts to the screenplay to automatically select and play the movie. It could even send the necessary prompts to launch the movie from a DVD menu. Or shut off the screenplay from a remote location.
There is a condition in which it won't run the script. This script will run each time the screenplay is powered on, but does not work if the screenplay is brought back from standby mode. If you shut off the screenplay with the remote, then any scheduled recordings you have will automatically boot up the screenplay. The screenplay is in Standby mode.
If you shut it down by holding down the power button on the front of the console, then it shuts off the power and you will miss any scheduled recordings. It is not in standby mode.
When you power up from standby mode, the "Iomega" logo does not appear during the boot process. That is one way you can identify that you are in standby mode. It also isn't going to run the rcS script, and thus won't run the startscript text file either.
Something else I discovered: If you telnet in, go into standby mode, then turn the screenplay back on, your telnet session will still be running. This is a symptom of it coming out of standby mode. All processes are still running. Thought it was interesting.
Thursday, September 24, 2009
Interface Update
I updated the wiki with new skins and a template for creating new skins.
http://screenplayprohd.wikia.com/wiki/Skins
The purpose of this blog is to explain how I did things, so here goes...
I created a grid.bmp file. It's actually in the template.zip if you want to see it. I used a special code to help identify the 100 / 200 / 300 / 400 / 500 / 600 point lines. The X in the grid boxes help to identify more specific points. By putting the grid into the background (giving it the name IMAGE_GUIDE_BG.bmp for instance) I was able to figure out the exact location of all of the other boxes on the screen. Then it was a matter of reconstructing that in layers through GIMP.
Playing around with the colors, I found that 0,0,0 was transparent on some of the images. I tried to take advantage of that fact, but quickly found out that most of the time you WANT the images to overwrite what was on the background before.
The Iomega Toys skin came from Superberny. It was similar to what I had been planning with a Disney theme. I decided to focus strictly on Mickey and found many resources on the web for getting Mickey pictures. I ended up having to modify most of them in one way or another. Mickey looks too fat on the TV. But I left it because, after all, TV does make you look too fat, right?
All kidding aside, I spent a lot of time trying to do the Mickey skin and toward the end got a little sloppy because I just wanted to get it done. There's a lot of graphics to replace if you want to match the whole theme.
I mentioned it many times on the interface page, but I'll say it again. You HAVE to save each and every bitmap out as R5G6B5 format or it will lock up the screenplay.
Kudos to SuperBerny for the initial work identifying the files to replace.
http://screenplayprohd.wikia.com/wiki/Skins
The purpose of this blog is to explain how I did things, so here goes...
I created a grid.bmp file. It's actually in the template.zip if you want to see it. I used a special code to help identify the 100 / 200 / 300 / 400 / 500 / 600 point lines. The X in the grid boxes help to identify more specific points. By putting the grid into the background (giving it the name IMAGE_GUIDE_BG.bmp for instance) I was able to figure out the exact location of all of the other boxes on the screen. Then it was a matter of reconstructing that in layers through GIMP.
Playing around with the colors, I found that 0,0,0 was transparent on some of the images. I tried to take advantage of that fact, but quickly found out that most of the time you WANT the images to overwrite what was on the background before.
The Iomega Toys skin came from Superberny. It was similar to what I had been planning with a Disney theme. I decided to focus strictly on Mickey and found many resources on the web for getting Mickey pictures. I ended up having to modify most of them in one way or another. Mickey looks too fat on the TV. But I left it because, after all, TV does make you look too fat, right?
All kidding aside, I spent a lot of time trying to do the Mickey skin and toward the end got a little sloppy because I just wanted to get it done. There's a lot of graphics to replace if you want to match the whole theme.
I mentioned it many times on the interface page, but I'll say it again. You HAVE to save each and every bitmap out as R5G6B5 format or it will lock up the screenplay.
Kudos to SuperBerny for the initial work identifying the files to replace.
Sunday, August 23, 2009
Changing the theme
Credit where credit is due: the rtd1261.wikidot.com site contained the information about what format the graphics had to be saved in. And Superberny put together a package for IomTools that contained most of the graphic files necessary, which made it easier to identify.
So what I did was go through all of the BMP files on the drive and identify the purpose and where they appeared on the screenplay. This is to make it easier for other people to do custom themes by changing the graphics.
I documented it on the wiki:
http://screenplayprohd.wikia.com/wiki/Modifying_the_Interface
That will make it easier for people to change what has to be changed to match whatever theme. Now I need to figure out how I'm going to identify the locations that each of the overlays appear. But it's really late at night / really early in the morning, so I'm done for today.
So what I did was go through all of the BMP files on the drive and identify the purpose and where they appeared on the screenplay. This is to make it easier for other people to do custom themes by changing the graphics.
I documented it on the wiki:
http://screenplayprohd.wikia.com/wiki/Modifying_the_Interface
That will make it easier for people to change what has to be changed to match whatever theme. Now I need to figure out how I'm going to identify the locations that each of the overlays appear. But it's really late at night / really early in the morning, so I'm done for today.
Tuesday, August 11, 2009
Other hacks
I picked up a Canon SX10 IS camera to replace my outdated Canon PowerShot S30. I had hacked the Powershot S30, so I figured there might be something for the SX10. And there was: http://chdk.wikia.com contains a wealth of information for supplementing the existing firmware. I'm already using many of the features, including taking snapshots of lightning, displaying the battery power in %, the temperature of the lens, ccd, and battery compartments, the time displayed on the OSD, and the best thing: Removal of the hot/dead pixels. I had one set near the middle and it was very obvious in all of my pictures. I didn't want to return the camera for "possibly" getting a fix, and the firmware fixed it right up. If you have a canon camera, it's definitely worth checking into that hack. I'd love to say I had something to do with it, but all I've done is applied other people's work at this point.
Today, my laundry machine had some problems. I have a GE Harmony washer. Luckily, with a lot of research and a little bit of luck, I was able to determine a "test" mode for the washer. Push power on, then hold down on help and press start/stop. Then you can test out specific things like spin, fill cold, fill hot, drain, agitate, etc, overriding what the washer would normally do. There's another one that is similar, something like back and home at the same time. But it will actually make your washer reset. I had to use it once when my washer reported a problem while I was reassembling it. Oh, and common knowledge, but if you put a magnet near the front left side of the lid, there is a reed switch that triggers so that the laundry machine thinks that the lid is down. That way you can watch what is going on inside.
Trying to catch up with everything after my vacation, so hopefully I will be able to get back to the Screenplay soon.
Today, my laundry machine had some problems. I have a GE Harmony washer. Luckily, with a lot of research and a little bit of luck, I was able to determine a "test" mode for the washer. Push power on, then hold down on help and press start/stop. Then you can test out specific things like spin, fill cold, fill hot, drain, agitate, etc, overriding what the washer would normally do. There's another one that is similar, something like back and home at the same time. But it will actually make your washer reset. I had to use it once when my washer reported a problem while I was reassembling it. Oh, and common knowledge, but if you put a magnet near the front left side of the lid, there is a reed switch that triggers so that the laundry machine thinks that the lid is down. That way you can watch what is going on inside.
Trying to catch up with everything after my vacation, so hopefully I will be able to get back to the Screenplay soon.
Subscribe to:
Posts (Atom)