T O P I C R E V I E W |
JDommi |
Posted - 11 Nov 2010 : 20:52:37 New update available on http://mitglied.multimania.de/jkdommi/xmm/ CoverManager_2010_11_11.rar
Suggestions welcome!
If time there will soon be a help available... but most should be clear on first sight. |
20 L A T E S T R E P L I E S (Newest First) |
JDommi |
Posted - 19 Nov 2010 : 11:40:44 Okay, I'm convinced ;) I avoid that mostly by adding [Remake] or [The Movie] to the title, so that wouldn't be so essential for me personally. But I think I'm an exception on that behaviour...
|
Prinz |
Posted - 19 Nov 2010 : 11:26:24 quote: Originally posted by JDommi But it's really the worst case szenario you described!
Yes, but it is not as unlikely as one may think. There are Movies are and TV Shows that have the same name, there are remakes of Movies/TV Shows and last but not least especially with simple 1-2 Word Titles is the possibility very high that there are more than 1 Movie/TV Show with the same name. |
JDommi |
Posted - 19 Nov 2010 : 11:14:15 You're right, Prinz. It's a bug in renumbering function - But it's really the worst case szenario you described! Easiest and fastest way (for a fresh database) would be to do no renumbering but to take eliminated IDs for next added movie. I know that this is not the ultimate solution, too... |
Prinz |
Posted - 19 Nov 2010 : 10:09:09 I thought i bit more about this problem and came to the following conclusion:
It is a Bug in the to Functions to renumber the Movie-ID's in XMM and it has to be fix by Ale. The current version can already make Problems in the unlikely but still possible event that 2 or more Entries have the same name and through the renumbering function get the ID of the other same named entire.
The 2 renumbering functions have to rename all Image-Files after a Movie-ID change in 2 steps: 1. Temporally rename all Covers, Backcover and Fanart that are in the Database. For example change the extension form .jpg to .tmp (this step is necessary to avoid renaming conflicts) 2. Now XMM has to go trough all entries and rename to temporarily renamed Covers, Backcovers and Fanart to new current name and then save the new names to the Database Fields.
So my conclusion is that is not a Problem in the Covermanger, it is a Bug in the 2 Renumbering Functions in XMM and that Bug has to be fixed, because without the renaming it can make problems already.
@JDommi I think i understood you already correctly but that way has many downsides and doesn't work always. Some Downsides i already wrote about. http://www.binaryworks.it/forum/topic.asp?TOPIC_ID=6775&whichpage=1 |
JDommi |
Posted - 19 Nov 2010 : 08:38:36 Yes, I have thought that it's because of ID renumbering. The code in my CoverManager uses only the field "Cover" as reference and not the actual movie id. This way you don't have to rename all covers in case of another need for renumbering. The only important thing is to keep cover category ids equal. Using the same basename on all 3 categories would also keep the possibility to remove those fields or change them from text to number of covers inthat category or to a simple boolean column. ( As I already have tried to explain in http://www.binaryworks.it/forum/topic.asp?TOPIC_ID=6775&whichpage=1 - but I think that I've done not a good job on explaining *lol*). It would also offer the possibility to add new categories without changing the database but only using that little piece of code I have posted before on "Number of Covers".
A thing I have forgotten to say about the ID tool in my CM: There is no automatic saving of the database after equalizing. So please save it manually. |
Prinz |
Posted - 18 Nov 2010 : 23:10:03 quote: Originally posted by JDommi Because of too less time today I have only managed a routine to equalize the IDs of backcovers and fanart to the one used in covers. All pics with a wrong ID will be renamed to fit the same correct one.
I don't have time to test today. I look at it tomorrow.
The current correct one would be at the moment 301, because that is the current Movie-ID of Chuck. Any or even none of numbers in the fields can be the correct current one. The reason for the different ID's is the Function:
Wartung der Sammelung -> FilmID Umnummerierung / Lücken in ID-Reihenfolge schließen
These functions only change the Movie-ID but don't change the filenames. And the Filenames-Ids are generated the first time a category is imported. So you see, any or none of ID-numbers from the image-files can be the current correct one. |
JDommi |
Posted - 18 Nov 2010 : 22:49:51 @Prinz Please check the CoverManager_Test.rar Because of too less time today I have only managed a routine to equalize the IDs of backcovers and fanart to the one used in covers. All pics with a wrong ID will be renamed to fit the same correct one. Keeping different IDs will cause much more time to implement... As I didn't have any differences in my IDs I can't tell anything about the speed of the routine. Maybe you can make a backup of your database and check it for me. Thanks a lot in advance! |
JDommi |
Posted - 18 Nov 2010 : 11:18:56 Strange... I only have a maximum of 20 pics per category and they are all shown. I have tested it with the example db with a few added database entries and covers and with my own one. Would be nice if you could send me your db (or an excerpt) and the pics.
*EDIT* Yes, that's the error. I don't read the field of the backcovers and fanarts. I have presumed that they all have the same base name and the same id. I will try to make a change on that. |
Prinz |
Posted - 18 Nov 2010 : 11:14:56 Maybe the reason is that the naming pattern isn't consistent in XMM.
Again the Chuck example:
Cover are named:
46-Chuck_1.jpg ... 46-Chuck_16.jpg
and Fanart are named:
301-Chuck_fanart_1.jpg ... 301-Chuck_fanart_42.jpg
The first number isn't always the same for the same title in all category's and doesn't has to be the Movie-ID. |
Prinz |
Posted - 18 Nov 2010 : 10:57:26 quote: Originally posted by JDommi
1st problem first. Well, there is a bug in XMM itself with picture names: some pictures have a doubled extension, especially in the TV Shows section. That could be the reason for not showing all covers.
Don't think so. The Names for the Chuck TV Show that isn't shown:
301-Chuck_fanart_1.jpg 301-Chuck_fanart_2.jpg 301-Chuck_fanart_3.jpg ... 301-Chuck_fanart_42.jpg
And i looked a bit more. Most other Cover don't work in my normal Database. Only a few titles are correctly shown with all Covers.
I have double extensions only for episode images and that shouldn't matter.
|
JDommi |
Posted - 18 Nov 2010 : 10:47:03 1st problem first. Well, there is a bug in XMM itself with picture names: some pictures have a doubled extension, especially in the TV Shows section. That could be the reason for not showing all covers. About the error message: Seems as if I have forgotten to remove my own hardcoded db path. Haven't thought to remove it as XMM posts the actual db to the plugin. |
Prinz |
Posted - 18 Nov 2010 : 10:19:56 First a all there is another bug in the new Covermanager. Every time i open it it show the following error message:
And the Bug about the Covers: I don't think it has anything to do with the name of the TV Show or Movie. Because the same titles that don't work in my normal Database work in my Test Database.
For Example (TV Show) Chuck doesn't work in my normal Database, but it works in my Test Database. In my normal Database the count of the different Imagetypes isn't correctly shown by the Covermanager. It says: 20/0/0 The correct numbers would be: 17/0/43 |
JDommi |
Posted - 17 Nov 2010 : 22:53:20 Please post the names of these Shows/Movies and the names of the not shown pics. In my database I have tested the first 100 and the last 100 of about 1200 and all (back-)covers and fanarts are shown. Maybe they are no JPEGs? When I have more infos from you I will have a look at that. |
Prinz |
Posted - 17 Nov 2010 : 22:38:38 Hi JDommi,
With my Database the CoverManager only shows Covers, but no Backcovers or Fanart for some TV Shows and Movies. |
JDommi |
Posted - 17 Nov 2010 : 19:32:08 CoverManager_2010_11_17.rar
Release 2.3 inclusive german and english translations changes: speech.ini renamed to speech.lng chosen language will be saved as default.lng (for next start) I made some labels wider to fit further translations
more translations are welcome... as well as any comment so far!!! |
JDommi |
Posted - 16 Nov 2010 : 14:32:57 CoverManager_2010_11_16.rar
Added: - multilingual by adding translation files (default.ini included) just add the new translation to as example francais.ini or deutsch.ini to Language folder default.ini will be loaded automatically on startup
|
JDommi |
Posted - 14 Nov 2010 : 22:35:21 CoverManager_2010_11_15.rar
Changes: All buttons now have a glyph
*edit* - removed bug on spaces in titles (replaced by "-") - added Picture Mask to cover names (same as in XMM's configuration). Please set to proper setting manually (until new release of XMM). |
JDommi |
Posted - 13 Nov 2010 : 20:29:20 New update available on http://mitglied.multimania.de/jkdommi/xmm/ CoverManager_2010_11_13.rar
Changes: added: RemoveAll and RemoveAllButFirst added: reading/writing of jpg comments
|
JDommi |
Posted - 12 Nov 2010 : 11:34:35 Yes, Prinz. For that I didn't have included new categories ;) And yes, the prog is not as fast as the original CoverManager on reading the pics - but therefor it's easier to move covers from one category to another. And it has the functionality to print covers. These were the only reasons to write this plugin.
By that way: really good job on the scripts and the cards! <- Can't be said too much, I think. |
Prinz |
Posted - 12 Nov 2010 : 10:02:34 I personalty won't hack the card. For many reasons:
1. You can't use the internal covermanager 2. You can't import any of the new covertypes without the direct support of XMM and the magic script engine
3. the external covermanager doesn't work for me many times (simply doesn't show any other category as the movie cover on some titles) and is extremely slow on my pc.
4. A Hack would mean, much less chance that Ale will include the new types in XMM
5. I don't like "hacked" databases
So i think a hack would be counterproductive. |