Issue #1: Single family listings are also created as condo listings, and condo listings are duplicated as single family listings. So many listings are getting created twice, once for each class.

Issue #2: On a new test build only the single family class is available to views. Looking at the content_type_pirets_prop table, the pirets_class_value column does contain values for all of the 4 classes I've enabled in the property classes selection (SF_1, CD_2, MF_3, LA_4).

CommentFileSizeAuthor
#5 Screen shot 2010-06-08 at 12.06.28 PM.png56.47 KBjday
#3 Screen shot 2010-06-08 at 10.46.49 AM.png74.12 KBjday
#3 Screen shot 2010-06-08 at 10.47.16 AM.png59.67 KBjday
Screen shot 2010-06-06 at 9.08.16 PM.png61.92 KBjday

Comments

scott_earnest’s picture

scott_earnest commented

Please also provide a screenshot of your PIRETS Property classes screen at: /admin/settings/pirets/classes for some better troubleshooting.

Garrett Albright’s picture

Garrett Albright commented

As scott said. Are we sure that listings besides single family ones are being downloaded?

jday’s picture

jday commented
StatusFileSize
new Screen shot 2010-06-08 at 10.47.16 AM.png59.67 KB
new Screen shot 2010-06-08 at 10.46.49 AM.png74.12 KB

screenshots

scott_earnest’s picture

scott_earnest commented

@jday - Do your MLS numbers contain letters?

@Garrett - could alphanumeric property classes be causing an issue?

jday’s picture

jday commented
StatusFileSize
new Screen shot 2010-06-08 at 12.06.28 PM.png56.47 KB

MLS numbers are all numbers, screenshot of db attached.

Garrett Albright’s picture

Garrett Albright commented

Sadly, I really have no idea what could be going on here…

Presumably you've already tried flushing and refetching the listings?

jday’s picture

jday commented

Yes, I've tried:
1. 'Resynchronize classes' link on the property classes admin page
2. flush and update listings
3. drop the database and start over ( quite a few times )

My live site is a disaster so I am trying to start from scratch with a development build to see where I went wrong. And I'm running into lots of problems. Initially I was getting the "Unknown column 'pirets_class_value'" and "Fatal error: Call to undefined function content_views_field_views_data()" errors" which seemed to be caused by the version of PHP being used (Ubuntu Hardy). I upgraded my server to Ubuntu Lucid which uses PHP 5.3, and 1GB RAM

That seems to fix those errors, and listings were fetched much quicker than the live site. But now I have this class problem, and after a few days the dev site is just as slow as the live site. I can't even count the times I've dumped the database and started over.

Issues on the live site (when you can get pages to load) include
1. geocode failures, some listings are mapped others are not
2. after updates some listings lose their photos and the only way to get them back is to delete the node and re-fetch
3. cron auto fetching never gets all listings, must manually update

Does PI offer hosting? Can anyone recommend hosting where PIRETS is successfully running?

scott_earnest’s picture

scott_earnest commented

jday-

Below are a couple of links on the pirets.info site that may help out. I am also geocoding the listings and found that I needed to go with the dev versions of the location and gmap modules. After running a PIRETS batch, I did get the listings to geocode, but it did appear that not all the listings were showing up on the map. Looking at the entires in the content_type_pirets_prop table, I was finding that all rows did have a corresponding 'lid', but looking at the location table some entries had the exact same lat/long, so only one marker was showing. I am in the process now of trying to work with clusters of nodes and tackle the problem of multiple locations on the same *exact* location.

More on the gmap view stuff here:
http://pirets.info/node/25

Also, check out the PIRETS compatibility chart. Is your RETS server listed here?
http://pirets.info/docs/compatibility

Not sure on the batch processing. Is anything showing up in watchdog?

Garrett Albright’s picture

Garrett Albright commented

This issue has enticed me to do some playing with PIRETS today, and I noticed some bizarre and disturbing behavior. The "pirets_crc32" and "pirets_class" fields are not created upon installation if PIRETS is enabled at the same time as CCK. The failure seems to be silent. That could be the cause of many of your problems.

I'm going to add a hook_requirements() which checks for these fields and instructs the user to reinstall PIRETS if it can't find them. Until then, jday, could you try this: Do another new install, go to the "Modules" page, and enable the "Content," "Text" and "Number" modules only. Then, once those are enabled, enable PIRETS and its dependencies (or just check the "PIRETS" box and let it enable the dependencies for you). I think you'll have much better luck this way.

jday’s picture

jday commented

@Scott
Thanks for all of your responses, I really appreciate hearing back from other Pirets users. My RETS server is compatible (with the class quirk #1 I mention at the start of this discussion) and I'm using the latest dev versions of cck, location and gmap. I still have a few prop nodes where the marker is in the ocean off the coast of Africa... I'm spending a lot of time in the gmap issue pages.

Watchdog errors include:
• Cron context (default) has been running for more than an 3600 secs and is most likely stuck.
• Failed generating an image from pirets_img/1581928/1581928-2.jpeg using imagecache preset listing-lg.
• 404: Unable to find sites/default/files/pirets_img/1568355/1568355-4.jpeg

@Garrett
I can confirm that enabling pirets at the same time as cck is not good, enabling all required modules first then going back and adding pirets will get those key fields into the pirets_prop table. And I don't know if this is an easy thing or not to add, but I wonder if you can (in all your spare time) write up a way to export/import your useful field selections (similar to views,cck and rules) because the biggest drag when creating new test builds is going through that gigantic list of fields and finding the ones you need over and over.

Anyway, I'm going to change my focus to the issues on my live server and let the dev problems rest. So the big one is that sometimes images get lost, erased, or something after an update. Yesterday I had a listing where all the photos were blank when I knew they were there before. Normally I would just delete the node and re-run the update. However this time I deleted the node through phpMyAdmin instead of through drupal. Now after running the update it does not pull in the missing property. So I'm wondering if there is some other place in the database that is telling the update script that that listing is already in the system...? I suppose I'll have to flush and start over but flushing 3000 properties takes close to 24 hours (is that normal?) and I hope there is some other way. What about deleting the imagecache directories?

I know I have more problems than you can shake a stick at so thanks in advance for your ideas and suggestions.

Garrett Albright’s picture

Garrett Albright commented

Janette;

Being able to export a PIRETS configuration is not a bad idea. I'll look into that if I can find the time.

With regards to your trouble after deleting the node with phpMyAdmin… when using CCK, data for a node tends to get packed away in all sorts of nooks and crannies in the database, so my guess is that you just didn't delete it all.

With regards to flushing properties taking a lot of time, the most time-consuming part of deleting property listings is actually deleting the images attached to it. There's a trick, though; just go to the "Field correlation" page and remove the property images field. The images will quickly be removed. Then flush the listings, and you'll find they'll be deleted much faster. I should probably squirrel away this bit of info on the doc pages somewhere…