<br><br><div class="gmail_quote">On Fri, Jan 20, 2012 at 10:59 PM, Jean-Yves Avenard <span dir="ltr"><<a href="mailto:jyavenard@gmail.com">jyavenard@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Saturday, 21 January 2012, Gordon McCrae <<a href="mailto:gordon.mccrae@gmail.com" target="_blank">gordon.mccrae@gmail.com</a>> wrote:<br><br><br>> It is in fact "looked at" again (at least in my 0.24.1 system). You get a message stating that it's found an entry with the same hash, but different name and updates the database entry to reflect the new file name.<br>
><br>> There's commentary in the Wiki that states "The location of any video content will be updated automatically based off a matching hash, with no loss of metadata, next time a Scan For Changes is triggered from the Watch Videos menu."<br>
><br>> What also happens though is that it also seems to flip-flop between the two names (assuming there's tow duplicate entries) each time you rescan. Raymond Wagner produced a script to remove duplicates blindly from the database so that there was only 1 unique entry.<br>
><br><br></div>None of which explain why if the same file is present twice, it is only showed once.<br><br></blockquote><div><br></div><div>This is exactly what it means. During the scan, if a new file is found with the same hash as an existing file, the record is unhooked from the old filename and hooked to the new filename. When there are > 1 files with the same hash, only one record/displayed item will ever exist. This is a known limitation/sacrifice to allow the renaming and moving of files without losing the metadata (which was a long-standing feature request when I implemented it-- this is the cost of such functionality).</div>
<div><br></div><div>Robert</div></div>