Bug RM 12 – Ghost Media Tag when using Drag-n-Drop – Forums

#1 · 2026-10-19, 8:51 pm

Quote from kevync on 2026-10-19, 8:51 pm
Bug RM 12 - Ghost Media Tag when using Drag-n-Drop

I have opened a ticket with support and have thread on community board

https://community.rootsmagic.com/t/not-expected-results-media-with-multiple-tags/16408

When a couple or family share a headStone for example I simply dragNdrop the media / headstone to each persons burial fact. The issue however with RM12 is not limited to burial facts.
The issue had a ghost Tag in addtion to the correct one. File tools does not remove the ghost and you can not delete it. The MediaID = 0 for the ghosts.

I have rule out reasons such as Media file location (Local or OneDrive) does not matter. Database is local NOT onedrive or cloud. I have done this same process for over 4 years without any issues. Probably over 1000 times.
short video demonstrating the issue.
https://1drv.ms/v/c/205d5e47209f0511/IQCHb-kRMTeYQ7vvd5Ht5Sn_AavHafPobnzy8Sdlqac5BNg?e=dc6t4S

My original plus two test copies databases (Completely new small tree imports from Family Search to create a quick small tree) all produced same result

More info below -- I am looking for feedback of anyone that can produce same results and more importantly if you follow same step YOU DO NOT produce "GHOSTS".

Thanks Kevin

--------------------------------------------------------------

Bug Report: RM12 “Ghost” Media Entries on Multi-Tagged Items

Issue: When attaching an existing media file (such as a headstone or document) to multiple people or facts using the drag-and-drop method, RootsMagic 12 displays a duplicate “ghost” row in the media edit grid with missing file info.

Scope & Reproducibility:

100% Reproducible: This occurs consistently every single time in extensive testing across dozens of cases in production databases as well as fresh test databases.

Version Specific: This behavior is exclusive to RM 12.x versions and does not occur in RM 11 or earlier versions.

Method Specific: It is triggered strictly by drag-and-drop workflows; traditional non-drag-and-drop linking methods do not produce this issue.

What the Database Shows:

Direct inspection of the database proves the actual media files are not duplicated.

However, whenever media is tagged to more than one record via drag-and-drop, the program incorrectly creates an extra, malformed link entry with a MediaID of zero (MediaID = 0).

Needed Fix: The software needs a patch to stop creating these zero-value link entries during multi-tagging, and a defensive UI check to ensure blank rows are never rendered on screen.

image1181×806 167 KB

Bug RM 12 - Ghost Media Tag when using Drag-n-Drop

I have opened a ticket with support and have thread on community board

https://community.rootsmagic.com/t/not-expected-results-media-with-multiple-tags/16408

When a couple or family share a headStone for example I simply dragNdrop the media / headstone to each persons burial fact. The issue however with RM12 is not limited to burial facts.
The issue had a ghost Tag in addtion to the correct one. File tools does not remove the ghost and you can not delete it. The MediaID = 0 for the ghosts.

I have rule out reasons such as Media file location (Local or OneDrive) does not matter. Database is local NOT onedrive or cloud. I have done this same process for over 4 years without any issues. Probably over 1000 times.
short video demonstrating the issue.
https://1drv.ms/v/c/205d5e47209f0511/IQCHb-kRMTeYQ7vvd5Ht5Sn_AavHafPobnzy8Sdlqac5BNg?e=dc6t4S

My original plus two test copies databases (Completely new small tree imports from Family Search to create a quick small tree) all produced same result

More info below -- I am looking for feedback of anyone that can produce same results and more importantly if you follow same step YOU DO NOT produce "GHOSTS".

Thanks Kevin

--------------------------------------------------------------

Bug Report: RM12 “Ghost” Media Entries on Multi-Tagged Items

Issue: When attaching an existing media file (such as a headstone or document) to multiple people or facts using the drag-and-drop method, RootsMagic 12 displays a duplicate “ghost” row in the media edit grid with missing file info.

Scope & Reproducibility:

100% Reproducible: This occurs consistently every single time in extensive testing across dozens of cases in production databases as well as fresh test databases.
Version Specific: This behavior is exclusive to RM 12.x versions and does not occur in RM 11 or earlier versions.
Method Specific: It is triggered strictly by drag-and-drop workflows; traditional non-drag-and-drop linking methods do not produce this issue.

What the Database Shows:

Direct inspection of the database proves the actual media files are not duplicated.
However, whenever media is tagged to more than one record via drag-and-drop, the program incorrectly creates an extra, malformed link entry with a MediaID of zero (MediaID = 0).

Needed Fix: The software needs a patch to stop creating these zero-value link entries during multi-tagging, and a defensive UI check to ensure blank rows are never rendered on screen.

Uploaded files:

#2 · 2026-10-20, 12:56 pm

RM team confirmed its a bug and reported it to development

#3 · 2026-10-20, 1:32 pm

Nice catch! I suspect that a fix will be out quickly due to the nature of this issue but it's not clear that it will be easy to correct the MediaLinkTable problems since, at least for me, the db contained a mix of duplicate entries and corrupted single entries.

The bug can be identified with:

Select * from MediaLinkTable where MediaID=0;

Any resulting table rows are affected. It would seem that a Delete action is appropriate when the prior table row contains the same OwnerType and OwnerID with a valid MediaID, whereas an Update action is appropriate if the adjacent table rows have different OwnerType and OwnerID pairs.

[edit] - after more testing, it seems that attempting to delete the ghost image from within the RM UI by clicking on the Media icon associated with the Fact and then clicking on the trash can icon from the left pane of the Media slide-in window, results in the valid MediaLinkTable row being deleted and leaving the second MediaLinkTable row with MediaID=0. So, as long as the user hasn't tried to fix the problem from with the RM UI, the table can be cleaned up with simple delete statements where MediaID=0.

#4 · 2026-10-20, 1:43 pm

Thanks
I made have been part to blame for adding confusion about the issue initially -- I called it out hoping others might identify conditions & scenarios when/where it occurred and did not occur. It seem to occur 100% of the time.

yes a simple DELETE WHEN COND fix could be done.
Not sure if they will that to the Cleanup PHANTOM routine. I understand part of the logic of not fixing some phantoms behind but seems RM is very NON aggressive to a fault at times. I am going to wait to see if the tools removes them when the publish fix -- I will let you know -- pretty sure they will do that.

Even if MEDIAID = 0 -- one would think they should NEVER be displayed (but of course it might have been quite sometime before I discovered them)