-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mjb.listing.clear.UNKNOWN should clear both "UNKNOWN" and "UNDEFINED" #1787
Comments
Comment #1 originally posted by Omertron on 2011-01-16T19:35:49.000Z: This issue was closed by revision r2063. |
Comment #2 originally posted by Omertron on 2011-01-18T17:30:42.000Z: Oan't index with this release (r2063): "GC overhead limit exceeded" ! {18:12:03 Thread-9} Finished: ça commence aujourd'hui (1999) -- Bertrand Tavernier - Philippe Torreton, Maria Pitarresi, Nadia Kaci I have to reverse to r2009 to make it work. Thanks for your help! |
Comment #3 originally posted by Omertron on 2011-01-18T17:32:40.000Z: ...sorry - I meant 6Gb machine... |
Comment #4 originally posted by Omertron on 2011-01-18T22:01:31.000Z: This issue was updated by revision r2076. Added more memory GC points during indexing |
Comment #5 originally posted by Omertron on 2011-01-19T16:43:20.000Z: Sorry, no change with r2076: {17:29:46 Thread-11} Finished: Zelig - Woody Allen (2266/2268) Please find attached a capture of the amount of memory used by java just after the error message appeared. |
Comment #6 originally posted by Omertron on 2011-01-19T16:59:48.000Z: Results with r2009: {17:50:05 Thread-10} Finished: Zelig - Woody Allen (2266/2268) |
Comment #7 originally posted by Omertron on 2011-01-22T20:21:53.000Z: Could anyone help me with this issue. I can't upgrade further than r2009! |
Comment #8 originally posted by Omertron on 2011-01-23T08:03:41.000Z: I thought I'd mentioned to reduce the Xms to a smaller value such as Xms256m. |
Comment #9 originally posted by Omertron on 2011-01-23T17:06:57.000Z: I tried with Xms256m and r2076 (java -Xms256m -Xmx5500m -XX:-UseGCOverheadLimit -classpath .;resources;lib/* com.moviejukebox.MovieJukebox %*) and I had to cancel the process after waiting more than 20mns for HTML indexing to complete (with r2009 it takes approximately 1mn). Thanks for your help! |
Comment #10 originally posted by Omertron on 2011-01-23T18:27:01.000Z: There are a lot of indexes there. Either that or increase the minimum cast/director indexes to reduce the number of indexes generated and the memory usage |
Comment #11 originally posted by Omertron on 2011-01-25T15:10:35.000Z: FYI with the new AllocineAPI plugin, the number of actors, firectors, etc... retrieve have increased enormously. Perhaps a side effect .... |
Comment #12 originally posted by Omertron on 2011-01-25T15:18:17.000Z: We need to find a better way to index the movies than we currently do. Perhaps we should look at indexing as videos are added, then indexing would just be about writing the indexes to disk. |
Comment #13 originally posted by Omertron on 2011-01-26T18:05:49.000Z: I think the main problem is that xml files are generated with all actors available for one movie, although I have set actors.max=6 in skins.properties. For example, here's what I find in the xml for the movie "2 days in Paris": Adam Goldberg Julie Delpy Daniel Brühl Marie Pillet Albert Delpy Aleksia Landeau Adan Jodorowsky Alexandre Nahon Charlotte Maury Sentier Vanessa Seward De Thibault Lussy Chick Ortega Patrick Chupin Antar Boudache Ludovic Berthillot Hubert Toint Sandra Berrebi Arnaud Beunaiche Claude Harold Benjamin Baroche Jean-Baptiste Puech Clément Rouault Nanou BenahmouI understand that max.actors is used to display THAT number of actors in the detail page (see attachment). But I think it would be useful if we could limit the number of actors written to the xml files. It would reduce the number of indexes to generate for casts. For example: I tried your suggestion to run YAMJ with -i, but it didn't change a thing. All xml were regenerated with too many actors... |
Comment #14 originally posted by Omertron on 2011-01-27T12:59:32.000Z: I think it will better to optimize index creation that adding another property... What's do you think Stuart ? |
Comment #15 originally posted by Omertron on 2011-01-27T13:44:12.000Z: Yes, the indexing is very inefficient at the moment (lots of wasted memory) and needs to be optimised |
Comment #16 originally posted by Omertron on 2011-01-27T13:45:10.000Z: Besides, chopping off the list of actors for each movie will give incorrect results when you add all the actors up to decided where to cut the list. |
Comment #17 originally posted by Omertron on 2011-01-27T17:57:03.000Z: I agree with you The best solution is to improve the indexing process. When do you think it could be done, Stuart? |
Comment #18 originally posted by Omertron on 2011-01-27T18:04:37.000Z: If I knew how to do it, it would be done already :) |
Comment #19 originally posted by Omertron on 2011-01-27T18:12:06.000Z: In that case, can't you implement the solution I suggest (xml.max.actors) until you find how to do it? I would be grateful! |
Comment #20 originally posted by Omertron on 2011-01-30T18:59:38.000Z: You can close this one. I'll open a new issue. |
Original issue 1788 created by Omertron on 2011-01-16T15:33:12.000Z:
Hi,
I find lots of UNDEFINED subtitles (see capture). I would be nice if mjb.listing.clear.UNKNOWN could clear both UNDEFINED and UNKNOWN subtitles.
Thanks for your help.
The text was updated successfully, but these errors were encountered: