Frequently Asked Questions
Here are some questions we were asked
- Q1: How can I update the database? Are IMDb diff files supported?
-
A1: Diff files are not supported. If you want an updated database,
delete the old one, download new IMDb list files and convert them to the jmdb database again.
We'll maybe add a function to update the old *.list files, but we can't directly update the database tables with the changes supplied in the diff files (technically impossible!), so you still need to do the conversion from the beginning. - Q2: Where can I get the IMDb text files?
- A2: You didn't read the readme file, did you? Visit http://us.imdb.com/interfaces. On OS/2 you can look into the WPS Folder "Java Movie Database\Additional Links" where you can find "IMDb Interfaces".
- Q3: How long does it take to import/convert the files?
- A3: It takes about 2 hours to import/convert them on an Athlon 1 GHz system with the index files (for faster search operations). The duration depends on the components of your system and the size of the IMDb files. Also note that the actors and actresses may take ages to get converted.
- Q4: I just started the database conversion, but now I want to pause it because I need my computer for <whatever>. Is this possible?
- A4: Yes! JMDB supports resuming a previously interrupted conversion from the beginning of the last database table that was converted. So you can simply click on the cancel button and resume the conversion later.
- Q5: The conversion/import crashed. Do I have to import/convert all the files again?
- A5: No. JMDB can resume the conversion. It will start at the table that was in work while the crash happened. So the database converter doesn't convert all the data again.
- Q6: There is no progress visible while the import/convert process is running, so what can I do?
-
A6: Maybe the Java Runtime crashed. We haven't got a clue why
this happens (but newer Java releases seem to have fixed this problem).
Start the program using "start*debug" (OS/2, Windows, Linux),
so you can switch to the command window where you can see what happens.
Note that you have to disable the "automatic close window on program
exit" to see the JVM hexdump after a crash.
Also note that the actors and actresses may take extremely long to get converted, so maybe it's just not finished - your hdd LED should tell you more (Hint: also look at Question 9). - Q7: Why can't I select the Windows Style (Look and Feel) on OS/2?
-
A7: You can select it, but nothing happens. ;)
I would call it a bug in the Java Runtime Env. (1.3, 1.31) but GoldenCode also can't use it. It seems to be some kind of copyright problem.
You can patch the Runtime (1.3/1.31), but make sure you make a backup of the file that has to be patched! There is a patch available from Christoph Bratschi (Java Swing Windows Look and Feel unter OS/2 nutzen) on his homepage: http://www.bratschi.net.
Notes:- The buttons (close, hide, max.) are not correctly displayed, but the rest is working!
- I've not checked if it can also be used with GoldenCode Java 1.4x
- Q8: How can I send a bug report?
-
A8: Send us a mail with the following information:
- JMDB version
- Java Runtime Type & Version
- MySQL or PostgreSQL Version
- Operating System used for Java Runtime + JMDB and for the MySQL/PostgreSQL database
- jmdb.log (you can find this file in the JMDB directory - this includes important information for us!)
- console output if it seems there's interesting output (start "jmdbdebug" to see the console while JMDB is running)
- Q9: The convert process is extremly slow. What can I do?
-
A9: We've made some changes to the start batch files to give the
Java Runtime Environment more RAM (300MB) at the program start!
This really helps to boost the performance (up to ~300%).
OS/2 and eCS users (maybe also applies to Linux) can use a Journaling
File System like JFS or the 32Bit HPFS386 for the
partition the database data is located! Both file systems support bigger
cache sizes in OS/2 & eCS compared to the standard HPFS (16-Bit)
and also boost the performance.
Another/additional way is reading the IMDb files from one harddrive, which is also used be the system/swap, and write to another harddrive (not only partition) which holds the database data. - Q10: How can I update the database drivers for MySQL?
-
A10: Just follow the following steps...
- download the latest stable Connector/J (currently v3.1.7; version number may change) from here
- extract the file mysql-connector-java-3.1.7-bin.jar from the subdirectory mysql-connector-java-3.1.7
- copy the file mysql-connector-java-3.1.7-bin.jar to your local JMDB directory
- replace the old mysql-connector-3.0.9-bin.jar with the new one (mysql-connector-java-3.1.7-bin.jar, or which version you use) in the JMDB startscript (start*.* file)
- now you should be able to use MySQL 4.1.x with the latest stable Connector/J driver
- Q11: I can't connect to the MySQL (or other) database?
-
A11: There are more than one possible reasons for this:
- The database has not yet been started.
- The JDBC driver is not working any longer (see Q10)
- Your login/password combination is not correct.
Some database installations use "root" as user and password, but some don't so you may also try "root" as user without a password. For other choices read the manual of you database. - The database URI may be wrong. Sometimes even the "localhost" (the address of your machine) doesn't work, so you may want to try "127.0.0.1" instead of "localhost".
- a lot of other possible reasons
- Q12: When executing the program with the "start*debug" script I see the message "java.lang.OutOfMemoryError" while processing the movies. The import doesn't continue after that error, so what can I do?
-
A12: The IMDb updated the movies.list with a lot of new data
between 2005-11-11 and 2006-02-03 (3 month).
- increase of compressed movie file between 2005-11-11 and 2006-02-03 (5.1MB to 8.2MB): ~62%
- increase of movies between 2005-11-11 and 2006-02-03 (3 month) from 474.272 to 745.259: ~56%
- increase of movies between 2006-02-03 and 2006-10-13 (8 month) from 745.259 to 863.062: ~13%
- JMDB needs round about 1.62 MB for 10.000 movies in memory. This is only a rough calculation as it's only a value I got while I looked how many entries I could process with 110MB (Error message at 680.000 entries: 110MB/680.000*10.000 = 1.62MB)!
- Update - 2006-11-08: The new calculation uses 1.71 MB for 10.000 movies based on the last month data growth (longer movie titles because of the series episodes need more space as just the title).
Solution: The Java -Xmx parameter (set maximum Java heap size) has to be changed. The parameter can be found in all start* scripts to start JMDB. JMDB v1.30 had it set to "-Xmx96M" (allow 96MB for the Java Runtime to be used - this worked for 3 years) but with the huge data increase this needs to be changed to -Xmx300M (300MB) which should be enough until the movies.list will get to nearly 1.650.000 entries! This is default for the final release of JMDB v1.35!
Note: The parameter is case sensitive! - Q13: My language is not recognized when I start JMDB. How can I force Java to use the correct language file?
-
A13: You can force Java to use the correct language file by using
command line parameters which set the language and region code.
Here two examples. The first one for Dutch (nl) and the second for Serbian (sr).- -Duser.language=nl -Duser.region=NL
- -Duser.language=sr -Duser.region=SR
Normally it shouldn't be necessary to specify the region, but it doesn't harm to do so! Note: The parameter is case sensitive! - Q14: Creating the two indexes on the movies2actors table with MySQL using the InnoDB backend takes a very long time (e.g. 30+ minutes or more). What can I do to speed things up?
-
A14: You might want to check the following possibilities...
- First you might want to take a look at Question 9 and 12, which cover the memory requirements for new IMDb data!
- Then you should check and maybe change your my.ini, my.cfg,... MySQL innodb_buffer_pool_size setting to 180 MB or more:
innodb_buffer_pool_size=180M - If the above doesn't help you might have a slow (old) computer. Buy a faster one.
On my Intel Core2Duo E6600 with 3 GB RAM on Windows XP x64 using MySQL 5.0.37 it took 7 min 28 sec for the first index and 9 min 12 sec for the second index. Don't ask me why eCS is that much faster, maybe the integrated memory controller does help the Athlon64 here. - Q15: Can I import the IMDb files with JMDB using command line options?
-
A15: Yes, since JMDB v1.35 (Beta from Feb. 2006) you
can import files using command line parameters. It's a little bit
of a hack and you will see an error message when the application
closes itself. Beside that it's working.
There are some notes before we get to the parameters:- All warning messages (DROP DATABASE,...) will be skipped so use it with extreme caution (we are not responsible for any data loss!!!).
- If the last import has been canceled the new import will automatically resume the last import (it will not ask you!).
Use the following command to start the import automatically:- Import with creating indexes on the movies2actors table: IMPORTWITHINDEX
- Import without creating indexes on the movies2actors table: IMPORTWITHOUTINDEX
Just add the parameter after "jmdb.base.JMDBMain" in your JMDB start script you use to call the application.
Example:
[...path java-runtime parameters for java and other stuff...] jmdb.base.JMDBMain ImportWithIndex
Note: The import parameter is case in-sensitive!
