Stream of Consciousness

I made a little boo-boo whilst preparing the FrameAlbum code for release. I’m restoring from last night’s backup so the site (and your feeds) may be a bit wonky for a bit.

Sorry about that folks.

And here you thought FrameAlbum was in the DeadPool — HA!

- I’ve located another issue with the Picasa grabbers that delays feed updates. I’ve seen a few instances where the process hangs during it’s regular updates. To prevent various nasty side-effects I’ve built in protections to prevent the process from running more than one copy of itself at a time. When it hangs it triggers these checks and prevents it from running again. I’m continuing to investigate.

- In other Picasa related news, we have a new contributor to the project! He is actively working on several Picasa improvements including a resolution to the ‘unknown user’ or ‘no public photos found’ error that some of you are experiencing. He is also working on… wait for it… private albums!

- I’m STILL trying to get my hands on a D-Link frame. I have, so far, been unsuccessful at winning them on eBay but I do bid on all that come up. I need one of these frames to troubleshoot the ‘big red X’ issue that most (all?) of you that have D-link frames have. Soooo….. if any of you have a spare D-Link frame they would lend to effort I’ll be eternally grateful and will be sure to immortalize you in the code comments.

Thanks for your patience, and support!

T.

Finally! I tracked down the issue that prevented the Picasa grabber from running on a schedule. It was something silly and basic that took my far too long to figure out.

The non-propeller heads in the audience can tune-out now, what follows is a load of geek-speak.

The problem was this; when I ran the Picasa grabber from the command line it worked just fine. However, when it ran via CRON it appeared to not run at all. It didn’t fail with an error message, no messages in the logs, nor did it generate any console message of any kind, it just didn’t do anything. It was very frustrating.

The basic problem was that the PATH statement in CRONTAB did not match the PATH statement of my interactive shell. However, the way in which it failed was not detected by any of my monitors. Since the durn thing didn’t even start none of the error checking/reporting code I have in the app. had any opportunity to catch/report the failure. Nor did my log scrapers find anything anomalous as there were nothing reported.

I tend to work under the basic Unix tenant of less is more, and specifically that if a process does not detect an error it need not report a ‘normal termination’; simply the absence of an error message is in itself an indication of successful completion. In this scenario this ideal failed completely.

There are two morals to this story, both very basic; “Always check your PATHs” and “Don’t assume (that no response is the same as a positive response).”