Hi Guys,
I have been trying to re`index my collection but it keeps failing.
As far as I can tell there are no missing entries but there are lots of duplicate index numbers now.
Is there a problem and how can I get a fully reindexed database please?
I will give it another go now.
Keith.
I’m not aware of a problem with this. I will investigate to see if I can reproduce the issue.
Can I ask why you need the index numbers to be reindexed? What do you use it for?
It’s just a thing I have that I like to re-index every month or two to keep things in order.
I suffer from OCD and when things are out of order it can trigger it and make me feel odd.
I ran it again and it got further but still failed.
But you do not need to re-index to have things in the correct order.
Is there a misunderstanding maybe?
We have been able to re-index your list just now, it was a connection hickup and it just went through. Still what Alwin asked does stand if you can let us know?
There is no reason apart from the fact that I LIKE to have the index numbers running from 1 upwards to the end. If I add or delete a lot of albums this goes out the window. This is why I re-index every couple of months.
I wonder why then, if it is not an important issue, why is it a function of the system anyway.
There is probably a logical reason for it but I must be too dumb to see it…lol.
The index field is one of those fields from… well version 1 of the desktop software.
This is how the index field works when all settings are default:
People use the Index numbers for stuff like putting stickers with a number on their CDs (to easily locate them in their CD room). Therefor, each Index number is only used Once.
When a number is deleted, the next added CD will still increment on the last added CD.
If you have #s 1,2,3,4,5,6,7,8,9,10
You delete #4
The next CD you add will automatically be #11. #4 will not return.
That way the stickers you put on the albums will stay correct. That is what the index field was originally for (and some users still use it for that of course!). And for that purpose, using re-indexing would be very dangerous (and not useful).
If you merely are looking for a way to sort by order of entry, using the sort option to sort by “date/time added” is the way to go.
If you want to know how many albums you have, the totals/statistics is the way to go.
Of course there are users that use it like “I just like the numbers to run from 1 to 100 etc.”, and for those the re-assign index fields has been introduced. But I’m just saying that there might be a point to reconsider using the index field at all (it would also save you the “work” of using the option, and the head ache if something would go wrong with it).
That said you are free to use it, and since the feature is there, it should of course work.
We have at some point also considered to introduce “row numbers” for each row so you never have to bother with index numbers, and everything always runs from 1-100 etc.
I hope this information helps!
It does thank you.
I appreciate your help.
While I am here I have just tried to create a backup file and the process failed.
I thought I would mention it.
I will try again.
Everyone here in the office went home for the day. I can check your collection for the backup tomorrow. I see you have a lot of albums - do you also have a lot of custom covers? It might be hitting some limit on our side if there’s a lot of custom images - which also shouldn’t happen since the feature is there, but, just saying it could be that 
Will get back to you tomorrow.
I would leave it for now - please also know that our servers are also constantly backed up so if anything does actually go wrong, we have ways to retrieve your data. (just to calm you for the next 24 hours
Thank you.
I look forward to hearing from you.
K.
Backup worked this time around when I tried it. The problem seems to be caused by the 1.8gb of custom images that are in there. The server has a bit of trouble (sometimes) zipping those in. We are aware of this, and it is on our “to check” list to find out if we can make this better.
Anyway, worked this time!
Thank you.
I was wondering, if I delete all the rear covers for the database entries with the format “Files” whether that would help. I don’t need rear covers for those entries.
However, when I do delete them they alll come back when I resync from my iPad and iPhone devices. I think it’s because of the way the CLZ cloud is set up with the Discogs system but I don’t know.
Removal of back covers do not sync correctly through CLZ Cloud. This is a known issue, and a big project for us to work on. It is on the to-do list.
I’m not sure it will fix the issue for the backups for you, it is likely very very high res covers in your collection - but also just something we should address and fix - not something you have to work on fixing
In any case, please do know that we make backups ourselves, of all collection, all the time, so if anything goes wrong, we can help you restore a version, always.
Hi AJ,
I thought I would try another backup to see if it worked but it didn’t.
I understand that it is probably (certainly) caused by the high res covers in the collection and I was wondering if there is anyway of me finding out which entries we are talking about here. If I can get that info I can get to work replacing them with lower res versions.
Any info you can give me would be appreciated.
Also, regarding the reindexing issue. If I were to run that now do you think it would work or should I just leave it as is for now?
Many thanks. I love the CLZ software and have recommended it to a lot of my fellow record, film and book collectors.
Regards,
Keith.