Error loading speccy snapshot from other computer

[bmtphoenix]

When attempting to load a snapshot from another computer, I get the message "Error loading data: Incorrect Speccy data file", and the snapshot does not load.

 

Both computers are running version 1.06.191. The snapshot is from a 32-bit OS (XP, SP3), while the one trying to read it is running a 64-bit OS (Windows 7 Ultimate).

[redhawk]

snapshot??

 

Richard S.

[Nergal]

snapshot??

 

Richard S.

 

*.speccy file achieved by file>save snapshot

[bmtphoenix]

That would be it, yep. I had hoped to start gathering snapshots of the computers that I built, but that doesn't seem to work very well.

[Nergal]

Hmm I don't have this issue on a 32bit windows 7 to 32 bit XP

 

Sadly I don't have a 64 bit pc to test the bit change

[Codeplayer]

I have taken 30 snapshots of Win XP Pro x86 computers, having different hardware configurations with version 1.04 sth. And read them with My W7 x64. Everything works for me perfectly. I also have saved .txt snapshots and created Macros for making summaries of Speccy databases. No problems there either.

[k22]

I get this same error "Error loading data: Incorrect Speccy data file" after File | Load Snapshot...

It does not matter whether I attempt the Load Snapshot on the same or a different PC to the one where the snapshot was created.

It happens for many but not all of the PCs I have created snapshots on. Both XP and Vista.

Importantly, whenever the snapshot is bad, so too is the equivalent .txt created at the same time using File | Save as Text file... The fault is consistent - on every occasion I have had the fault it has been that it stopped short at a few lines into the Hard Drives section. Always seems to be truncating at the end of the Serial Number line; however in one case I noticed, where there were 3 internal HDD in the pc, it listed the first and second HDDs fully, and truncated at the end of the Serial Number line for the third HDD. Truncations have all been, as far as I have noticed, at the end of Serial Number lines for WDC disks - maybe Speccy doesn't like something about WDC?

My conclusion is that the output from Save Snapshot and Save as Text file are bad.

Note that Save as XML and Publish Snapshot work properly even when Save Snapshot and Save as Text file do not.

I'm using portable Speccy freshly downloaded from the Piriform website.

 

Exhibits

good: http://speccy.piriform.com/results/x2WGLM9BdetYv7x7Oquk48F

bad.txt attached

bad.speccy - it wouldn't let me attach this, plain nor zipped

good.xps - I was gonna add this, but I couldn't work out how to remove the identifying info

 

bad2.txt this is from a different computer, with 3 HDD, it stopped after a few lines into the third HDD listed.

 

Thanks

bad.txt

bad2.txt

[Nergal]

I feel as though you didn't really read the thread. Many people have reported success in the .speccy file (save snapshot), so most likly "the output from Save Snapshot and Save as Text file are bad" is not a true statement. Also you posted two .txt files, perhaps if you posted a .speccy file and one of us tried to load it we'd (or better yet the developers would) be able to tell what is occuring.

[k22]

1. I did say I tried to attach a speccy file and it wouldn't let me. So I will happily do that if someone can tell me how. After I choose the .speccy file using Browse... and then click on Attach This File, it says "Error You aren't permitted to upload this kind of file". There is no hint of why not, how I might gain permission, or any other alternatives.

 

2. I did say I didn't have the problem on all computers, only some. Ergo I do know how to do it and I do know the difference between bad output and good output. I did provide a URL and a .txt file for the same PC. A quick comparison of them will show (prove) that the .txt file is wrong. It is quite clear and certain the statement <so most likly "the output from Save Snapshot and Save as Text file are bad" is not a true statement> is false. In other words, the output from Save Snapshot and Save as Text file are bad, without doubt, for those computers where the problem exists.

 

3. I went to a lot of trouble to research and post extensive details. I am now really upset (can you tell) that Nergal has dismissed my input with little consideration. My aim was to help improve a fine product. Such responses will not help that aim. The only appropriate response when someone says there is a fault is to attempt to identify and resolve, not to dismiss.

 

Thanks

[hazelnut]

k22 I think it just boils down to your choice of wording.

 

'Save as txt file is bad' only applies to your pc, it works for others. That is what Nergal was trying to point out.

 

So now we need to find out why, if we can, that you have the problem.

 

Can you upload the speccy file to somewhere like mediafire and post the link to it here so the devs could take a look?

[Nergal]

Thank you hazelnut, yes that was what i was ineloquently saying

[Olav the Viking]

Speccy Forum 20Nov2010.txt - 20Nov2010 18:09

 

I have reported a similiar problem about the hard drive data stopping at the last (in my case 2nd) hard drive. See forum post My link

 

I then started to do some more troubleshooting/analysis . . .

 

