Tonight, I found that in the Ellion Open source, UnitTest/Grandma_DG_StateMachine was the source code for the DvdPlayer. It was everything necessary, but referenced a few things that weren't quite right. For one, it tried to get to the Utility and Platform_Lib as if they were right there. So I put in a symbolic link to put them there. Second was that it was trying to reference the mp3info.h in the mp3info directory when it was really in the mp3info/Include directory. So I copied to to the mp3info directory (yeah, I should have used a hard link instead, doh!)
Last piece was that it was trying to get to a Tools/MConfig, which wasn't there. So I found a Tools/MConfig in the conceptronic sources and put it there. It all compiled (and I mean compiled, not linked a bunch of already compiled .o files :D )
I copied it and the resource directory out on the ScreenPlay. Like in previous attempts, it came up in Pal mode. Unlike in previous attempts, it was now reading the keyboard. So I exited the program and this time brought it up by typing ./DvdPlayer -f NTSC which forced it to NTSC mode.
It worked.
The remote control didn't work, but I could control everything from the keyboard through telnet. I was able to complete the configuration screen, then browse to both the USB and Main hard drives. Naturally, the menu is based on the same principles that the Iomega SPP is, where it just lists filenames and shows a preview. But I was able to browse to specific movies and launch them.
Since there is a file called ir_control.cpp in the directory, I'm positive I'll be able to get the remote control working...
But not tonight. It'll have to wait a couple of nights before I can get back to it.
Update: Too excited to sleep tonight. RemoteControl.cpp and RemoteControl.h in the Platform_Lib were the ones responsible. In RemoteControl.h, it defines the manufacturer's code for the Ellion, which they had two. So I stuck in a printf in the ir_control.cpp to find out what remote code was for the Iomega, and found out mine was 0x3f40. Stuck that in, now it should process the codes...except that the codes are all different. Luckily, prior work has paid off now: http://screenplayprohd.wikia.com/wiki/Remote the bottom half JP1 OBC codes are listed. So it is just a matter of changing the RemoteControl.cpp switch statement to use the Iomega codes intead of the Ellion ones. :)
Wednesday, November 4, 2009
Tuesday, November 3, 2009
smbpasswd
Inspired from a forum post on the wiki, I decided to try to get smbpasswd going.
The post includes everything needed to set it up. The highlights are:
1) mount -o rw,remount /
2) vi /usr/local/samba/lib/smb.conf
3) Press i. modify the smb.conf.
4) change guest ok = yes to guest ok = no on whichever share you want to restrict. Adding shares is already documented on the wiki.
5) save the smb.conf file (press esc key followed by :wq )
Now you need smbpasswd. I've stuck it out there at: http://www.box.net/shared/l6kbxxb5pn
But the question is how did I make it?
351H_AP_GL ellion source that I blogged about earlier had the samba in system/branch_src_sharedmemory_integration/Utility/samba/Samba-3.0.23C. So I brought up my fedora virtual machine, switched to that directory and ran make. It built all of the samba stuff. mipsel-linux-strip on the smbpasswd file when it was finished, and copied it to my screenplay.
Since my screenplay is currently ext3, I didn't have to do a chmod to make it executable as it was already marked executable. I think the NTFS may do that too, but if it doesn't you'll need to move it onto one of the ext3 drives. Anyway, executed smbpasswd -a root and it added a root user with the password I gave it to the /etc/smbpasswd data file. I did this on my root share that I added, so now when I browse there, it prompts for password (username defaults to guest, grayed out), which I use the root smbpassword I set up and it opens. If I browse to the ScreenPlay share or my USB share, it just opens immediately, does not prompt for password. That's actually an added bonus, since it used to ask for my password and there was none so I just click OK and it would open it.
The post includes everything needed to set it up. The highlights are:
1) mount -o rw,remount /
2) vi /usr/local/samba/lib/smb.conf
3) Press i. modify the smb.conf.
4) change guest ok = yes to guest ok = no on whichever share you want to restrict. Adding shares is already documented on the wiki.
5) save the smb.conf file (press esc key followed by :wq )
Now you need smbpasswd. I've stuck it out there at: http://www.box.net/shared/l6kbxxb5pn
But the question is how did I make it?
351H_AP_GL ellion source that I blogged about earlier had the samba in system/branch_src_sharedmemory_integration/Utility/samba/Samba-3.0.23C. So I brought up my fedora virtual machine, switched to that directory and ran make. It built all of the samba stuff. mipsel-linux-strip on the smbpasswd file when it was finished, and copied it to my screenplay.
Since my screenplay is currently ext3, I didn't have to do a chmod to make it executable as it was already marked executable. I think the NTFS may do that too, but if it doesn't you'll need to move it onto one of the ext3 drives. Anyway, executed smbpasswd -a root and it added a root user with the password I gave it to the /etc/smbpasswd data file. I did this on my root share that I added, so now when I browse there, it prompts for password (username defaults to guest, grayed out), which I use the root smbpassword I set up and it opens. If I browse to the ScreenPlay share or my USB share, it just opens immediately, does not prompt for password. That's actually an added bonus, since it used to ask for my password and there was none so I just click OK and it would open it.
Sunday, November 1, 2009
Temporary diversion -- VSFTP and BFTPD
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.
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.
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.
Subscribe to:
Posts (Atom)