Rightly or wrongly, my working practice is to maintain my Rootsmagic Database as my master database. I upload a tree to Ancestry and maintain it via Treeshare as I go along, when I have updated Rootsmagic. As a matter of course, I tend to completely upload the Rootsmagic database to Ancestry every 3-4 months and replace the existing Ancestry Tree with a new one, in the knowledge that not every change I make to my master database (e.g. Media) is reflected in the Ancestry Tree. This way, I knw the Ancestry Tree is as accurate as can be.
Over the last few days I have tried to upload a new tree to Ancestry (after disconnecting the existing tree from Ancestry and resetting Treeshare etc.). Unfortunately, I have not been able to do so. (Tree Rootsmagic 11.3.1.0 13637 people, 7830 media items with 14756 media links ā Windows 11 Home PC Upload speed 110 mbps)
It appears to upload the media up to 100% then just hangs and eventually have to close using task manager. It creates the tree on the Ancestry website but shows āno peopleā. It is the same database I have uploaded before without issue.
If I omit the media or upload a database with a very small amount if media it works fine.
I have reported to support and sent them a backup if the database with media. They have suggested that non-standard media file names may be the issue.
However, I do NOT have any file names like that in my database! They have been created/renamed by the backup, which I find very odd. I have created a database from the backup and worked through the 91 items highlighted like this and made sure they donāt exist in it. Then dragged and dropped it into a new file (as suggested by support) and tried to upload to Ancestry ā still no go.
Would appreciate any thoughts why not able to upload to Ancestry ā does appear to be an issue with media, perhaps the amount, on the face if it. Thanks.
I have recently had a similar issue but with creating a backup in RM with media (when closing program) as opposed to uploading a tree and I too had to close it via task manager several times. In the end I left it running for a considerable period of time while I did something else and it eventually it saved and closed the program. Donāt know how long you waited but it may be worth waiting longer. Otherwise it may be worth contacting Ancestry, their site seems to have been a bit flaky recently for me.
Iām not a techie but wonder whether there is a cache involved in the upload and, if so, whether the 100% relates to exporting the database to the cache which then needs to upload it to Ancestry. Iām sure some of the boffins here will know the answer.
I suspect what has happened is that you have the same file linked into your database more than one time. RMās Add New Media dialog makes this very easy to do by accident. In my view, thatās either an implementation bug or a design flaw in RM. The Drop New Media dialog does not have the same problem.
In the case of creating a backup file with media, RM bundles all your media into one large media folder instead of maintaining your folder and subfolder structure. In that case, your duplicate media files will be given version numbers such (2) to distinguish the duplicates from each other. Iāve never been quite clear if itās the app such as RM thatās doing the versioning or if itās Windows itself. In any case, the fact that you have a (2) on a file name in an RM backup file is a strong indication that you have the same file linked into RM more than once.
I canāt speak to how TreeShare handles the same situation without first doing extensive testing. I did test with a one person database where the one person had the same file linked twice. The one person database with the twice linked media file did upload just fine. But still, itās still something to think about, especially since the (2) in a file name suggests that you have the same file linked into RM more than one time. By the way, itās fine for the same file to be linked into RM in lots of different places. Itās just that after the first time, you use the existing file rather than adding it again.
I notice that the file name in your screenshot contains 2 periods ā.jpg(2).jpgā. You might want to check to see me that the original files end in ā.jpg.jpgā . If so, this is non standard and something you could fix. You might want to start there to confirm that itās not the cause of the problem.
If that doesnāt fix it, Iād tackle the (2) issue next. if itās true that you donāt have any duplicated media files (ie with a ā(x)ā in the file name), then it seems that the request to send a ābackup with mediaā is introducing a new problem and obscuring your actual issue. You might want to let support know that you need to send them your existing media file structure so that they can accurately reproduce the error. (ie a backup without media plus a copy of your existing media file structure on a cloud drive that you can give them access to ) That could be a bit more work to set up but is the only way for them to reproduce the error, short of fixing all of the duplicate media table entries that Jerry alluded to.
Iāve experienced the same while uploading a new Treeshare file to Ancestry. It hangs just after uploading the media. I sent a copy of the the backup file to RootsMagic support. I also had the experience of successfully uploading the same Treeshare file to Ancestry without the media. I am waiting on a software update to RootsMagic 11 to address this issue. I suspect it is related to the new Ancestry TreeShare API.
Thanks, all those media files created in the backup with (2) I have cleared. Created a new backup and they donāt reappear. Database created from that backup still wonāt upload.
I think there is an intermittent fault with Ancestry with regard to uploading media generally. In the past 2 weeks I have had issues with uploading individual jpgs to Ancestry profiles on my existing database. The jpgs were all certificates created by the (UK) GRO and were dragged and dropped to the gallery page. On several occasions I got the āuploadingā message and then went into a death spiral for maybe 5 or 10 minutes before aborting and trying again. Eventually, after 4, 5 or 6 attempts, I succeeded in uploading the certificates. I just wonder if this happens to a media item at the Ancestry end during upload and then goes into a loop, whereas RM thinks it has uploaded the whole file? Cache?
@MKGT in the meantime have you tried uploading your new media to your Ancestry site one by one until itās resolved? Seems strange that media is not uploaded via TreeShare - it certainly works the other way round.
After suggesting it was my files that were causing the issue, despite uploading the exact same files successfully previously, I have received the following from Support:
"***Thank you for the update. Since this is a known issue, itās expected that the upload may still not be working correctly.
I donāt receive updates directly from the development team. Due to company policy and confidentiality agreements, I am unable to provide a timeline for releases or updates, or specify what will be added or fixed in the program. However, I can confirm that our development team and Ancestry are currently working together to resolve the problem**.* "
After the number of similar posts on the forum it beggars belief that the company havenāt posted this information to the forum and/or included in the news items shown in the program itself. It may have avoided loads of stress and angst. I feel I may have chosen the right path by updating Ancestry and then TreeSharing to RM but that doesnāt help others.
To be honest, bit disappointed with them - obviously knew there was an issue but took them a number of days to finally say so. I guess they are not in the habit of saying there are problems with their program.
Iām a long-time RM user who has purposely avoided the Ancestry features up to now.
Out of curiousity, I sought permission from a friend to access their small tree (about 900 people and just over 550 pieces of media) to test TreeShare since last update.
The tree made it down to the database and the TreeName_media folder contains some .HTML files, but none of the images were downloaded.
At some point during the TreeShare process, the screen progress status does list the media download as an upcoming (3rd) step, but it never reports that step as āin progressā or that any media are downloaded. So, thereās that.
I agree to an extent, but although the number of people reporting here (and perhaps to support) may be low, but it is a pretty fundamental part of the program. There are far more people using treeshare generally (which maybe working Ok) than there are those uploading/downloading a tree which I guess is not a regular event for most people. I guess this is an issue with Ancestry API and was not noticed in testing? As an aside, I have tried uploading via Family Tree Maker and that uploads with the same database/media! Hopefully will be sorted soon.
I just noticed I didnāt put my note on this one. Development is aware of the issue with media and is working on it. There are a few other issues we are working with Ancestry on for resolution.
@MKGT After reading on here for a very long time, I suspect that there are just as many people who upload/ download a file as those who tree share
I may be wrong BUT I think the reason it took a couple of days was because they needed to test your file to see if your problem was related to this or if it was related to another issue that some have had for a while-- that said, you now know they are working on itā¦
Since you were able to upload your tree via FTM, have you tried downloading it with RMā perhaps late at night when traffic on Ancestry MIGHT be lighter..
Also, you MIGHT be able to restore your other file from BACKUP and still be connected to Ancestry-- just make sure your rename your current file before importing the backup-- and suggest you have no other files open at the time you IMPORT the backup, so that it doesnāt combine the BACKUP with another file
The problem with uploading a new tree to Ancestry is that all your Ancestry tree-share āhintsā get reset as if you had never gone through them and accepted or rejected them.