With regards to using Speccy to view files from another PC, or earlier saved snapshots from the same PC, it appears that data from other PCs can be loaded and displayed with version 1.07.205 or 1.06.191 OK. I have found out, however, that 4 different releases of Speccy I tested (1.07.205, 1.06.191, 1.05.183, and 1.02.156) were NOT able to load ANY Speccy snapshot created by 1.07.205 or 1.06.191 from PCs that had more than one hard drive AND could not successfully save their complete data in text format (.txt). I know that sounds confusing, but I created a .Speccy snapshot on a Dell 2400 system with 2 hard drives and was able to load its snapshot OK. The same Dell 2400's text snapshot was complete; it showed both hard drive data and all subsequent data. The .Speccy snapshots created by 1.07.205 or 1.06.191 on both a Dell 4600 with 2 hard drives and a Home-Built P4 560J Intel Mobo PC that has 3 hard drives and a IDE ZIP were unreadable by Speccy, giving the error message:

 

"Error loading data: Incorrect Speccy data file"

 

With the Dell 4700, the text snapshot data was truncated in the middle of reporting the second hard drive's data:

 

WDC WD800BB-75CAA0

Manufacturer Western Digital

Form Factor GB/2.5-inch

Serial Number WD-WMA8E8746485

[NO MORE TEXT DATA REPORTED]

 

With the Home-Built P4 560J Intel Mobo PC, the text snapshot data was truncated in the middle of reporting the first hard drive, an IDE ZIP-100:

 

Hard Drives

IOMEGA ZIP 100

Manufacturer Unknown manufacturer

Serial Number

[NO MORE TEXT DATA REPORTED]

 

I don't know if this is related to the problem, but both the Dell 4600 and the Home-Built have multiple hard drives and dual monitors; the Dell 2400 that gave good text snapshots has 2 hard drives and a single monitor.

 

Another funny thing was seen in the first text snapshot that I did with 1.06.191 on the Home-Built PC, but not on the second snapshot with 1.06.191. The text snapshot (only) said the PC had 4 used memory slots but then continued to show only 3 ram modules:

 

RAM

Memory slots

Total memory slots 4

Used memory slots 4

Free memory slots 0

Memory

Type DDR2

Size 3072 MBytes

Channels # Dual

DRAM Frequency 280.9 MHz

CAS# Latency (CL) 4 clocks

RAS# to CAS# Delay (tRCD) 4 clocks

RAS# Precharge (tRP) 4 clocks

Cycle Time (tRAS) 12 clocks

SPD

Number Of SPD Modules 3

 

Note: There was no restart done between these two snapshots.

 

One feature of Speccy that really helped out while doing this troubleshooting:

 

THANK YOU Speccy programmers for providing the label at the top of the snapshot display window giving the file name of a loaded snapshot and the label at the bottom of a saved snapshot giving the current Speccy revision level and the label (Snapshot created with x.xx.xxx). It would be nice if this same useful information could also be included in the saved snapshot text files.

 

I tried to upload the .Speccy file, but got this error message:

Error You aren't permitted to upload this kind of file

 

Found a work-around - see post by me that follows below . . .

DELL4600 Speccy 20Nov2010 1715 1.07.205.txt

2005P4XP 20Nov2010 1548 1.06.191.txt

2005P4XP 20Nov2010 1608 1.06.191.txt

2005P4XP 20Nov2010 1552 1.05.183.txt

[k22]

Can you upload the speccy file to somewhere like mediafire and post the link to it here so the devs could take a look?

 

OK, here

http://www.mediafire.com/?4owy0q85e95t1e6

 

I redid it with Speccy 107, getting the same result as before with 106.

See the Read Me in the zip file.

[Olav the Viking]

I attempted to upload both the unreadable and readable .Speccy files . . .

but the upload was unsuccessful if I use the .Speccy file type:

 

I renamed the xxxxxx.Speccy files xxxxxx.doc.

 

Rename them back to xxxxxx.Speccy after downloading them for testing . . .

DELL4600 20Nov2010 1715 1.07.205.doc

2005P4XP 20Nov2010 1544 1.02.156.doc

2005P4XP 20Nov2010 1548 1.06.191.doc

2005P4XP 20Nov2010 1552 1.05.183.doc

2005P4XP 20Nov2010 1608 1.06.191.doc

[Nergal]

Thank you both (Olav and k22) the developers should be able to look at these files to assertain the cause of the "bad speccy output" Just to clear up any further questions, will these speccy files also not load on the speccy the produced them?

[k22]

Thank you both (Olav and k22) the developers should be able to look at these files to assertain the cause of the "bad speccy output" Just to clear up any further questions, will these speccy files also not load on the speccy the produced them?

 

That's right, none of the bad speccy files will load anywhere, not even the PC that made them, whether before or after restarting speccy. I recommend the devs commence by looking at the "matching" bad .txt files - basically they look correct as far as they go, but they all stop short at a hard disk line "serial number", not always the first hard disk reported on. Note that the txt files are bad in sync with the speccy files - on a given pc either both are bad or both are good. It is interesting that although the speccy and .txt files are bad, the .xml and Print... appear to be ok. My zip file (earlier post) contains matching bad speccy, txt and matching good xml; you gotta take my word for it that the matching Print was ok.