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.
Monday, October 26, 2009
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.
Subscribe to:
Posts (Atom)