Offline Scantool (for X2 models)

[Unreal]

I think having the Mede8er.db use relative paths (like it does now) is better than a single master db, although I could live with one db per device.  If you had a single master, you would also need to devise a way to skip scanning certain folders, like a gigantic FLAC music library, picture libraries, etc. which would otherwise slow down the scan.  Despite all of my involvement in this, I still use my Mede8er a lot more for music and music videos than I do for movies.  In fact, the amount of disk space for my music and music videos collection is probably about the same as my movie collection.

[Skylinc]

Found another bug, although I believe this is a small one. I have a movie called '9', and it's not showing the hash (See attached)

Oops. Accidentally attached the same file twice. The 2 files should've been '9.zip' and 'lmede8er.zip'

[Unreal]

@Lupissimo

I can confirm that using the same two test samples I gave you before, the Mede8er.db created by your scan tool now shows the same results as the Mede8er.  However, for this test, I only used dummy (empty) movie files, so the hash value must be of the movie name, not the movie size like I thought (although apparently you already knew that).

[Lupissimo]

@ skylink :what does the mede8er scan show?? a hash of 1 character should be blank - I think

[Skylinc]

@ skylink :what does the mede8er scan show?? a hash of 1 character should be blank - I think

Mede8er scan attached

[Lupissimo]

@unreal: the hashcode ist the hash of the foldername not the moviefile

[Unreal]

@Skylinc

Perhaps the issue is generating a hash value for a single character?  With that in mind, I renamed it to "9 (2009)" and it generated the hash.  I did not run a Mede8er scan to see what value, if any, it writes for just a single character like "9".

Update: I also tried renaming it just "A" and it had the same problem but "A9" works fine, so the issue is not with the number, but apparently with single character names.

@Lupissimo

Thanks for that clarification

[mognons]

@Lupissimo

I can confirm that using the same two test samples I gave you before, the Mede8er.db created by your scan tool now shows the same results as the Mede8er.  However, for this test, I only used dummy (empty) movie files, so the hash value must be of the movie name, not the movie size like I thought (although apparently you already knew that).

You're wrong: the hash code is a MD5 checksum of the column folder, not a byte per byte computation of the real file. It would be of no use and unbearably slow...
On this subject, the hash for the movie folder "9" would be 45c48cce2e2d7fbdea1afc51c7c6ad26, according to mede8er (and to my scanner too).

Edit: sorry, I see now that Lupissimo was faster than me...  

[Skylinc]

On this subject, the hash for the movie folder "9" would be 45c48cce2e2d7fbdea1afc51c7c6ad26, according to mede8er (and to my scanner too).

I can confirm that my Mede8er also has '45c48cce2e2d7fbdea1afc51c7c6ad26' as the hash for '9'

[Lupissimo]

Mede8er scan attached

Found the error. we did not think of a 1 character name and checked for >1 not >0

[Lupissimo]

Here is the updated scantool and thanks for testing!

[Skylinc]

Hascode, Foldername, Year, Genre, Timestamp all look good. Getting a few discrepancies with the rating though. Attached is the small version of the folder, as well as the 2 databases.

[Unreal]

@Lupissimo

Don't forget that you can run an md5 or sha-1 check sum against the Mede8er created Mede8er.db and the one your scan tool creates to quickly determine if there are any differences between the files (there should be no differences at all).  If the check sums do not match, you know there is a difference somewhere...then it becomes just a matter of time looking over the data to find it.  If you have access to a Unix (or Cygwin) system, you can speed up this process by exporting the data from sqllite to a CSV (comma separated values) text file and run the "diff" command against the two text files to have it spot the differences for you.  I've never used it, but there is a diff for Windows available here...

http://gnuwin32.sourceforge.net/packages/diffutils.htm

Hope that helps.

[Lupissimo]

@unreal: Thank you for the hint!
@skylink: we have tried to find out how sanji calculates the rating value in the mede8er.db
According to Maasbommel (above):
It should be the IMDB figure like this:

We get from IMDB Rating = '81'
so we divide by 2 and take it to the nearest full digit
So '81' will get a rating of '4' in the db

Which cannot be correct as 81 /2 =40.5 which is not equal to 4. So maybe he forgot  / 10

Taking your data there are two non integer values 23.0 and 68.0 which lead to 5 in the mede8er.db, which is obviously wrong independant of the algorithm.
Also others dont follow the "Massbommel" algorithm:
10 Things I Hate About You    xml Rating=  69 mede8er.db = 5    "Maasbommel"=34.5 => 3.45=> 4 (which is "our" value) but NOT 5.
So unless we get the exact algo from sanji we can only guess!
On the other hand this value is ( for me as a user) not so important as long as it is calculated consistantly keeping the relative ranking. But for a programmer the situation is unsatisfactory.

Just saw in your data:
28 Weeks Later xml rating= 71 mede8er.db = 4  which does not agree with the 10 Things I Hate About You calculation.

[Unreal]

@Lupissimo

I'm not familiar with Delphi, so I've included some generic code which should properly convert the rating, including rounding, and it should work regardless of whether the value is stored in the XML file as "6.9" or "69".

x = {value from XML file}

if x < 11 then
   x = x * 10
end
x = x / 2
x = x / 10
y = int(x)
z = y * 100
x = x * 100
z = x - z
if z > 49 then
   y = y + 1
end

y now holds the new value for rating

If the value the Mede8er returns is something other than this value, then they may not be using proper rounding, and may just be taking the first digit after dividing by 2.